5 ms·

What is it about go that makes it 'non-existent' ?

ed25519FUUU 6y ago
The feeling "there's probably a much better way of doing this" because the chances are there's really not. For better or for worse, there's simply not a lot of ways to accomplish the same task in Go.
- whateveracct 6y ago
  There typically is a better way to do pretty much everything you write in Go..but Go doesn't support it. It's just Worse is Better The language for better or worse.
Scarbutt 6y ago
Less features.
chc 6y ago
To be clear, I think it's mainly nonexistent if you haven't worked in more powerful languages than Go before. All those people complaining about lack of generics and stuff probably are experiencing that feeling. Go is simple enough that the way you write something is likely to be at least very much along the right track to the the best way you could write it in Go. But that won't necessarily stop you thinking of other ways that just aren't supported by the language.
loopz 6y ago
What Gophers mean by that is that golang nudges you to write the naive, straightforward and readable solution at first. This sidesteps premature optimization and false design choices too early on. In practice go stdlib and direct code tend to be faster than clever and more complex alternatives.
- zozbot234 6y ago
  Rust similarly nudges you to write the highest-performing-but-still-safe solution. You can opt into "convenience" features that come with some overhead, but that always involves some extra boilerplate so you'll know where a refactor may improve performance. And you can add unsafety, but it will always be clearly marked. I actually think Rust has a better story of what it "nudges" devs to write. Go strives for a very fuzzy feeling of surface simplicity, but in practice it's way less principled.
  - loopz 6y ago
    Go is faster to write, read, can have faster defaults/libs and less need for choice. I'd consider rust where further optimization is warranted.
hombre_fatal 6y ago
Because Go lacks powerful tools like sum types and generics. In a language like Rust or Haskell, you're always asking yourself if you can better express the problem in the type system, or which constructs you can use that, say, make runtime errors impossible. In Go, your tools are limited to copy-and-paste and `interface{}` type-casting. There are no better options to consider, so you try to untrain your brain from its reflex of "hmm this is error prone, I should find a better way." A good example of this is when you're parsing a binary file into a sequence of record structs. In a language like Typescript or Rust, you just make one ergonomic `Record = Record1(int, int) | Record2(string) | ...` and `fn parse([]byte) -> []Record`. In Go, the best you have is `fn parse([]byte) -> []interface{}` with type-casting.
- damnyou 6y ago
  That sounds like it would increase the load on your brain, not decrease it.
  - masklinn 6y ago
    I guess they mean it doesn't give you that feeling of "there must be a better way" because chances are very high there is not, and so after some time looking for better ways and never finding them, since there's no feedback loop of "yeah I found a better way!" that feeling stops occurring.

The feeling "there's probably a much better way of doing this" because the chances are there's really not. For better or for worse, there's simply not a lot of ways to accomplish the same task in Go.

whateveracct 6y ago
There typically is a better way to do pretty much everything you write in Go..but Go doesn't support it. It's just Worse is Better The language for better or worse.

Scarbutt 6y ago

Less features.

chc 6y ago

To be clear, I think it's mainly nonexistent if you haven't worked in more powerful languages than Go before. All those people complaining about lack of generics and stuff probably are experiencing that feeling. Go is simple enough that the way you write something is likely to be at least very much along the right track to the the best way you could write it in Go. But that won't necessarily stop you thinking of other ways that just aren't supported by the language.

loopz 6y ago

What Gophers mean by that is that golang nudges you to write the naive, straightforward and readable solution at first. This sidesteps premature optimization and false design choices too early on. In practice go stdlib and direct code tend to be faster than clever and more complex alternatives.

zozbot234 6y ago
Rust similarly nudges you to write the highest-performing-but-still-safe solution. You can opt into "convenience" features that come with some overhead, but that always involves some extra boilerplate so you'll know where a refactor may improve performance. And you can add unsafety, but it will always be clearly marked. I actually think Rust has a better story of what it "nudges" devs to write. Go strives for a very fuzzy feeling of surface simplicity, but in practice it's way less principled.
- loopz 6y ago
  Go is faster to write, read, can have faster defaults/libs and less need for choice. I'd consider rust where further optimization is warranted.

hombre_fatal 6y ago

Because Go lacks powerful tools like sum types and generics. In a language like Rust or Haskell, you're always asking yourself if you can better express the problem in the type system, or which constructs you can use that, say, make runtime errors impossible. In Go, your tools are limited to copy-and-paste and `interface{}` type-casting. There are no better options to consider, so you try to untrain your brain from its reflex of "hmm this is error prone, I should find a better way." A good example of this is when you're parsing a binary file into a sequence of record structs. In a language like Typescript or Rust, you just make one ergonomic `Record = Record1(int, int) | Record2(string) | ...` and `fn parse([]byte) -> []Record`. In Go, the best you have is `fn parse([]byte) -> []interface{}` with type-casting.

damnyou 6y ago
That sounds like it would increase the load on your brain, not decrease it.
- masklinn 6y ago
  I guess they mean it doesn't give you that feeling of "there must be a better way" because chances are very high there is not, and so after some time looking for better ways and never finding them, since there's no feedback loop of "yeah I found a better way!" that feeling stops occurring.