Comment by osigurdson
3 months 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.
3 months 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.
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.
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.
> 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.
.NET needs runtime code generation for some of its core features, like generics. Bytecode makes this much easier.
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.