7 ms·

As an engineer, Java would be one of the languages I would choose for maintaining a large codebase over time. It is far better for that than most other popular

by _skel 4y ago

As an engineer, Java would be one of the languages I would choose for maintaining a large codebase over time. It is far better for that than most other popular languages.

emodendroket 4y ago
Agreed. Even if we buy into the argument that Java is just wordy and slow to work with, once we're doing with long-lived code that needs maintenance, that's less of a concern than code that's hard to decipher, so the trade-off seems like a good one.
- lukeramsden 4y ago
  In my experience (and our experience at TransFICC building middleware for financial trading systems, which is extremely throughput and latency sensitive), Java is the fastest language to work with simply because the tooling support is second to none.
- twblalock 4y ago
  Yep. The wordy nature of Java is just giving you more info to work with when you dive into code you haven't seen before. Java is also a lot less wordy than it used to be, and if you use the right tooling you don't need to actually type everything by hand anyway. What matters most for maintaining large codebases that a lot of people work on is the type system and the tooling. A large ecosystem of good tooling exists for working with Java, and it is empowered by the static type system to do some very impressive things. Some of the .net stuff is probably close to that with Visual Studio and the ecosystem around it. Everything else is pretty far behind, including Python and Ruby and Go. I know people who work on a massive Java codebase that is almost 20 years old and has over 1000 people currently working on it -- and thousands more have passed through that codebase in prior years. It's not a lot of fun. But if it was a Python codebase, it would actually be impossible.
  - civopsec 4y ago
    The type system isn’t impressive. You can find usages and thereby get navigation and refactoring via excellent Java-centric IDEs. But it seems like that’s it(?). On the other hand you have to constantly exercise your code because of lurking NPEs. Although hopefully we can get good annotations through third-party tooling (Facebook’s looks good).
    - emodendroket 4y ago
      That's a lot on its own, and being able to understand the argument and return types solely by signature is a big productivity boost compared to environments where that isn't possible.
    - EdwardDiego 4y ago
      I do like Kotlin's nullable types for that reason alone. At least Java has far better NPE messages now. https://www.baeldung.com/java-14-nullpointerexception https://www.baeldung.com/java-14-nullpointerexception
- cle 4y ago
  I disagree that it's a tradeoff, because those two are orthogonal. Java is often hard to decipher because there are many things that can happen dynamically outside the visible code path that affect execution logic, like annotation processing, classloading, dynamic bytecode manipulation, AOP, dynamic proxies, reflection, etc.
  - emodendroket 4y ago
    Most of those strategies are equally popular in Ruby but without the guardrails that at least make them cumbersome enough to make you think "is this really how I want to approach this?" The pitch for Ruby has always been productivity because it's terser so I'm trying to be charitable here and grant them their greenfield case.
- civopsec 4y ago
  Java can be hard to decipher in its own way. Mostly because of a culture of favoring just-in-case indirections, a propensity towards making deep call stacks as the codebase evolves (maybe because IDEs make that navigation tolerable, although it never makes it easy to see the whole context), and pretty imperative constructs outside of streams and lambdas. But on the whole Java is not bad. I think it’s perfectly OK. I am more afraid of Java culture.
- commandlinefan 4y ago
  > code that's hard to decipher I've worked on a lot of codebases that appeared to be put together by developers who took that as a challenge - IME Java developers LOVE global variables (but they call them "public static" to make themselves forget they're using global variables).
nh23423fefe 4y ago
I never understand java hate. The hate seems isomorphic to: "i hate types and i dont use a real ide"
- habibur 4y ago
  Search for the memo where google employees were saying, "we the developers of google are losing to Youtube, as Youtube engineers use Python and we use Java. And iteration in Java is slower than Python." That's before google purchased youtube. Edit : Python. The point remains the same. Link : https://news.ycombinator.com/item?id=16674628 https://news.ycombinator.com/item?id=16674628
  - twblalock 4y ago
    Rate of iteration changes with the size of the codebase, and not in PHP's favor...
  - StevePerkins 4y ago
    YouTube was based on Python from the very beginning. And since then has migrated more and more pieces to Golang. PHP was never a major component of their stack, if it was ever used at all. Search for the memo where Twitter migrated to the JVM. That one actually did happen.
  - mike_hearn 4y ago
    The link from your linked page states that Google were using C++, not Java. Which is correct. I was there. Writing web servers in C++ is a good idea if your web server is 1% HTML rendering/UI and 99% complex algorithms over large binary data structures i.e. a search engine. It's not so great if your web server is 95% UI.
    - habibur 4y ago
      Found the memo, reads Java. Link : The source : https://twitter.com/TechEmails/status/1433837480449613839/photo/2 https://twitter.com/TechEmails/status/1433837480449613839/ph... Discussed on HN, 2021 https://news.ycombinator.com/item?id=28424339 https://news.ycombinator.com/item?id=28424339
silvestrov 4y ago
refactor tools for Java is just so much better than what you can do in a plain text editor or if the language does not have type annotations.
- garethrowlands 4y ago
  It's the (static) types, not the type annotations that matters in IDEs these days. Even in Java there are (very limited) situations where you can omit the type and the compiler infers it. And the ide handles it just fine. And in, say, Scala, which has more inference, the ide works fine (albeit not as well as Java but that's more down to maturity).
hinkley 4y ago
Large codebases in dynamic languages are the pits. Determining if some bit of code is used and how is a probabilistic exercise. Eventually you learn to give up or YOLO and see what happens.
- twblalock 4y ago
  Everyone always says that's fine if you have tests, but that's never actually true.
  - hinkley 4y ago
    If I write the tests, maybe. Some tests make refactoring even harder. If I couldn't already refactor my own code we're also in pretty bad trouble. If I've written more than 10% of the tests overall, things have already gone badly.
btilly 4y ago
And so we have a chicken and egg problem. Thanks to verbosity, Java creates the very problem that it tries to help with. Did you need to have that many programmers and that much code? Who knows. But once you have it, continuing with Java makes sense.
- twblalock 4y ago
  Verbosity is not a problem. The problem is being able to navigate and understand a large codebase. Terseness and dynamic typing are the enemy of that goal.
  - btilly 4y ago
    Attempts I've seen to quantify it have found that you hit a productivity peak in a team of 5-8 people. Then you need to add processes to avoid n^2 communication overhead. You don't get back to the same productivity until you have a team of 20-25 people. If you've never worked on a small team, the productivity difference from staying small may not sink in. But they are real and large. And companies should not lightly cross that threshold. I agree with you that, on a large team and in a large organization, terseness and dynamic typing are bad. But I don't agree that verbosity is not a problem. It absolutely is. It makes you have to go to large teams sooner.
- invalidname 4y ago
  Modern Java isn't remotely as verbose at scale. The language is very different and the API+3rd party support is so vast you can usually build huge things with very little code.
  - btilly 4y ago
    20 years ago, the rule was that Java took an average of 10x as much code to say the same thing as a scripting language did. In all the time since I keep hearing "modern Java this" and "modern Java that". But every time I venture into some Java, well, my limited experiences haven't fit what I was told about "modern Java". Maybe I just haven't encountered modern Java? As for the API+3rd party support argument, the productivity of third party libraries has been used as an argument for ages. I remember when it was being made about Perl with CPAN. My experience of it has always been that libraries make a great start to the extent you have a common problem. Which is wonderful for demos. But once you're in the weeds, you still have to write lots of code. Maybe there isn't a library for your unique needs. Maybe the standard library has bugs. Maybe you wrote code because there wasn't a library but now there is. No matter how it comes about, you wind up writing code.
grumpyprole 4y ago
If that is because of static types then I might agree with you, however once Spring and other reflection-heavy frameworks are added to the mix then I'm not so sure. Java's biggest problem is not the boilerplate, but the culture of over-engineering.
- brunoborges 4y ago
  Luckily, the culture of over-engineering has shifted significantly thanks to modern approaches for designing Java-based systems. The "Triple Crown" of Java frameworks, namely Spring Boot, Quarkus, and Micronaut, but also with the influence of smaller contenders (Dropwizard, Javalin, SparkJava, and a few others) have helped developers focus on business code rather 'design patterns' because these frameworks have embedded a lot of the "over-engineered" concepts into their 'opinionated' approaches. Developers are no longer thinking too much about layers, and just writing components by following the guidelines and best practices of these frameworks. The final result is pretty similar among all of them, especially for microservices.
  - acdha 4y ago
    I like the sounds of that but I would definitely note that this requires _significant_ technical leadership. If you try to hire Java developers, 95% of the resumes you're going to get are people who learned Spring the bad way and have very little experience shipping efficient or reliable code.
    - bottlerocketj 4y ago
      Can I ask what you mean by learning Spring the bad way? I'm new to the industry and starting a Java role in Jan.
      - acdha 4y ago
        The general problem I’ve seen is complexity and action at a distance - basically many things where anyone trying to figure out how it works or make changes has to understand a lot of code in multiple places. A mundane version of this problem is dependency management: every Spring app I know is constantly patching CVEs, almost always in optional code for features they aren’t even using, and sometimes upgrades are not trivial because you have to push around a lot of framework code. Node is similar but at least the tools are better. None of that is specific to Spring, and I’m sure someone will pop up to say that’s doing it wrong but it’s been 100% of the work I’ve seen from multiple contractor teams so perhaps the way to characterize it is that the community doesn’t have enough culture of pushing back against support burden or complexity.

by _skel 4y ago

As an engineer, Java would be one of the languages I would choose for maintaining a large codebase over time. It is far better for that than most other popular languages.

emodendroket 4y ago

Agreed. Even if we buy into the argument that Java is just wordy and slow to work with, once we're doing with long-lived code that needs maintenance, that's less of a concern than code that's hard to decipher, so the trade-off seems like a good one.

lukeramsden 4y ago
In my experience (and our experience at TransFICC building middleware for financial trading systems, which is extremely throughput and latency sensitive), Java is the fastest language to work with simply because the tooling support is second to none.
twblalock 4y ago
Yep. The wordy nature of Java is just giving you more info to work with when you dive into code you haven't seen before. Java is also a lot less wordy than it used to be, and if you use the right tooling you don't need to actually type everything by hand anyway. What matters most for maintaining large codebases that a lot of people work on is the type system and the tooling. A large ecosystem of good tooling exists for working with Java, and it is empowered by the static type system to do some very impressive things. Some of the .net stuff is probably close to that with Visual Studio and the ecosystem around it. Everything else is pretty far behind, including Python and Ruby and Go. I know people who work on a massive Java codebase that is almost 20 years old and has over 1000 people currently working on it -- and thousands more have passed through that codebase in prior years. It's not a lot of fun. But if it was a Python codebase, it would actually be impossible.
- civopsec 4y ago
  The type system isn’t impressive. You can find usages and thereby get navigation and refactoring via excellent Java-centric IDEs. But it seems like that’s it(?). On the other hand you have to constantly exercise your code because of lurking NPEs. Although hopefully we can get good annotations through third-party tooling (Facebook’s looks good).
  - emodendroket 4y ago
    That's a lot on its own, and being able to understand the argument and return types solely by signature is a big productivity boost compared to environments where that isn't possible.
  - EdwardDiego 4y ago
    I do like Kotlin's nullable types for that reason alone. At least Java has far better NPE messages now. https://www.baeldung.com/java-14-nullpointerexception https://www.baeldung.com/java-14-nullpointerexception
cle 4y ago
I disagree that it's a tradeoff, because those two are orthogonal. Java is often hard to decipher because there are many things that can happen dynamically outside the visible code path that affect execution logic, like annotation processing, classloading, dynamic bytecode manipulation, AOP, dynamic proxies, reflection, etc.
- emodendroket 4y ago
  Most of those strategies are equally popular in Ruby but without the guardrails that at least make them cumbersome enough to make you think "is this really how I want to approach this?" The pitch for Ruby has always been productivity because it's terser so I'm trying to be charitable here and grant them their greenfield case.
civopsec 4y ago
Java can be hard to decipher in its own way. Mostly because of a culture of favoring just-in-case indirections, a propensity towards making deep call stacks as the codebase evolves (maybe because IDEs make that navigation tolerable, although it never makes it easy to see the whole context), and pretty imperative constructs outside of streams and lambdas. But on the whole Java is not bad. I think it’s perfectly OK. I am more afraid of Java culture.
commandlinefan 4y ago
> code that's hard to decipher I've worked on a lot of codebases that appeared to be put together by developers who took that as a challenge - IME Java developers LOVE global variables (but they call them "public static" to make themselves forget they're using global variables).

nh23423fefe 4y ago

I never understand java hate. The hate seems isomorphic to: "i hate types and i dont use a real ide"

habibur 4y ago
Search for the memo where google employees were saying, "we the developers of google are losing to Youtube, as Youtube engineers use Python and we use Java. And iteration in Java is slower than Python." That's before google purchased youtube. Edit : Python. The point remains the same. Link : https://news.ycombinator.com/item?id=16674628 https://news.ycombinator.com/item?id=16674628
- twblalock 4y ago
  Rate of iteration changes with the size of the codebase, and not in PHP's favor...
- StevePerkins 4y ago
  YouTube was based on Python from the very beginning. And since then has migrated more and more pieces to Golang. PHP was never a major component of their stack, if it was ever used at all. Search for the memo where Twitter migrated to the JVM. That one actually did happen.
- mike_hearn 4y ago
  The link from your linked page states that Google were using C++, not Java. Which is correct. I was there. Writing web servers in C++ is a good idea if your web server is 1% HTML rendering/UI and 99% complex algorithms over large binary data structures i.e. a search engine. It's not so great if your web server is 95% UI.
  - habibur 4y ago
    Found the memo, reads Java. Link : The source : https://twitter.com/TechEmails/status/1433837480449613839/photo/2 https://twitter.com/TechEmails/status/1433837480449613839/ph... Discussed on HN, 2021 https://news.ycombinator.com/item?id=28424339 https://news.ycombinator.com/item?id=28424339

silvestrov 4y ago

refactor tools for Java is just so much better than what you can do in a plain text editor or if the language does not have type annotations.

garethrowlands 4y ago
It's the (static) types, not the type annotations that matters in IDEs these days. Even in Java there are (very limited) situations where you can omit the type and the compiler infers it. And the ide handles it just fine. And in, say, Scala, which has more inference, the ide works fine (albeit not as well as Java but that's more down to maturity).

hinkley 4y ago

Large codebases in dynamic languages are the pits. Determining if some bit of code is used and how is a probabilistic exercise. Eventually you learn to give up or YOLO and see what happens.

twblalock 4y ago
Everyone always says that's fine if you have tests, but that's never actually true.
- hinkley 4y ago
  If I write the tests, maybe. Some tests make refactoring even harder. If I couldn't already refactor my own code we're also in pretty bad trouble. If I've written more than 10% of the tests overall, things have already gone badly.

btilly 4y ago

And so we have a chicken and egg problem. Thanks to verbosity, Java creates the very problem that it tries to help with. Did you need to have that many programmers and that much code? Who knows. But once you have it, continuing with Java makes sense.

twblalock 4y ago
Verbosity is not a problem. The problem is being able to navigate and understand a large codebase. Terseness and dynamic typing are the enemy of that goal.
- btilly 4y ago
  Attempts I've seen to quantify it have found that you hit a productivity peak in a team of 5-8 people. Then you need to add processes to avoid n^2 communication overhead. You don't get back to the same productivity until you have a team of 20-25 people. If you've never worked on a small team, the productivity difference from staying small may not sink in. But they are real and large. And companies should not lightly cross that threshold. I agree with you that, on a large team and in a large organization, terseness and dynamic typing are bad. But I don't agree that verbosity is not a problem. It absolutely is. It makes you have to go to large teams sooner.
invalidname 4y ago
Modern Java isn't remotely as verbose at scale. The language is very different and the API+3rd party support is so vast you can usually build huge things with very little code.
- btilly 4y ago
  20 years ago, the rule was that Java took an average of 10x as much code to say the same thing as a scripting language did. In all the time since I keep hearing "modern Java this" and "modern Java that". But every time I venture into some Java, well, my limited experiences haven't fit what I was told about "modern Java". Maybe I just haven't encountered modern Java? As for the API+3rd party support argument, the productivity of third party libraries has been used as an argument for ages. I remember when it was being made about Perl with CPAN. My experience of it has always been that libraries make a great start to the extent you have a common problem. Which is wonderful for demos. But once you're in the weeds, you still have to write lots of code. Maybe there isn't a library for your unique needs. Maybe the standard library has bugs. Maybe you wrote code because there wasn't a library but now there is. No matter how it comes about, you wind up writing code.

grumpyprole 4y ago

If that is because of static types then I might agree with you, however once Spring and other reflection-heavy frameworks are added to the mix then I'm not so sure. Java's biggest problem is not the boilerplate, but the culture of over-engineering.

brunoborges 4y ago
Luckily, the culture of over-engineering has shifted significantly thanks to modern approaches for designing Java-based systems. The "Triple Crown" of Java frameworks, namely Spring Boot, Quarkus, and Micronaut, but also with the influence of smaller contenders (Dropwizard, Javalin, SparkJava, and a few others) have helped developers focus on business code rather 'design patterns' because these frameworks have embedded a lot of the "over-engineered" concepts into their 'opinionated' approaches. Developers are no longer thinking too much about layers, and just writing components by following the guidelines and best practices of these frameworks. The final result is pretty similar among all of them, especially for microservices.
- acdha 4y ago
  I like the sounds of that but I would definitely note that this requires _significant_ technical leadership. If you try to hire Java developers, 95% of the resumes you're going to get are people who learned Spring the bad way and have very little experience shipping efficient or reliable code.
  - bottlerocketj 4y ago
    Can I ask what you mean by learning Spring the bad way? I'm new to the industry and starting a Java role in Jan.
    - acdha 4y ago
      The general problem I’ve seen is complexity and action at a distance - basically many things where anyone trying to figure out how it works or make changes has to understand a lot of code in multiple places. A mundane version of this problem is dependency management: every Spring app I know is constantly patching CVEs, almost always in optional code for features they aren’t even using, and sometimes upgrades are not trivial because you have to push around a lot of framework code. Node is similar but at least the tools are better. None of that is specific to Spring, and I’m sure someone will pop up to say that’s doing it wrong but it’s been 100% of the work I’ve seen from multiple contractor teams so perhaps the way to characterize it is that the community doesn’t have enough culture of pushing back against support burden or complexity.