Live data from Hacker News

Java 21 makes me like Java again

wscp.dev

731–740 of 777 posts

Re: Java 21 makes me like Java again

#731
post #695

Earlier quoted context omitted.

We are in the process of switching to Gradle at work and I'm not sure I like it. I used Gradle when building some OSS projects, but my experience wasn't that great.

Just make sure that whoever writes the majority of the build file actually understands gradle, at least its fundamentals. It really is not hard, and afterwards it is a really great tool that can significantly improve compile/CI times.

The tool whose main purpose is to build stuff should not demand "understand gradle at least fundamentals so that afterwards you can probable possibly improve times".

Why isn't it fast out of the box? Why does the simple "provide a list of deps, provide a list of paths, build" take so darn long? Because Gradle is a great tool or something?

Don't forget that it's also already at version 8, where each change is mostly incompatible, bizarre and inexplicable breakages between versions, often due to meaningless option renames. Imagine if they spent all that effort on actually making it a great tool.

Re: Java 21 makes me like Java again

#732
post #329

Earlier quoted context omitted.

Java's build times are very fast. Java's build tools are anything but. And I'm surprised no one is doing anything about it.

If you avoid pre-Java 11 modules in Apache Maven, it is very fast to build. Plus, IntelliJ is auto-magically incremental build. Can you give some specific examples where Java build tools are slow? Most Java developers spend their whole day in an IDE that is doing incremental build, jumping in and out of a debugger to fix bugs or broken unit tests.

Maven is okay-ish, Gradle is an abomination. Incremental compilation doesn't always work, and the fact that the build tools often spends a magnitude or more time just starting up than actually doing useful work is inexcusable.

Re: Java 21 makes me like Java again

#733
post #694

Earlier quoted context omitted.

That is exactly what I used to think when I started with it. But I changed my opinion after 6 months with Go and eco-system. It's not ugly, it's different and much more concise.

It is more verbose than java by all objective counts.

I think there may be a “Penny wise but pound foolish” thing going on in your analysis.

Re: Java 21 makes me like Java again

#734
post #616

Earlier quoted context omitted.

Gradle is much faster than maven as it can properly parallelize the workloads. Sure, it won’t be visible on a hello world, though.

There seems to be some disagreement to your statement. Can you provide some concrete examples?

https://gradlehero.com/maven-vs-gradle-comparison/

Re: Java 21 makes me like Java again

#735

Earlier quoted context omitted.

I don't think any existing Go developer is going back to Java. I worked with Java for 10 years and switched to Go and I will never go back. This is mostly because applications and libraries are so hard to reason about and understand due to inheritance, packaging, OOP, build tools ect compared to Go. Go is simple. It's easy to understand, read, and maintain. The packaging is like how you would package files on your co…

This is correct. It is about culture too. Java is the kind of language that attracts some mediocre programmers who produce mediocre code based on the wrong ideas of object oriented programming. of course, there are great Java programmers. It is just that a better programming language would help average programmers like us to achieve more

> attracts some mediocre programmers who produce mediocre code

That will be reality for most companies, no matter the language. And if Java projects still got delivered in such conditions - it might also be a mediocre language but it is also just good enough.

Re: Java 21 makes me like Java again

#736
post #388

Earlier quoted context omitted.

How does jruby relate to truffleruby?

He actually talks about that during the video as well. Short answer is “it depends”. IIRC Truffle is dramatically faster in some benchmarks but slower in others. And there are some usability aspects of the language that are negatively impacted.

I think he shows the performance of running JRuby on top of GraalVM. GraalVM uses Graal (the JIT compiler) in place of C2 (the JIT from HotSpot).

But TruffleRuby is something different. It is another Ruby implementation (just like JRuby is a Ruby implementation) using the Truffle framework. And Truffle framework requires to be run on GraalVM.

Re: Java 21 makes me like Java again

#737

Earlier quoted context omitted.

> Go's major selling point to me is that you can ship one binary, nothing beats that. You can ship one compiled binary in Java too if you want it. https://www.graalvm.org/22.0/reference-manual/native-image/ > Go is simple. It's easy to understand, read, and maintain Go involves a lot of code repetition which makes it difficult to human-scan and maintain. Worked on both large scale Go and Java projects and I found Jav…

I’m neither a Golang nor a Java developer per se, but I touch source from both as an SRE. I find it weird to see so many comments saying Go is verbose and Java is not. I found the opposite to be true. To do every little thing, the Java code has a ton of abstraction, and the actual implementation of anything is so far removed from the place where it is used that it gives me such a headache to touch anything without wo…

Quite a bit depends on how the codebase has been written and what era are you looking. Before Java 8/9 or after it. Java code written in the recent era is pretty lean and mean.

No matter the amount of abstraction though, one rarely runs into the sort of issues in Java that Go code tend to run into frequently - causing multi-million dollar mistakes frequently even for experienced Go programmers. For loop semantics https://bugzilla.mozilla.org/show_bug.cgi?id=1619047, Unintended variable shadowing, common mistakes in slice appends/copies, slices and memory leaks, defers inside loops, nil interface vs nil, panics in go-routines. There are loads of bugs in OSS projects wrt to these usually repeated again and again.

Go is very simple to learn and very hard to master writing bug-free code. Looking forward to seeing how languages like Rust perform if/when adopted by enterprise.

Re: Java 21 makes me like Java again

#738
post #718
post #666

Earlier quoted context omitted.

Combining the best parts of Java and JavaScript isn't exactly something to boast about. Dart lives and dies with the Flutter framework. Other than that it's not doing anything special. Not terrible but also not a significant improvement.

I mean you’ve taken my point, cut it in half to remove the relevant context and are now arguing against a point you’ve made up as some kind of gotcha… I don’t know what you want me to say to that. Same with your second point. I made a big point to explicitly say I think that right now Dart is very underused and has a huge potential outside of Flutter. Quoting that back to me as though it was something I hadn’t consid…

I'm with you, I think that Dart is very sensible and very underappreciated language. But he does have a point in saying that currently Dart is tied to Flutter. Google is presenting Dart as a language that you write Flutter with, not as a separate entity. I'd much prefer if Google would present Flutter as a GUI framework for Dart, but alas. Perception is everything. As much as I'd love to start my next project in Dart I probably won't because I can't be sure that Dart won't end up in Google's graveyard in next couple of years whereas I'm pretty sure that Go won't.

Re: Java 21 makes me like Java again

#739

The "Sealed classes" feature, as described here, just feels all wrong to me. They are saying that if you have a (normal) interface, anyone can create a new class implementing it. So if you do if (x instanceof Foo) { ... } else if (x instanceof Bar) { ... } ... then your code will break at runtime if someone adds a new class, as that code won't expect it. So the article is saying the solution is to use the new "sealed…

The solution with sealed classes also allows anyone to extend the code, but in a different dimension than the solution with an interface method. The solution with interface method and virtual call is very inflexible when you want to add new operations instead of adding new classes. If you want to just add one new operation, then you have to go to all the implementations and add new methods. And you possibly break the…

  > If you want to just add one new operation, then you have to go to all the implementations and add new methods.
not necessarily, if you have extension methods (kotlin, swift) you have the option to extend the interface and only override the specific implementation when needed

Re: Java 21 makes me like Java again

#740
post #645

Earlier quoted context omitted.

Teasing this apart I see a few things: a) logging, b) modules rollout and c) missing frameworks. I’ve never had a logging issue in large systems. Explicit error return (as you know, on every function) allows you to log in your code, not lean on only libraries that support your interface. Modules rollout was part of growing up. But, you won’t get Go 1->2 upgrade issues as we have 100% backward compatibility on version…

> Too many allocations for Go is going to be too many allocations for JVM too No, Go’s GC is a toy compared to the JVM’s. It is lowerish in latency by actually stopping the application threads when under high contention. Java doesn’t slow down the allocation rate, it tries to keep up with the churn.

Huh, Go also does not allocate ten times more more memory like Java. So even if Go's GC is 1/10th performant as Java (and it isn't) it will be equally better Go applications.

Java's GC improvement is relentless because Java's applications are relentless in memory allocation.

Being on endless Java memory/perf issue prod calls I can say Java GC improvement, performance tuning is cottage industry in itself. Meanwhile end users keep suffering but at least Java devs get to tune GC to their heart's content.

Post reply on HN