3 ms·

I think OP’s point is that given the go devs casual disregard for every development in PL theory and design over the last 30 years, it’s amusing to watch them r

I think OP’s point is that given the go devs casual disregard for every development in PL theory and design over the last 30 years, it’s amusing to watch them rediscover half the issues from scratch.

skybrian 3y ago
This meme is commonly repeated on HN, but I think it's inaccurate or at least greatly exaggerated. There's nothing casual about Go's approach to language design, and I haven't seen any evidence that they're unaware of what other languages do. I also haven't seen much criticism of languages other than C++ or Java.
- bobbylarrybobby 3y ago
  If they're aware of how other languages either handle these issues or suffer the consequences of not handling them, then it sure is odd that they consciously decided to introduce the same issues into their own language, only to fix them down the road.
  - skybrian 3y ago
    Given Go’s success, it seems like fixing certain footguns much later actually worked out pretty well for them? That doesn’t necessarily mean it was right, but it was perhaps not as big a deal as some people assume.
- FridgeSeal 3y ago
  Sum/Product types. Generics/type-parameters. Bizarre handling of nil in places. Error handling that’s like some deliberately crippled version of a Result<T,E>. The absolutely unhinged decision about zero-value-defaults for types. I’m sure other people can think of some more, but that’s the ones I can think of off the top of my head. Non PL theory but related: incorrect implementation of monotonic clocks, and then refusing to fix it because “just use google smear time bro”.
  - skybrian 3y ago
    Everyone who disagrees with you is “unhinged.” This is just name-calling.
    - FridgeSeal 3y ago
      But they’re like, genuinely wild decisions? Unhinged is a great description! The error design can return the value, or an error, or both, for some inexplicable reason and you can check it - or not - and if your function returned some indication of severe error, and you happen to not check it, you can totes just continue your program, in who knows what invalid state. Oh and also, because the devs are apparently deathly allergic to abstractions of apparently kind, you’ve got to do this janky little if err != nil check at. every. single. point. Which occludes your fundamentally important logic in pointless line noise, with zero opportunity for streamlining or improving the logic or guarantees.
  - kiitos 3y ago
    Go definitely implements monotonic clocks correctly? https://pkg.go.dev/time#hdr-Monotonic_Clocks https://pkg.go.dev/time#hdr-Monotonic_Clocks
    - FridgeSeal 3y ago
      It definitely didn’t used to lol: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
      - kiitos 3y ago
        That article is so cringeworthy
        FridgeSeal 3y ago
        I disagree, but the style isn’t for everyone. However, that still doesn’t mean that it’s wrong.

skybrian 3y ago

This meme is commonly repeated on HN, but I think it's inaccurate or at least greatly exaggerated. There's nothing casual about Go's approach to language design, and I haven't seen any evidence that they're unaware of what other languages do. I also haven't seen much criticism of languages other than C++ or Java.

bobbylarrybobby 3y ago
If they're aware of how other languages either handle these issues or suffer the consequences of not handling them, then it sure is odd that they consciously decided to introduce the same issues into their own language, only to fix them down the road.
- skybrian 3y ago
  Given Go’s success, it seems like fixing certain footguns much later actually worked out pretty well for them? That doesn’t necessarily mean it was right, but it was perhaps not as big a deal as some people assume.
FridgeSeal 3y ago
Sum/Product types. Generics/type-parameters. Bizarre handling of nil in places. Error handling that’s like some deliberately crippled version of a Result<T,E>. The absolutely unhinged decision about zero-value-defaults for types. I’m sure other people can think of some more, but that’s the ones I can think of off the top of my head. Non PL theory but related: incorrect implementation of monotonic clocks, and then refusing to fix it because “just use google smear time bro”.
- skybrian 3y ago
  Everyone who disagrees with you is “unhinged.” This is just name-calling.
  - FridgeSeal 3y ago
    But they’re like, genuinely wild decisions? Unhinged is a great description! The error design can return the value, or an error, or both, for some inexplicable reason and you can check it - or not - and if your function returned some indication of severe error, and you happen to not check it, you can totes just continue your program, in who knows what invalid state. Oh and also, because the devs are apparently deathly allergic to abstractions of apparently kind, you’ve got to do this janky little if err != nil check at. every. single. point. Which occludes your fundamentally important logic in pointless line noise, with zero opportunity for streamlining or improving the logic or guarantees.
- kiitos 3y ago
  Go definitely implements monotonic clocks correctly? https://pkg.go.dev/time#hdr-Monotonic_Clocks https://pkg.go.dev/time#hdr-Monotonic_Clocks
  - FridgeSeal 3y ago
    It definitely didn’t used to lol: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
    - kiitos 3y ago
      That article is so cringeworthy
      - FridgeSeal 3y ago
        I disagree, but the style isn’t for everyone. However, that still doesn’t mean that it’s wrong.