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

181–190 of 503 posts

Re: One year after switching from Java to Go

#181

Post by starquake »

Saser wrote: post #135
throwaway2037 wrote: post #101

Earlier quoted context omitted.

> internal Google style guide Can we read this somewhere?

https://google.github.io/styleguide/go/ is the public version of it. Having read both I'd say the differences are small. The main thing missing, though, are the GoTip episodes that haven't been made public, and which are excellent.

I think the Google Go style guide is really nice and pragmatic. There are some references to the GoTips for some advanced subjects. I hope they release it someday.

I made an issue for it: https://github.com/google/styleguide/issues/881

Re: One year after switching from Java to Go

#182

Post by someothherguyy »

roncesvalles wrote: post #171
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…

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

So, write python in go instead, gotcha.

Re: One year after switching from Java to Go

#183

Post by 65a »

3uler wrote: post #175
roncesvalles wrote: post #171

Earlier quoted context omitted.

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

And yet Uber wrote fx[1] to support DI in their golang services. It’s clearly a useful pattern when working on large services. [1]: https://github.com/uber-go/fx

I really cannot say Uber's use of Go is particularly idiomatic to me, having started writing Go more than a decade ago now. It just strikes me as overwrought, and I've worked on big services.

Re: One year after switching from Java to Go

#184

Post by rob74 »

demi56 wrote: post #132
zdragnar wrote: post #104

Earlier quoted context omitted.

The languages aren't, strictly speaking, so much the problem as are the massive frameworks configured via distant files with lots of DI and reflection magic involved. Go has some large frameworks, but the community frequently suggests they aren't needed and that the standard library is enough.

So the community influences the language, not the language that influence the community that explains everything

Well, it's a bit of both. Java is of course very influential, and because it uses a framework for web applications, many languages/communities started imitating that (Ruby/Rails, PHP/Laravel, JS/[Framework_of_the_day] etc.). Then Go came along with its back-to-basics approach and its standard library which is "batteries included" but definitely not a framework, and for some this is a breath of fresh air, while for others it's apparently unbearably alien and backwards...

Re: One year after switching from Java to Go

#185

Post by roncesvalles »

someothherguyy wrote: post #182
roncesvalles wrote: post #171

Earlier quoted context omitted.

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

So, write python in go instead, gotcha.

The idiomatic way to write Go is as naively as possible after you fully understand how it works. Otherwise it'll just feel like Java with shitty ergonomics.

If you're ever writing Go and wish you had real classes instead of this deconstructed "mess" with struct types, methods, and interfaces, you're writing Go totally wrong.

Re: One year after switching from Java to Go

#186

Post by ninetyninenine »

God I hate working with Java developers on go projects. They try to introduce “design patterns” into the whole ecosystem and twist golang into doing something it wasn’t designed to do.

It’s a bit too late because tons of golang libraries are like this now.

Re: One year after switching from Java to Go

#187

Post by stpedgwdgfhgdd »

roncesvalles wrote: post #171
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…

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

I don't get the part on package. Often you want to use structs. (Instance vs static)

How would you construct an instance in a test that needs mock implementations?

Re: One year after switching from Java to Go

#188

Post by akoboldfrying »

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…

> Regarding stack traces, it turns out you don’t need them.

goes on to suggest rolling your own buggy, slow, informally specified implementation of half of a stack trace printer

Re: One year after switching from Java to Go

#189

Post by mrkeen »

winrid wrote: post #85
maccard wrote: post #9

Earlier quoted context omitted.

I worked on an app in kotlin a while back, and am currently working in a dotnet app. We can run our entire unit test suite faster than the JVM started up on that project. Also, 8 seconds is quick in my experience for Java - I’ve seen more like 15-30

The JVM starts in milliseconds Probably you're loading many thousands of classes...

It certainly tells me it does. i can hit 'run unit test', sit back in my chair and zone out for 5 seconds, then come back and read that the test took 22ms.

Re: One year after switching from Java to Go

#190

Post by roncesvalles »

stpedgwdgfhgdd wrote: post #187
roncesvalles wrote: post #171

Earlier quoted context omitted.

IoC DI in Go is a massive antipattern and absolutely should not be done. Do NOT write Java/.NET style controllers in Go i.e. initializing an instance of a "controller" type with some instances of a "dependency" such as a store. Just use the dependent package directly. Initialize the package once using init() or Init(). Rely on the built-in package dependency resolver system in Go, which will catch cyclic dependencies…

I don't get the part on package. Often you want to use structs. (Instance vs static) How would you construct an instance in a test that needs mock implementations?

Such an instance would just be a variable somewhere that would be initialized in some init() call when the program starts. Every user of that instance will use it directly (as opposed to storing a reference to it locally DI style).
Post reply on HN