zlacker

[parent] [thread] 29 comments
1. ozim+(OP)[view] [source] 2025-12-02 23:55:12
From what I gather everyone is still stuck on Java 8 so no need to check?
replies(4): >>foo4u+z3 >>vips7L+Lc >>throwa+ue >>gf000+X41
2. foo4u+z3[view] [source] 2025-12-03 00:27:17
>>ozim+(OP)
This is absolutely untrue. Code from JDK 8 runs fine on JDK 25 (just released LTS). It is true that if you did something silly that locks you into certain dependency versions, you may be stuck, but this is not the majority of applications.
3. vips7L+Lc[view] [source] 2025-12-03 01:51:05
>>ozim+(OP)
No, everyone isn’t. You really should check.
4. throwa+ue[view] [source] 2025-12-03 02:07:01
>>ozim+(OP)
Where do you gather this from? We are a startup, on Java and on 25.
replies(1): >>pylotl+jO
◧◩
5. pylotl+jO[view] [source] [discussion] 2025-12-03 08:27:29
>>throwa+ue
Why didn't you choose something more modern/sensible. go/kotlin/anything else on the planet?
replies(3): >>gf000+k51 >>throwa+aO1 >>krzyk+zV1
6. gf000+X41[view] [source] 2025-12-03 10:20:16
>>ozim+(OP)
Even stuck on Java 8 it's less verbose than Go, which everyone seems to love.

But the majority of projects are on a newer JDK than 8 for quite some years now.

replies(1): >>the_gi+N61
◧◩◪
7. gf000+k51[view] [source] [discussion] 2025-12-03 10:23:34
>>pylotl+jO
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+QM1 >>zeroc8+vl4
◧◩
8. the_gi+N61[view] [source] [discussion] 2025-12-03 10:33:45
>>gf000+X41
Not even latest Java is less verbose than Go.
replies(2): >>gf000+I71 >>vright+BZ4
◧◩◪
9. gf000+I71[view] [source] [discussion] 2025-12-03 10:40:35
>>the_gi+N61
Are we talking about the language that has a couple extra lines after every statement, disguising as error handling?
replies(2): >>the_gi+rn1 >>BobbyJ+sJ2
◧◩◪◨
10. the_gi+rn1[view] [source] [discussion] 2025-12-03 12:48:14
>>gf000+I71
go's error handling is very poor and too verbose, but go is still way less verbose than Java overall. Like any other language.

Java is the running joke of verbosity, and you are too if you seriously argue that it's not.

replies(3): >>gf000+Ct1 >>lenkit+ep2 >>vips7L+TV3
◧◩◪◨⬒
11. gf000+Ct1[view] [source] [discussion] 2025-12-03 13:30:09
>>the_gi+rn1
Feel free to provide some evidence. Like really, I would be interested in examples e.g. from the Java stdlib that are significantly more verbose than another generic purpose language.

But I do know that you are meaning stuff like AbstractFactoryFactory, but you do realize that there is zero need to write anything like that and you can (and people do) write bad code in any language?

replies(2): >>ground+yT1 >>the_gi+rl2
◧◩◪◨
12. codr7+QM1[view] [source] [discussion] 2025-12-03 15:17:00
>>gf000+k51
Except for Kotlin, which is a much nicer language to deal with.
replies(2): >>throwa+pO1 >>lenkit+Ao2
◧◩◪
13. throwa+aO1[view] [source] [discussion] 2025-12-03 15:24:31
>>pylotl+jO
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+fK2
◧◩◪◨⬒
14. throwa+pO1[view] [source] [discussion] 2025-12-03 15:25:19
>>codr7+QM1
Little nicer for sure
◧◩◪◨⬒⬓
15. ground+yT1[view] [source] [discussion] 2025-12-03 15:50:17
>>gf000+Ct1
Why is the quality of discourse in this thread so low?
◧◩◪
16. krzyk+zV1[view] [source] [discussion] 2025-12-03 15:58:27
>>pylotl+jO
Kotlin sensible? It plays catchup game with newest JDKs.
◧◩◪◨⬒⬓
17. the_gi+rl2[view] [source] [discussion] 2025-12-03 17:50:39
>>gf000+Ct1
You started it, where's your evidence?
◧◩◪◨⬒
18. lenkit+Ao2[view] [source] [discussion] 2025-12-03 18:05:32
>>codr7+QM1
A nicer language which is much slower to compile compared to Java.
◧◩◪◨⬒
19. lenkit+ep2[view] [source] [discussion] 2025-12-03 18:08:36
>>the_gi+rn1
Coding repetitive for-loops for everything and mind-numbing error handling put everywhere makes line count bloat up like crazy. Go is one of the most verbose languages I have seen and I say this as a guy coding in Go in my daily work.

Evidence is easy - think of a problem and ask LLM to generate idiomatic examples (leverage Java streams, with functional decomposition, etc) in Go and Java and with error handling. You will find that more often than not, the Java line count is far smaller.

replies(1): >>the_gi+cY2
◧◩◪◨
20. BobbyJ+sJ2[view] [source] [discussion] 2025-12-03 19:47:53
>>gf000+I71
Go only looks like that in toy examples where you have one method calling a bunch of libraries and services. If you are writing actual logic, the error handling is preferable to exceptions IMO, because no project even uses them correctly.

Now if you complain about slice handling, I'm with you.

◧◩◪◨
21. BobbyJ+fK2[view] [source] [discussion] 2025-12-03 19:51:28
>>throwa+aO1
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.

◧◩◪◨⬒⬓
22. the_gi+cY2[view] [source] [discussion] 2025-12-03 20:54:32
>>lenkit+ep2
I also code go daily for work, and while what you say is true, it's still far less than what I remember from working with Java, which was constantly wrapping mundane crap in classes and other stuff.
replies(1): >>lenkit+Z94
◧◩◪◨⬒
23. vips7L+TV3[view] [source] [discussion] 2025-12-04 04:04:44
>>the_gi+rn1
I can guarantee you that 9/10 times any similar Go snippet will be more verbose than Java.
◧◩◪◨⬒⬓⬔
24. lenkit+Z94[view] [source] [discussion] 2025-12-04 06:55:48
>>the_gi+cY2
Yeah, well you can write "enterprise 10k patterns crap" in any language. Java projects suffered from the craze of those initial years where every "architect" and their grandmother insisted on patterns.

Idiomatic, Modern Java is written quite differently. Today, Go has a lot of arcane, noisy, complex code too. Ex: many, many k8s Go projects.

replies(1): >>ngrill+2n8
◧◩◪◨
25. zeroc8+vl4[view] [source] [discussion] 2025-12-04 08:53:16
>>gf000+k51
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+LJ5
◧◩◪
26. vright+BZ4[view] [source] [discussion] 2025-12-04 14:06:24
>>the_gi+N61
Before go had generics it was pretty common to have multiple implementations of the same thing just for different datatypes.
◧◩◪◨⬒
27. throwa+LJ5[view] [source] [discussion] 2025-12-04 17:58:40
>>zeroc8+vl4
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+kQ6
◧◩◪◨⬒⬓
28. zeroc8+kQ6[view] [source] [discussion] 2025-12-04 23:43:43
>>throwa+LJ5
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+dD7
◧◩◪◨⬒⬓⬔
29. gf000+dD7[view] [source] [discussion] 2025-12-05 08:09:52
>>zeroc8+kQ6
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?)

◧◩◪◨⬒⬓⬔⧯
30. ngrill+2n8[view] [source] [discussion] 2025-12-05 13:06:41
>>lenkit+Z94
What is an example of a modern Java open source codebase, so I can have a look?
[go to top]