It is so tragically funny whatching everyone re-inventing mainframe language environments, JVM application servers and the CLR.
> > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language.
> It is as if a newer generation never bothered to learn about what came before.
I'd be very surprised if you could find a significant number of people who both 1. care about wasm and 2. had never heard of previous VMs that could run multiple languages.
WASM is cool. That doesn't mean that earlier takes on the same idea weren't also cool. It also doesn't mean that nobody is allowed to build a new take on the idea, and you can be 100% sure that the people involved in implementing WASM knew about the CLR and the JVM, and probably even things like the UCSD p-System.
Software engineers are far too keen to disparage new implementations of old ideas, or even new ideas - "it's not novel - it can't do anything a turing machine doesn't do".
Sure, but then don't talk about the "new" stuff as if it was the best invention since sliced bread, without any clue that Egypitans, Babylons, Romans and ancient Greeks were already having it.
All too often they didn’t even know about these systems, at least in my (limited) experience. Not necessarily true here, but it’s not like NIH/reinventing the wheel isn’t common in certain parts of the industry.
AFAIK the most important difference between WASM and other VMs on the level of CLR or JVM is that WASM has a simple linear memory model, which allows languages which expect a linear heap (like C, C++, Rust, ...) to be supported by just adding new backends to existing compilers (and most importantly without requiring changes to the language).
The CLR and JVM might be able to simulate a linear heap through a byte array (just like asm.js did), but it's questionable whether this allows the same performance as WASM when the whole VM instruction set is built around high level object references.
> It'll work just as well as C# or C++ or Visual Basic.
That C++ in there is weird in a 2002 article. Did Microsoft have a C++ compiler in 2002 which supported .NET bytecode output? Up until very recently they had their own incompatible C++ dialect (don't remember what it was called) with new CLR-compatible pointer types. I'm pretty sure that it wasn't possible to just take a vanilla C or C++ library and compile it to the CLR or JVM at least around 2010 when Emscripten was first released (and from there it still was a long way to go to WASM).
Yes, it was called Managed C++, and was later replaced by C++/CLI on .NET 2.0.
Why people always complain about Microsoft language extensions to C and C++, and yet are perferctly fine with GCC C, GCC C++, clang C, clang C++ ?!?
And I am pretty sure to have wrapped a cross-platform C++ RPC framework for .NET in 2002 while using Managed C++, somehow it even ended up in the market for a contact center CRM, go figure.
Maybe one should learn about Microsoft technologies properly instead of just bashing and writing M$.
Not only does MSIL support all the features required for a language like C or C++, mixed mode Assemblies allow to embedded native code, at the expense of being marked unsafe for the verifier. You can force pure MISL, with the side effect that some UB patterns will be considered a compile error instead.
Well nice, really - but as you yourself point out, it's Windows only, and being locked to Windows is not an option. Perhaps if dotnet was open source and multi platform from the beginning, it would've been used instead of developing Wasm etc - but we're way past that.
That's cool, but you can't run standards. I tried Mono since its early days and kept trying until .NET Core came, but it was nowhere near production-ready, it wasn't enough for my school assignments, much less production.
I'm not saying it changes anything. Wasm is just a more modern attempt, like .NET itself. I don't see any reason to prefer one or the other only because of its age.
Well, I wanted to use Linux, not Windows. And my servers ran (and still run) Linux, not Windows. The point wasn't that I couldn't do my school assignments (I was forced to use Windows VM) but that not even this simple task could be accomplished - so running it in production was straight up impossible.
Wasm is much newer than Mono was at the time. Let's wait.
Technically you can always write you own C compiler like this project https://github.com/ForNeVeR/Cesium. Obviosuly C++ is much more complicated journey and require real investment. But at this point this is not CoreCLR limitations mostly.
> > One of the exciting things in Visual Studio .NET is its language agnosticism. If a vendor has written a .NET-compliant language, you can use it in Visual Studio .NET. It'll work just as well as C# or C++ or Visual Basic. This isn't just a future feature-in-planning. There are already nearly two dozen languages being developed for Visual Studio .NET: Visual Basic, C#, C++, JScript, APL, Cobol, Eiffel, Fortran, Pascal, Perl, Python, RPG, Smalltalk, Oberon, Component Pascal, Haskell/Mondrian, Scheme, Mercury, Alice, and even the Java language.
-- February 2002 issue of MSDN Magazine
https://learn.microsoft.com/en-us/archive/msdn-magazine/2002...
It is as if a newer generation never bothered to learn about what came before.