Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

Post reply on HN
Print view View original

71–80 of 503 posts

Re: One year after switching from Java to Go

#71

Post by ratorx »

CharlieDigital wrote: post #60
bmurphy1976 wrote: post #56

Earlier quoted context omitted.

To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.

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…

In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the top level like: “failed to process item ‘foo’: unable to open user database at ‘/some/path’: file does not exist” as an example.

Here, the lowest level IO error (which could be quite unhelpful, because at best it can tell you the name of the file, but not WHY it’s being opened) is wrapped with the exact type of the file being opened (a user database) and why the database is being opened (some part of processing ‘foo’, could even generate better error message here).

Although this is a bit of work (but in the grand scheme of things, not that much), 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.

I think the common complaint of ‘if err != nil { return err }’ is generally not the case because well-written Go will usually prepend context to why the operation was being performed.

Re: One year after switching from Java to Go

#72

Post by paulddraper »

tomcam wrote: post #64
paulddraper wrote: post #58

Earlier quoted context omitted.

> as if Golang's context has anything at all to do with DI Yes, Go's context can be used as a DI container.

I thought it was mostly used to terminate an asynchronous event?

Yeah it can inject a signal for that.

Re: One year after switching from Java to Go

#73

Post by alexjplant »

epolanski wrote: post #26

Very ignorant about Go, is dependency injection not a thing there? E.g. I like declaring interfaces in other languages that model some service (e.g. the database), focus on the API, and then be able to provide different implementations that may use completely different technologies behind them. I know that some people don't see the point, but I'll make an example. At my primary client the database layer is abstracted…

> Very ignorant about Go, is dependency injection not a thing there?

It is but there isn't a heavy emphasis on a DI framework per se. At its core DI is "inversion of control" insofar as an object constructor receives what it needs to do its job as opposed to the constructor instantiating said requirements itself. In my experience Golang devs don't use of a bunch of meta-programming via tags/annotations/decorators to tell a third-party framework what reflect-y magic it has to do at runtime; they typically just abstract everything behind an interface and pass instances of what you need to a New function that instantiates the consumer object. I personally prefer this to Spring-type frameworks because it's more verbose and checked at compile time. This means one can easily follow what's going on instead of having to dig through a bunch of nested stack traces riddled with Aspect4J esoterica to find out why some magical Maven dependency suddenly broke your entire app for no reason at all.

Then again the last time I had to bootstrap a complex Spring project was in 2014. Since then I've used Spring Boot for simple 3-tier microservices and it worked fine... it's likely improved since then but I still wouldn't use it for anything greenfield after the loop it threw me for.

Re: One year after switching from Java to Go

#74

Post by codr7 »

blindriver wrote: post #36

I've been using Go for a while now. The biggest headache is error handling. I don't care what the "experts" say, having exception handling is so, so, so much cleaner in terms of error handling. Checking for err is simply bad, and trickling errors back up the call stack is one of the dumbest experiences in programming I've endured in multi-decades. If they are willing to add generics, they should add exception handlin…

Agreed, every time I jump back into Go I'm at first relieved at how nimble it feels; but it never takes long to remember what a pita error handling is or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc).

Re: One year after switching from Java to Go

#76

Post by evil-olive »

paulddraper wrote: post #58
evil-olive wrote: post #33

it's really weird to see a "Dependency Injection & Context" section as if Golang's context has anything at all to do with DI. in particular, reading between the lines here: > 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. suggests to me that they've implemented one of the Golang anti-patterns…

> as if Golang's context has anything at all to do with DI Yes, Go's context can be used as a DI container.

> Go's context can be used as a DI container.

the WithValue/Value API allows you to treat the context as essentially a map[string]any. [0]

so if you want to make the definition so expansive as to be meaningless, then yes, map[string]any can be used as a "DI container". and so can a context object, because it exposes a map[string]any-ish API.

0: though if you read the implementation [1] looking up a value in a context is essentially a linked-list traversal and not a hashtable lookup

1: https://cs.opensource.google/go/go/+/refs/tags/go1.24.0:src/...

Re: One year after switching from Java to Go

#77

Post by codr7 »

38 wrote: post #70
codr7 wrote: post #68

I'm pretty fond of Java; it's definitely a superior language to Go if you ask me, which I've also written a ton of code in. But I stay away from Spring Boot, end the entire EE stack of crap that came before it, if at all possible. I've had more success adding whatever I need on top of embedded Jetty. It's mostly a cultural problem, no one is forcing you to go the AdapterFacadeInjectionBuilderWhatever way. I've been w…

[flagged]

I could tell you why, based on writing a ton of code in both, but I doubt that would lead anywhere.

Re: One year after switching from Java to Go

#78

Post by codr7 »

ratorx wrote: post #71
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…

In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the top level like: “failed to process item ‘foo’: unable to open user database at ‘/some/path’: file does not exist” as an example. Here, the lowest level IO error (which could be quite unhelpful, because at best it can tell you the name of the file, but not WHY i…

It's perfectly possible, and a lot less work, to wrap exceptions on their way up the call stack. The difference is you have to remember it at EVERY SINGLE freaking call site in Go.

Re: One year after switching from Java to Go

#79

Post by nine_k »

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…

Implicit shared state? Exactly the thing to enjoy in a highly concurrent environment!

At least I hope that a context can be immutable throughout. I only see one variable in the documentation of the context package. Extending it with mutable fields, and mutating them to pass data between functions, would be something I'd never approve in a code review.

Re: One year after switching from Java to Go

#80

Post by throwaway894345 »

scubbo wrote: post #23
honkycat wrote: post #2

After dealing with constant build issues between Java and Typescript and Node and Python: I love go so much. The package management alone makes it worth it.

After dealing with constant build issues with Go, I hate Go so much. The fact that they've conflated "source code" with "consumable library" means that you need a special case in your CI to publish new versions of a library in Go vs. every other language that builds and publishes an executable, and any tooling that pulls from a private repository has to hack `git config` rather than authenticating like you would any…

I’m confused by this. Go doesn’t have a “publish a library” step, whereas every other language does. Is “noop” the special case you are referring to? And why are you comparing publishing a library in Go to publishing executables in other languages?

> unidiomatic to continue developing your packages after you publish them

Are you talking about publishing breaking changes without bumping the major version? Because that seems … like a bad idea in any language?

Post reply on HN