6 ms·

I’ve basically forgotten about Java. It would never occur to me to start a new project in it. Am I the only one? It feels like I’d reach for python if I want fa

I’ve basically forgotten about Java. It would never occur to me to start a new project in it. Am I the only one? It feels like I’d reach for python if I want fast development and flexibility, Go if I want to handle a bunch of I/O concurrency in a garbage collected way, Swift if I want a nice language that’s compiled and balanced, or Rust if I want performance and safety in a compiled language. Those are just my personal leanings. I know kotlin has made Java more ergonomic, and yet….

mpenet 2y ago
There are plenty of very ergonomic languages on the JVM (for instance clojure). I wouldn’t dismiss the JVM as a whole, it is a marvel of engineering and is evolving quickly nowadays (see loom, panama, leyden, etc…).
pianoben 2y ago
I think it's not just you, but certainly not everyone. Kotlin with Java 21+ is my go-to choice for an I/O-bound service, or really any service. It's just so ergonomic, and with virtual threads the code can be as simple and efficient as Go - while also taking advantage of possibly the best and largest library ecosystem in the world. I'm not knocking Go or Python - if those are your preferred tools, they're more than adequate. Java, however, isn't nearly as irrelevant as you may perceive.
- kaba0 2y ago
  Go is definitely not an ergonomic language.
  - pianoben 2y ago
    I mean, I share your opinion personally but plenty of people find it pleasant to read and write. If it was really a bad language, it wouldn't have the adoption it does.
izacus 2y ago
For posters like you I always wonder: why are you posting? Why did you even click on the article if you dislike Java so much? Is this posturing? Do you feel cool? Why did you come here and bloviate over something as silly as a language choice?
- azinman2 2y ago
  Are you the reason I got downvoted? I was very surprised by that. I’ve spent years writing Java and later Scala, in academia and later production. I’ve always followed to see how the JVM and the language/ecosystem has progressed. And now I don’t use it at all. Is it really that odd to take a temperature on a site filled with other tech folks? I don’t understand why you took it so negatively and use words like bloviate, or attack me as just posturing to look cool (how does one look cool on a geeky Internet forum?). One of the HN tenants is to “converse curiously,” which is exactly my mindset when I wrote my comment. And if you look at the other replies, it seems others took it that way as well with healthy discussion.
  - deleted 2y ago
    [deleted]
  - ivan_gammel 2y ago
    Your comment is generic off-topic that has only Java in common with original post. The way it is written, it gives certain vibes and doesn’t sound like genuine invitation to compare Java with other technologies. If that was your intention, maybe you should write your own post and ask there instead.
  - palata 2y ago
    I don't understand the downvotes, I don't find your post offensive. My guess is that people don't downvote to moderate, but rather to show that they disagree. Which unfortunately kills the discussion a bit. I like Java (but I love Kotlin), and it seems like work on the JVM is more active than ever. I can understand your preferences, but what I observe e.g. with Desktop apps is that people use Javascript and embed a whole browser with it (e.g. ElectronJS). I would always prefer a JVM desktop app. Also with modern UI frameworks (including e.g. Compose), I am really hoping that the JVM will get a boost for Desktop apps.
cyberax 2y ago
> Am I the only one? Probably not. Java had stagnated for quite a while, entirely missing the lightweight threading and/or async/await revolution of the last decade. The JVM ergonomics also just sucks, a lot of apps _still_ have to use -Xmx switches to allocate the RAM, as if we're still using a freaking Macintosh System 6! On the other hand, it's a very mature ecosystem with plenty of established battle-tested libraries.
- azinman2 2y ago
  Omg I forgot about that. So there’s no way to say just grab the memory you need and that’s that?
  - NovaX 2y ago
    That’s in the works, where it adapts from 16mb to terabyte heaps. The current GCs have a max, with lazy allocation and ability to release back to the system periodically, but are not as system aware. 1. https://openjdk.org/jeps/8329758 https://openjdk.org/jeps/8329758 2. https://m.youtube.com/watch?v=wcENUyuzMNM&embeds_referring_euri=https%3A%2F%2Fwww.reddit.com%2F https://m.youtube.com/watch?v=wcENUyuzMNM&embeds_referring_e...
- marginalia_nu 2y ago
  I think your information is outdated. Java has had lightweight threads for several releases now. It also has type pattern matching switches, and a bunch of modern ergonomics. async/await is not really a revolution, so much as a bandaid bringing a modicum of parallelism to certain programming languages that don't have a good threading model. Xmx is mostly a thing if you have very small RAM, or some sort of grievously misconfigured container setup. By default it grow up to 25% of the system RAM, which is a relatively sane default.
  - cyberax 2y ago
    > I think your information is outdated. Java has had lightweight threads for several releases now. Well, yes. It was released as a part of JDK 21 a year ago. So far, the adoption has been spotty. They are also implemented not in the best possible way. > Xmx is mostly a thing if you have very small RAM, or some sort of grievously misconfigured container setup. By default it grow up to 25% of the system RAM, which is a relatively sane default. Other more sane runtimes (like Go) do not even have developers care about the heap sizing. It just works.
dcminter 2y ago
You're not the only one I'm sure, but sounds like you don't need it. Its major strengths are: • Bottomless resource of developers with Java experience • Vast array of existing libraries many of which are enterprise focused • Managing very large codebases with many contributors is straightforward • Standard VM that's very solid (decades of development), reasonably fast, and supported on essentially all platforms. It doesn't have quite the stranglehold (even in Enterprise) that it had in perhaps the early 2000s and it's the archetypical "blub" language, but it's a perfectly reasonable language to choose if you're expecting Enterprise scale and pure performance is less valuable to you than scaling out with large numbers of developers. I like Rust, but it's Java that puts bread on my table.
- sriram_malhar 2y ago
  I fully agree with you about the solidity of the VM. The others I am not so sure about. > Bottomless resources of developers with Java experience. With Java experience, but what fraction have a systems outlook? What fraction have an experience with other languages to ensure that the code they write is simple and understandable and direct? My own experience is that too many come out addled by Enterprise Java idioms, and when you actually write some code in Erlang or Go you realize systems aren't as complicated as they have been made out to be. > Managing very large codebases ... I wonder if this is self-fulfilling. My theory is that these codebases are huge because their designs are enterprisey. The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise.
  - plandis 2y ago
    > With Java experience, but what fraction have a systems outlook? It depends what you mean by systems outlook but JVM based code is pretty common (to the point I’d say ubiquitous) in large distributed systems. In open source it’s much the same. Many of the large Apache projects are in JVM languages, for example. > The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise The indirection in Java does drive me crazy. But dependency injection is a problem to solve in every language and libraries that can do code generation at compile time like Dagger2 make this predictable, debuggable, and fairly easy to reason about on the JVM. Microservices are, in my opinion, more of a business organization solution than one tied to any specific language. If you haven’t read Steve Yegge’s blog post about Amazon vs Google I think it’s good reading on why/when SoA is a good idea.
ivan_gammel 2y ago
In addition to other answers: Java absolutely does have the qualities necessary for startups, so using it for new projects makes sense. 1. Modern frameworks and AI assistance can help ramping up a decent backend in days. Solo tech co-founder needs to know only Java or Kotlin and some frontend stack to build MVP quickly and will spend such amount of time on non-coding tasks where language features will be irrelevant. Swift can be the second language if you go mobile-native. 2. Scaling isn’t the problem you are going to have for quite a while. It is quite likely, that problem of scaling the team will come first and any performance bottlenecks will be noticeable much later. Java is good for large teams. That said, from business perspective, if you want larger talent pool, fast delivery cycles and something that may remain as your core stack in the long term - Java or Kotlin is probably the best choice. If you want fancy tech as a perk to attract certain cohort of developers or you have that rare business case, you can choose Go or Rust. Python is popular in academia and bootcamps, but TBH I struggle to see the business value of it for generic backends.
fulafel 2y ago
It's an interesting parallel development that people are complaining about the bad original language on both JS and JVM platforms and often using other languages (Kotlin, TypeScript, Clojure/ClojureScript, etc). I guess even Swift instead of Objective-C on the Apple side counts here in a way.
- pjmlp 2y ago
  What I find sad in some of the guest languages communities, like Kotlin and Scala ones, is how so many happen to disdain the platform that makes their ecosystem possible in first place. No one is going to rewrite the JVM, even though there are several implementations, all of them are a mix of C, C++, Assembly and Java, zero Kotlin and Scala. Yet as usual there is this little island of Kotlin or Scala ecosystem, with their own replacement of everything, and continuous talks how it is possible that the platform that makes their existence possible hasn't been rewriten into them. Typescript and Clojure folks are traditionally more welcoming of the platform, they rather appreciate the symbiotic relationship with the host, and much more fun to hang around with.
kaba0 2y ago
Flamewar-y reply to a flamewar-y comment: Java is better than Go on every count, and almost all of your cases are 90% done by Java, so it's quite clearly a very good choice for almost everything.
palata 2y ago
Can you easily make a Desktop app in Swift (I guess Python, Go and Rust don't fit your criteria) and distribute it to all platforms? I think anything JVM (be it Java, Kotlin or Scala) would be very good there. A lot better than ElectronJS.

mpenet 2y ago

There are plenty of very ergonomic languages on the JVM (for instance clojure). I wouldn’t dismiss the JVM as a whole, it is a marvel of engineering and is evolving quickly nowadays (see loom, panama, leyden, etc…).

pianoben 2y ago

I think it's not just you, but certainly not everyone. Kotlin with Java 21+ is my go-to choice for an I/O-bound service, or really any service. It's just so ergonomic, and with virtual threads the code can be as simple and efficient as Go - while also taking advantage of possibly the best and largest library ecosystem in the world. I'm not knocking Go or Python - if those are your preferred tools, they're more than adequate. Java, however, isn't nearly as irrelevant as you may perceive.

kaba0 2y ago
Go is definitely not an ergonomic language.
- pianoben 2y ago
  I mean, I share your opinion personally but plenty of people find it pleasant to read and write. If it was really a bad language, it wouldn't have the adoption it does.

izacus 2y ago

For posters like you I always wonder: why are you posting? Why did you even click on the article if you dislike Java so much? Is this posturing? Do you feel cool? Why did you come here and bloviate over something as silly as a language choice?

azinman2 2y ago
Are you the reason I got downvoted? I was very surprised by that. I’ve spent years writing Java and later Scala, in academia and later production. I’ve always followed to see how the JVM and the language/ecosystem has progressed. And now I don’t use it at all. Is it really that odd to take a temperature on a site filled with other tech folks? I don’t understand why you took it so negatively and use words like bloviate, or attack me as just posturing to look cool (how does one look cool on a geeky Internet forum?). One of the HN tenants is to “converse curiously,” which is exactly my mindset when I wrote my comment. And if you look at the other replies, it seems others took it that way as well with healthy discussion.
- deleted 2y ago
  [deleted]
- ivan_gammel 2y ago
  Your comment is generic off-topic that has only Java in common with original post. The way it is written, it gives certain vibes and doesn’t sound like genuine invitation to compare Java with other technologies. If that was your intention, maybe you should write your own post and ask there instead.
- palata 2y ago
  I don't understand the downvotes, I don't find your post offensive. My guess is that people don't downvote to moderate, but rather to show that they disagree. Which unfortunately kills the discussion a bit. I like Java (but I love Kotlin), and it seems like work on the JVM is more active than ever. I can understand your preferences, but what I observe e.g. with Desktop apps is that people use Javascript and embed a whole browser with it (e.g. ElectronJS). I would always prefer a JVM desktop app. Also with modern UI frameworks (including e.g. Compose), I am really hoping that the JVM will get a boost for Desktop apps.

cyberax 2y ago

> Am I the only one? Probably not. Java had stagnated for quite a while, entirely missing the lightweight threading and/or async/await revolution of the last decade. The JVM ergonomics also just sucks, a lot of apps _still_ have to use -Xmx switches to allocate the RAM, as if we're still using a freaking Macintosh System 6! On the other hand, it's a very mature ecosystem with plenty of established battle-tested libraries.

azinman2 2y ago
Omg I forgot about that. So there’s no way to say just grab the memory you need and that’s that?
- NovaX 2y ago
  That’s in the works, where it adapts from 16mb to terabyte heaps. The current GCs have a max, with lazy allocation and ability to release back to the system periodically, but are not as system aware. 1. https://openjdk.org/jeps/8329758 https://openjdk.org/jeps/8329758 2. https://m.youtube.com/watch?v=wcENUyuzMNM&embeds_referring_euri=https%3A%2F%2Fwww.reddit.com%2F https://m.youtube.com/watch?v=wcENUyuzMNM&embeds_referring_e...
marginalia_nu 2y ago
I think your information is outdated. Java has had lightweight threads for several releases now. It also has type pattern matching switches, and a bunch of modern ergonomics. async/await is not really a revolution, so much as a bandaid bringing a modicum of parallelism to certain programming languages that don't have a good threading model. Xmx is mostly a thing if you have very small RAM, or some sort of grievously misconfigured container setup. By default it grow up to 25% of the system RAM, which is a relatively sane default.
- cyberax 2y ago
  > I think your information is outdated. Java has had lightweight threads for several releases now. Well, yes. It was released as a part of JDK 21 a year ago. So far, the adoption has been spotty. They are also implemented not in the best possible way. > Xmx is mostly a thing if you have very small RAM, or some sort of grievously misconfigured container setup. By default it grow up to 25% of the system RAM, which is a relatively sane default. Other more sane runtimes (like Go) do not even have developers care about the heap sizing. It just works.

dcminter 2y ago

You're not the only one I'm sure, but sounds like you don't need it. Its major strengths are: • Bottomless resource of developers with Java experience • Vast array of existing libraries many of which are enterprise focused • Managing very large codebases with many contributors is straightforward • Standard VM that's very solid (decades of development), reasonably fast, and supported on essentially all platforms. It doesn't have quite the stranglehold (even in Enterprise) that it had in perhaps the early 2000s and it's the archetypical "blub" language, but it's a perfectly reasonable language to choose if you're expecting Enterprise scale and pure performance is less valuable to you than scaling out with large numbers of developers. I like Rust, but it's Java that puts bread on my table.

sriram_malhar 2y ago
I fully agree with you about the solidity of the VM. The others I am not so sure about. > Bottomless resources of developers with Java experience. With Java experience, but what fraction have a systems outlook? What fraction have an experience with other languages to ensure that the code they write is simple and understandable and direct? My own experience is that too many come out addled by Enterprise Java idioms, and when you actually write some code in Erlang or Go you realize systems aren't as complicated as they have been made out to be. > Managing very large codebases ... I wonder if this is self-fulfilling. My theory is that these codebases are huge because their designs are enterprisey. The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise.
- plandis 2y ago
  > With Java experience, but what fraction have a systems outlook? It depends what you mean by systems outlook but JVM based code is pretty common (to the point I’d say ubiquitous) in large distributed systems. In open source it’s much the same. Many of the large Apache projects are in JVM languages, for example. > The primary drivers of complexity are indirection: factories, dependency injection, microservices, these are all part of the same malaise The indirection in Java does drive me crazy. But dependency injection is a problem to solve in every language and libraries that can do code generation at compile time like Dagger2 make this predictable, debuggable, and fairly easy to reason about on the JVM. Microservices are, in my opinion, more of a business organization solution than one tied to any specific language. If you haven’t read Steve Yegge’s blog post about Amazon vs Google I think it’s good reading on why/when SoA is a good idea.

ivan_gammel 2y ago

In addition to other answers: Java absolutely does have the qualities necessary for startups, so using it for new projects makes sense. 1. Modern frameworks and AI assistance can help ramping up a decent backend in days. Solo tech co-founder needs to know only Java or Kotlin and some frontend stack to build MVP quickly and will spend such amount of time on non-coding tasks where language features will be irrelevant. Swift can be the second language if you go mobile-native. 2. Scaling isn’t the problem you are going to have for quite a while. It is quite likely, that problem of scaling the team will come first and any performance bottlenecks will be noticeable much later. Java is good for large teams. That said, from business perspective, if you want larger talent pool, fast delivery cycles and something that may remain as your core stack in the long term - Java or Kotlin is probably the best choice. If you want fancy tech as a perk to attract certain cohort of developers or you have that rare business case, you can choose Go or Rust. Python is popular in academia and bootcamps, but TBH I struggle to see the business value of it for generic backends.

fulafel 2y ago

It's an interesting parallel development that people are complaining about the bad original language on both JS and JVM platforms and often using other languages (Kotlin, TypeScript, Clojure/ClojureScript, etc). I guess even Swift instead of Objective-C on the Apple side counts here in a way.

pjmlp 2y ago
What I find sad in some of the guest languages communities, like Kotlin and Scala ones, is how so many happen to disdain the platform that makes their ecosystem possible in first place. No one is going to rewrite the JVM, even though there are several implementations, all of them are a mix of C, C++, Assembly and Java, zero Kotlin and Scala. Yet as usual there is this little island of Kotlin or Scala ecosystem, with their own replacement of everything, and continuous talks how it is possible that the platform that makes their existence possible hasn't been rewriten into them. Typescript and Clojure folks are traditionally more welcoming of the platform, they rather appreciate the symbiotic relationship with the host, and much more fun to hang around with.

kaba0 2y ago

Flamewar-y reply to a flamewar-y comment: Java is better than Go on every count, and almost all of your cases are 90% done by Java, so it's quite clearly a very good choice for almost everything.

palata 2y ago

Can you easily make a Desktop app in Swift (I guess Python, Go and Rust don't fit your criteria) and distribute it to all platforms? I think anything JVM (be it Java, Kotlin or Scala) would be very good there. A lot better than ElectronJS.