Most active commenters
  • yencabulator(4)
  • kragen(3)

←back to thread

Go is still not good

(blog.habets.se)
644 points ustad | 11 comments | 22 Aug 25 09:25 UTC | HN request time: 0.019s | source | bottom
Show context
blixt ◴[22 Aug 25 11:35 UTC] No.44983245[source]▶
I've been using Go more or less in every full-time job I've had since pre-1.0. It's simple for people on the team to pick up the basics, it generally chugs along (I'm rarely worried about updating to latest version of Go), it has most useful things built in, it compiles fast. Concurrency is tricky but if you spend some time with it, it's nice to express data flow in Go. The type system is most of the time very convenient, if sometimes a bit verbose. Just all-around a trusty tool in the belt.

But I can't help but agree with a lot of points in this article. Go was designed by some old-school folks that maybe stuck a bit too hard to their principles, losing sight of the practical conveniences. That said, it's a _feeling_ I have, and maybe Go would be much worse if it had solved all these quirks. To be fair, I see more leniency in fixing quirks in the last few years, like at some point I didn't think we'd ever see generics, or custom iterators, etc.

The points about RAM and portability seem mostly like personal grievances though. If it was better, that would be nice, of course. But the GC in Go is very unlikely to cause issues in most programs even at very large scale, and it's not that hard to debug. And Go runs on most platforms anyone could ever wish to ship their software on.

But yeah the whole error / nil situation still bothers me. I find myself wishing for Result[Ok, Err] and Optional[T] quite often.

replies(18): >>44983384 #>>44983427 #>>44983465 #>>44983479 #>>44983531 #>>44983616 #>>44983802 #>>44983872 #>>44984433 #>>44985251 #>>44985721 #>>44985839 #>>44986166 #>>44987302 #>>44987396 #>>45002271 #>>45002492 #>>45018751 #
xyzzyz ◴[22 Aug 25 11:56 UTC] No.44983427[source]▶
Go was designed by some old-school folks that maybe stuck a bit too hard to their principles, losing sight of the practical conveniences.

I'd say that it's entirely the other way around: they stuck to the practical convenience of solving the problem that they had in front of them, quickly, instead of analyzing the problem from the first principles, and solving the problem correctly (or using a solution that was Not Invented Here).

Go's filesystem API is the perfect example. You need to open files? Great, we'll create

  func Open(name string) (*File, error)
function, you can open files now, done. What if the file name is not valid UTF-8, though? Who cares, hasn't happen to me in the first 5 years I used Go.
replies(10): >>44983477 #>>44983490 #>>44983605 #>>44984231 #>>44984419 #>>44985099 #>>44985582 #>>44985985 #>>44988513 #>>44993106 #
koakuma-chan ◴[22 Aug 25 12:04 UTC] No.44983490[source]▶
> What if the file name is not valid UTF-8

Nothing? Neither Go nor the OS require file names to be UTF-8, I believe

replies(3): >>44983611 #>>44983702 #>>44985411 #
zimpenfish ◴[22 Aug 25 14:56 UTC] No.44985411[source]▶
> Nothing?

It breaks. Which is weird because you can create a string which isn't valid UTF-8 (eg "\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98") and print it out with no trouble; you just can't pass it to e.g. `os.Create` or `os.Open`.

(Bash and a variety of other utils will also complain about it being valid UTF-8; neovim won't save a file under that name; etc.)

replies(2): >>44986040 #>>44988615 #
1. yencabulator ◴[22 Aug 25 15:49 UTC] No.44986040{3}[source]▶
That sounds like your kernel refusing to create that file, nothing to do with Go.

  $ cat main.go
  package main

  import (
   "log"
   "os"
  )

  func main() {
   f, err := os.Create("\xbd\xb2\x3d\xbc\x20\xe2\x8c\x98")
   if err != nil {
    log.Fatalf("create: %v", err)
   }
   _ = f
  }
  $ go run .
  $ ls -1
  ''$'\275\262''='$'\274'' ⌘'
  go.mod
  main.go
replies(3): >>44988948 #>>44989617 #>>44996439 #
2. commandersaki ◴[22 Aug 25 19:42 UTC] No.44988948[source]▶
I'm confused, so is Go restricted to UTF-8 only filenames, because it can read/write arbitrary byte sequences (which is what string can hold), which should be sufficient for dealing with other encodings?
replies(1): >>44989010 #
3. yencabulator ◴[22 Aug 25 19:49 UTC] No.44989010[source]▶
Go is not restricted, since strings are only conventionally utf-8 but not restricted to that.
replies(1): >>44991666 #
4. zimpenfish ◴[22 Aug 25 20:47 UTC] No.44989617[source]▶
> That sounds like your kernel refusing to create that file

Yes, that was my assumption when bash et al also had problems with it.

5. commandersaki ◴[23 Aug 25 00:23 UTC] No.44991666{3}[source]▶
Then I am having a hard time understanding the issue in the post, it seems pretty vague, is there any idea what specific issue is happening, is it how they've used Go, or does Go have an inherent implementation issue, specifically these lines:

If you stuff random binary data into a string, Go just steams along, as described in this post.

Over the decades I have lost data to tools skipping non-UTF-8 filenames. I should not be blamed for having files that were named before UTF-8 existed.

replies(3): >>44992042 #>>44992430 #>>44996448 #
6. comex ◴[23 Aug 25 01:20 UTC] No.44992042{4}[source]▶
Yeah, the complaint is pretty bizarre, or at least unclear.
7. yencabulator ◴[23 Aug 25 02:17 UTC] No.44992430{4}[source]▶
Let me translate: "I have decided to not like something so now I associate miscellaneous previous negative experiences with it"
8. kragen ◴[23 Aug 25 14:55 UTC] No.44996439[source]▶
I've posted a longer explanation in https://news.ycombinator.com/item?id=44991638. I'm interested to hear which kernel and which firesystem zimpenfish is using that has this problem.
replies(1): >>44996727 #
9. kragen ◴[23 Aug 25 14:56 UTC] No.44996448{4}[source]▶
The post is wrong on this point, although it's mostly correct otherwise. Just steaming along when you have random binary data in a string, as Golang does, is how you avoid losing data to tools that skip non-UTF-8 filenames, or crash on them.
10. yencabulator ◴[23 Aug 25 15:35 UTC] No.44996727[source]▶
I believe macOS forces UTF-8 filenames and normalizes them to something near-but-not-quite Unicode NFD.

Windows doing something similar wouldn't surprise me at all. I believe NTFS internally stores filenames as UTF-16, so enforcing UTF-8 at the API boundary sounds likely.

replies(1): >>44997033 #
11. kragen ◴[23 Aug 25 16:26 UTC] No.44997033{3}[source]▶
That sounds right. Fortunately, it's not my problem that they're using a buggy piece of shit for an OS.