4 ms·
That "antiquated" VM is head and shoulders above any other extant runtime in compilation, GC and observability. Not only that, most of the major innovations in
by pron 7y ago
That "antiquated" VM is head and shoulders above any other extant runtime in compilation, GC and observability. Not only that, most of the major innovations in recent years in those areas seem to be happening there. Moving from the JVM to almost anything else -- be it Python, Go, Erlang or Node -- feels like being transported to medieval society. Don't get me wrong, some find it liberating as in, huh, I turns out I can survive without my smartphone, but calling the state-of-the-art technological leader "antiquated" is taking it way too far. If you care about performance, productivity and observability, there really aren't that many alternatives out there, and whatever adequate alternatives there are, they are even more "antiquated." And guess what? It turns out that a great many people care about those things.
- varjag 7y agoIt is state of the art in the same sense that America is the uncontested leader in WWE.
- pron 7y agoIs it? I've looked hard and couldn't find any runtime that isn't more than five years behind OpenJDK(+Graal) in those areas, but maybe I missed something. I'm not saying it's perfect, but there's nothing out there that's better in those areas.
- pjmlp 7y agoJust to add to your point the only alternative that I would consider is .NET, and even then I do acknowledge that it is behind some JIT stuff, given that they have been favoring AOT / and single JIT scenarios. Without Valhahla we will never get a Java variant of Unity, jMonkey Engine is a good as it gets and it has plenty of native code to overcome the areas where the JVM is found lacking.
- Scarbutt 7y agoYou don't need Graal when you have Golang around the corner.
- yrio 7y agoWhat do you think about .NET?
- pron 7y agoIt's probably the closest contender [1], but its non-Windows story is still a handicap, as is Microsoft's habit of making sweeping incompatible changes to their development platforms every 5-6 years. [1]: A different philosophy that gives more control to the user in exchange for explicitness puts it ahead in some areas (structs) and behind in others (compilation quality, GC), but as a runtime engineer it's "technologically" behind (I work on OpenJDK so I'm biased, but I came to work on OpenJDK because that's where most interesting innovation in runtimes happens).
- moron4hire 7y agoMicrosoft doesn't make breaking changes. I have code that has survived three or four of your supposed cycles that still runs completely fine.
- orthoxerox 7y agoMicrosoft did kill off or sunset some parts of the Framework. WCF, WWF, AppDomain, expression trees, dynamic, VB. People who wrote WCF services in VB for a living are probably extremely disappointed.
- mr_custard 7y agoDisappointed? Not at all! I worked with it many years ago. Whilst WCF made some notable improvements over what existed within the ecosystem before it, it was still a sprawling, complex PITA and full of developer friction. Killing it off in this case was definitely the right thing to do :-)
- jbeam 7y agoDo you have anything to support that expression trees are being sunset? I haven't seen anything of the sort, unless you are talking about a deprecated library that has been replaced. But System.Linq.Expressions is still around.
- StreamBright 7y agoI guess this boils down the difference between what I call "l'art pour l'art" software engineering vs production-ready code providing a business functionality. The amount of hello world computing on HN is out of the roof, it seems nobody really cares about software lifetime or just never run into a situation when observability is a must. I think the reason for this that most businesses being ok with software being ridiculously expensive and shitty quality. The few places where software matters use Java/C++ because that works at a massive scale and these languages bring observability to the table that is required to maintain a service.