Comment by jacquesm
1 day ago
I'd say no, access to a larger pool of programmers is an important ingredient in the decision of what you want to write something in. Netscape pre-dated Java which is why it was written in C/C++ and that is why we have rust in the first place. But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers. For Go the situation is a bit less good but if you really need that extra bit of performance (and you almost never really do) then it might be a good choice.
> But today we do have Java which has all of the rust safety guarantees and then some, is insanely performant for network code and has a massive amount of mindshare and available programmers.
I'm not entirely convinced that Java has much mindshare among system programmers. During my 15 years career in the field I haven't heard "Boy I wish we wrote this <network driver | user-space offload networking application | NIC firmware> in Java" once.
I've seen plenty of networking code in Java, including very large scale video delivery platforms, near real time packet analysis and all kinds of stuff that I would have bet were not even possible in Java. If there is one thing that I'm really impressed by then it is how far Java has come performance wise, from absolutely dog slow to being an insignificant fraction away from low level languages. And I'm not a fan (to put it mildly) so you can take that as 'grudging respect'.
The 'factory factory' era of Java spoiled the language thoroughly for me.
I never said it is due to performance considerations (although developers in a projects like you described tend to always become experts in things like tuning Java GC). It is more like "If we wanted to write this in a shitty verbose OOP language we would just use C++".
While it might be possible to get the performance required for a web rendering engine out of Java, I think you'd miserable writing Java in the style you'd need to get that kind of performance. And you'd likely still end up with issues around memory usage, app bundle size (remember that browsers ship to client devices), GC pauses, and integrating with the JavaScript engine.
Browsers already eat up GBs of ram... I don't want to know how bad it would get written in Java.
> which has all of the rust safety guarantees and then some
That's not really true. Data races are possible in Java.
Data races are possible on some types, specifically `long` when not declared as `volatile` - but these do not directly cause memory unsafety.
Not just some types - any object with members. Shared references are a thing in Java and if not careful can cause data races left and right.
Rust controls that quite a bit.
All the mainstream browsers do their own low-level graphics rendering (e.g., of text and icons and such). Is Java performant enough to do that?
Absolutely. Again, not a fan of the language. But you can transcode 10's of video streams on a single machine into a whole pile of different output resolutions and saturate two NICs while you're at it. Java has been 'fast enough' for almost all purposes for the last 10 years at least if not longer.
The weak point will always be the startup time of the JVM which is why you won't see it be used for short lived processes. But for a long lived process like a browser I see no obstacles.
Are the streams actually transcoded in Java, or is Java just orchestrating FFMpeg (and likely platform accelerators)?
It’s only fast enough if it is as fast or faster than the alternatives. Otherwise it is wasting battery power, making older/cheaper computers feel sluggish and increasingly inefficient.