←back to thread

78 points pjmlp | 1 comments | | HN request time: 0s | source
Show context
epistasis ◴[] No.46189804[source]
The only thing worse than launching the JVM from the command line, with it's looooooooooooong and inexplicable load time, was hitting a web page and having it lock the browser for that amount of load time.

I remember a few decades ago somebody saying the JVM was incredible technology, and as a user and programmer I still have zero clue what the hell they could have been thinking was good about the JVM.

I hear that now, decades into Java, they have figured out how to launch a program without slowing a computer down for 10+ seconds, but I'll be damned if I find out. There are still so many rough edges that they never even bothered to try to fix about launching a .jar with classpath dependencies. What a mess!

replies(9): >>46189847 #>>46189885 #>>46189898 #>>46189998 #>>46190090 #>>46190158 #>>46191314 #>>46191875 #>>46197627 #
another_twist ◴[] No.46189898[source]
I understand the sarcasm but this take is devoid of fact. Modern Java loads fast, Java 21 has pretty good functional programming featurez. The ecosystem churns out language level features at a pace and a budget that would put most large funded startups to shame.

Java is also the workhorse of the big data ecosystem and moves enough money either as product revenue or as transactions than most nations GDP. They didn't figure out startup times for 10+ years, they were busy dealing with Oracle and its messy management. I think it will simply continue to get better given that Java has endured through so many language fads. It has its ways to go but it will end up like SQL - here before we were alive and will be here when most of us are dead.

replies(2): >>46189968 #>>46190089 #
epistasis ◴[] No.46189968[source]
There's zero sarcasm in my comment.

The JVM is quite different from Java language features or Scala language features. I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it. A stack based machine? Why? Not a huge blocker, it's weird, but usable. The poor engineering around the JVM for many use cases? That's a blocker for me, and where are the alternatives in implementation that don't have the atrocious launch performance and interface for specifying class path and jars?

Java may be used a lot, but so is Windows. It's an accident of history, of early adoption and network effects, rather than being inherently good technology. Java, the language, made a very wide and broad swath of programmers productive, just as Windows lets a very wide and broad set of IT people run IT systems, without having to learn as much or know as much as they would need to with, say, Linux. But Java's low-barrier-to-entry is quite distinct from the weaknesses of the JVM...

replies(3): >>46190111 #>>46190215 #>>46190258 #
writebetterc ◴[] No.46190215[source]
> A stack based machine? Why?

The JVM being a stack-machine is probably the least controversial thing about it. Wasm, CPython and Emacs all also have a stack-based bytecode language. The value, of course, comes from having a generic machine that you can then compile down into whatever machine code you want. Having a register machine doesn't seem very useful, as it's completely unnecessary for the front-end compiler to minimize register usage (the backend compiler will do that for you).

Specifying classpath isn't fun, I agree with that. Launch performance isn't good, and is generally a consequence of its high degree of dynamicism and JIT compiler, though of course there are ways around that (Leyden).

> I've written entire programs in JVM bytecode, without a compiler, and I see very little of value in it

I agree, I also see very little value in manually writing JVM bytecode programs. However, compiling into the JVM classfile format? Pretty darn useful.

replies(1): >>46190276 #
1. Skinney ◴[] No.46190276{3}[source]
> Having a register machine doesn't seem very useful...

Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in.

Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).