I’m really excited about this. I think the world needs a really great cross platform byte coded VM that’s not Java for all kinds of reasons, and given that .Net is an evolutionary step beyond Java in so many ways, this is fantastic news in my book.
I guess I’m interested in why the world needs a “great cross platform byte coded VM”. I’m not sure what the big win of byte coded VM’s is these days. Backends don’t really seem to benefit from them at all. Byte coded VMs haven’t taken over desktop apps. And mobile is going even more AOT these days.
In some cases, using a byte code vm lets you do things that are hard to have an os let you (Eg Erlang’s hot code reload) or allow code reuse with legacy code / libraries but provide modern language features (Eg scala/clojure/ jvm target langauge) While is not the most compelling set of reasons, they are still a set of valid niches that tools like this will always be around to fill.
One problem I see in the JVM world is that there is a lot of complexity that exists simply because one or two people might want to compile (or maybe they even lost the source code and just have .jar’s) something from Java 1.0, which is insanity. Someone starting a new project today gets a load of baggage for someone still living in 1997.
Back ends don’t benefit? You’re saying HotSpot ISN’T an incredibly performant VM iplementation? And I think many of us would agree that memory safety is a huge deal in mission critical applications.
You’re saying HotSpot ISN’T an incredibly performant VM iplementation?
I’m saying that it isn’t significantly more performant than non VM implementations. It also adds a huge level of complexity with a fairly small benefit (if any).
And I think many of us would agree that memory safety is a huge deal in mission critical applications.
VMs have little to do with memory safety. Ocaml, Haskell, Rust and (mostly) Go are all natively, AOT, compiled languages that are memory safe.
Maybe now they’ll stop messing around with new fancy features, and actually fix their shitload of bugs that have been plaguing Xamarin for the past X years.
Well there was the ‘little’ problem of monetization before - not trivial when you’re talking about something as foundational as a set of APIs. This should help.
This was bound to happen eventually. It makes sense given .net core becoming more and more important internally at MSFT and Xamarin being a great use case for it.
I for one am excited for a future where .net is a first class citizen on linux (in addition to iOS!).
I’m really excited about this. I think the world needs a really great cross platform byte coded VM that’s not Java for all kinds of reasons, and given that .Net is an evolutionary step beyond Java in so many ways, this is fantastic news in my book.
Why does the world need a great cross platform byte coded VM that’s not Java?
Oracle v. Google aside, even because that would strengthen business competition, and that usually leads to progress on both sides.
I guess I’m interested in why the world needs a “great cross platform byte coded VM”. I’m not sure what the big win of byte coded VM’s is these days. Backends don’t really seem to benefit from them at all. Byte coded VMs haven’t taken over desktop apps. And mobile is going even more AOT these days.
In some cases, using a byte code vm lets you do things that are hard to have an os let you (Eg Erlang’s hot code reload) or allow code reuse with legacy code / libraries but provide modern language features (Eg scala/clojure/ jvm target langauge) While is not the most compelling set of reasons, they are still a set of valid niches that tools like this will always be around to fill.
One problem I see in the JVM world is that there is a lot of complexity that exists simply because one or two people might want to compile (or maybe they even lost the source code and just have .jar’s) something from Java 1.0, which is insanity. Someone starting a new project today gets a load of baggage for someone still living in 1997.
Back ends don’t benefit? You’re saying HotSpot ISN’T an incredibly performant VM iplementation? And I think many of us would agree that memory safety is a huge deal in mission critical applications.
I’m saying that it isn’t significantly more performant than non VM implementations. It also adds a huge level of complexity with a fairly small benefit (if any).
VMs have little to do with memory safety. Ocaml, Haskell, Rust and (mostly) Go are all natively, AOT, compiled languages that are memory safe.
What about WASM?
I don’t see WebAssembly as being in the same category as the JVM or Mono.
Maybe now they’ll stop messing around with new fancy features, and actually fix their shitload of bugs that have been plaguing Xamarin for the past X years.
Well there was the ‘little’ problem of monetization before - not trivial when you’re talking about something as foundational as a set of APIs. This should help.
I don’t really mind their pricing. Sure it’s not cheap, but what bothers me much more is how broken it is.
This was bound to happen eventually. It makes sense given .net core becoming more and more important internally at MSFT and Xamarin being a great use case for it.
I for one am excited for a future where .net is a first class citizen on linux (in addition to iOS!).