Live data from Hacker News

One year after switching from Java to Go

glasskube.dev

101–110 of 503 posts

Re: One year after switching from Java to Go

#101
post #40

> 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…

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?

Re: One year after switching from Java to Go

#102

> 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…

How are interfaces a replacement or improvement to context? Is it just that they're type safe?

Re: One year after switching from Java to Go

#103

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 i…

    > But now that Go is routinely compared with Java/Kotlin and friends
Do you think Go is "moving up" (away from systems prog) or is Java "moving down"?

Re: One year after switching from Java to Go

#104

> 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.

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.

Re: One year after switching from Java to Go

#105

As a Java developer... If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'. Java is good right now because most problems have libraries to do what you want. Most formats have APIs. It's not perfect in any area - the start-up time is a bit lame, you have to…

Yeah, language ecosystems get no love here. Part of me dreads Java, but the developer experience is mostly worse elsewhere.

Re: One year after switching from Java to Go

#106
post #66

As a Java developer... If the entire problem domain space is written in a language it's dumb not to follow suit. Libraries that solve problems reduce your work to your own specific issues, rather than 'building an apple pie from scratch'. Java is good right now because most problems have libraries to do what you want. Most formats have APIs. It's not perfect in any area - the start-up time is a bit lame, you have to…

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.

Re: One year after switching from Java to Go

#107
post #81
post #77

Earlier quoted context omitted.

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

https://github.com/codr7/tyred-java/tree/main/src/codr7/tyre... 24 of those files are under 100 lines - some of them are as small as three lines of code. and that's not a personal preference - that's mandated by Java that each type needs to be in its own file, ridiculous.

I don't see that as a problem at all, just like I don't see header files in C++ as a major problem, there are benefits as well and Java has the best IDEs of any language I've worked in except maybe SmallTalk.

Re: One year after switching from Java to Go

#108
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…

I've written ORMs for both Java and Go and agree that Java is a wonderful language with a much more complete type system than Go. However, it feels like Java web development teams typically suffer from not having their own Wagtail/Payload/etc and build way too much from scratch. Maybe there is some great open source framework+CMS out there making waves in Java land that I'm unaware of?

Re: One year after switching from Java to Go

#109
post #74

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).

    > or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc).
Why hasn't anyone written a good open source for this problem, now that Go has generics?

Re: One year after switching from Java to Go

#110
post #44
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…

This comment is about a very minor part of what you said, but isn’t the whole point of a DI framework to write code you’d have written anyway to save you time?

I was writing code similar to how the popular int13 kubelogin kubectl plugin works, which also uses wire for DI and is organized as a clean architecture repo. In that particular case I found both the clean architecture and the wire DI to add more layers of abstraction, which took more time to comprehend, write, and maintain than jettisoning both and doing it with idiomatic Go.
Post reply on HN