Java is a resource hog when you use patterns and libraries popular in Java land.
When you are working in the Java ecosystem, you just assume that this much resource is needed by the app! But when you'll code the same thing in Go using the same methods, you'll find resource usage is really very low.
We’ve a 1: 1 copy of the app; on JVM, it's using 2GB RAM using Spring Boot, and on Go, it runs on 512MB RAM and is blazingly fast.
ofc, it's possible to tune java app but why bother? when we get same low resource usage and better performance in Go from get go while still writing naive and dumb code?
Deployment is super simple in Go, upload a single cross compiled binary it's done. Very simple and easy.
Rust needs a lot more effort to write correct code than Go in my experience. We get the same performance out of Go, with much less effort. At some point, it's just cheaper to start one extra instance than perform some low-level optimisation; modern hardware is fast enough that Rust-level optimisation is rarely needed for what we do.
I cant really agree on Rust. It does take a bit more time to write the same code in rust vs go. But in my experience the code is much more likely to be incorrect in go than it is in rust. Which over longer periods means rust is easier to maintain.
If you have unmotivated employees then using Go will only exacerbate the shortcomings it has. Cutting corners is much easier in Go than it is in Rust. But in general it's true, if you want a piece of code released a bit faster but spend more in developer hours maintaining it later than Go is the better fit. And there are definitely use cases for that.
You can write exploratory code in Rust fairly quickly, it's just obvious when you've done so due to the heavy boilerplate involved. Keep in mind that the earliest versions of Rust were actually very Golang-like, the language iteratively evolved towards what it is today.
I'm not sure the effort part makes sense now that we have LLMs? LLMs basically liberate language choice, which has made Rust incredibly attractive to me since I basically get good performance out of the box, while any possibly annoying pedantic obsession with correctness can be easily handed over to the LLM.
If I use a JVM language, running my test suite takes 10 to 30 seconds. With Rust it spends 3 seconds compiling and half a second to run 250 tests.
The irritating parts of Rust are more related with bloated libraries like serde that insist on generating code which massively slows down compilation for not much benefit.
This is both a fair response and isn’t! The OP was talking about typical Java stuff you’ll encounter, which is overwhelmingly spring boot. But I also agree that you can do much better than that for resource usage if you’re willing to avoid the common defaults the community has embraced.
I agree, but it's still frustrating. There are a lot of red flags / contradictions in the post above which are typical of such debates. E.g.
> Java is a resource hog when you use patterns and libraries popular in Java land
Which java land. The java 8.0 land which is all about design pattern hell? Or modern java in 2026 which is largely about terseness and functional programming? From the tone, they're referring to the former.
> Deployment is super simple in Go, upload a single cross compiled binary it's done
To me this just sounds like OP is unaware of simple things like jlink or jpackage, and their idea of deploying a java application probably involves launching an IDE.
> But when you'll code the same thing in Go using the same method
Same method would mean using "Springboot for Go". Or, conversely, doing a clean implementation in pure java or with equivalent lightweight libraries. If all you want to do is basic calculations, you don't compare using a computer to a calculator and then complain the computer is heavy and slow to boot.
I agree and appreciate that there's a lot of legacy bloated java libraries out there which are "popular" and possibly for the wrong reasons, and that this is a problem. But, that aside, they're comparing building a bespoke lightweight tool from scratch in a language they enjoy, to using a bloated framework they can't be bothered to fine-tune on a language they associate with pre-2000 patterns. Just say you're more familiar with Go than modern Java and enjoy it more and leave it at that. Java has made great leaps into becoming a very beautiful language recently, and biased rants like this aren't helping.
It's a specific liquid scanner that's done on bottles that have been pulled aside for extra scanning (at least, that's what Frankfurt was doing a couple weeks ago)
As far as I know, it's not. You're now specifically told to not take liquid out of your luggage.
At least that was the situation when I flew out of London Gatwick last time - they had people going up and down before the scanners admonishing people to leave everything in their bags to avoid delay.
We had 4 bags go through, 3 had liquids (2 water bottles and one Barenfang) in them. All three were pulled for secondary screening, at which point they put the specific liquid bottles in a secondary scanner and cleared them.
So, yes, they stay in the bag, but then they're pulled out and scanned separately, at least in Frankfurt.
I've noticed every airport is different, and major airports are usually more likely to have the big fancy looking scanners that help keep the crowd moving along, without taking everything out. Smaller airports seem to have less of that tech and are thus often more of a hassle.
And yet somehow, airport security staff frequently get impatient when people in line ask whether to remove their shoes, laptop, etc. As if the travelers are stupid for asking.
This is a fairly new change - the new scanners are being rolled out "everywhere", but not everyone has them again, and there were some snafu's last summer that caused them all to be decertified within the EU, and at least for a while only scanners from one company had been recertified.
It'll probably be chaos for the next couple of years while this sorts itself out.
>One way to avoid this is to prevent the command from being written to history. Bash has a configuration variable named HISTCONTROL, which when set to include ignorespace prevents commands prefixed with whitespace from being saved in history.
reply