@CobaltVelvet Because you have to work with potentially infinite combinations of workflows, including dumb computers, dumb installations, dumb users and dumb developers.

@CobaltVelvet Overall, if you can have a single VM as a de-facto standard for abstracting technical details, and use languages on top of it which enforce not making dumb mistakes (like Java or Rust), you could get a pretty solid framework for all needs. Try to optimize the virtual machine as much as possible (OpenJVM is getting pretty decent for desktop and mobile, just like it was already great for servers) and then make it easy to work, hard to make mistakes.

@espectalll what part of this cannot be done at least as easily as a rust crate

@CobaltVelvet Portability, multiple language compatibility (FFIs are not *that* great), isolation by default. The JVM offers all of that.

@espectalll portability: never liked the jvm as a portability examples. it's always an awful experience to get the jvm somewhere. but yeah that's just because the jvm in question is badly done.

compatibility: really? java doesn't add much to that, except what is already based on java. i'd rather emulate it than add a layer :/

isolation: how so?

@CobaltVelvet On portability, I don't think "write once, debug everywhere" applies anymore, especially since most compatibility issues came from old libraries (such as Swing) or Windows-specific issues. I wouldn't blame it on the JVM, but I admit I don't know that well its issues.

On compatibility, you should check out Graal (which is why you can now run Rust on the JVM): http://www.oracle.com/technetwork/oracle-labs/program-languages/overview/index.html - it's still WIP, but largely works.

@CobaltVelvet
On isolation, it's much easier to provide it with a VM, since it tries to abstract from the hardware as much as possible. It sandboxes by default and it makes it a lot easier to set permissions, and you can access as easily to tools such as containers as you would with a regular binary. The JVM itself can still be buggy - and while OpenJDK's C code seems pretty reliable, you can also write a JVM in Rust (yes, run Rust in top of a JVM written on Rust - in top of a Rust kernel)

@espectalll but why would you run rust on the jvm

"Performance" -> like rust but slower
"Polyglot" -> i'd tell one to get their shit together. there is *no* good reason to mix all that.
"Interoperability" -> like uhhhh an api

i can't think of *any* use for this that isn't a very convoluted entreprise-grade awful mess that should be avoided at any cost.

@CobaltVelvet Slower performance than native Rust is to be expected - but 1.5x to 2x performance loss is barely noticeable on almost every case, and you gain instead on avoiding bad practices on e.g. shitty corporate environments.

On polyglot, it's really useful for stuff such as scripting support (plugins/extensions) and easily using libraries from one language on the other. You should not randomly mix languages, of course, but that's not something Graal-specific.

@CobaltVelvet And yup, it's mainly for that. Consider those shitty environments are the ones that will use your software the most, and then problems arise.