7 ms·

I love Java. I focused on front-end for 10 years. Starting with motools and IE6, jQuery, into React + Redux. I moved on exclusively to backend development afte

by prhn 4y ago

I love Java. I focused on front-end for 10 years. Starting with motools and IE6, jQuery, into React + Redux. I moved on exclusively to backend development after a few years of the latter. You couldn't pay me enough to maintain a highly available/scalable system that wasn't written in a "verbose," strongly typed and compiled language. I'm done with that pain. If you're going to pick Node, I hope you're using TypeScript. Python, no thanks. Refactoring and implementing new features in Java with IntelliJ feels like cheating, in comparison. Even Go, which I actually really like, starts to lose specificity at large scale due to its intentional terseness. I deeply dislike implied interfaces, and the error handling in a large codebase is really noisy (one of Java's main complaints), without much net benefit. There definitely was a learning curve with Java. To the untrained eye it looks very noisy and magical, but once you learn to visually parse it and understand what all the annotations do you can move very quickly with low risk. Your mileage may vary. If you can move fast without breaking things using some other technology, go for it. But I hope you're prepared for success, when 30+ devs are contributing code to your house of cards. You'll want all the natural protections you can get from your choice of stack.

The_Colonel 4y ago
> Refactoring and implementing new features in Java with IntelliJ feels like cheating, in comparison. This shines especially in large monoliths. Refactoring microservice interfaces is hell (which means it's rarely done and they rot), refactoring module interfaces in a Java monolith is a breeze. Very few projects benefit from microservice architecture.
- 5e92cb50239222b 4y ago
  > Very few projects benefit from microservice architecture. I think the pendulum will swing in the other direction, as it usually does. The previous (NoSQL) hype burned out in about ten years, hopefully this one will go out a bit quicker.
  - bb88 4y ago
    I don't know. NoSQL is still going strong and kinda makes sense for unstructured data. I attended a tutorial earlier this year and the DB they wanted to put in was Mongo rather than SQLite say, even though they were storing structured data in it -- which I didn't understand. Also the problem with microservices in my mind is the tooling. Right now microservices are deployed with k8s in docker containers which is still heavyweight for what they're supposed to be. It could be that a language (maybe go) introduces features to allow for tooling to make easier refactoring.
- CuriouslyC 4y ago
  It isn't just refactoring them that is hell. Even testing things can be hell - those unit tests just became integration tests or you're rolling the dice with mocks. If you don't get the result you expect from a service call, the lack of a single call stack you can debug up and down means tons of time wasted jumping around. They're hell for new developers coming on to a project too, since they can't just follow IDE links to trace execution paths, and too few projects implement full REST call request/response type safety for endpoints.
packetlost 4y ago
As someone maintaining a hugely complex system in Python: type hints make it bearable, but not good. A strongly typed, verbose language is an absolute, fucking, *must* for all but the simplest of systems. You can make it work if you're building web services where the type contract is in the web/RPC API (and hopefully strongly enforced), but for basically anything else, use something with a good type system. I cannot stress enough how important it is for scaling complexity. If you must use Python, turn on mypy with the `--strict` flag, and do it early in your project's lifecycle. Do NOT make exceptions or allow for "gradual" typing, it's monumentally more difficult to add typing after the fact than early on. Type hint as much as you can, including tests. Pytest's fixtures can be type hinted both at the `def` and with their results as function args.
- EdwardDiego 4y ago
  We should form a support group. Even though I'm pushing Mypy as hard as possible, there's some notable areas it can't help, like unittest.mock call assertions.
- ReflectedImage 4y ago
  Or you could use Python with microservices that talk over a message queue instead.
  - packetlost 4y ago
    I hope this is satire.
    - ReflectedImage 4y ago
      No, it's one of the fastest ways in software development you can ship software features to the customer. Scripting language, dynamic typing, microservices and a message queue is shockingly effective. There is no way to compete with that if you are using traditional development techniques. It's why we watch videos online on Youtube and not Google videos. The Google developers got beaten up by the much smaller group of Youtube Python developers. To be honest, I find it shocking that the average user on hacker news doesn't know that software development using dynamic typing is considerably faster than software development using static typing.
nicoburns 4y ago
Static types are great, but they can be quite painful in languages like Java that don't support Sum Types/Tagged Unions. I just want to represent "OR" goddammit. It should also be noted that statically typed doesn't necessarily imply verbose. Many statically typed languages support type inference which more or less gives you the best of both worlds.
- 5e92cb50239222b 4y ago
  Java supports sealed classes (which is close enough to sum types at least for the stuff I work on), and pattern matching over them is in preview. https://openjdk.org/jeps/409 https://openjdk.org/jeps/409 https://openjdk.org/jeps/427 https://openjdk.org/jeps/427
  - kaba0 4y ago
    They are literally sum types, with records being the corresponding product types.
- UncleMeat 4y ago
  You can very easily create an Or<T1, T2> class that supports the relevant features.
mradek 4y ago
(just my opinion) I find java mentally exhausting. I have only ever worked with java once, and it was long ago when I just began my career over 6 years ago. Since then I mostly work with typescript and go on backend, and the languages are quite simple and strange code can be understood quickly without having to dive too much into documentation and navigating a million folders/layers of OO abstraction. I've tried getting back into java and each time I just get exhausted looking at the code.
- dandigangi 4y ago
  Similar feelings towards Java. Kotlin has been a refreshing change to read by comparison at my new job. Much less exhausting.
  - kubota 4y ago
    The problem with Kotlin is that Java copies its features pretty quickly. So as time progresses, the benefit gap between the two languages diminishes, and eventually will not justify switching ecosystems. For example, Project Loom is the answer to coroutines. Sealed classes, etc. Up until recently, Kotlin was not a 1st class supported language for Bazel, gRPC, etc.
    - synthc 4y ago
      I'm fine with Java copying features. I'm happy to use Kotlin now while it is ahead, no problem with switching back to Java once it catches up.
      - yukinon 4y ago
        This approach breaks down when thinking about teams in a large organization. Language switches are a big deal.
    - dandigangi 4y ago
      The time for this to happen though is a long cycle though since Java holds such heavy backwards compatibility though right?
super256 4y ago
> Your mileage may vary. Idk, I have written Java EE (and Jakarta EE) projects, and I found everything to be so much worse than e.g. Next.js + TypeScript. It feels like everything is broken in the Java web-dev ecosystem, except spring. I had plenty of struggles with the JPA, where some SQLite JDBC wasn't straight up working or MySQL8 was not supported. This was just to get the project running. Then, JSPs have like 300 different ways and 300 different opinions on how to do stuff. Should you do routing via XML? Should you put your routes in annotations? Or do implicit navigation in the JSPs? Managing sessions is a pain too. Setting up and deploying Java application servers in prod is way too complicated compared to Node, Deno, Python, Ruby, Whatever. > Starting with motools and IE6, jQuery, into React + Redux Anyway, I hope you didn't have to write pure react without any framework on top of it. I mean, the library is fine, and the React patterns mostly stay the same, but React.js is missing a lot. Personally, I wouldn't touch pure react, unless I have to write my own framework on top of it, but that hasn't been the case yet. P.S. I also had to work on JavaFX applications in the past. I used IntelliJ too, and the tooling of JavaFX is broken to the point, where you can't even use place controls in your great FXML. Which just made me think about another thing I dislike: Java's XML fetish. I don't hate the format, but knowing what XML namespace is the correct one is often beyond me. Writing new Java is probably fine, but older Java codebases are the often PITA. :(
- whywhywhydude 4y ago
  XMLs, JSPs, Java EE are relics of the old age. They were built during late 90s and early 2000s. No new projects use them. You can’t say Java is bad because of how things were 20 years ago.
  - stcroixx 4y ago
    Java EE is an evolving spec and includes basic things like JSON processing, REST, JMS, JPA, even the servlet API itself - these things are very popular in greenfield projects. If you're writing a web app, you're using Java EE unless you're writing your own server.
- yCombLinks 4y ago
  All of the things you complained about were out of fashion before the thing you endorsed was even invented. Hardly a fair comparison.
rlawson 4y ago
Yep Java rocks and is well suited for larger projects. If I have a small team and need to move super fast - then I use Django. If it's > 10 devs and is going to be a large project then it's Java all the way.

by prhn 4y ago

The_Colonel 4y ago

> Refactoring and implementing new features in Java with IntelliJ feels like cheating, in comparison. This shines especially in large monoliths. Refactoring microservice interfaces is hell (which means it's rarely done and they rot), refactoring module interfaces in a Java monolith is a breeze. Very few projects benefit from microservice architecture.

5e92cb50239222b 4y ago
> Very few projects benefit from microservice architecture. I think the pendulum will swing in the other direction, as it usually does. The previous (NoSQL) hype burned out in about ten years, hopefully this one will go out a bit quicker.
- bb88 4y ago
  I don't know. NoSQL is still going strong and kinda makes sense for unstructured data. I attended a tutorial earlier this year and the DB they wanted to put in was Mongo rather than SQLite say, even though they were storing structured data in it -- which I didn't understand. Also the problem with microservices in my mind is the tooling. Right now microservices are deployed with k8s in docker containers which is still heavyweight for what they're supposed to be. It could be that a language (maybe go) introduces features to allow for tooling to make easier refactoring.
CuriouslyC 4y ago
It isn't just refactoring them that is hell. Even testing things can be hell - those unit tests just became integration tests or you're rolling the dice with mocks. If you don't get the result you expect from a service call, the lack of a single call stack you can debug up and down means tons of time wasted jumping around. They're hell for new developers coming on to a project too, since they can't just follow IDE links to trace execution paths, and too few projects implement full REST call request/response type safety for endpoints.

packetlost 4y ago

As someone maintaining a hugely complex system in Python: type hints make it bearable, but not good. A strongly typed, verbose language is an absolute, fucking, *must* for all but the simplest of systems. You can make it work if you're building web services where the type contract is in the web/RPC API (and hopefully strongly enforced), but for basically anything else, use something with a good type system. I cannot stress enough how important it is for scaling complexity. If you must use Python, turn on mypy with the `--strict` flag, and do it early in your project's lifecycle. Do NOT make exceptions or allow for "gradual" typing, it's monumentally more difficult to add typing after the fact than early on. Type hint as much as you can, including tests. Pytest's fixtures can be type hinted both at the `def` and with their results as function args.

EdwardDiego 4y ago
We should form a support group. Even though I'm pushing Mypy as hard as possible, there's some notable areas it can't help, like unittest.mock call assertions.
ReflectedImage 4y ago
Or you could use Python with microservices that talk over a message queue instead.
- packetlost 4y ago
  I hope this is satire.
  - ReflectedImage 4y ago
    No, it's one of the fastest ways in software development you can ship software features to the customer. Scripting language, dynamic typing, microservices and a message queue is shockingly effective. There is no way to compete with that if you are using traditional development techniques. It's why we watch videos online on Youtube and not Google videos. The Google developers got beaten up by the much smaller group of Youtube Python developers. To be honest, I find it shocking that the average user on hacker news doesn't know that software development using dynamic typing is considerably faster than software development using static typing.

nicoburns 4y ago

Static types are great, but they can be quite painful in languages like Java that don't support Sum Types/Tagged Unions. I just want to represent "OR" goddammit. It should also be noted that statically typed doesn't necessarily imply verbose. Many statically typed languages support type inference which more or less gives you the best of both worlds.

5e92cb50239222b 4y ago
Java supports sealed classes (which is close enough to sum types at least for the stuff I work on), and pattern matching over them is in preview. https://openjdk.org/jeps/409 https://openjdk.org/jeps/409 https://openjdk.org/jeps/427 https://openjdk.org/jeps/427
- kaba0 4y ago
  They are literally sum types, with records being the corresponding product types.
UncleMeat 4y ago
You can very easily create an Or<T1, T2> class that supports the relevant features.

mradek 4y ago

(just my opinion) I find java mentally exhausting. I have only ever worked with java once, and it was long ago when I just began my career over 6 years ago. Since then I mostly work with typescript and go on backend, and the languages are quite simple and strange code can be understood quickly without having to dive too much into documentation and navigating a million folders/layers of OO abstraction. I've tried getting back into java and each time I just get exhausted looking at the code.

dandigangi 4y ago
Similar feelings towards Java. Kotlin has been a refreshing change to read by comparison at my new job. Much less exhausting.
- kubota 4y ago
  The problem with Kotlin is that Java copies its features pretty quickly. So as time progresses, the benefit gap between the two languages diminishes, and eventually will not justify switching ecosystems. For example, Project Loom is the answer to coroutines. Sealed classes, etc. Up until recently, Kotlin was not a 1st class supported language for Bazel, gRPC, etc.
  - synthc 4y ago
    I'm fine with Java copying features. I'm happy to use Kotlin now while it is ahead, no problem with switching back to Java once it catches up.
    - yukinon 4y ago
      This approach breaks down when thinking about teams in a large organization. Language switches are a big deal.
  - dandigangi 4y ago
    The time for this to happen though is a long cycle though since Java holds such heavy backwards compatibility though right?

super256 4y ago

> Your mileage may vary. Idk, I have written Java EE (and Jakarta EE) projects, and I found everything to be so much worse than e.g. Next.js + TypeScript. It feels like everything is broken in the Java web-dev ecosystem, except spring. I had plenty of struggles with the JPA, where some SQLite JDBC wasn't straight up working or MySQL8 was not supported. This was just to get the project running. Then, JSPs have like 300 different ways and 300 different opinions on how to do stuff. Should you do routing via XML? Should you put your routes in annotations? Or do implicit navigation in the JSPs? Managing sessions is a pain too. Setting up and deploying Java application servers in prod is way too complicated compared to Node, Deno, Python, Ruby, Whatever. > Starting with motools and IE6, jQuery, into React + Redux Anyway, I hope you didn't have to write pure react without any framework on top of it. I mean, the library is fine, and the React patterns mostly stay the same, but React.js is missing a lot. Personally, I wouldn't touch pure react, unless I have to write my own framework on top of it, but that hasn't been the case yet. P.S. I also had to work on JavaFX applications in the past. I used IntelliJ too, and the tooling of JavaFX is broken to the point, where you can't even use place controls in your great FXML. Which just made me think about another thing I dislike: Java's XML fetish. I don't hate the format, but knowing what XML namespace is the correct one is often beyond me. Writing new Java is probably fine, but older Java codebases are the often PITA. :(

whywhywhydude 4y ago
XMLs, JSPs, Java EE are relics of the old age. They were built during late 90s and early 2000s. No new projects use them. You can’t say Java is bad because of how things were 20 years ago.
- stcroixx 4y ago
  Java EE is an evolving spec and includes basic things like JSON processing, REST, JMS, JPA, even the servlet API itself - these things are very popular in greenfield projects. If you're writing a web app, you're using Java EE unless you're writing your own server.
yCombLinks 4y ago
All of the things you complained about were out of fashion before the thing you endorsed was even invented. Hardly a fair comparison.

rlawson 4y ago

Yep Java rocks and is well suited for larger projects. If I have a small team and need to move super fast - then I use Django. If it's > 10 devs and is going to be a large project then it's Java all the way.