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

141–150 of 503 posts

Re: One year after switching from Java to Go

#141

Post by searealist »

hedora wrote: post #114
BytesAndGears wrote: post #51

Earlier quoted context omitted.

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…

Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possi…

equivalent exceptions:

    let res = bar(foo());
(I think you meant: let res = bar(foo()?)?;

Re: One year after switching from Java to Go

#142

Post by konart »

throwaway2037 wrote: post #101
cflewis wrote: post #40

Earlier quoted context omitted.

FWIW the internal Google style guide says to not pass anything via Context unless you _really_ know what you're doing and why. Things that make sense: security tokens and tracing. Things that don't make sense: almost everything else.

> internal Google style guide Can we read this somewhere?

I'm not sure about Google style guild but Go's context package docs state:

"Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions."

https://pkg.go.dev/context

Using context as a some sort of a mule is an antipattern.

Re: One year after switching from Java to Go

#144

Post by lelanthran »

nine_k wrote: post #124
MrDarcy wrote: post #25

Earlier quoted context omitted.

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…

The exact stack trace may not be very necessary, but tracing the chain of calls, especially async, can be hugely helpful in troubleshooting, performance tracking, etc. In Node, I remember wrapping Promisesromises into objects that had a stack for pushing messages onto them, so that the creator of a Promise could mark the calling site, and creating another Promise within that promise would pick up the chain of call si…

> In Node, I remember wrapping Promisesromises into objects that had a stack for pushing messages onto them, so that the creator of a Promise could mark the calling site, and creating another Promise within that promise would pick up the chain of call site names and append to it, etc. Logging that chain when a Promise fails proved to be very useful.

Sounds complicated. I don't use Node much (nor recently, for that matter), but when I write f/end JS I capture the chain of function calls by creating a new exception (or using whatever exception was thrown), and sending the `.stack` field to a globally-scope function which can then do whatever it wants with it.

Will that not work in Node?

Re: One year after switching from Java to Go

#145

Post by tonyhart7 »

throwaway2037 wrote: post #106
pylua wrote: post #66

Earlier quoted context omitted.

I’m also a long time java spring developer. I started writing a game recently and was really surprised about how bad the performance can be when you run it in a tight game loop. The startup time is also a real problem, as you really want to be able to scale up pods quickly. That said, it’s good enough right now. You can make it work at scale, and it’s worth the cost trade off of trying to do it more efficiently in a…

> I would be curious to see how a rust microservice would compare in my companies infrastructure. How much cloud saving could we squeeze? So, replace cheap Java developers for expensive Rust devs to squeeze out some savings? It makes no sense to me.

well if the argument is cheaper, I can argue that JS/python dev would be more cheaper since there are more pool of talent

Re: One year after switching from Java to Go

#146

Post by lelanthran »

throwaway2037 wrote: post #100
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…

> 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 This is not possible in Java or C#? Both of those languages are so simple to grasp.

> This is not possible in Java or C#? Both of those languages are so simple to grasp.

Not really, no.

Apart from the cognitive burden of knowing the test framework in use, the DI tooling in use, the Mocking framework in use, plus all the annotations that each framework may want/need, almost none of which applies to the Go projects I've seen, the languages themselves have drifted away from simplicity.

I used to program in C# but left it for a long time and only recently looked at it again. C# is approaching C++ levels of syntax indecipherability.

Re: One year after switching from Java to Go

#147

Post by alpb »

user9999999999 wrote: post #143

Any suggestions for how to store request scoped data without context? Specifically when using middlewares, like in the example of an auth middleware, needs store isAdmin or isLoggedIn or UserId

Presumably you control the entire handler stack in Go. So you can extend the HandlerFunc signature with parameters customizations to carry explicit structs, or return “error”, for example.

Re: One year after switching from Java to Go

#148

Post by skeeks »

pm90 wrote: post #11

The startup time comparisons may not seem like a big deal but having an app take several seconds just to start up can burn you really bad in incidents where you want to roll new application versions. And yes, it is possible to engineer around it but I think a better question to ask is why these apps take so goddamn long to start in the first place. There should be some kind of compile or runtime flag to speed this up…

There are a lot of applications where the startup time of several seconds does not matter at all. More likely, for most applications it does not matter. Of course, if you are FAANG, it does, but you should not optimize for that in the beginning.

Re: One year after switching from Java to Go

#149

Post by nesarkvechnep »

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’m yet to see a former Java developer who uses the idioms of the language they currently use. They all just write Java in a different language.

Re: One year after switching from Java to Go

#150

Post by wavemode »

qaq wrote: post #137
hedora wrote: post #114

Earlier quoted context omitted.

Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possi…

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?

Post reply on HN