9 ms·

Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple langua

Go: "I'm a simple language!" User uses Go for some time. User: "I hate you, you're a simple language!" Perhaps it's because I'm 50+, I love a simple language. I feel the "critique" is not very balanced, and I view judgements that are not balanced as weak, as everything in technology is about tradeoffs. I of course come to a different conclusion: https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our-startup https://www.inkmi.com/blog/why-we-chose-go-over-rust-for-our...

richbell 2y ago
I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 https://archive.ph/WcyF4). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".
- jonathanstrange 2y ago
  I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.
  - LinXitoW 2y ago
    I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy. Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard library a special exception with maps and lists. That's easy, but not simple. People used to literally use code generators or weird UTF-8 characters to fake generics, that's not remotely simple.
    - stouset 2y ago
      Frankly code generators to fake generics aren’t remotely easy either.
- nulld3v 2y ago
  This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things. And plenty of other examples that aren't in that article: - You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever embedded struct is fulfilling the inner interface? - When should I pass by value and when should I pass by reference? Like I generally know when to choose which, but do I really know without performing a benchmark? And what about arrays? Should I store pointers in them? But it also seems that people just don't care and just randomly roll the dice on when to return a pointer or a value? - Shorthand variable declaration. How does it work when you shorthand declare two variables but one of them already exists? Don't both answering the questions, that's not the problem. The problem is that it's just not intuitive enough such that I'm confident I know the correct answer.
  - KingOfCoders 2y ago
    Your thinking is too complex for Go. You might be better of with Rust. Same about benchmarking, if you want and need the fastest code, or the best memory management, use Rust. If you need something faster than Python in general but not the fastest, use Go.
    - nulld3v 2y ago
      But that's the thing right? Like I come from Java. In Java, we have objects. They are pointers. That's it. You don't get to decide on whether you want a pointer or a value (I guess primitives are an exception lol). But it was so simple! And same in JavaScript. Everything is a pointer except primitives. That's it. End of story. And I have written Rust too, and while the situation is definitely more complicated there, the guidance is extremely simple and straightforward: If the struct implements Copy, then it is very cheap to copy and you should pass by value. Otherwise, you should pass by pointer/reference. And meanwhile in Go, I just see pointers and values being used seemingly interchangeably, and seemingly at random.
  - ralegh 2y ago
- KingOfCoders 2y ago
  Yes, like "Opening Brace Can't Be Placed on a Separate Line" (from your link). Everyone can read Go code and understand what happens. There are some minor difficulties like func (*A) vs func (A).,
  - eru 2y ago
    RiscV assembly is even easier to read by that metric.
    - KingOfCoders 2y ago
      My assembler days were 4 decades ago, but "Everyone can read Go code and understand what happens." There seems to be a difference between "easy to read" and "understand what happens" - or what happens on what level. The challenge is that there is a tradeoff between the two. Assembler is too low to understand what "really" happens, on the other hand Haskell for example with Monad stacks is again very easy to read + understand what happens "most of the time", but hard to understand all the abstracted away side effects. In Haskell with add 3 5 everything can happen beside what you see. In assembler ld a, 3 add a, 5 nothing happens except these two instructions. The tradeoff is how much you want to be explicit, with the downside of creating too much noise, and how much you want to abstract away, with the downside of magic happening somewhere.
      - eru 2y ago
        Yes. And to be less snarky: Go doesn't really sit on the efficiency frontier here: It requires you to write a lot of stuff by hand and is incredibly verbose, but it also does a lot of magic behind the scenes.
- LandR 2y ago
  It's easy not simple, but the consequence is that any complexity that other languages handles for you, in go gets forced onto the developer. There's more stuff to think about, because the language is doing less for you.
GaryNumanVevo 2y ago
Go is "simple" insofar as you're doing simple things. If you've tried writing a KV store or database (as I have) you'll quickly find yourself wanting slightly more modern language features.
- KingOfCoders 2y ago
  "quickly find yourself wanting slightly more modern language features." Use the tool that works for you.
  - GaryNumanVevo 2y ago
    Feel free to take a look at any more complicated GoLang code (k8s, gorm, etc) and you'll see that the tool/library you're depending on requires a veritable rats nest of bad practices to work around the Go's inherent limitations.
    - matttproud 2y ago
      My opinion on Kubernetes as a yardstick example of Go is this: This was one of the first large systems developed in Go, not too long after the language hit version 1.0 (ca. 12 years ago). What constituted good Go style and package architecture were not well known at that time even. Given that and hindsight being 20:20, I could easily imagine the internal architecture (not even the public surface) for Kubernetes being a lot different and simpler. The package architecture alone makes me cringe. As a hypothetical counterpoint, I wonder what Kubernetes would have looked like had Dave Cheney (https://dave.cheney.net/ https://dave.cheney.net/) and Rob Pike built it in that era. I think that would have been a better yard stick. I have a unique appreciation for this first large systems perspective as I co-designed an adjacent product in the cloud native ecosystem at that time (Prometheus). There was no good example to follow when it came to large program structure and design in Go at that time. We were all figuring that out for ourselves — organically. I think this point about organic evolution of the architecture is important to call out explicitly, because developers often look at an existing structure and essentially mimic it with their additions, changes, and refactors irrespective of whether the structure was correct for the problem it was trying to solve or even good. Given that reality, is it really any wonder that one of the first major pieces of software ended up being this metaphorical mess? And the truth is that's not a language-specific problem: it could have happened with any new language. And taking a legacy system of this age and refactoring is difficult from a social perspective, ignoring the gradient/cost of refactoring that is language-specific. You'll have a lot of people who will oppose structural change just because, so probably a significant refactoring to achieve these goals is just not in the cards. Had there been so much as something similar to https://google.github.io/styleguide/go https://google.github.io/styleguide/go at that time (ca. 2012) (it's based on the very spartan https://go.dev/wiki/CodeReviewComments https://go.dev/wiki/CodeReviewComments), that would have been tremendously useful and impactful in helping preserve simplicity.
zozbot234 2y ago
Scheme is a simple language, Go just hides complexity until it blows up in the worst possible way. (Of course, most reasonable alternatives to Go are even worse from that POV. See Python, Ruby, JS etc.)
serial_dev 2y ago
Very common misrepresentation of any critique of Go. "You just don't get simplicity, you got them Java brainwormz"... There are many examples in the article that point out the annoying inconsistencies in the language, those are the opposite of simplicity. I love Rob Pike's presentations on Go, some of them were eye-opening to me. However, I just wish that the Go I see in practice would be much closer to the Go language that Go-fans describe in abstract.
heresie-dabord 2y ago
> Perhaps it's because I have experience, I love a simple language. (fixed the statement to focus on your value, not age per se) I love language ergonomics above all. Python wins. But for runtime bang-for-the-buck, Go wins.
LinXitoW 2y ago
Go is not simple, it's easy. The difference, for example is: Go invents an abstraction just for one use case, and just for the standard library/runtime itself, instead of taking the time to create a universal version of that abstraction. Generics for maps and lists, and tuples for error handling.
Seb-C 2y ago
The problem is that Go is not designed to be a simple language for it's users, it's designed to be a simple language to implement for it's maintainers. In my opinion, a simple language should be highly consistent (have a few rules, but which are universal and consistent everywhere). Instead we have a language with weirdnesses, inconsistencies and workarounds all over the place. A good example is type elision: it's available when declaring arrays, slices and maps, but not for structs. Allowing that would have several benefits in terms of readability, and also allow named parameters via anonymous struct arguments (which would greatly improve the design compared to the ugly workarounds that are currently used).
- deleted 2y ago
  [deleted]

richbell 2y ago

I wish the discourse that Go is a "simple" language would die. Despite its veneer, once you start writing Go it quickly becomes apparent that it isn't simple. Hidden complexity and footguns are abundant (e.g., https://archive.ph/WcyF4 https://archive.ph/WcyF4). It's nevertheless a useful language, and I use it quite a bit, but it's not "simple".

jonathanstrange 2y ago
I have no idea why anyone would say it's not simple, it's super-simple. Learning how duck typing works with interfaces and how to use it is perhaps the only hurdle. In my experience, only certain BASIC dialects like VisualBasic are simpler.
- LinXitoW 2y ago
  I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy. Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard library a special exception with maps and lists. That's easy, but not simple. People used to literally use code generators or weird UTF-8 characters to fake generics, that's not remotely simple.
  - stouset 2y ago
    Frankly code generators to fake generics aren’t remotely easy either.
nulld3v 2y ago
This 100%, I was just about to type a long rant up about this. There are so many weird parts of the language that took me forever to grasp, and in many cases, I still don't have an intuitive grasp of things. And plenty of other examples that aren't in that article: - You have a struct with an embedded interface. Does the outer struct satisfy the embedded interface? And can I type assert the outer struct into whatever embedded struct is fulfilling the inner interface? - When should I pass by value and when should I pass by reference? Like I generally know when to choose which, but do I really know without performing a benchmark? And what about arrays? Should I store pointers in them? But it also seems that people just don't care and just randomly roll the dice on when to return a pointer or a value? - Shorthand variable declaration. How does it work when you shorthand declare two variables but one of them already exists? Don't both answering the questions, that's not the problem. The problem is that it's just not intuitive enough such that I'm confident I know the correct answer.
- KingOfCoders 2y ago
  Your thinking is too complex for Go. You might be better of with Rust. Same about benchmarking, if you want and need the fastest code, or the best memory management, use Rust. If you need something faster than Python in general but not the fastest, use Go.
  - nulld3v 2y ago
    But that's the thing right? Like I come from Java. In Java, we have objects. They are pointers. That's it. You don't get to decide on whether you want a pointer or a value (I guess primitives are an exception lol). But it was so simple! And same in JavaScript. Everything is a pointer except primitives. That's it. End of story. And I have written Rust too, and while the situation is definitely more complicated there, the guidance is extremely simple and straightforward: If the struct implements Copy, then it is very cheap to copy and you should pass by value. Otherwise, you should pass by pointer/reference. And meanwhile in Go, I just see pointers and values being used seemingly interchangeably, and seemingly at random.
- ralegh 2y ago
KingOfCoders 2y ago
Yes, like "Opening Brace Can't Be Placed on a Separate Line" (from your link). Everyone can read Go code and understand what happens. There are some minor difficulties like func (*A) vs func (A).,
- eru 2y ago
  RiscV assembly is even easier to read by that metric.
  - KingOfCoders 2y ago
    My assembler days were 4 decades ago, but "Everyone can read Go code and understand what happens." There seems to be a difference between "easy to read" and "understand what happens" - or what happens on what level. The challenge is that there is a tradeoff between the two. Assembler is too low to understand what "really" happens, on the other hand Haskell for example with Monad stacks is again very easy to read + understand what happens "most of the time", but hard to understand all the abstracted away side effects. In Haskell with add 3 5 everything can happen beside what you see. In assembler ld a, 3 add a, 5 nothing happens except these two instructions. The tradeoff is how much you want to be explicit, with the downside of creating too much noise, and how much you want to abstract away, with the downside of magic happening somewhere.
    - eru 2y ago
      Yes. And to be less snarky: Go doesn't really sit on the efficiency frontier here: It requires you to write a lot of stuff by hand and is incredibly verbose, but it also does a lot of magic behind the scenes.
LandR 2y ago
It's easy not simple, but the consequence is that any complexity that other languages handles for you, in go gets forced onto the developer. There's more stuff to think about, because the language is doing less for you.

GaryNumanVevo 2y ago

Go is "simple" insofar as you're doing simple things. If you've tried writing a KV store or database (as I have) you'll quickly find yourself wanting slightly more modern language features.

KingOfCoders 2y ago
"quickly find yourself wanting slightly more modern language features." Use the tool that works for you.
- GaryNumanVevo 2y ago
  Feel free to take a look at any more complicated GoLang code (k8s, gorm, etc) and you'll see that the tool/library you're depending on requires a veritable rats nest of bad practices to work around the Go's inherent limitations.
  - matttproud 2y ago
    My opinion on Kubernetes as a yardstick example of Go is this: This was one of the first large systems developed in Go, not too long after the language hit version 1.0 (ca. 12 years ago). What constituted good Go style and package architecture were not well known at that time even. Given that and hindsight being 20:20, I could easily imagine the internal architecture (not even the public surface) for Kubernetes being a lot different and simpler. The package architecture alone makes me cringe. As a hypothetical counterpoint, I wonder what Kubernetes would have looked like had Dave Cheney (https://dave.cheney.net/ https://dave.cheney.net/) and Rob Pike built it in that era. I think that would have been a better yard stick. I have a unique appreciation for this first large systems perspective as I co-designed an adjacent product in the cloud native ecosystem at that time (Prometheus). There was no good example to follow when it came to large program structure and design in Go at that time. We were all figuring that out for ourselves — organically. I think this point about organic evolution of the architecture is important to call out explicitly, because developers often look at an existing structure and essentially mimic it with their additions, changes, and refactors irrespective of whether the structure was correct for the problem it was trying to solve or even good. Given that reality, is it really any wonder that one of the first major pieces of software ended up being this metaphorical mess? And the truth is that's not a language-specific problem: it could have happened with any new language. And taking a legacy system of this age and refactoring is difficult from a social perspective, ignoring the gradient/cost of refactoring that is language-specific. You'll have a lot of people who will oppose structural change just because, so probably a significant refactoring to achieve these goals is just not in the cards. Had there been so much as something similar to https://google.github.io/styleguide/go https://google.github.io/styleguide/go at that time (ca. 2012) (it's based on the very spartan https://go.dev/wiki/CodeReviewComments https://go.dev/wiki/CodeReviewComments), that would have been tremendously useful and impactful in helping preserve simplicity.

zozbot234 2y ago

Scheme is a simple language, Go just hides complexity until it blows up in the worst possible way. (Of course, most reasonable alternatives to Go are even worse from that POV. See Python, Ruby, JS etc.)

serial_dev 2y ago

Very common misrepresentation of any critique of Go. "You just don't get simplicity, you got them Java brainwormz"... There are many examples in the article that point out the annoying inconsistencies in the language, those are the opposite of simplicity. I love Rob Pike's presentations on Go, some of them were eye-opening to me. However, I just wish that the Go I see in practice would be much closer to the Go language that Go-fans describe in abstract.

heresie-dabord 2y ago

> Perhaps it's because I have experience, I love a simple language. (fixed the statement to focus on your value, not age per se) I love language ergonomics above all. Python wins. But for runtime bang-for-the-buck, Go wins.

LinXitoW 2y ago

Go is not simple, it's easy. The difference, for example is: Go invents an abstraction just for one use case, and just for the standard library/runtime itself, instead of taking the time to create a universal version of that abstraction. Generics for maps and lists, and tuples for error handling.

Seb-C 2y ago

The problem is that Go is not designed to be a simple language for it's users, it's designed to be a simple language to implement for it's maintainers. In my opinion, a simple language should be highly consistent (have a few rules, but which are universal and consistent everywhere). Instead we have a language with weirdnesses, inconsistencies and workarounds all over the place. A good example is type elision: it's available when declaring arrays, slices and maps, but not for structs. Allowing that would have several benefits in terms of readability, and also allow named parameters via anonymous struct arguments (which would greatly improve the design compared to the ugly workarounds that are currently used).

deleted 2y ago
[deleted]