Thus, many sub-optimal project coordination approaches ended up fighting the design patterns. Java is a good student language, but there are so many better options now... with fewer footguns, and without Oracles farts. =3
Pulling the oracle card when java is mentioned is a useless stunt.
Do you actually use that option at enterprise scale? =3
It’s much better than ideal.
As much as I love hating Oracle, they pushed the language forward much more than Sun ever did.
The only reason Java is still somewhat relevant is ironically Android/Kotlin, and SAP/heinous-dual-stack-blobs product lines.
Best regards, =3
>high--frequency trading systems
Probably not the Java stack itself, given GC latency and precision timing skew would translate into millions of lost dollars a second. However, people do silly things in the wrong languages all the time. =3
It did look weird, of course, but they're also using Go (which iiuc has worse GC latency) or other garbage-collected languages (OCaml being a famous example).
I guess it is like using a Fiat Coupe as a gravel dump-truck. lol =3
Tend to deprecate Java services for a number of other reasons =3
Java/JVM is literally everywhere. And let me get this clear: not a fan of both java-the-language and java-the-culture.
Most Enterprise level Java I saw was not clean OOP, but rather a heinous kludge sitting next to a half-baked design pattern. The 3.6B Android OS users in the world probably are more relevant in terms of development projects, and keeping your team staffed. Good luck =3
Besides, what is "clean OOP" even?
Thus, people that actually leveraged the OO paradigm properly, and in a way that may be sustainably regression-tested/maintained over many continuous integration cycles. That kind of "clean" code tree usually only needs juniors to study around <5 files to understand even the most complex modules operation, helps mitigate bugs, and team-leads can weed out quality "issues" in minutes.
People that churn teams usually discover a YOLO and OO paradigm are fundamentally incompatible concepts. People won't know everything they need in the first release, and they will have stuff they don't need but now have to live with by the third release.
This is not a Java specific problem... but it does make it easy.
Nothing integration "teams" do will likely matter much compared to a 3.6B user-base policy change. Have a great day =3
"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )
Depends on the use-case, but I also like Elixir/Erlang, Julia, and Go.
Not all are very popular, yet each offer something uniquely beautiful. =3
(One might argue Go comes close, though)
Javas selling point is that it can do everything reasonably well and has a huge talent pool.