undefined | Better HN

0 pointsKwpolska6mo ago0 comments

C# 1.0 was pretty much Microsoft Java, but since then, C# has evolved into its own, more powerful thing, while Java has stayed much more conservative over the years.

0 comments

osigurdson6mo ago

I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.

KwpolskaOP6mo ago

What’s wrong with bytecode? Using something abstract helps with porting between OSes and architectures. .NET supports compiling to native executables, but only a limited subset of projects is supported, because reflection is not available in native AoT mode.

osigurdson6mo ago

I think cross compilation has gotten a lot better so there is basically no need for it today. Obviously nothing is for free and would be hard for .NET to completely get rid of it at this point but I don't think a greenfield project would take the bytecode approach. Bytecode still makes sense in something like WASM as it is a sandboxed environment but otherwise skip the VM abstraction if you can imo.

kbolino6mo ago

> I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today.

Have you never written a plugin or a mod?

Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features.

As soon as you AOT compile CLR or JVM languages, you lose access to the stable, feature-complete ABI that bytecode provides. Heck, many languages built from the ground up for static compilation like Go and Rust still have dismal ABI stories. The only exception I can think of is Swift, and it didn't come by it easily. AOT also imposes limits on reflection and runtime codegen (often, to the point of totally removing them).

If your software exists only in a walled garden, only gets deployed to infrastructure you 100% control, can't be extended at all, and/or can only be extended by full recompilation, then bytecode may seem useless. But that isn't the whole world of software.

naasking6mo ago

.NET needs runtime code generation for some of its core features, like generics. Bytecode makes this much easier.

osigurdson6mo ago

I agree that .NET uses bytecode and likely cannot practically remove it outside of narrow cases. My argument is, if .NET were a greenfield project, they likely would not use bytecode today.

DarkNova66mo ago

I think this was a fair statement up until a couple years ago, but right now I am lamenting the actual progress in C# and CLR technology.

I think the progress on Java and the JVM has been nothing but impressive. Not only compared to the baseline to where things were 10/15 years ago, but simply how much stuff comes out each year and how well-thought it all is.

Frankly, it's an inspiration for my private and professional projects.

j / k navigate · click thread line to collapse

0 comments

osigurdson6mo ago

I'm not sure it is more powerful but it might be more ergonomic. The strange part about both (today - it made sense 20 years ago) is the whole bytecode thing. That should go away imo.

KwpolskaOP6mo ago

osigurdson6mo ago

kbolino6mo ago

> I think cross compilation has gotten a lot better so there is basically no need for [bytecode] today.

Have you never written a plugin or a mod?

Yes, AOT and cross-compilation are very good nowadays. This only replaces one of bytecode's features.

naasking6mo ago

.NET needs runtime code generation for some of its core features, like generics. Bytecode makes this much easier.

osigurdson6mo ago

I agree that .NET uses bytecode and likely cannot practically remove it outside of narrow cases. My argument is, if .NET were a greenfield project, they likely would not use bytecode today.

DarkNova66mo ago

I think this was a fair statement up until a couple years ago, but right now I am lamenting the actual progress in C# and CLR technology.

Frankly, it's an inspiration for my private and professional projects.

j / k navigate · click thread line to collapse