zlacker

[parent] [thread] 11 comments
1. pylotl+(OP)[view] [source] 2025-12-03 08:27:29
Why didn't you choose something more modern/sensible. go/kotlin/anything else on the planet?
replies(3): >>gf000+1h >>throwa+RZ >>krzyk+g71
2. gf000+1h[view] [source] 2025-12-03 10:23:34
>>pylotl+(OP)
Go is more verbose than Java though, in what way would it be more sensible?

Also, Java's ecosystem is unparalleled (top 3 in size, depending on domain it usually has the best packages (e.g. typical backend-related functionality)), has stellar performance, a huge developer base, best-in-class IDE support, even LLMs understand it exceptionally well (given how widely represented it is in the training corpus, plus has a decent type system) if that's your thing.

For a typical backend system, you really have to have a good reason to choose something else at this point.

replies(2): >>codr7+xY >>zeroc8+cx3
◧◩
3. codr7+xY[view] [source] [discussion] 2025-12-03 15:17:00
>>gf000+1h
Except for Kotlin, which is a much nicer language to deal with.
replies(2): >>throwa+601 >>lenkit+hA1
4. throwa+RZ[view] [source] 2025-12-03 15:24:31
>>pylotl+(OP)
While kotlin is somewhat nicer, it is not making a huge difference compared to java25. Like the sibling said, go is as verbose , the JVM is unparalleled still.

Why wouldn't I choose java

replies(1): >>BobbyJ+WV1
◧◩◪
5. throwa+601[view] [source] [discussion] 2025-12-03 15:25:19
>>codr7+xY
Little nicer for sure
6. krzyk+g71[view] [source] 2025-12-03 15:58:27
>>pylotl+(OP)
Kotlin sensible? It plays catchup game with newest JDKs.
◧◩◪
7. lenkit+hA1[view] [source] [discussion] 2025-12-03 18:05:32
>>codr7+xY
A nicer language which is much slower to compile compared to Java.
◧◩
8. BobbyJ+WV1[view] [source] [discussion] 2025-12-03 19:51:28
>>throwa+RZ
Golang has a way smaller memory footprint on average.

I left a place using Java to run edge apps and the footprint was a major issue.

◧◩
9. zeroc8+cx3[view] [source] [discussion] 2025-12-04 08:53:16
>>gf000+1h
Java is ok for typical backend stuff, but Go doesn't hide things the way Java does. With Go, you actually learn what's going on, while with Java, you just learn your way around the various frameworks. As a programmer, I don't want that That said, my current company uses Spring Boot. It does its job, but it wouldn't be my top choice.
replies(1): >>throwa+sV4
◧◩◪
10. throwa+sV4[view] [source] [discussion] 2025-12-04 17:58:40
>>zeroc8+cx3
It is the programmer's job to learn what is going on. Java itself doesn't hide anything from you. You are free to write a servlet from scratch, or use a framework like Spring to hide everything. Your (company's) choice really.

People end up choosing something that has batteries included so they can focus on solving business problems. A programmer who will superficially understand SpringBoot without understanding how it works. Really, there is no magic there - its a few core concepts - annotations, bytecode enhancement and dynamic proxies. Maybe Im missing one or two. Everything else is built on top of this.

This is regardless of language/ecosystem. If I do not understand the fundamental concepts, I will never be successful in that ecosystem.

replies(1): >>zeroc8+126
◧◩◪◨
11. zeroc8+126[view] [source] [discussion] 2025-12-04 23:43:43
>>throwa+sV4
The layer in Go is much thinner, if I want to learn about a new concept or technology. Of course there is no magic, if you are willing to put the time in. The question is how much time is required.
replies(1): >>gf000+UO6
◧◩◪◨⬒
12. gf000+UO6[view] [source] [discussion] 2025-12-05 08:09:52
>>zeroc8+126
The layer is thinner because you can't create abstractions as well in that language.

But that's like saying that a bicycle is better than a car, because the first is simpler to understand. (At the same time, nothing prevents you from assembling a bicycle in Java if that's indeed what you need. But for general long distance travel you are better off starting with a car frame, aren't you?)

[go to top]