Hacker News Reader

Comment by curtis | Hacker News Reader

Crystal reminded me of Mirah [1], a Ruby-like programming language which is statically typed but relies heavily on type inference in order to compile efficiently to JVM bytecode, while retaining the appearance of being a dynamically typed language.

(I've got no real point here other than to say I had a strong feeling of deja vu while reading about Crystal.)

[1] https://en.wikipedia.org/wiki/Mirah_(programming_language)

View on HN

Why are people so interested in running things on the JVM? I'd much rather compile and ship binaries than force someone to install Java (or Ruby or Python).

For one, the JVM is available on multiple platforms. Rather than requiring a project to target each of these platforms individually, they can target a single platform—the JVM.

There are plenty of people who dislike the JVM for any number of reasons (performance often being cited as one) and prefer to target specific platforms individually. Like many other things, it's a tradeoff, and people may arrive at different decisions depending on their priorities.

Modern languages like Crystal target LLVM IR, which if, I'm not mistaken, supports even more platforms than the JVM.

But it would need to be recompiled right?

Correct. But due to the separation of the front-end and back-end, the language developer doesn't have to do extra work to support different architectures.

There's a lot of existing tooling around the JVM: debugging, diagnostics, profiling, performance tuning, deployment, security, enterprise-y concerns... It also boasts perhaps the most advanced VM implementation of its kind—hard to beat the number of collective person-hours invested in it over its long lifespan.

You can ship native binaries with Java, it is only a matter of getting the right toolchain for it.

Java is not only OpenJDK.

Jars are also just zip files, so you can prepend a shell script without impacting the ability for Java/zip to decompress. Add a shell script to run Java on its self and you have a executable (though not a true native elf/mach binary).

It’s not much worse than a standard dynamically linked binary at that point. You just need a JVM on the system. Combined with the AOT compiler (as it stabilizes) makes Java applications more competitive with standard binaries.

The sbt module I'm using for creating JARs (sbt-assembly) has this feature and I really like how seamless it makes creating executable JARs. I used it in a couple cases to create artifacts/executables for research projects that can be easily run and without many dependencies, usually just a recent enough JVM.

The JVM is a fairly nice platform overall if somewhat heavy (though with modules in JDK9 you can ship an executable package competitive in size to a Go binary).

All that aside, performance is great and has a massive ecosystem of mature libraries.

I’m not saying it’s always appropriate, but it’s not a bad platform.

With JVM you get a couple nice features: a good garbage collector, a JIT compiler[1], platform independence, access to a lot of libraries through Java interop.

The requirement for a JVM to be installed on a system isn't that dramatic in my opinion, it may change for others' use cases though (e.g. if you are shipping code to embedded systems etc., it's not a good option probably). Also, if you are OK with heavy app sizes, you can ship with OpenJDK although I acknowledge that it is as bad taste as shipping with electron.

[1]: JIT compilers can help with performance even for pretty static languages (e.g. Java is not so much dynamic than C++) because you have runtime statistics for that specific run and you can speculate using that. Although, with smarter branch predictors etc. in CPUs, some of the benefits of the JITs are slowly disappearing.

Reply on news.ycombinator.com