6 ms·
> hey both come with baggage (JVM). I'm always surprised to hear people say this, when my perspective on the JVM is that it's a modern technical marvel several
by RhodesianHunter 3y ago
> hey both come with baggage (JVM).
I'm always surprised to hear people say this, when my perspective on the JVM is that it's a modern technical marvel several decades in the making with advantages like several unparalleled GCs and an ecosystem with extensive off-the-shelf & highly performant code available for any domain.
- fnfjfk 3y agoI don’t work on server code, and I think a lot of discussions are really focused on server-side work. I have done desktop, mobile, and developer tools (CLIs and “scripts”). If I was working on a server thing Kotlin would seem really good. In my work it is obviously applicable to Android, but not so much elsewhere. I think Rust is nearly perfect for developer CLIs, you don’t really need to deal with the thorny memory and lifetime stuff because most things are allocated on the stack and the entire program is synchronous. clap is very good. Performance, especially startup performance, is incredible.
- square_usual 3y agoYou can use GraalVM Native Image and Kotlin/Native to compile Kotlin to a binary executable, which is fairly fast to start up but does not have all of the high-performance JVM features.
- throwaway894345 3y agoJVM is a marvel at making OOP code merely 10% or 50% slower than C, but I find procedural/data-oriented programming to be quite a lot clearer, faster, and more predictable (with respect to performance) and I don't need nor a huge runtime nor an expert to tune it nor a complicated toolchain to bundle it in with my application (or otherwise ensure that the properly tuned runtime is installed on my target).
- hedora 3y agoTo get it to that level of performance, you need to have expert java programmers, and the result will be hard to maintain. For instance, you can’t use String on hot paths. Also, NPEs can happen almost anywhere, and the compiler doesn’t enforce thread safely (by which I mean “statically checked to be data race free”) Also, the 10-50% slower rule of thumb only applies to throughput. Tail latency is generally much worse than that.
- RhodesianHunter 3y agoIt depends on what you're doing. In C you're going to be hampered by, again, the ecosystem. There is nothing comparable in C as performant as all of the streaming tooling built up around Kafka for example. So your can benchmark percentages all you want, but there are a lot of things you just can't do in C that you can on the JVM (without 100 developers and three years)
- morelisp 3y ago> There is nothing comparable in C as performant as all of the streaming tooling built up around Kafka for example. This is an ill-chosen example. librdkafka is as or more performant than the Java stuff. As a server, Redpanda blows Kafka out of the water (but this is rarely any bottleneck with brokers).
- RhodesianHunter 3y agoYes, if you take the time to hand roll a replacement like Redpanda did it will be faster (though to your point that seems fairly pointless given the constraints imposed by IO) I was referring more to the general ecosystem of Flink/Spark/KStreams/KTable etc.
- agallego 3y agothis seems truthy but isn't in practice. a lot of work, my perf optimization team @ redpanda does (yes we have a full team chasing tail latencies) is spent on CPU optimization, debouncing, amortizing costs, metadata lookups, hash tables, profilers, etc. so there is a lot of additional work after the IO layer which a decent async eventing thing can get you to get good perf.
- c_crank 3y agoYou can write procedural/data-oriented code in Java.
- morelisp 3y agoAs long as you hire C/C++/Rust programmers to write it.
- throwaway894345 3y agoSort of (Java still doesn't have value types), and even then you still have most of the cons of a big runtime.
- za3faran 3y agoAlways funny to see OOP being thrown around like it's some sort of bogeyman. C++ is OOP, so is Rust (minus inheritance), yet both are as fast or faster than C.
- soulbadguy 3y agoAs compared to what... JVM is neither particularly advance nor particularly performant. Can't quite comment on the GCs though
- jacquesm 3y ago> JVM is neither particularly advance nor particularly performant I'm not exactly a fan of Java, to put it mildly, but it is pretty efficient these days. To the point that it sometimes amazes me.
- soulbadguy 3y agoI don't want to sound like i am downplaying you understanding of the JVM. But i still have to ask : efficient as compare to what ? From having played around the JVM, and spent quite a bite of time optimizer large spark workload , from the limited Monomorphization, to memory and cache inefficient object model, to the limited inlining depth, absence of code compaction ( for i-cache performance), the poor registor allocator etc... the JVM is really not up there. I think it only shines when compare to things like go/python/javascript that the JVM can appear to be great.
- pjmlp 3y agoCompared to doing distributed systems in DCOM/CORBA using C and C++ for example, that is one of the reasons it took off. Many that like to bash Java EE, have no clue how bad it was before it came to be, it wasn't only Sun's marketing pushing it. It isn't by accident that RMI had interoperability with CORBA.
- soulbadguy 3y agoI am not sure how this is an answer the my argument. However saying that distributed system in JAVA EE are more performant that in C++ ( i am no familliar with DCOM/CORBA but i do know other libraries and system ) is news to me. And again, the success of JAVA in the 90 and 00 can also be explained by better tooling, safer language,better x-platform stories,better libraries etc... etc... Saying that java/jvm are not particularly performant is not bashing ... java/jvm have other great things going on... performance just isnt one of them
- imtringued 3y agoJVM memory consumption is prohibitive for small applications and overall the JVM is very memory inefficient. If you can, avoid Java for anything that isn't a long running server process
- RhodesianHunter 3y agoHave your worked with the JVM since Java 8? Is memory util on servers still really a consideration in 2023 for most workloads if performance is otherwise good? > If you can, avoid Java for anything that isn't a long running server process Isn't that the JVM's niche?
- chriskrycho 3y agoMemory utilization on servers is absolutely a consideration in 2023. At work, we're looking seriously at migrating some key parts of our infrastructure from Java to Rust precisely because of factor (as well as startup time, throughput).
- RhodesianHunter 3y agoAs someone working on systems that handle trillions of message per day in Java, I find this hard to relate to. Is it bad code? Some critical infrastructure flaw? Misunderstanding of memory options settings or how they work in containers? Startup time is definitely a concern. Good luck on the throughput front though. Java libs (like Netty) still outpace what's available in Rust. You may end up with your own code being more performant, but the things you rely on externally being slower. This was our experience when trialing re-writes in Rust.
- za3faran 3y agoIt's probably RDD (resume driven development). It's always fun to rewrite in the latest new hype, and I don't have anything against Rust - I think it's great in the domains it is targeting.
- 3y ago
- morelisp 3y agoI don't want several GCs, though.
- RhodesianHunter 3y agoYeah, I've always derided the having of options as well. I find it best when you cannot toggle between various options to find the best set of tradeoffs for your use case.
- morelisp 3y agoYes, for example, it's much better when the language completely takes away your ability to specify memory layouts or allocation patterns because it will never pick stupid ones.