4 ms·

Java and the CLR are not suitable targets for C or C++ compilation. Likewise with Python Bytecode. Using LLVM is exactly what Google tried with PNaCl. It had

Java and the CLR are not suitable targets for C or C++ compilation. Likewise with Python Bytecode. Using LLVM is exactly what Google tried with PNaCl. It had a lot of drawbacks; WebAssembly is a much improved iteration of this idea.

pjmlp 8y ago
Except that was exactly one of the goals of the CLR, hence Managed C++, followed by C++/CLI. Microsoft's original plan for CLR was to replace the complete Windows stack with .NET, they just failed to do, because not only they had to deal with technical issues, there were the internal wars from WinDev making sure that would never happen, hence the Longhorn failure, followed by the same ideas reborned as COM on Vista, rebooted as WinRT/UAP/UWP a couple of years later. Microsoft even had something like LLVM, done on top of the CLR, called Phoenix. It just never came out of MSR into production. https://en.wikipedia.org/wiki/Phoenix_(compiler_framework) https://en.wikipedia.org/wiki/Phoenix_(compiler_framework) https://www.infoq.com/news/2008/05/Phoenix-Compiler-Framework https://www.infoq.com/news/2008/05/Phoenix-Compiler-Framewor... Also, GraalVM will happily consume LLVM bitcode.
- haberman 8y ago
  Managed C++ and C++/CLI are not C++. They will not help you if you have an existing C++ codebase, or if you want to avoid GC.
  - pjmlp 8y ago
    Sure they are, they are Visual C++ language extensions. Standard C++ compiles just fine. There is no different than using language extensions on GCC, clang or any other C++ compilers. You are not forced to use GC beyond the interop to other .NET languages. I have integrated quite a few C++ libraries this way, given that my C++ experience makes it easier than having to deal with P/Invoke attributes and possible linking issues.
    - haberman 8y ago
      My bad, I read about these too quickly. Still, unless you are in the CLI ecosystem, these are not very compelling propositions. WebAssembly is a response to the shortcomings of previous iterations of the universal bytecode idea.
      - repolfx 8y ago
        I think the point people are making is that WebAssembly can't be a response to the prior shortcomings of the CLR/JVM because so many of the things being identified as shortcomings aren't (at least not in the latest versions), and so many basic features that you'd want aren't in WebAssembly. WASM exists mostly for political reasons as far as I can tell: it's something people who work on browsers can "own", vs outsource to other older teams with more historical baggage and different backing corporations. I mean, for WASM to be technically compelling you have to buy the idea that the best way to move the web forward is to enable applets-written-in-C without any useful form of DOM interop or GUI. That seems like a rather implausible claim.
        haberman 8y ago
        Are you suggesting that browsers should just embed a JVM or CLR? Those are huge runtimes that evolved independently of the design constraints of the web. Java Applets were available in browsers 20 years ago and lost to JavaScript. Why would JVM in the browser do any better now?
        repolfx 8y ago
        Lol. Java was absolutely designed for the web. Why do you think the main language of the web is called JavaScript? Java 1.0 came with the HotJava browser and Netscape 3 had a feature called LiveConnect that linked the JVM and the DOM together. As for embedding a JVM, sure, why not? Good JVMs are open source these days and HotSpot starts in 50 msec or less. V8 is very comparable, tech wise in terms of its approach. Lots of code out there targets JVM bytecode.
        8y ago

pjmlp 8y ago

Except that was exactly one of the goals of the CLR, hence Managed C++, followed by C++/CLI. Microsoft's original plan for CLR was to replace the complete Windows stack with .NET, they just failed to do, because not only they had to deal with technical issues, there were the internal wars from WinDev making sure that would never happen, hence the Longhorn failure, followed by the same ideas reborned as COM on Vista, rebooted as WinRT/UAP/UWP a couple of years later. Microsoft even had something like LLVM, done on top of the CLR, called Phoenix. It just never came out of MSR into production. https://en.wikipedia.org/wiki/Phoenix_(compiler_framework) https://en.wikipedia.org/wiki/Phoenix_(compiler_framework) https://www.infoq.com/news/2008/05/Phoenix-Compiler-Framework https://www.infoq.com/news/2008/05/Phoenix-Compiler-Framewor... Also, GraalVM will happily consume LLVM bitcode.

haberman 8y ago
Managed C++ and C++/CLI are not C++. They will not help you if you have an existing C++ codebase, or if you want to avoid GC.
- pjmlp 8y ago
  Sure they are, they are Visual C++ language extensions. Standard C++ compiles just fine. There is no different than using language extensions on GCC, clang or any other C++ compilers. You are not forced to use GC beyond the interop to other .NET languages. I have integrated quite a few C++ libraries this way, given that my C++ experience makes it easier than having to deal with P/Invoke attributes and possible linking issues.
  - haberman 8y ago
    My bad, I read about these too quickly. Still, unless you are in the CLI ecosystem, these are not very compelling propositions. WebAssembly is a response to the shortcomings of previous iterations of the universal bytecode idea.
    - repolfx 8y ago
      I think the point people are making is that WebAssembly can't be a response to the prior shortcomings of the CLR/JVM because so many of the things being identified as shortcomings aren't (at least not in the latest versions), and so many basic features that you'd want aren't in WebAssembly. WASM exists mostly for political reasons as far as I can tell: it's something people who work on browsers can "own", vs outsource to other older teams with more historical baggage and different backing corporations. I mean, for WASM to be technically compelling you have to buy the idea that the best way to move the web forward is to enable applets-written-in-C without any useful form of DOM interop or GUI. That seems like a rather implausible claim.
      - haberman 8y ago
        Are you suggesting that browsers should just embed a JVM or CLR? Those are huge runtimes that evolved independently of the design constraints of the web. Java Applets were available in browsers 20 years ago and lost to JavaScript. Why would JVM in the browser do any better now?
        repolfx 8y ago
        Lol. Java was absolutely designed for the web. Why do you think the main language of the web is called JavaScript? Java 1.0 came with the HotJava browser and Netscape 3 had a feature called LiveConnect that linked the JVM and the DOM together. As for embedding a JVM, sure, why not? Good JVMs are open source these days and HotSpot starts in 50 msec or less. V8 is very comparable, tech wise in terms of its approach. Lots of code out there targets JVM bytecode.
      - 8y ago