Live data from Hacker News

I want off Mr. Golang’s Wild Ride (2020)

fasterthanli.me

161–170 of 477 posts

Re: I want off Mr. Golang’s Wild Ride (2020)

#161
post #140

Earlier quoted context omitted.

Well put and I agree with most points but > Go is not a fun language to program in Not having to think about how something should be done in the most elegant way, instead focus on the problem at hand is a lot of "fun"

True, fun is certainly different for everyone! I also enjoy being able to just focus on a real world problem, but I also programmed Scala professionally for many years, and I found it a lot more fun purely from the point of view of writing code. Writing a really elegant for comprehension or using currying in clever ways to make your code "elegant" was just enjoyable in and of itself, regardless of what problem you we…

Same. I use Go for work because that's what the company uses, but I can't imagine coding in it for "fun". Elm + Scala feel much better to me.

Re: I want off Mr. Golang’s Wild Ride (2020)

#162

Earlier quoted context omitted.

Inversely, virtually all languages with "easy FFI" end up being even more hostile in that a significant chunk of the ecosystem depends on C build tooling which is almost always fragile: C build systems have implicit dependency management, so you don't know what dependencies you need to have installed on your system or where they need to be installed. This means that something which builds on one machine may fail to b…

The Rust ecosystem does one better and packages the C libraries and build configuration (including making it portable across platforms) as part of the crate. So you just add the dependency to your Cargo.toml and the C library will build as part of the regular `cargo build` process.

Unless something has changed in the relatively recent past, I think you're overselling a fair bit. Not only does the package author have to understand the C dependency well enough to package it correctly on all platforms (basically by verifying the build in a hermetically sealed environment, and who is doing that?), but also the process for cross compiling is (or at least was) pretty complicated: https://www.modio.se/cross-compiling-rust-binaries-to-armv7..... And even then, I'm not sure this will yield a truly static binary (i.e., no dependency on libc).

In Go, it's just `CGO_ENABLED=0 GOARCH=armv7 GOOS=linux go build` for pure Go programs.

Re: I want off Mr. Golang’s Wild Ride (2020)

#163
post #26

Go has a lot of issues. Some of them would be easily fixable if people promoting and developing Go actually admitted the problems. However, the fanbase usually acts as a cult pretending that issues are features. Thing is, just like broken, hackish dependency "management" had to be fixed (introducing tons of complexity for the sake of not destroying backward compatibility), other problems will have to be fixed as well…

> However, the fanbase usually acts as a cult pretending that issues are features. Per Rob Pike (Lang NEXT 2014), golang was created for fairly young programmers that are fresh out of school and don't know many other languages. So, something I've observed: When somebody doesn't know many things but is building a career, planning their life, on one of the things they know, they're going to take that one thing more per…

Do you have any data or survey to back your statement? Forgive me if I've misunderstood you but are you saying that Golang is mostly used by young programmers?

In my experience most Golang developers are highly experienced... Same with Rust.

Re: I want off Mr. Golang’s Wild Ride (2020)

#164
post #65

Earlier quoted context omitted.

The Kubernetes codebase is huge, but in my (limited) experience I really felt like it was delivering on Go’s promise: that I can read any given file and understand what’s happening. At least when I needed to debug Kubernetes issues 4 years ago, I could grep around, dive into a file, and command-click to “go to definition” and quickly build a local understanding of the code around my problem. No spooky action. Everyth…

> It is tedious. > to reduce the variance between the best programmer on a project and the worst. In my experience the only way this can be done as with trying to level anything is to bring down the level of the best. I find this awful.

For small companies, variance can be good. For large companies, avoiding surprises is everything. So they cram a bunch of processes to make everyone a B player. That’s great if you’re naturally a C player, and can be less work if you’re a B+ player who wants to coast. But it’s hell hell if you’re an A player who is now working with handcuffs, and getting paid the same as the C player.

Re: I want off Mr. Golang’s Wild Ride (2020)

#165
post #144

"Cross platform handling is bad." That's all I've had the energy to extract. Isn't cross-platform software always a nasty compromise between not being able to do anything useful and being too specific to some OS or another. IMO go write a library if it really annoys you. There are much more unpleasant problems that I've had with the language but I've had more with C++ so ... it's a step up for me.

Read to the end. It eventually talks about monotonic clock bugs that affect every major platform, including Linux.

Re: I want off Mr. Golang’s Wild Ride (2020)

#166
post #68

Earlier quoted context omitted.

The latter is a much stronger argument than the former (no idea why people get so worked up about character counts), but even then, "shit" is really strong considering how often one experiences exception traces when using an application written in Python or Java or some other exception-based language. Point being, we should probably evaluate error handling schemes based on results rather than ideology (even though I…

Screen real estate is limited, especially vertical real estate. Compared to languages with saner error handling, I can read approximately 25% as much Go code at once. That's a real cognitive burden when maintaining code or learning your way around a new codebase, which seems especially egregious from a language whose community consistently proselytizes about how the lack of language features is great for maintainabil…

Additionally, the more repetitive code there is, the more opportunities there are for some subtle difference to be lurking in one particular chunk. And with pervasive boilerplate it becomes easier to eyeglaze past that subtle difference. Whether that difference is a bug or intentional, it's important to have code that highlights it by default.

Re: I want off Mr. Golang’s Wild Ride (2020)

#167
I am both bemused and empathetic for those who keep having this realization with Go. It is like an abusive relationship and people stay in it too long before realizing it is not going to get any better.

I took a look early on at Go. I tinkered with it and decided it would not work for me.

It lacked a lot of things that any new language should have, given the lessons learned in language design over the last few decades. It was clearly the result of a lot of NIH syndrome. It was built by Plan 9 guys to solve their problems on their preferred platform. For their purpose, I am sure it works just fine and is very comfortable for them. To expect it to be adapted to other kinds of problems and platforms is just wishful thinking.

For years, I have been hearing that Go will get generics and that it will be easy to add and use. I was working with Java before and after generics and saw what a mess it made to not design it in from the beginning. This made me skeptical that Go with generics would be as good as it could be. Now Go finally has generics and many are not happy. This should not be surprising.

This is why I see it as an abusive relationship. That partner you are so fond of is not going to change. Accept that and stay or move on.

Re: I want off Mr. Golang’s Wild Ride (2020)

#168

Earlier quoted context omitted.

And as a bonus, be statically linked with all the benefits that brings.

I recall statically compiling Rust to be a big pain (like, actually statically compiling, no dynamic dependencies on libc in Linux). I assume this is all the more true with arbitrary C dependencies?

If you have no C dependencies, it’s simple: you ask for the musl libc, and you’re done. It is not more onerous than go.

If you have C dependencies, then it does become a pain, depending on how well those dependencies' -sys packages interface with whatever build system they use.

Re: I want off Mr. Golang’s Wild Ride (2020)

#169
ZZzzZzzz I'm so bored of this article and I'm so bored of this author picking out extremely specific arguments about how things aren't exactly perfect for exactly his need, but moreso than anything I'm so bored of this culture of takedown posts being taken super seriously just because they're takedown posts, articles that are thirty pages long when they could be three or four, and the back-and-forth with cartoon characters blog posts.

> I've been suffering Go's idiosyncracies in relative silence for too long, there's a few things I really need to get off my chest.

this notion that because someone designed a tool in a way that is not exactly the way you wanted it to be is a form of suffering is ridiculous. You're not suffering, you are at best mildly inconvenienced.

> Most of Go's APIs (much like NodeJS's APIs) are designed for Unix-like operating systems.

This whole angle of attack is frankly absurd. Go's APIs (and the APIs of countless other ecosystems) are Unix-like because the Unix-like ecosystem is structured around interoperability. The reason that Go's APIs for dealing with Windows aren't as good as for other systems is that Microsoft has at every turn made their environments subtly different from other things often for no good reason at all.

This whole thing with making a file path with arbitrary byte strings that aren't representable in utf-8 is frankly embarassing. He's spinning a yarn about filesystem APIs and then goes on a tangent about string handling and how great it is that Rust displays one thing and Go displays another, but here's the rub: he used the `%s` format string operator, whose entire function is to print the uninterpreted bytes; if you want to print something quoted in a string-safe manner, you use `%q`. That entire section can be summarized in three lines of code:

    s := "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98"
    fmt.Printf("Hello, %s\n", s)
    fmt.Printf("Hello, %q\n", s)
https://go.dev/play/p/NVbLMhb7UkV

His examples are always like this: long, convoluted, and so complicated that people who know what's going on don't bother to interject because it's an impossibly tedious waste of time.

Re: I want off Mr. Golang’s Wild Ride (2020)

#170

Earlier quoted context omitted.

And as a bonus, be statically linked with all the benefits that brings.

I recall statically compiling Rust to be a big pain (like, actually statically compiling, no dynamic dependencies on libc in Linux). I assume this is all the more true with arbitrary C dependencies?

I'm not talking about an actual static binary, I'm talking about a typical "mostly static" binary with the handful of common dynamic dependencies.
Post reply on HN