I found the argument to be poor. Maybe if Java is the only alternative to Python you’re aware of it sound pleasant but otherwise it sounds like a nightmare. I have Ocaml, a language that is significantly more enjoyable to write than Java, nearly just as fast under many workloads, and a runtime that is orders of magnitude simpler such that I can actually understand it. Why would I use Java over that without getting my arm twisted. On top of that, Java completely sucks for CLI tools (like the one mentioned in this story) where as Ocaml is great for them. For other people, Ocaml fills a similar niche that Go does.
I think story the author really wants to tell, and hinted at it a few times but didn’t finish the thought, is that one should prefer to minimize their technology choices and stray from them only when it is required. So if your codebase is Java, stick to Java for most things unless you have a great reason not to. If it’s in something else, then stick to that. But the lesson is to minimize complexity by minimizing tools. Java itself still sucks and the only reason to continue with it is momentum.
I think the author’s real problem is that he’s making four different points that are actually pretty unrelated, and then mushing them all together.
Minimize your technology choices. This is great advice, as you pointed out. I’m on board. This would be a great article, and is a point more devs I work with need to get.
Static languages are faster than dynamic languages. While we can have a lovely discussion about theoretical limits here, the fact is that, right now, the widely used static languages are faster than the widely used dynamic languages. I don’t honestly think this should be controversial when framed this way.
Java isn’t meaningfully less productive than Python. The author effectively says this, but then proceeds not to make any points about why he’s correct other than some hand-waving that double typing isn’t a big deal and implying that Python programs ought to have comments before every variable explaining what it does. This is at best subjective, and at any rate, the author provides absolutely nothing to back up his assertion.
Java is a good statically typed language. This is patently ridiculous. You mentioned OCaml; I’d also mention C#, F#, Kotlin, Swift, and maybe even Go. All of these are terser, more powerful, and provide comparable speed to Java.
I really wish the author would just go back and remove the extra points. An article focusing entirely on the first would be an excellent thing to send my colleagues.
You mentioned OCaml; I’d also mention C#, F#, Kotlin, Swift, and maybe even Go. All of these are terser, more powerful, and provide comparable speed to Java.
Haskell is speed-competitive with Java, with better concurrency options, and terser than anything mentioned so far.
He says he wants to use Java mostly because it’s fast and efficient compared to python. Which it is. But if that’s his reason then why not pick a language which is actually fast and efficient rather than one which is fast-ish and not very resource efficient at all? He should consider C, C++, Rust or Go. They’re all faster and use much less resources than Java.
I note that he dismisses them out of hand at the end of the article, but really what he means is “I prefer Java”. Not a compelling argument.
The argument here is really:
Java or Python? Use Java because fast.
I found the argument to be poor. Maybe if Java is the only alternative to Python you’re aware of it sound pleasant but otherwise it sounds like a nightmare. I have Ocaml, a language that is significantly more enjoyable to write than Java, nearly just as fast under many workloads, and a runtime that is orders of magnitude simpler such that I can actually understand it. Why would I use Java over that without getting my arm twisted. On top of that, Java completely sucks for CLI tools (like the one mentioned in this story) where as Ocaml is great for them. For other people, Ocaml fills a similar niche that Go does.
I think story the author really wants to tell, and hinted at it a few times but didn’t finish the thought, is that one should prefer to minimize their technology choices and stray from them only when it is required. So if your codebase is Java, stick to Java for most things unless you have a great reason not to. If it’s in something else, then stick to that. But the lesson is to minimize complexity by minimizing tools. Java itself still sucks and the only reason to continue with it is momentum.
I think the author’s real problem is that he’s making four different points that are actually pretty unrelated, and then mushing them all together.
I really wish the author would just go back and remove the extra points. An article focusing entirely on the first would be an excellent thing to send my colleagues.
Haskell is speed-competitive with Java, with better concurrency options, and terser than anything mentioned so far.
And you get best-in-class type inference. :)
He says he wants to use Java mostly because it’s fast and efficient compared to python. Which it is. But if that’s his reason then why not pick a language which is actually fast and efficient rather than one which is fast-ish and not very resource efficient at all? He should consider C, C++, Rust or Go. They’re all faster and use much less resources than Java.
I note that he dismisses them out of hand at the end of the article, but really what he means is “I prefer Java”. Not a compelling argument.
Go isn’t faster than Java, but it’s surprisingly close considering how young the compiler is.
Rust is turning in surprisingly good performance–better than Java mostly too, but… More verbose than Java? Ouch.
Can you elaborate more on Rust being more verbose than Java? I don’t think it is, but I also have pretty intense bias. :)
I was just going by the graph on the Shootout results, which–visually at least–shows Rust with a larger code volume than Java in most of the programs.