3 ms·

I can’t stand go. It is painful and annoying to write compared to almost any modern language. Yes it’s simple, and makes it easy to write concurrent programs us

I can’t stand go. It is painful and annoying to write compared to almost any modern language. Yes it’s simple, and makes it easy to write concurrent programs using one particular style of concurrency, which are about the only good things anyone can say about it. The proponents of go seem to have an almost cult-like devotion to simplicity. They think adding any facility for abstraction makes a language into a complicated mess like C++, and any type system feature that didn’t exist in C makes a language into an ivory tower academic plaything like Haskell. The way the author talks about spending all day writing a perfectly beautiful, inscrutable piece of Rust code is an example of that. Yes, there are a few things in rust that are a bit harder to understand, but not to such an exaggerated extent, and that strawman is really not the typical experience when writing Rust. It’s very unusual for an experienced user of any mainstream language (except C++) to have any real difficulty understanding what a given piece of code does.

silisili 2y ago
I guess I'm part of that cult as I value simplicity greatly. Heck I was even against generics and iterators, though the former has grown on me a bit. One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go? There are so many good ones out there now, it feels like a person can choose something to their own liking. If it's being forced at work, I guess that makes some sense, but I'm also a big proponent of 'when in Rome.'
- School-Cotton 2y ago
  The thing about simplicity is making the language simpler often makes programs themselves more complex. For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, you have to either write them 10 times (meaning anyone reading the code has to read 10 different functions), or you have to write some code generator (meaning anyone reading the code has to now understand your code generator). And, all this cost in the complexity of programs is to avoid something that, in my opinion, _barely_ makes the language any more complex. So you're not uniformly increasing simplicity. I do agree that when there is a way to make a language simpler without any other downsides (e.g. making programs more complex or error-prone), it should always be done! Most people, even Go programmers, would think it was silly if you couldn't define your own functions and had to copy-paste blocks of code everywhere, so clearly they aren't against abstraction in principle. And I don't think generics is a particularly more complex form of abstraction than the ability to define functions is! The fundamental difference is not the level of abstraction, but just that _it didn't exist in C_, and the version of it in C++ (templates) is extremely difficult and unwieldy. So presumably that's what the designers of Go were afraid of. > One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go? I have to use Go because I am working in an ecosystem that is entirely in Go. Rewriting it in another language would be much more effort than is feasible. When I work on personal projects not for work I don't use Go at all. Also, not everyone uses Go because it lacks features for abstraction; there are other reasonable reasons to use it, for example if one likes the Goroutine-style concurrency model.
  - cherry_tree 2y ago
    > For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, Can you give an example of why you would need to do this? I use go everyday and have never had multiple copies of the same function as described here.
    - School-Cotton 2y ago
      There are tons of examples. So here's a random one: a function that sorts an array. You either need generics, need to write it using runtime polymorphism (making it significantly slower), or need to re-write it for every type of element that you want to sort an array of. The fact that Go has functions called sort.Strings, sort.Floats, sort.Ints, etc. is just silly duplication that wouldn't have happened in any other modern language.
      - cherry_tree 2y ago
        Wouldn’t you just use sort.Slice? Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.
        IshKebab 2y ago
        Sorting using generics is faster and more ergonomic. That's why they are adding generic based sort to the standard library. https://pkg.go.dev/golang.org/x/exp/slices#Sort https://pkg.go.dev/golang.org/x/exp/slices#Sort Sort on its own is maybe not the best example because it's relatively easy to work around, but those workarounds quickly break down. Write me a function that returns the keys of a map in order without using generics... I'm not exactly sure what your second point is.
        cherry_tree 2y ago
        But go isn’t a language without generics, so I don’t understand the criticism
- GaryNumanVevo 2y ago
  You value simplicity because all of the complicated and painful code (mostly as a fault of Go's shortcomings) have been abstracted away from you.
  - silisili 2y ago
    I guess that depends on your definition of simplicity. I don't think of simplicity as 'easy to do' or 'less lines of code', but in terms of easy to immediately understand what the code in question is doing, both from explicitness of said code and size of language. Perhaps I should have used 'readability.'
mbvisti 2y ago
For the record, I love Rust. It’s an amazing language and my example was not meant to discourage the use of Rust. But, it is verbose and generally takes longer time to write and understand compared to Go. For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.
- School-Cotton 2y ago
  > But, it is verbose and generally takes longer time to write and understand compared to Go. I respectfully disagree, and I don't think I'm alone in that. I would be willing to bet that the majority of people who have used both languages professionally would agree with me. Reading or writing N lines of Go is easier and faster than reading or writing N lines of Rust, true. But you have to repeat yourself so much in Go that doing the same thing takes a lot more lines of code than it does in Rust, so reading and understanding a whole program that does something useful is much harder. And that's just reading. Writing is even harder because Go has very few guardrails for protecting against important classes of bugs, so you spend way more time debugging issues that are just not a thing in Rust. > For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance. I disagree about speed of development for the reasons I said above. Ease of use is subjective; I find Rust much easier to use than Go (no exhaustive match on tagged unions in 2024? Really?) As for performance, Rust is hard to beat. So you're left with onboarding new people. Sure, Go is easier to learn than Rust. But it doesn't really make sense to optimize a language for the first 100 hours spent learning it when for most people it's a tool they will use for years.
  - mbvisti 2y ago
    I can’t claim to have been paid to write rust, but I’ve written code professionally for many years now and most of them in Go. I have also written my fair share of rust code for web applications. The repetition in Go, in my experience, mostly happens at the beginning and then you only have to deal with ‘if err != equal nil’, which to be fair is probably a good thing. Is it really more verbose and repetitive than error handling in rust? I would love to have the type system rust has in go. It really allows you to be expressive and put in guard rails in a way you can’t using go. But I don’t think most applications need that. My experience tells me something different than yours, maybe I’m wrong. But I can’t reconcile your arguments with my experience writing rust web applications. Even if I still miss writing my queries using sqlx and my views with asakama.
raincole 2y ago
Go is the epitome of "different people have different tastes." I completely understand why Go is designed as it is now. I can see the principles and crafts behind it. But I just can't bring myself to like it.

silisili 2y ago

I guess I'm part of that cult as I value simplicity greatly. Heck I was even against generics and iterators, though the former has grown on me a bit. One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go? There are so many good ones out there now, it feels like a person can choose something to their own liking. If it's being forced at work, I guess that makes some sense, but I'm also a big proponent of 'when in Rome.'

School-Cotton 2y ago
The thing about simplicity is making the language simpler often makes programs themselves more complex. For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, you have to either write them 10 times (meaning anyone reading the code has to read 10 different functions), or you have to write some code generator (meaning anyone reading the code has to now understand your code generator). And, all this cost in the complexity of programs is to avoid something that, in my opinion, _barely_ makes the language any more complex. So you're not uniformly increasing simplicity. I do agree that when there is a way to make a language simpler without any other downsides (e.g. making programs more complex or error-prone), it should always be done! Most people, even Go programmers, would think it was silly if you couldn't define your own functions and had to copy-paste blocks of code everywhere, so clearly they aren't against abstraction in principle. And I don't think generics is a particularly more complex form of abstraction than the ability to define functions is! The fundamental difference is not the level of abstraction, but just that _it didn't exist in C_, and the version of it in C++ (templates) is extremely difficult and unwieldy. So presumably that's what the designers of Go were afraid of. > One question I ask in earnest, why do people not just use another language rather than try to get features jammed into Go? I have to use Go because I am working in an ecosystem that is entirely in Go. Rewriting it in another language would be much more effort than is feasible. When I work on personal projects not for work I don't use Go at all. Also, not everyone uses Go because it lacks features for abstraction; there are other reasonable reasons to use it, for example if one likes the Goroutine-style concurrency model.
- cherry_tree 2y ago
  > For example, in a language without generics, if you have 10 different versions of the same function that only differ by a type parameter, Can you give an example of why you would need to do this? I use go everyday and have never had multiple copies of the same function as described here.
  - School-Cotton 2y ago
    There are tons of examples. So here's a random one: a function that sorts an array. You either need generics, need to write it using runtime polymorphism (making it significantly slower), or need to re-write it for every type of element that you want to sort an array of. The fact that Go has functions called sort.Strings, sort.Floats, sort.Ints, etc. is just silly duplication that wouldn't have happened in any other modern language.
    - cherry_tree 2y ago
      Wouldn’t you just use sort.Slice? Doesn’t go having such type specific functions mean you don’t have to? Feels like that makes your codebase _less_ complex since the core logic is handled by the language stdlib, not code written and maintained by your team.
      - IshKebab 2y ago
        Sorting using generics is faster and more ergonomic. That's why they are adding generic based sort to the standard library. https://pkg.go.dev/golang.org/x/exp/slices#Sort https://pkg.go.dev/golang.org/x/exp/slices#Sort Sort on its own is maybe not the best example because it's relatively easy to work around, but those workarounds quickly break down. Write me a function that returns the keys of a map in order without using generics... I'm not exactly sure what your second point is.
        cherry_tree 2y ago
        But go isn’t a language without generics, so I don’t understand the criticism
GaryNumanVevo 2y ago
You value simplicity because all of the complicated and painful code (mostly as a fault of Go's shortcomings) have been abstracted away from you.
- silisili 2y ago
  I guess that depends on your definition of simplicity. I don't think of simplicity as 'easy to do' or 'less lines of code', but in terms of easy to immediately understand what the code in question is doing, both from explicitness of said code and size of language. Perhaps I should have used 'readability.'

mbvisti 2y ago

For the record, I love Rust. It’s an amazing language and my example was not meant to discourage the use of Rust. But, it is verbose and generally takes longer time to write and understand compared to Go. For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance.

School-Cotton 2y ago
> But, it is verbose and generally takes longer time to write and understand compared to Go. I respectfully disagree, and I don't think I'm alone in that. I would be willing to bet that the majority of people who have used both languages professionally would agree with me. Reading or writing N lines of Go is easier and faster than reading or writing N lines of Rust, true. But you have to repeat yourself so much in Go that doing the same thing takes a lot more lines of code than it does in Rust, so reading and understanding a whole program that does something useful is much harder. And that's just reading. Writing is even harder because Go has very few guardrails for protecting against important classes of bugs, so you spend way more time debugging issues that are just not a thing in Rust. > For most projects, Go simply fits the bill for speed of development, ease of use, onboarding new people and performance. I disagree about speed of development for the reasons I said above. Ease of use is subjective; I find Rust much easier to use than Go (no exhaustive match on tagged unions in 2024? Really?) As for performance, Rust is hard to beat. So you're left with onboarding new people. Sure, Go is easier to learn than Rust. But it doesn't really make sense to optimize a language for the first 100 hours spent learning it when for most people it's a tool they will use for years.
- mbvisti 2y ago
  I can’t claim to have been paid to write rust, but I’ve written code professionally for many years now and most of them in Go. I have also written my fair share of rust code for web applications. The repetition in Go, in my experience, mostly happens at the beginning and then you only have to deal with ‘if err != equal nil’, which to be fair is probably a good thing. Is it really more verbose and repetitive than error handling in rust? I would love to have the type system rust has in go. It really allows you to be expressive and put in guard rails in a way you can’t using go. But I don’t think most applications need that. My experience tells me something different than yours, maybe I’m wrong. But I can’t reconcile your arguments with my experience writing rust web applications. Even if I still miss writing my queries using sqlx and my views with asakama.

raincole 2y ago

Go is the epitome of "different people have different tastes." I completely understand why Go is designed as it is now. I can see the principles and crafts behind it. But I just can't bring myself to like it.