1. 35
  1. 9

    As for the .NET CLI, it just never seems to have caught on for realsies much outside of the Microsoft world. I’m really not sure why; it’s a technological improvement to the JVM in basically every way that I am aware of

    According to conversations I’ve had with Rich Hickey (who has written multiple compilers targeting each runtime) the optimizations that the CLI does tend to lean a lot more heavily on having type information available at compile time, whereas the hotspot optimizations in the JVM rely on runtime tracing data, even for languages with static types. Plus the GC implementations available on the JVM are much more efficient. Then on top of that there’s the fact that the very idea that programs could be portable across operating systems is a relatively recent development in CLI-land.

    1. 11

      Unavailability on desired platforms and being publicly dropped by Microsoft before they started porting .NET was definitely a huge factor. ironruby and ironpython were rather visibly discontinued. .NET CLI and .NET in general would have had a huge impact if Microsoft had pushed towards multiplatform earlier.

      1. 2

        Better late than never :P

      2. 4

        Then on top of that there’s the fact that the very idea that programs could be portable across operating systems is a relatively recent development in CLI-land.

        I’m still mad about all the FUD…

        1. 3

          As I understand it, Mono is a reimplementation of C# and .NET. I think the perception of many developers who are not already familiar with C# and .NET is that two runtimes (Microsoft and Mono) creates a lot of added complexity versus just running Java or Python or whatever on all platforms.

          I don’t think that’s completely unreasonable to be honest, in spite of seeing most of my Linux games run quite well with Mono/Unity.

          1. 1

            Mono is great, but it was seen as an effort that Microsoft didn’t quite want for a long time. To be quite frank, I think Microsoft not immediately jumping on the Mono train has not helped them.

            1. 3

              A lot of it was:

              1. .NET developers ignoring a workable Mono for years

              2. The GNU/Linux community spreading FUD (not helped by the FSF promoting dotGNU instead, which was a shitshow from rms appointing someone who used the label to develop PHP groupware), going as far as cancelling people over Mono. This didn’t help the lack of polish on GNU/Linux despite the tight integration with things like GTK.

              3. Now people pay attention to .NET on non-Windows, but I feel the .NET ecosystem might not be moving in a good direction (Core’s long-time dislike of DllMap and seeming desire to reinvent bad solutions like JNI when Mono had workable solutions to real problems, emphasis on performance above other concerns, potential Scala/C++ level featuritis in C#, etc.)

              But this is just my own opinion, of course.

              1. 1

                Ah, that’s what you mean with FUD. Yes, agree on all points.

        2. 3

          To disable wasm in firefox set javascript.options.wasm to false… just sayin’.

          1. 4

            If you’re going to do that, you might as well just disable JavaScript, and that will take care of wasm, too.

            1. 2

              JavaScript is a little different than wasm.

          2. 2

            The inNative WebAssembly Runtime is worth a look too. Complete AoT compilation through LLVM, and minimal runtime weight to make that happen.

            1. 2

              Great post! I appreciate your lower-level focus on embedding wasm in compiled applications, survey of the ecosystem, and thorough examples. I never knew wasm targeted anything other than browsers. As I avoid frontend stuff like the plague—especially web/JS—I never would have looked into any of this myself.

              1. 2

                You can probably compile and run nethack for wasm using WASI, if you work at it a bit and are willing to get your hands dirty with terminal nonsense.

                Probably not. That ‘terminal nonsense’ is more syscalls and ioctls, which wasi doesn’t have.

                1. 2

                  I am really curious if it would be theoretically feasible at some point in future to maybe build a CPU architectured specifically for running WASM - or is WASM in some ways fundamentally a poor choice as a language to optimize a CPU for?

                  1. 1

                    Interesting idea!

                    Considering that there are CPUs for Forth and Java Bytecode (both of which are stack based languages) I think that’s quite feasible.

                    May you should file a patent ;-)

                  2. 2

                    Not fair to say “LLVM is better” than Cranelift. Tradeoffs, as usual! LLVM does very advanced optimizations (which you don’t need all that much when recompiling optimized WASM to native code) but LLVM is slooooow, which is a good reason to use something else in some situations — rustc might eventually use Cranelift for debug mode and Valve is sponsoring a non-LLVM compiler for Radeon GPUs.

                    Also, note that WASI’s “high-level, sandboxed pseudo-OS” is heavily inspired by CloudABI, which did it with native binaries :)