Earlier quoted context omitted.
I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program…
Java UI and applets have been abandoned long ago (>10 years). This was partly due to webapps becoming the standard, but also the realization that for desktop apps non-native UIs just suck. The vast majority of Java (=running on the JVM) software these days is server-side, without any user interface.
Don’t call it a comeback: Java is still champ
221–230 of 557 posts
Re: Don’t call it a comeback: Java is still champ
#222Earlier quoted context omitted.
No Erlang can't share memory between cores atomically. Erlang can only scale 1-to-1 things like phone calls. Java is the ONLY language that scales many-to-many with stable non-blocking IO and concurrent parallelism that shares memory atomically AND doesn't crash.
And for the fraction of the software projects out there that that actually need this feature as a hard requirement, I'm sure it's wonderful.
Think MMO here, which is the "metaverse" thing they keep talking about.
Simulating 3D reality over the network IS the ONLY thing humans can do now that doesn't HAVE to burn all the energy we got left while giving use a tool to experiment without risk.
So I'm building the final 3D action MMO game engine.
Re: Don’t call it a comeback: Java is still champ
#223Earlier quoted context omitted.
I am not convinced that Java is adequate. I do not know if the problems are related to the Java language or to the typical Java programmers, but Java is the only programming language where I have seen a strong correlation between the programming language used to implement some application and a low quality of that application. During decades of experience with various programs, whenever I was surprised that a program…
Java UI and applets have been abandoned long ago (>10 years). This was partly due to webapps becoming the standard, but also the realization that for desktop apps non-native UIs just suck. The vast majority of Java (=running on the JVM) software these days is server-side, without any user interface.
With Java programs without a Java GUI, I never had problems.
Re: Don’t call it a comeback: Java is still champ
#224Earlier quoted context omitted.
Hit too close with the analogy: Been a Java dev for ten years and I drive a Toyota Corolla.... ...but also in my spare time I play around with Clojure and dream of buying a '69 SS Camaro
Admit it, you never will.
Re: Don’t call it a comeback: Java is still champ
#225I've used Java my entire career and i'm fortunate for it. I appreciate how readable the code is (unlike my experience with Erlang, Haskell, etc), typically i don't have foundational issues in the web framework (once again had some with Haskell). Everything works, if I need to do low latency, there's great libraries and resources, if i need to build a simple internal tool, it can be done effortlessly. I think python i…
You can do better in your own code, but you still have exposure to the code in the library ecosystem.
Worth it, though. It really does seem like there's a Java library for everything.
Re: Don’t call it a comeback: Java is still champ
#226Earlier quoted context omitted.
Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…
All that said, Erlang is a very sharp knife, built for one specific purpose. This is just not true: "a much better concurrency model" If your program is CPU-bound, where real threads are king, then Erlang is a pretty poor solution. Because you cannot have real threads in Erlang, even if you wanted to. Number crunching or string processing are not its forte. Also, most enterprise software does not really benefit from…
The one thing I will say is that, when I say Erlang has a better concurrency model, I mean that it is much easier to write correct concurrent code in Erlang than in Java.
Re: Don’t call it a comeback: Java is still champ
#227Earlier quoted context omitted.
Have you ever had to maintain an old enterprisey Java thing? It's pure hell. Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml…
> Have you ever had to maintain an old enterprisey thing? It's pure hell. FTFY. And yes, I have worked on old Java apps, they are not worse than any other app that lived for a similarly long timeframe (and the fact that there seem to be more old monstrosity in Java may just mean that it actually manages to do its work written in java, and not fail in some other language). Why don’t you have a bin repo for old junit v…
You can't. 'null' represents an empty optional.
Re: Don’t call it a comeback: Java is still champ
#228Re: Don’t call it a comeback: Java is still champ
#229and it still enforces terribly strict OOP patterns onto the developer which is almost never the right way to develop software if you care about performance even a little.
I'm not sure you fully appreciate how tailored the JVM, and hotspot in particular, are to executing OOP oriented code. One great example I can think of is polymorphic methods. In C++ for example, you have to explicitly declare a class method as "virtual" in order for it to be polymorphic - i.e. the version called at runtime is tied to the runtime object instance, not the compile time type. This is because in order to…
Procedural code will always be more efficient with CPU and RAM, arrays will always be faster than Lists, being able to control datatype sizing to the byte will always outperform classes, and so on.
java is very fast, please do not misunderstand me. java is much better than it used to be, as well.
Java is not a language chosen when performance is a concern. Java is chosen when you have a giant pile of developers of various levels of skill and you want to pile a ton of rules and linters on them all so they write software in the same way.
Re: Don’t call it a comeback: Java is still champ
#230Earlier quoted context omitted.
With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be written in Java?
It will take more than green threads to be equivalent to Erlang. Erlang's concurrency model depends upon a completely non-shared memory model, which Java will never have. Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?