JAVA is threaded go down to the OS level and is relatively resource-expensive (RAM and context switching) so don't scale well. If you want to know more visit CETPA INFOTECH PVT LTD
I agree. There is some work to go off heap with Java and supposedly you can get incredibly results. Unfortunately the libraries that seem to help doing this are either proprietary are not very well support or stalled.
Of course I think part of the problem is most people in Java land just don't have the 5m concurrency requirements so it doesn't get the love it probably should.
It's been a while since I've programmed in Java. I wonder how good the concurrency stuff is these days. On a somewhat related note I was talking to a team from a random bay area company on how they switched from Java/Spring to Node and that Node is slower but since it's single threaded they load balance a bunch of servers and in practice it's just as fast when considering the developer productivity.
Compute is really cheap these days, so I wonder how much it's worth it to squeeze every drop of performance out now.
Java would take the cake in almost anything speed measure you mentioned. Golang is the only one comparable in memory throughput and latency. Java with async IO like Vert.X can do higher concurrency than Erlang. As can Go.
IMO Java is the most well rounded language, but I'm not trying to convince you of that.
Also there's nothing with java that stops threads from being restarted. In a modern web framework it's virtually impossible to crash the JVM. You just crash a thread, at most (usually the framework catches the exception and it doesn't even do that). Java is also hot reloadable if you use the right framework.
Your tooling argument doesn't make much sense IMO. You can attach to a Go binary but that's about it. Attaching to a VM or interpreter will tell you almost nothing. I would wager you haven't used a Java profile if you're making these arguments. It's vastly superior to anything but maybe C#
The JVM is a real beast, which makes sense as a good chunk of the whole internet runs on top of it (almost every big corp has plenty of infrastructure running Java), so it had plenty of engineering time poured into it.
Regarding concurrency, I wouldn’t choose existing reactive frameworks and what not for a new system. Java will soon get Project Loom, which will introduce Go-like virtual threads - so that one can write a web server that spawns a new thread for each request as well. Since the Java ecosystem is very purely written almost exclusively in Java itself (no FFI), basically everything will turn automagically non-blocking.
I think Java is a pretty good choice, especially for doing comet or any other problem where performance is required. Today Java's perfomance almost matches the speed of C or C++... I have some time ago played around with using Jetty's continuations and it's pretty impressive (and highly scaleable).
In my next iteration I'll probably try to go with the long polling model and I'll probably explore C and Java.
Web servers' performance benefit from concurrent programming models. Concurrent programming is certainly possible in Java, but Java/JVM is not particularly well suited for it compared to other languages/VMs, e.g. Erlang.
RE Java/JVM just try Clojure for a bit... it's really rather good.
Otherwise, do Go. Really useful for high performance. Channels are easy as pie for concurrency. Web services, command line tools, etc; lovely. Downside is that it's verbose and if you hate loops then there's no salvation for you.
I'm guessing you're the Quasar guy or am I off? Either way, I think you have benchmarked the lightweight thread approaches on JVM's. How much simultaneous concurrency can the JVM methods manage right now for say serving web requests? And how much does Erlang's best do on same machine?
I think that's an interesting and useful comparison point to start with to test your claim. This is also something I figured Java side would greatly improve on.
Why not just use the JVM and concurrency? I routinely parse 300+ GB of geospatial data without breaking a sweat using a very simple combination of concurrent linked queues and cached thread pools. I couldn't imagine diving head long into some new esoteric language just to do something as simple as what this author is describing. And things are only going to get easier with Virtual Threads...If I'm doing something boring (parsing data) I'd just want to use a boring standard language I guess (Java).
Agreed, in fact what's surprising is that anyone thinks it's surprising that the JVM with its billions of man hours and primary usage in mission critical finance/banking/etc is anything but one of the most performant, scalable, robust, well-tooled platforms around.
>Aside from terrific performance, the JVM gives you the best concurrency platform out there (though not the easiest to use)
Though I'd probably still reserve that accolade for Erlang OTP/BEAM.
You never defined what you meant by a "good concurrent GC", only now are you asking for "performance" numbers.
My point is that writing a GC for Java has in fact proved very difficult. It took Sun and Oracle many man years and different GC designs to get where they are today. So it seems Java also needs a "good" concurrent GC. With both functional and OOP languages generating a lot of garbage and sharing language features, I don't see a big difference in requirements in practice. And sure enough, Clojure/Scala seems to work well using the JVM GC and F# seems to work well with the .NET GC too.
I think the burden of proof rests with you and your statement that the concurrent GC situation is somehow more challenging for an FP language.
I've used it a little and haven't had any problems. You can run it on Jetty, so performance is excellent, and you get access to the whole Java ecosystem. Things like Core.async, Pulsar (modeled after Go's coroutines/Erlang's actors) and Software Transactional Memory make parallel/concurrent programming a breeze. The biggest "issue" some people have with it is that it's generally dynamically typed, but if you don't mind that then it's at least as effective as other server side dynamic languages.
>Perhaps, but they're not solved by any of the languages/platforms mentioned.
Go and Elixir do support concurrency/paralellism mechanisms that are not supported very well by the JVM. Go also solves the value type issues that cause the JVMs excessive memory usage. Code/skills sharing between client and server isn't supported by the JVM either (for web apps that is).
>Except that they were the same VMs (HotSpot was a Smalltalk VM)
Yes, but HotSpot is from 1999 whereas Java is came out in 1995 if I remember correctly. The initial Java VM was a bit of a throwback.
>I don't know if the JVM environment is "broken" or not, but it certainly isn't any more broken than any other platform for serious server-side software.
Well, there was a real-time thing bought by Sun from Sweden but I'm still unclear as to how much of that has made it into the open-source part of the JDK. Time will tell!
Joint Parallelism is a term that I invented, it means loosely defined: if two threads can read and write to the same memory at the same time without it causing too much loss... basically you need atomic concurrency which is only really efficient on a complex memory model VM with GC if you want high level language support:
"While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only 12 times faster than C means you haven't started optimizing"." - Martin Fowler https://martinfowler.com/bliki/OOPSLA2005.html
"Many lock-free structures offer atomic-free read paths, notably concurrent containers in garbage collected languages, such as ConcurrentHashMap in Java. Languages without garbage collection have fewer straightforward options, mostly because safe memory reclamation is a hard problem..." - Travis Downs https://travisdowns.github.io/blog/2020/07/06/concurrency-co...
I'm not an expert, I can't explain why these things are true, because I'm trying to make something useful on top of C/Java instead of going too deep.
But what I do know is that my app. server kicks everythings ass to the stone age in terms of performance and ease of use: https://github.com/tinspin/rupy
It's facinating to see humans struggle with the wrong tools, and defending those same tools without even trying the alternatives (I have also worked with perl, PHP and C# so I know why those are bad).
But I'm sure time will flush the bad apples out eventually, specially when electricity prices go up.
reply