231–238 of 238 posts
Earlier quoted context omitted.
UNIX is thoroughly obsolete. Its continued use is from inetia; people rarely need anything but a tiny subset of its capabilities, for which there are more simpler alternatives every day.
are you kidding? do you know how many subsystems that people take for granted are using UNIX? furthermore, how do you get simpler than UNIX? it's not complex..
Earlier quoted context omitted.
Targeting the JVM (or the CLR) requires that your language work nicely in the Java (or C#) memory model. This basically means your language needs to work nicely with stop the world garbage collection. (And yes, I know that modern garbage collectors aren't really stop the world, but the tradeoffs are still there.)
CLR was designed for multi-language since the beginning. Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.
The problem is that the CLR comes with the the C# memory model and garbage collection.
If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection.
That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane.
If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model.
At that point, you might as well target your language to compile natively and use standard libraries in the operating system.
Earlier quoted context omitted.
Signed types and a proper cross language target. There is very little technical difference between the two, esp now that GraalVM has shipped. WASM is now the portable executable standard. https://www.graalvm.org/
So you're saying the JVM wasn't good enough so they had to make a better one? Why does the HN crowd constantly compare WASM with the "obsolete" JVM, when even the creator admits that it is not adequate?
It isn’t that the JVM is bad, it is that it isn’t the universal compilation target that WASM is.
Remember folks getting excited about LLVMIR, Bitcode? WASM is this but with a clean sandbox and minimal tractable semantics.
The JVM is awesome, esp with Graalvm and Truffle. WASM is the next evolutionary step.
Earlier quoted context omitted.
CLR was designed for multi-language since the beginning. Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.
I know that. The problem is that the CLR comes with the the C# memory model and garbage collection. If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection. That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an…
Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it.
And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.
Earlier quoted context omitted.
You're conflating C++/CLI with the MSVC /clr compiler switch. They're distinct. With /clr:pure (which produces CIL only, although it is allowed to use memory-unsafe features like pointers), the entirety of ISO C90 is supported on CLR, with the sole exception of setjmp/longjmp. C++/CLI adds language extensions that allow one to interact with the CLR object model from C++ code. It is only needed if you need to call int…
I'm not conflating anything. And as I said, none of this is sandboxed like WebAssembly so it's hardly a comparison anyway.
Earlier quoted context omitted.
Python, Ruby and Common Lisp were designed for the JVM?
To the extent that their object and memory models match the JVM's, you might say they were. To the extent that they don't, their JVM implementations wind up with warts and inconsistencies. (But this is pedantry, you clearly know what I meant.)
Earlier quoted context omitted.
We could re-implement C as well, but is it sensible if we already have C? If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here. As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely…
Someone correct me if I'm wrong, but don't the JVM and CLR assume they're working with GC'd languages and a number of other things? Making them poor targets for many languages, and AFAIK a WASM runtime is a lot more lightweight than both of them The JVM and CLR seem like they're language platforms first and VMs second
Earlier quoted context omitted.
Someone correct me if I'm wrong, but don't the JVM and CLR assume they're working with GC'd languages and a number of other things? Making them poor targets for many languages, and AFAIK a WASM runtime is a lot more lightweight than both of them The JVM and CLR seem like they're language platforms first and VMs second
"The JVM and CLR seem like they're language platforms first and VMs second" Ding ding ding ding ding. There are lots of extant application VMs out there, but effectively all of them were implemented specifically to be able to run a specific language (Java → JVM, C# → CLR, Perl 6 → Parrot/NQP/whatever, Erlang → EVM/BEAM, etc.). Other languages have been implemented on top of those VMs, but they have to adopt the seman…
Parrot was intended as a more universal VM, and was started before the Perl6 design solidified. So in the end it didn't actually fit that well with Perl6.
NQP is a small subset of Perl6 that is used for bootstrapping Perl6, and provides an isolation layer from the vagaries of the various VMs it targets. It used to target Parrot, and now targets MoarVM, the JVM, and JavaScript. (NQP is an acronym for Not Quite Perl6.)
MoarVM (Metamodel On A Runtime) was built specifically for Perl6, but its design is minimal. Most of the Perl6 specific features are built using Perl6 and NQP.
For example, MoarVM only provides only enough of an object/type system to bootstrap the full object system. That is MoarVM gets taught how Perl6 objects work every time it loads the Perl6 runtime.
MoarVM also has a pluggable optimizer where you write the plugins in a higher level language. It could be any language that compiles down to MoarVM bytecode. The Perl6 ones are written in NQP.
I think this dynamism makes MoarVM an interesting target for other languages.