One year after switching from Java to Go • Hacker News Board

Re: One year after switching from Java to Go

#411

Post by geodel » Wed, Feb 19, 2025, 3:32 PM UTC

okeuro49 wrote: post #333

lenkite wrote: post #325

Earlier quoted context omitted.

In Go, people will write code to use the standard library for the app they are developing instead of pulling in a framework to do the work for them. Most Go developers have a culture of minimizing dependencies to utterly essential ones that they cannot write on their own. In Java, people will pull in a 100MB+ mega-framework for a hello-world REST service. Oh and another 50MB for ORM. Another 25MB+ for nailpolish, etc…

> In Java, people will pull in a 300MB+ mega-framework for a hello-world REST service. Oh and another 200MB for ORM. Another 250MB+ for nailpolish, etc. I just now used https://start.spring.io/ to generate a project using Spring web, Spring security and Spring data JPA (Hibernate). It generated a JAR that is 52MB.

Good. Just a little bigger than linux image size for containers and thats without including JVM.

Re: One year after switching from Java to Go

#412

Post by CBLT » Wed, Feb 19, 2025, 3:38 PM UTC

kuschku wrote: post #332

theshrike79 wrote: post #293

Earlier quoted context omitted.

It's kinda understandable. I've seen "Java coders" write Python for example. The first thing they do is create a class and maybe even a Factory or Interface. You can see instantly where their experience is from and it's hard to unlearn.

Java developers may write verbose python, but that doesn't compare to the crimes actual python devs commit. Currently trying to modernize a python project that doesn't use modules, just executable python files that import each other with custom sys.path hackery, which is also used for globals, no type annotations, GLib used for everything including math and string to int parsing.

Hey, sorry, that might have been me. I did that then left the company.

In my defense, I had to hack around a different Python library also manipulating sys.path, which nobody likes except this one dev team in a different timezone. They somehow got a director to declare that I would fix this issue they self-created before they woke up in 8h, and I wasn't allowed to rip out the library. So, ugly sys.path manipulation in the exact way that library wants. Not proud of it, but it sounds like you were given time to engineer an actually correct solution.

Re: One year after switching from Java to Go

#413

Post by mexicocitinluez » Wed, Feb 19, 2025, 3:43 PM UTC

unscaled wrote: post #300

saturn_vk wrote: post #289

Earlier quoted context omitted.

> Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work. DI is necessary in every language that doesn't rely solely on global singletons. Passing dependencies as arguments to a function is DI. What may not be necessary, are IOC containers automatically create objects and satisfy their dependencies.

Too many people confuse the concept of DI with a DI framework. You don't even need a DI framework to write straightforward programs in Java. After all, Java also has interfaces! One of the reason people needed a DI framework in Java is crazy "enterprise" configurability requirements and Java EE-based standards that required you to implement a class with a default no-argument constructor. If you're using a web framewo…

> One of the reason people needed a DI framework in Java is crazy "enterprise" configurability requirements a

No, it's so that you can have something else manage the lifetime and disposal of your services instead of doing this yourself. You don't have to be writing crazy enterprisey code to have the need for this.

I agree DI is simple, but 100% disagree that you can achieve this through a hand-rolled library without sinking a ton of wasted time.

Re: One year after switching from Java to Go

#414

Post by mooreds » Wed, Feb 19, 2025, 3:44 PM UTC

procaryote wrote: post #213

time4tea wrote: post #156

The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author…

Yep. Java is really good. Java developer culture is awful. If you instead of spring boot just pick a few dependencies you really need, you don't throw the whole Design Patterns book at it just because you can, and you don't try to make everything changeable without recompiling or redeploying, it's pretty nice to work with

At $CURJOB, we have built a pretty good business on an app built in Java. We don't use Spring, but instead a lightweight MVC of our own creation[0]. It is open source but I don't know if anyone else is using it :) .

I once asked the founders why they chose java; it was because it was 2015ish and they had an existing product in java and they knew it. Which makes sense to me. I think there's a lot of path dependence to language choice.

I also think the domain matters. For database based webapps, Java can be great. Lots of tooling and knowledge around it. And modern java is pretty friendly to write. Plus, if you are interacting with something over an API and deploying it via a container, who really cares what it is written in?

For kubernetes operators? Seems like a natural fit for golang. Anything kube really. I had a friend who ran a k8s consultancy for a while and said that they'd prototype stuff in python because it was easy, then implement in golang because that was what was consistent with the rest of the ecosystem.

0: https://github.com/prime-framework/prime-mvc

Re: One year after switching from Java to Go

#415

Post by mexicocitinluez » Wed, Feb 19, 2025, 3:50 PM UTC

MrDarcy wrote: post #25

bryancoxwell wrote: post #18

> But there are obviously work around solutions in the Go ecosystem. It uses the Context ctx, which we pass around functions in order to juggle data around in the application. Man. This works. The context API allows/enables it. But I’d really recommend against passing data to functions via context. The biggest selling point of Go to me is that I can usually just look at anyone’s code and know what it’s doing, but thi…

I hit this point in tfa and had the same comment. Please don’t pass things around in a Comtext. Maybe stash a slog logger in there, but that’s about it. I made the switch to Go a few years ago. For those who are on a similar journey as the author, or the author himself, I suggest spending time with the Go standard library and tools written by Rob Pike and Russ Cox to get a handle on idiomatic Go. It’s clear the autho…

> I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.

This is like saying "I won't use source generators because it generates code I would normally write myself"

Like, yea no shit. THAT'S the point.

Re: One year after switching from Java to Go

#416

Post by qaq » Wed, Feb 19, 2025, 3:52 PM UTC

wavemode wrote: post #150

qaq wrote: post #137

Earlier quoted context omitted.

99% of people who never written go will know what the go version does

Then... look it up? If someone saw "go funcName()" for the first time, would they know how it worked without looking it up?

Prob not but I would still argue go is way easier to read than Rust for someone who does not know either.

Re: One year after switching from Java to Go

#417

Post by mike_hearn » Wed, Feb 19, 2025, 3:52 PM UTC

anthropodie wrote: post #212

okeuro49 wrote: post #203

Earlier quoted context omitted.

> But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware... No, people use it because we don't want to reinvent the wheel. Spring is well documented and Spring Boot gives you a set of dependencies that all work together. Then you don't have to spend time messing around with things like OAuth and authentication, you can just write th…

> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application. It sounds good but in reality people end up spending time messing around with config files and annotations.

Maybe? Depends on the framework. I've been using some Micronaut lately and it's a Spring-inspired framework where a lot of stuff Spring does at runtime is done up front at compile time.

The result is apps start really fast, can be compiled to a standalone native binary with GraalVM, use little memory, and errors that would once have resulted in a complex exception at startup now yield reasonable compiler errors instead (it has compiler plugins to make this work well).

I can't say I've spent much time messing with annotations or config files in this project. Certainly, what little time has been spent on the framework is more than saved by what it does.

Re: One year after switching from Java to Go

#418

Post by bdhcuidbebe » Wed, Feb 19, 2025, 3:55 PM UTC

amazingamazing wrote: post #395

bdhcuidbebe wrote: post #329

Earlier quoted context omitted.

Provide strong typing, low memory footprint and good performance at scale. See the topic of discussion for more details.

Yes, I agree, but what you're saying isn't really relevant in an I/O bound scenario. In any case, I wouldn't write a K8s operator in node.js, yes. Go is the best for that.

Sorry, but what IO bound scenario?

Re: One year after switching from Java to Go

#419

Post by blindriver » Wed, Feb 19, 2025, 3:59 PM UTC

Mawr wrote: post #338

CharlieDigital wrote: post #60

Earlier quoted context omitted.

What challenge did you run into with exception handling? I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions. The only cas…

How can you "let the exception bubble up" when you don't know what "the exception" is nor where it's going to be thrown? The agency you imply here does not exist. All you can do is what you've described - catch all exceptions at the top level and log them. It's a valid strategy so long as you don't mind your service going down at 3am because someone didn't realize that the call to Foo() on line 5593 could in fact thr…

No, I disagree with you.

If you are using Go, you have no idea what the error you're going to receive is, because the code you call could be calling other code that you have no idea about. You might use existing code that gets modified to call into another module and then you're going to get a whole set of errors that you aren't expecting and won't be able to react to.

What this means is that you have NO way to handle errors except to just error out and bubble up. Because all you can do is look at the error, the best you can do is throw your hands up and say "okay just returning this error." How is this any better than an exception?

Re: One year after switching from Java to Go

#420

Post by Capricorn2481 » Wed, Feb 19, 2025, 4:00 PM UTC

Mawr wrote: post #357

throwaway2037 wrote: post #111

Earlier quoted context omitted.

> Most of my code will annotate a lower error with the context of the operation that was happening. This is easy to solve with chained exceptions to add context. > it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. You cannot add method args to an exception message? I am confused.

If it's easy then why does nobody do it? ;) In all exception-based languages I know of, catching an exception is so syntactically heavy that annotating intermediate exceptions is never done: try { Foo() } catch (err) { throw new Exception("message", err) } One line just turned into four and the call to Foo() is in a nested scope now, ew. At that point even Go is more ergonomic and less verbose: err := Foo() if err !=…

> If it's easy then why does nobody do it? ;)

People do this all the time with exceptions.

> One line just turned into four

The Go version has one line of difference?

> At that point even Go is more ergonomic and less verbose

You can't compare it to your Go version because you have to write the error check at every single level, whereas once I throw that exception I can catch it wherever I want. Obviously the Go version will have much more code just around one error.