Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lies we tell ourselves to keep using Golang (2022)

fasterthanli.me

Post reply on HN
Print view View original

251–260 of 526 posts

Re: Lies we tell ourselves to keep using Golang (2022)

#251

Post by matttproud »

GaryNumanVevo wrote: post #185
KingOfCoders wrote: post #182

Earlier quoted context omitted.

"quickly find yourself wanting slightly more modern language features." Use the tool that works for you.

Feel free to take a look at any more complicated GoLang code (k8s, gorm, etc) and you'll see that the tool/library you're depending on requires a veritable rats nest of bad practices to work around the Go's inherent limitations.

My opinion on Kubernetes as a yardstick example of Go is this:

This was one of the first large systems developed in Go, not too long after the language hit version 1.0 (ca. 12 years ago). What constituted good Go style and package architecture were not well known at that time even. Given that and hindsight being 20:20, I could easily imagine the internal architecture (not even the public surface) for Kubernetes being a lot different and simpler. The package architecture alone makes me cringe. As a hypothetical counterpoint, I wonder what Kubernetes would have looked like had Dave Cheney (https://dave.cheney.net/) and Rob Pike built it in that era. I think that would have been a better yard stick.

I have a unique appreciation for this first large systems perspective as I co-designed an adjacent product in the cloud native ecosystem at that time (Prometheus). There was no good example to follow when it came to large program structure and design in Go at that time. We were all figuring that out for ourselves — organically.

I think this point about organic evolution of the architecture is important to call out explicitly, because developers often look at an existing structure and essentially mimic it with their additions, changes, and refactors irrespective of whether the structure was correct for the problem it was trying to solve or even good. Given that reality, is it really any wonder that one of the first major pieces of software ended up being this metaphorical mess? And the truth is that's not a language-specific problem: it could have happened with any new language. And taking a legacy system of this age and refactoring is difficult from a social perspective, ignoring the gradient/cost of refactoring that is language-specific. You'll have a lot of people who will oppose structural change just because, so probably a significant refactoring to achieve these goals is just not in the cards.

Had there been so much as something similar to https://google.github.io/styleguide/go at that time (ca. 2012) (it's based on the very spartan https://go.dev/wiki/CodeReviewComments), that would have been tremendously useful and impactful in helping preserve simplicity.

Re: Lies we tell ourselves to keep using Golang (2022)

#252

Post by XorNot »

usrnm wrote: post #30
XorNot wrote: post #8

Earlier quoted context omitted.

When I started trying to teach myself Rust, the error handling story fell apart on me very quick. Like as soon as I wanted to try and get sensible reporting in their, suddenly we were relieving libraries, adding shims and fighting mismatched types and every article was saying the same thing: haha yeah it's kind of a problem. I'm very, very unsold on explicit error handling compared to exceptions for practical program…

The problems you're describing don't exist in go. There is exactly one standard type that is used by everyone, at least in public API's, you can always just return the error to the caller, if you don't want to handle it in place. The main difference with exceptions in my practice is the fact that it's a lot easier to mess up, since it requires manual typing. This is probably my main problem with everything being as e…

I think that sort of nails it: the problem with errors as values is errors become part of the type signature and put under user control, and the user can't really be trusted with that power.

Even the simplest functions tend to have error states - i.e. floating point math can always wind up handing back NaN.

So where I end up is, the default assumption is every function is effectively of a type MightError(T)...so why even make us type this? Why not just assume it, assume the unwrap handling code, and so you basically wind up back at try-catch exception handling as a syntactic sugar for that whole system.

Re: Lies we tell ourselves to keep using Golang (2022)

#253

Post by Daegalus »

guappa wrote: post #144
wokwokwok wrote: post #83

Earlier quoted context omitted.

> I guess I feel bad for people who are particularly sensitive to the areas that Go does not succeed in, because they are probably going to be complaining about it for the rest of their lives. Well, that’s a stellar endorsement of the article, because that’s literally the point they’re making. You’ll use go. …and then regret it. …but by then it’ll be too late, and you’re stuck with it. I think the author makes a comp…

In my personal experience your average go developer that likes go, likes it because he doesn't really know anything else. As a result most things written in go are, in my own experience, of lower quality compared to things written in other languages. So using things written in go is usually my last resort, because I expect they won't be high quality before even downloading them.

That is an interesting experience, as I find the opposite true in most of my cases.

And I am a go developer that likes go and use it for 95% of my coding, including MMO servers. I love programming languages and have used and dabbled in many. I still go to go.

And many go tools I use tend to be pretty well written. But maybe this is just a sample size of 1 vs a sample size of 1 issue.

Re: Lies we tell ourselves to keep using Golang (2022)

#254

Post by guappa »

underdeserver wrote: post #160
guappa wrote: post #151

Earlier quoted context omitted.

Go is very boilerplate. It requires at least 3 lines of error checking every 1 line of actual code. Also it doesn't have packed structs so it's completely incapable of doing low level networking or to handle binary files (you can of course do all the bitwise operations yourself… but is it sensible to use a language that is more error prone than C in 2024?). Also due to its lack of A LOT of system calls, you will need…

I worked on a project with gopacket. It was completely fine.

Try defining a new packet format and ping me.

Re: Lies we tell ourselves to keep using Golang (2022)

#255

Post by Daegalus »

ivell wrote: post #237
sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

There is Crystal and Nim. With especially Nim, there is GC and generates c in the end.

I love Crystal, but the lack of a proper LSP and tooling makes it hard to just jump in and adopt for bigger projects.

Re: Lies we tell ourselves to keep using Golang (2022)

#256

Post by guappa »

Daegalus wrote: post #253
guappa wrote: post #144

Earlier quoted context omitted.

In my personal experience your average go developer that likes go, likes it because he doesn't really know anything else. As a result most things written in go are, in my own experience, of lower quality compared to things written in other languages. So using things written in go is usually my last resort, because I expect they won't be high quality before even downloading them.

That is an interesting experience, as I find the opposite true in most of my cases. And I am a go developer that likes go and use it for 95% of my coding, including MMO servers. I love programming languages and have used and dabbled in many. I still go to go. And many go tools I use tend to be pretty well written. But maybe this is just a sample size of 1 vs a sample size of 1 issue.

From go programs at the very least I can expect they won't respect normal GNU getopt command line options, and work terribly with signals and going background in the terminal and so on.

If it's a server, of course it won't support any way of communicating it's ready. Not the old fork way and certainly not the new sdnotify things.

Re: Lies we tell ourselves to keep using Golang (2022)

#257

Post by coldtea »

jchw wrote: post #235
coldtea wrote: post #203

Earlier quoted context omitted.

> There's no tool boring enough to prevent any chance of regret. I'm not so sure. I know C programmers that swear by it, warts and all, with absolutely zero regrets for using it e.g. in the embedded space.

If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings. Using C in embedded development is probably OK, even if you have to suffer with whatever crappy vendor compiler you are stuck with, but tha…

>If anyone tells you C is "boring", that's just plain and simple bullshit. C gives you undefined behavior, buggy compilers (yes even for simple C code, MSVC is especially bad at plain C but there are other offenders) and the world's worst standard library for manipulating strings.

Boring doesn't mean "has no issues" or "takes care of everything for you".

It means, stable syntax, lots of mature tooling and compilers, and any problems the language has are well known.

Of the various languages around, C is the least likely one to have "buggy compilers" (issues in MSVC because MS compilers focus on C++ are a different thing, also falling in the "known" category).

Re: Lies we tell ourselves to keep using Golang (2022)

#258

Post by LinXitoW »

theshrike79 wrote: post #87
liotier wrote: post #59

Earlier quoted context omitted.

Unsure if this is the right place to ask, but this conversation inspires me this question: Is there in practice a significant difference between try/catch and Go's "if err" ? Both seem to achieve the same purpose, though try/catch can cover a whole bunch of logic rather than a single function. Is that the only difference ?

You can decide not to catch a thrown exception, it travels upwards automatically if you don't catch it. I think that's the biggest difference. With Go you need to specifically check the errors and intentionally decide what to do, do you handle it right there or do you bubble it upwards. If you do, what kind of context would the caller want from this piece of code, you can add that too.

I'd argue that at least checked exceptions also require a conscious decision from you. You either need to add the Exception type to your throws clause, or your catch clause.

Compared to Go, this is actually better because the type system can tell you what kind of errors to expect, instead of just "error".

Re: Lies we tell ourselves to keep using Golang (2022)

#259

Post by Daegalus »

sureglymop wrote: post #133

Rust and Go are very different and I feel people want a middle ground that just doesn't exist currently. A garbage collected relatively simple language that compiles into a statically linked binary but has a type system similar to rust, rest types etc. Syntactically, Gleam and Kotlin come somewhat close but not really. I like Rust but I do believe it is too complicated for many people who are capable of creating some…

I think Inko (https://inko-lang.org/) has the potential to be that language with some tooling/adoption/maturation

Re: Lies we tell ourselves to keep using Golang (2022)

#260

Post by Mawr »

chikere232 wrote: post #40
forrestthewoods wrote: post #18

Earlier quoted context omitted.

Because someone decides what language to write a new thing in is very likely to consider Go and Rust. They are very unlikely to consider Java. Are Rust and Go sufficiently different that they should each be chosen in different cases? Sure! But that’s literally why someone would consider both and pick one.

They should consider Java though. People have an irrational hate for it based on the enterprise cruft and horrible third party frameworks you can just completely ignore if you build a new thing It's not good for commandline stuff but for a long running small service it is pretty great

That's a big if. In practice you're not going to be able to escape needing to interface with Java code others have written. What then? You either waste time putting up shims in front of every single API or, more likely, give up and just go with it, at which point you've lost.

It is much more practical to choose a language that does not have a terrible history of poor API design to begin with.

Post reply on HN