5 ms·

I know this project may just be for fun, but with WASM targets for all sorts of languages, I'm hoping we get to a future where mixing and matching different lan

I know this project may just be for fun, but with WASM targets for all sorts of languages, I'm hoping we get to a future where mixing and matching different languages for different parts of your program will be seamless. Imagine starting a project in an easy language, then migrating pieces to a faster "bare metal" language as needed in a super piecemeal way. Same with moving pieces to a safer language as the project grows, slowly expanding the boundaries of the safe bits as appropriate.

pjmlp 7y ago
Just like the JVM and CLR I guess. https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_CLI_languages https://en.wikipedia.org/wiki/List_of_CLI_languages https://www.graalvm.org/docs/ https://www.graalvm.org/docs/
- 6gvONxR4sf7o 7y ago
  Same idea, yeah, but hopefully with better common adoption. For various reasons users didn't adopt those (e.g. numpy on JVM would be a ton of effort, especially a decade ago). But the web is an irresistable force, maybe. I'm hopeful (though not necessarily optimistic).
  - pjmlp 7y ago
    But they did, just not with the languages that are loved on HN as "taking over the world". Most people on JVM land, use a mix of Java, Kotlin, Scala, Clojure, Groovy, JRuby. Whereas on CLR land it is C#, F#, VB.NET and C++/CLI (for low level stuff). Naturally those that want to kill Java, or rather not touch Windows, aren't aware of this.
    - tasogare 7y ago
      I know you know this, but I’ll write it for other readers: there is even more languages on CLR if we count the one not supported by MS. Also, C native libraries and thus any language that can target it, can by used as well on Windows, Mac OS and Linux with PInvoke.
      - pjmlp 7y ago
        Hence why I posted a link to the language list on my first comment. :)
    - akiselev 7y ago
      Every single language I've seen that has been 'loved on HN as "taking over the world"' has had C FFI interop, whether it is Node, Rust, Python, Ruby, C#, Java, Haskell, Zig, Crystal, Julia, LUA, etc. Web assembly is the browser C FFI, not some high level platform like Java or .Net. Your examples aren't comparable.
      - pjmlp 7y ago
        Failure to understand what bytecode based execution runtimes is all about it seems. Also failure to understand that C ABI does not exist, rather it is the OS ABI from OS written in C, and that other OS, not written in C, don't have such thing as C ABI across all languages. Examples of such OSes, IBM i, z/OS, Unisys ClearPath, UCSD, Unisys ClearPath, Classic Mac OS, UCSD, Native Oberon, Mesa/Cedar, Windows (plenty of stuff is .NET/COM/UWP nowadays), Android, ChromeOS, Garmin OS, and the Web. So no, it isn't the browser C FFI, all major ones aren't even written in C for the past 20 years.
        akiselev 7y ago
        You have repeatedly missed the point of the discussion because you are hyper-focused on the implementation details that are irrelevant to the end user. I honestly don't know how you jumped from the JVM and CLR to Unisys Clearpath (twice) and Mesa/Cedar except as a red herring. The topic of discussion is Web Assembly which implies a modern browser. The majority of browsers now support Web Assembly and about half the global population has a web browser and access to the internet - and now, access to an actual universal bytecode based execution runtime by nature of being part of the web browser standards instead of an OS feature or framework installation or (god forbid) Oracle TOS. The C FFI part was an analogy. The whole point of Web Assembly is that it can't call out to just any library on the OS.
        pjmlp 7y ago
        Except it can, because WebAssembly has long stop being a browser only story. By the way, JVM on the browser, Flash CrossBridge and PNaCL were there first in what concerns "universal bytecode based execution runtime by nature of being part of the web browser".
    - littlestymaar 7y ago
      I know I haven't worked with Java for the past 6 years (time flies!), but back then none of the 2 companies I worked for used anything else than Java on the JVM. In fact, until Kotlin came I only met one guy working with Scala, and nobody for the other languages. It was in France though,not in the US. But I think your argument holds for CLR, were I've seen the 4 languages you mention being used altogether in the same code base.
- jasode 7y ago
  >Just like the JVM and CLR I guess. (List_of_JVM_languages, List_of_CLI_languages) I don't see JVM & CLR even with the dozens of language choices on top of the virtual machine runtimes as giving you ways to do "bare metal" programming. I guess one could arguably squint and say Java's JNI or C# P/Invoke and "unsafe{}" gets you some "bare metal" capabilities but that's a stretch. I go back to the gp's sentence: "Imagine starting a project in an easy language, then migrating pieces to a faster "bare metal" language as needed in a super piecemeal way." For example, JVM/Java doesn't have value types[1] (yet) and that's required for programmer's control of exact and efficient memory layout for many bare metal domains. It doesn't matter what flavor of JVM language you use because you're ultimately limited by the JVM's capabilities which causes excessive pointers to pointers which is inappropriate for some high-performance code. In C#, some future tech like CoreRT might open up some more "bare metal" programming possibilities but that's not production yet[2]. I remember you couldn't even develop a Windows Explorer right-click menu shell extensions in C# because it was a bad idea to load up 2 different versions of the NET Framework runtimes (until NET 4.0). That's not even that low a level of programming and yet C++ had no such limitation. I use C# as much as I can but I still have to do 50% my projects in C++ because JVM/CLR are not "bare metal" enough. [1] https://en.wikipedia.org/wiki/Criticism_of_Java#Compound_value_types https://en.wikipedia.org/wiki/Criticism_of_Java#Compound_val... [2] https://github.com/dotnet/corert#user-content-net-core-runtime-corert https://github.com/dotnet/corert#user-content-net-core-runti...
  - pjmlp 7y ago
    Since when is WebAssembly bare metal?!? Apparently you missed the Windows 8, 8.1 and 10 train regarding your "bare metal" compilation from C# and VB.NET code. .NET 4.0 was released in 2008 and I have been able to use C++ as .NET language since 2001, so .... In fact one of my first .NET projects, in 2002, was to integrate C++ RPC library into Managed C++, long replaced replaced by C++/CLI with .NET 2.0 release. Going back to Java, IBM, Aicas, PTC, Gemalto will happily sell you Java compilers that generate AOT native code for embedded deployment targets, not to mention what is running on my phone, where 95% of the OS APIs are exposed only via Java and where your beloved C and C++ code needs to use JNI to access them.
alfalfasprout 7y ago
The problem is that inherently a lot of the times when you want to drop down to C/C++, you're doing numerical code that would really benefit from SIMD operations and many of those tend to not be portable (as far as I'm aware, basic SIMD is just in the proposal stage for WASM).
- unrealhoang 7y ago
  Controlling memory layout of your data structures really goes a long way for tight loop performance. SIMD might be just the icing on top of the cake.
Kinrany 7y ago
I wonder if we'll ever get to a future where all code is write-only, immutable, and thrown away after compilation. The choice of the language would become a matter of presenting the compiled code and writing replacements for new code. The runtime and the type system can't be replaced this way though.
- 1f60c 7y ago
  I can't tell if you're joking or not. Why would I delete the source code of every program after writing it?
  - deleted 7y ago
    [deleted]
  - Kinrany 7y ago
    I mean, delete the source, but store an intermediate representation that can be decompiled into any other language for reading. Languages with good type systems and tooling support a workflow where you mostly rely on Intellisense hints and docs, and never read the code itself. That, but taken to its logical conclusion: if you never read the source code, you don't need to store the source code. The missing part is the ability to define algorithms as modifications of existing algorithms.

pjmlp 7y ago

Just like the JVM and CLR I guess. https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_JVM_languages https://en.wikipedia.org/wiki/List_of_CLI_languages https://en.wikipedia.org/wiki/List_of_CLI_languages https://www.graalvm.org/docs/ https://www.graalvm.org/docs/

6gvONxR4sf7o 7y ago
Same idea, yeah, but hopefully with better common adoption. For various reasons users didn't adopt those (e.g. numpy on JVM would be a ton of effort, especially a decade ago). But the web is an irresistable force, maybe. I'm hopeful (though not necessarily optimistic).
- pjmlp 7y ago
  But they did, just not with the languages that are loved on HN as "taking over the world". Most people on JVM land, use a mix of Java, Kotlin, Scala, Clojure, Groovy, JRuby. Whereas on CLR land it is C#, F#, VB.NET and C++/CLI (for low level stuff). Naturally those that want to kill Java, or rather not touch Windows, aren't aware of this.
  - tasogare 7y ago
    I know you know this, but I’ll write it for other readers: there is even more languages on CLR if we count the one not supported by MS. Also, C native libraries and thus any language that can target it, can by used as well on Windows, Mac OS and Linux with PInvoke.
    - pjmlp 7y ago
      Hence why I posted a link to the language list on my first comment. :)
  - akiselev 7y ago
    Every single language I've seen that has been 'loved on HN as "taking over the world"' has had C FFI interop, whether it is Node, Rust, Python, Ruby, C#, Java, Haskell, Zig, Crystal, Julia, LUA, etc. Web assembly is the browser C FFI, not some high level platform like Java or .Net. Your examples aren't comparable.
    - pjmlp 7y ago
      Failure to understand what bytecode based execution runtimes is all about it seems. Also failure to understand that C ABI does not exist, rather it is the OS ABI from OS written in C, and that other OS, not written in C, don't have such thing as C ABI across all languages. Examples of such OSes, IBM i, z/OS, Unisys ClearPath, UCSD, Unisys ClearPath, Classic Mac OS, UCSD, Native Oberon, Mesa/Cedar, Windows (plenty of stuff is .NET/COM/UWP nowadays), Android, ChromeOS, Garmin OS, and the Web. So no, it isn't the browser C FFI, all major ones aren't even written in C for the past 20 years.
      - akiselev 7y ago
        You have repeatedly missed the point of the discussion because you are hyper-focused on the implementation details that are irrelevant to the end user. I honestly don't know how you jumped from the JVM and CLR to Unisys Clearpath (twice) and Mesa/Cedar except as a red herring. The topic of discussion is Web Assembly which implies a modern browser. The majority of browsers now support Web Assembly and about half the global population has a web browser and access to the internet - and now, access to an actual universal bytecode based execution runtime by nature of being part of the web browser standards instead of an OS feature or framework installation or (god forbid) Oracle TOS. The C FFI part was an analogy. The whole point of Web Assembly is that it can't call out to just any library on the OS.
        pjmlp 7y ago
        Except it can, because WebAssembly has long stop being a browser only story. By the way, JVM on the browser, Flash CrossBridge and PNaCL were there first in what concerns "universal bytecode based execution runtime by nature of being part of the web browser".
  - littlestymaar 7y ago
    I know I haven't worked with Java for the past 6 years (time flies!), but back then none of the 2 companies I worked for used anything else than Java on the JVM. In fact, until Kotlin came I only met one guy working with Scala, and nobody for the other languages. It was in France though,not in the US. But I think your argument holds for CLR, were I've seen the 4 languages you mention being used altogether in the same code base.
jasode 7y ago
>Just like the JVM and CLR I guess. (List_of_JVM_languages, List_of_CLI_languages) I don't see JVM & CLR even with the dozens of language choices on top of the virtual machine runtimes as giving you ways to do "bare metal" programming. I guess one could arguably squint and say Java's JNI or C# P/Invoke and "unsafe{}" gets you some "bare metal" capabilities but that's a stretch. I go back to the gp's sentence: "Imagine starting a project in an easy language, then migrating pieces to a faster "bare metal" language as needed in a super piecemeal way." For example, JVM/Java doesn't have value types[1] (yet) and that's required for programmer's control of exact and efficient memory layout for many bare metal domains. It doesn't matter what flavor of JVM language you use because you're ultimately limited by the JVM's capabilities which causes excessive pointers to pointers which is inappropriate for some high-performance code. In C#, some future tech like CoreRT might open up some more "bare metal" programming possibilities but that's not production yet[2]. I remember you couldn't even develop a Windows Explorer right-click menu shell extensions in C# because it was a bad idea to load up 2 different versions of the NET Framework runtimes (until NET 4.0). That's not even that low a level of programming and yet C++ had no such limitation. I use C# as much as I can but I still have to do 50% my projects in C++ because JVM/CLR are not "bare metal" enough. [1] https://en.wikipedia.org/wiki/Criticism_of_Java#Compound_value_types https://en.wikipedia.org/wiki/Criticism_of_Java#Compound_val... [2] https://github.com/dotnet/corert#user-content-net-core-runtime-corert https://github.com/dotnet/corert#user-content-net-core-runti...
- pjmlp 7y ago
  Since when is WebAssembly bare metal?!? Apparently you missed the Windows 8, 8.1 and 10 train regarding your "bare metal" compilation from C# and VB.NET code. .NET 4.0 was released in 2008 and I have been able to use C++ as .NET language since 2001, so .... In fact one of my first .NET projects, in 2002, was to integrate C++ RPC library into Managed C++, long replaced replaced by C++/CLI with .NET 2.0 release. Going back to Java, IBM, Aicas, PTC, Gemalto will happily sell you Java compilers that generate AOT native code for embedded deployment targets, not to mention what is running on my phone, where 95% of the OS APIs are exposed only via Java and where your beloved C and C++ code needs to use JNI to access them.

alfalfasprout 7y ago

The problem is that inherently a lot of the times when you want to drop down to C/C++, you're doing numerical code that would really benefit from SIMD operations and many of those tend to not be portable (as far as I'm aware, basic SIMD is just in the proposal stage for WASM).

unrealhoang 7y ago
Controlling memory layout of your data structures really goes a long way for tight loop performance. SIMD might be just the icing on top of the cake.

Kinrany 7y ago

I wonder if we'll ever get to a future where all code is write-only, immutable, and thrown away after compilation. The choice of the language would become a matter of presenting the compiled code and writing replacements for new code. The runtime and the type system can't be replaced this way though.

1f60c 7y ago
I can't tell if you're joking or not. Why would I delete the source code of every program after writing it?
- deleted 7y ago
  [deleted]
- Kinrany 7y ago
  I mean, delete the source, but store an intermediate representation that can be decompiled into any other language for reading. Languages with good type systems and tooling support a workflow where you mostly rely on Intellisense hints and docs, and never read the code itself. That, but taken to its logical conclusion: if you never read the source code, you don't need to store the source code. The missing part is the ability to define algorithms as modifications of existing algorithms.