3 ms·
Then your feelings are wrong. No runtime environment provides anything near the JVM's combination of performance, productivity and observability. It's steam eng
by pron 6y ago
Then your feelings are wrong. No runtime environment provides anything near the JVM's combination of performance, productivity and observability. It's steam engines vs. an electric motor, alright.
Yes, there is a cost in footprint and warmup, but footprint is very often (though not always) the right cost. Of all software resources -- development, maintenance, memory, processing and bandwidth -- it's the cheapest (well, second to storage). By comparison Go is less RAM hungry but it's sluggish and opaque.
- entha_saava 6y agoI guess you work on JVM. But the opinion that Go is sluggish and opaque is purely subjective. For anything but long running server apps, Java's memory consumption makes it feel sluggish, especially on desktop. Also, when are the value types coming?
- pron 6y ago> But the opinion that Go is sluggish and opaque is purely subjective It is not. It's significantly slower than Java and has maybe 5% of its observability tools. Go is technologically more than a decade behind Java in compilation, GC, and observability. I'm not saying it's not good enough for certain things -- sometimes primitive and simple gets the job done, and you might not need a Ferrari to go to the grocery store -- but let's not turn an acceptable compromise into a win. > Java's memory consumption makes it feel sluggish Why? If you don't mind it performing as poorly as Go, you can reduce the heap size and pick a low-latency collector like ZGC, but really Java says, give me the cheapest resource, RAM, and in return you'll get something much better. > especially on desktop Java desktop applications consume less RAM than Electron ones, and IntelliJ is more snappy than Atom (and recently, unfortunately, vscode, too), although there are perfectly valid reasons to prefer Electron. > Also, when are the value types coming? I don't know. Not my area.