4 ms·
I'm a stereotypical Java dev even though I've used many other languages in the past. I think the author missed the point on what Java is designed for. It's supp
by throwaway189262 6y ago
I'm a stereotypical Java dev even though I've used many other languages in the past. I think the author missed the point on what Java is designed for. It's supposed to be a friendlier, safer, more general purpose C++ for when you need good but not the absolute best performance. And in this I think its the best thing out there.
The cruft in Java, and hacks like Lombok to reduce it exist in every statically typed language I've used. And if you've worked on a big enough project you'll start to see why dynamic languages like JS and Python are bad choices for enterprise apps.
It's telling that every major dynamic language now has optional typings. Once you get to a certain size the ceremony around access modifier and statically typed objects makes sense.
And the author falls into the common idiom of "the JVM is huge it uses too much ram". Then advocates for dynamically typed languages with even bigger run times that use multiple times more ram. Dynamic languages like Python and JS, as a generality, use 3-10X as much ram as VM languages like Java and C#. They're also equally slower. And the runtime argument makes zero sense. V8 is massive. CPython is massive. Any popular language over time develops a huge runtime.
The author also complains about Spring. Spring isn't Java. There's a ton of Java web frameworks that aren't Spring. No matter how much you like Java you can always find common ground hating on Spring.
Overall the article is a common set of complaints from developers that never used Java or only did a few Spring tutorials, got frustrated at the complexity of the language, and moved on to something else.
Java is one of the fastest popular languages and uses way less ram than many alternatives. And the JVM is a great runtime, not a bloated one. Look at how massive V8 is and the JS standard library is still complete trash compared to Java's. The JVM is possibly the best runtime out there, and a big part of why Java is so popular.
The JVM has great and fast FFI, profiling, metrics, multiple world class GC's, it's rock stable, it optimizes code to within spitting distance of C, it handled projects with hundreds of megs of code with no problem.
- deleted 6y ago[deleted]
- donmcronald 6y agoYeah. Java is pretty solid as a language / platform IMO. I gave up on it when Oracle fumbled the ball with JavaFX, but I agree a lot of the criticisms aren't really issues. The one that gets me is the microservices. I've never really understood it. I can build a Java project with a bunch of small, composable modules and things like refactoring across the entire codebase are trivial. There's no rule saying you can't put your (ex) auth API in a separate module and bundle it independently at build time, right? Or, if you want to use the same module in multiple projects, formalize the versioning and bundle it as a library. I think the thing that drives microservices adoption is that it's easy to start out without any planning or API design. You just yeet some code out, publish the REST "API" via Swagger, and call it a "service". There's no versioning, no clear rules, etc.. All of that becomes tomorrow's problem. Then, since you don't have proper API versioning or anything, you start to end up with things like mono-repos to ensure your "API" changes aren't going to break anyone relying on your "service". Seriously. Microservices in mono-repos. It's like a bad joke.
- throwaway189262 6y agoMicroservices make more sense in dynamically typed languages without a good module system because they turn into spaghetti mess after 20k lines. The worst giant spaghetti projects I've touched were PHP, Perl, and JS. If you can't put boundaries within your app you don't really have a choice but to put them at service level. In Java (and similar) "enterprise" languages you have static typing, access modifiers, a quality module system. It's trivial to split your app into multiple independent units. And the JVM + CLR are designed for giant monstrosities. They use a compact bytecode format, zip their dependencies, and do crazy things like runtime code unloading and in-memory string deduplication. We have Java apps with millions of lines of cruft that run fine on reasonable machines. Totally anecdotal but our worst disasters are dynamically typed stuff like node where the only way to know what the objects being passed around look like is to see them in a debugger. And with JS the "module system" always devolves into webpack concatenating everything into one giant file. It's pretty gross