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

51–60 of 503 posts

Re: One year after switching from Java to Go

#51

Post by BytesAndGears »

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…

Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?”

Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle.

The thing that always happens with exceptions in API projects I’ve worked on, is that exceptions can come from any level of the stack, then by default it skips everything in the middle, and the controller has default handlers for what to do in case of an exception.

If there are exceptions you didn’t know existed because of some library or just complex code with dozens of possible exceptions? They still end up being handled in your controller. You need to know exactly what exceptions could happen at every level of the stack, and how to handle it, otherwise everything just short circuits.

With the go errors, you only need to know “did this function call work? If not, then what?”

Re: One year after switching from Java to Go

#52

Post by CharlieDigital »

amazingamazing wrote: post #49
CharlieDigital wrote: post #46

Earlier quoted context omitted.

You double up your work. What you really wanted all along are static types.

not necessarily, and in plenty of programming languages static types do not give you validation for free, and in the case of .net you still have to call something else. it's no different than just using zod, other than the fact that it's built in. if you're using typescript in the front end, seems double to even bother to introduce .net, when typescript and node is fine for the backend too.

    > [amazingamazing 31 minutes ago] I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either.
I think that if you're here trying to make the case that if your whole stack is TS, you don't need to validate your incoming data, then you probably haven't built a system of consequence where the data actually matters and none of this discussion really matters; you have no context. Go ahead and try to `curl` some nonsense data to any of your TS endpoints and see what happens at runtime without validation.

Re: One year after switching from Java to Go

#53

Post by scubbo »

diamondfist25 wrote: post #38
scubbo wrote: post #23

Earlier quoted context omitted.

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…

Btw js/ts, python, and golang, which one do you find more productive with?

Hard to pick between Python and TypeScript - they have different strengths. TypeScript's type system is more useful (you'd hope, given the name!), but Python "just works" more often for simple use-cases IME (though I have well over double the lifetime experience with Python, so that might be a me-factor rather than a language factor).

Re: One year after switching from Java to Go

#54

Post by owlstuffing »

Going back to first principles, nominal typing is what I miss most with Go. I get the utility of structs + interfaces + structural typing, but most of the time there is more benefit in declaring that a type nominally implements an interface when that is the intention. Code is far easier to read and understand that way, both for developers and tooling.

I suppose exclusively structural typing would be more acceptable if Go supported _real_ interface composition, like Scala with traits or true delegation via the manifold project[1] for Java. But that's missing as well e.g., does not inherently fix the Self problem, etc.

Considering Go's initial goal, which was IIRC a better systems language, then yeah, sure it's an improved C. But now that Go is routinely compared with Java/Kotlin and friends, I personally don't see it, particularly wrt the type system, to be taken seriously as a Java contender. Shrug.

1. https://github.com/manifold-systems/manifold/blob/master/man...

Re: One year after switching from Java to Go

#55

Post by amazingamazing »

CharlieDigital wrote: post #52
amazingamazing wrote: post #49

Earlier quoted context omitted.

not necessarily, and in plenty of programming languages static types do not give you validation for free, and in the case of .net you still have to call something else. it's no different than just using zod, other than the fact that it's built in. if you're using typescript in the front end, seems double to even bother to introduce .net, when typescript and node is fine for the backend too.

> [amazingamazing 31 minutes ago] I mean you could say the same thing about TypeScript - if your entire stack is TypeScript then there's no need for the type validation either. I think that if you're here trying to make the case that if your whole stack is TS, you don't need to validate your incoming data , then you probably haven't built a system of consequence where the data actually matters and none of this discus…

I'm not really sure what your point is. you can add validation in node.js, just like you can with .net.

also, with curl you'd use isomorphic type safety, or just know what you're expecting and hard code the types per inputs, trivial with typescript.

anyway, I'm done here since this conversation is going in circles.

Re: One year after switching from Java to Go

#56

Post by bmurphy1976 »

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…

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.

Re: One year after switching from Java to Go

#57

Post by badrequest »

cflewis wrote: post #37
gt0 wrote: post #29

Earlier quoted context omitted.

DI exists in Go, but it's not ubiquitous like it is in the C# or Java worlds. Last time I used Go, I used "wire" for DI and was pretty happy with it.

I worked on Wire right at the beginning, happy to answer any questions about it.

No questions, but a heartfelt thank you. I've used wire for years and plan to continue doing so. :)

Re: One year after switching from Java to Go

#58

Post by paulddraper »

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.

Re: One year after switching from Java to Go

#59

Post by TheCycoONE »

We run mostly Java apps with a few Go apps. What I miss with Go, maybe just because I'm not as familiar and don't know where to look, is all the runtime analysis that's built in. Thread dumps, heap dumps, and even flight recorder profiling is all built in to the JVM so it works with all apps everywhere. When a Go app suddenly slows down it's very difficult to determine why unless the app was coded to provide the right metrics.

Re: One year after switching from Java to Go

#60

Post by CharlieDigital »

bmurphy1976 wrote: post #56
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…

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 case where I might add explicit exception handling probably falls into a handful of use cases when there is a desire to a) retry, b) log some local data at the site of failure, c) perform earlier transform before rethrowing up, d) some cleanup, e) discard/ignore it because the exception doesn't matter.

Post reply on HN