131–140 of 503 posts
Earlier quoted context omitted.
I actually much prefer go ‘s runtime tooling. Pprof has everything I need built in; heap, cpu, blocking, mutex contention. And don’t need additional tools to visualize the collected data. https://pkg.go.dev/net/http/pprof@go1.24.0
Does pprof work when CGO is enabled?
Earlier quoted context omitted.
> 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.
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"?
I haven't been keeping score, but I've read other articles like this one claiming Go as an enterprise language alternative to Java. Not much concerning Java as a systems language, but that makes good sense. I see Go v. C/Rust, not Go v. Java/Kotlin. Just my take.
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?
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 work with a brownfield go monorepo with a couple different styles and lesser known “frameworks” in it. It sucks to work in, one of the previous devs was a huge fan of clean code, so every function with more than a couple inputs has its own struct, pointers are used everywhere just by default (and basically never nil checked) and the AI generated tests are so plentiful that changing a small thing quickly explodes in…
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…
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…
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.
Each public type, but in general I agree, this is ridiculous decision.
I long for a deep article about the same topic. The real, core difference between Java and Go for backend is declarative vs imperative coding styles. This one, as typical for such articles, repeats typical secondary talking points and even makes similar mistakes. For example it conflates the concept of DI with specifics of implementation in some frameworks. Yes there are older Java frameworks that do runtime magic. B…