8 ms·

> Ignore comments about how go is simple to write. Do people say that? I've never heard anyone claim that Go is simple to write. Pike, I believe (may have bee

> Ignore comments about how go is simple to write. Do people say that? I've never heard anyone claim that Go is simple to write. Pike, I believe (may have been someone else), claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read." Go was built on the premise that people spend more time reading code than writing code and Go attempts to make tradeoffs towards reading optimization rather than writing optimization. Whether or not it is successful in that is another topic for another day.

Thaxll 6y ago
Go is very simple to read and to write, I'm not sure how one can argue against that. Without prior knowledge you can jump into any code base and won't be suprised by something you never seen before or does not understand what it does. The language is simple to grasp because it has just a few concepts and keywords.
- egeozcan 6y ago
  you cannot write a generic function that returns a modified slice without losing types. that, in my book, means hard to write. ...which makes it also very easy to read.
  - Thaxll 6y ago
    Then you write 2 functions, what you're talking about is a different question.
    - adkadskhj 6y ago
      Maybe. If you have to remember two functions to _understand_ the code, is reading really easier? I imagine reading implies understanding, and while i definitely think Go is easier to read without understanding, i don't think that's the real implication.
    - egeozcan 6y ago
      if having to write a separate function for each type of container is easy for you, then I can only respectfully disagree :) I'm saying this as someone who is learning go for fun.
  - hnlmorg 6y ago
    I don't see the point of cherry picking highly specific examples because for every argument there will be just as many counterarguments from other domains. To be more specific: the point isn't whether Go is "always" simpler to write but whether it is generally simpler to write. I think the latter is true for all the domains I've written code in Go and I've solved some pretty hard problems in Go (check out my Github repositories if you don't believe me). The awesome thing about programming languages is that you're free to pick another language if that is a better fit for any specific domain or even personal preference. Hence why I've worked in more than a dozen different programming languages over the years. So rather than moaning that Go doesn't fit a particular pattern where you need to rely on generics, perhaps use a language that has generics to solve that problem and save Go for the occasions you don't need generics (which, if we're all honest, isn't something we need to rely on half as much as people claim when moaning about the lack of features in Go). As a veteran developer, what really annoys me the most is people who pick a language that isn't well suited for solving the problem at hand and then moan that language needs to change, rather than developers picking the right tools for the job. I'd rather see a language lack features but focuses to serves its core demographic well than see everything and the kitchen sink is thrown at it and everyone using it even when they know they shouldn't simply because they're too afraid to learn anything new. What we need is more appreciation that "general purpose languages" doesn't mean "should be used to do practically anything in". Then I'd think we'd all get along better.
    - egeozcan 6y ago
      I meant it as a random example. I do not dislike go. As I've stated below, I actually am learning it (more like, the conventions around it), just for fun. I find it especially powerful for writing tools. That doesn't remove my rights to nitpick its shortcomings though.
  - unchar1 6y ago
    I think the word you're looking for is "tedious". Go is both simple and tedious to write. I'd actually argue it's tedious _because_ of its simplicity.
    - nicoburns 6y ago
      But all that boilerplate also makes it hard to read. You have to pick out the meaning amongst a bunch of noise.
      - marcus_holmes 6y ago
        Not once you're used to it. Humans are good at spotting patterns, and once you're used to the patterns of the boilerplate it becomes easy to read and you only notice the anomalies. The famous "if err != nil {" boilerplate becomes expected after each call and you only notice if it changes.
  - throwaway894345 6y ago
    I would argue that it only makes it hard to write type safe generic functions that return modified slices. If you're writing generic code for the sake of writing generic code, Go is probably going to give you a bad time, but if you're trying to solve real problems, you can get a very long way with slices, maps, and interfaces/functions.
    - erik_seaberg 6y ago
      filter/map/reduce are more productive than anything I could write without them.
      - fwip 6y ago
        Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way. Here are three options that were on the first page of google: * https://github.com/kulshekhar/fungen https://github.com/kulshekhar/fungen * https://github.com/awalterschulze/goderive https://github.com/awalterschulze/goderive * https://github.com/cheekybits/genny https://github.com/cheekybits/genny
      - throwaway894345 6y ago
        I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.
        erik_seaberg 6y ago
        filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.
        throwaway894345 6y ago
        Wall? var out []X for _, x := range elts { if condition(x) { out = append(out, x) } } That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block. I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.
  - q3k 6y ago
    I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of what Go's designed to be good at. On the side, I occasionally write some Rust, Haskell, and other 'good' languages. I have kept a counter of many times I've told myself, over the past years, 'I wish Go had generics, this would really make my life easier right now'. It's currently at 5. In my experience, the supposed issue of a lack of generics is _extremely_ overblown with regards to real world use. Sure, it would be nice to have them. I would've really liked them to exist a month ago when I was writing a generic container. But they're not going to make the language that much better for me, and there's always going to be more things PL people lust after (usually the next candidate would be GADTs, “Go does not have algebraic data types!” coming to HN comments very soon).
    - rob74 6y ago
      > there's always going to be more things PL people lust after How about non-nullable types?
      - q3k 6y ago
        Sure, put that on the pile labeled “things that sometimes bother me, but I forget they're even an issue when I talk about Go with others”, next to generics.
    - morelisp 6y ago
      As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety). If I kept a similar counter for the past 3 years, it would be at least five per day. Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant. Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex). 90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields. Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams. I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.
- MisterTea 6y ago
  As someone who cut their teeth on programming via C and c++ Go did come surprisingly easy. My first interaction with it was a small change to a web thing and I had no trouble reading source code, understanding it, and making the necessary changes without ever learning to write a line of Go before. That alone is value. To me Go feels like a "modern" C language from 90's Bell Labs. Of course that is kind of true as Go is the spiritual successor to Alef and Limbo. Though it feels like it came out 10+ years too late.
  - pjmlp 6y ago
    Yes, Go is what Java 1.0 should have been, in 1996.
    - MisterTea 6y ago
      That was supposed to be Inferno/Limbo but sadly it didn't happen.
      - pjmlp 6y ago
        Yes, not only it did not happen, most people aren't even aware of it as they keep praising Plan 9 instead. In any case, Go is Limbo with a bit of Oberon-2 facelift, and as such a bit too late to the party. At least they might finally support some level of generics and catch up with CLU.
        MisterTea 6y ago
        Because plan 9 was developed naturally in the Lab as an evolution of Unix research. Inferno on the other hand was a blunt force attempt by Lucent to leapfrog Sun by halting Plan 9 development for a whole year forcing the team to instead work on Inferno. It was a commercial project to produce a product which was in stark contrast to the more academic/research oriented development of Plan 9. Unfortunately, this hamfisted attempt by Lucent left Inferno in a state of Limbo, pun intended. The target was more along the lines of embedded systems like set top boxes and early PDA's. The Dis VM also suffers from hard coded 32bit pointer magic which means it only builds on 32bit plan 9 or in a 32bit chroot under a unix-like for hosted mode. And finally, the Charon web browser has a bug that crashes the Dis VM. I have yet to see it boot on bare metal hardware in its entirety. These reasons are why Plan 9 gets all the love, it works out of the box on 386/amd64 and arm32/arm64 (Rpi, Zynq, etc) Though not all is lost. Someone is working on getting it to build on 64bit 9front and OpenBSD, though the code is very much a WIP (if interested, hop into #cat-v on freenode and ask about the Inferno 64 bit port). It's not completely dead. Patches welcome :-)
- pxue 6y ago
  it's simple to write ONCE you understand and learn the idiomatic code. some people call not having native string/int/whatever sorting methods is "hard to write". some people think the verbose `if err != nil` every other line is also "hard to write" again, there is an upstart cost, which is to integrate yourself into the language community.
  - makapuf 6y ago
    Golang does have a few simple types sorting functions such as string and int https://golang.org/pkg/sort/#Strings https://golang.org/pkg/sort/#Strings. Now that generics will be out, could we even have generic sort functions ?
- derefr 6y ago
  If by "read" here we mean "grok" — i.e. to read and understand well-enough to be able to modify without breaking the abstract guarantees the code makes, without documentation — then I would say that the low level of Go's concurrency primitives (relative to other languages modelling the same actor-based architecture, e.g. Erlang) means it takes more effort to "read" production-quality (concurrent, fault-tolerant, no resource-leaks, no data races) Go code relative to production-quality code written in other languages. Sure, when reading Go, you aren't really encountering new language features; but you're often being forced to recognize things that should be language features, which are instead implemented as design patterns. (And, at that, often with those patterns reified into code by new-ish programmers who don't understand those design-patterns very well, rather than by language maintainers after much careful scrutiny.) It's like doing OOP in C, and having to mentally parse vtable structs into the object-model they represent — with every project having done its own vtable implementation, all slightly different. Except that OOP is unusual in C, while concurrent infrastructure is near-universal in Go. When reading Go, I'm essentially mentally "decompiling" it as I go into a higher-level representation within my mental-model. "These 50 lines are a parallel map-reduce; these 200 lines are a read-through cache with per-key synchronization to avoid duplicate work; etc." I'd rather just read that higher-level representation directly!
adkadskhj 6y ago
> I have seen that message distilled down into "Go is simple to read." I think the two are related, directly. However in my experience i don't even agree with Pike. Go is not easy to read. Yes, a single small function in Go is much easier to read (perhaps) than X lang. However Go requires a huge (brain)memory table to remember everything, because it spreads logic out. So you have to remember X function, scroll up, look at Y function remembering how it interacts with X, etcetc. > Whether or not it is successful in that is another topic for another day. I guess i bikeshedded, sorry :s
rob74 6y ago
> Pike, I believe [...], claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read." Yeah, it was Pike, and I have also seen it distilled (in bad faith) into "Go is a primitive language for inexperienced programmers, so it's beneath me to touch it". And yes, it is easier to write and read compared to other languages (old and new), but it does have some concepts that you should follow to write "idiomatic" Go code, e.g. don't throw panics as liberally as you would throw exceptions in other languages, use composition and interfaces where you would use inheritance in other languages etc. But I'm afraid people who have been indoctrinated with disregarding Go as "simple", but want to try it nevertheless (or are forced to use it), won't take the time to get into these details, and will see their preconceived opinions confirmed...
dvfjsdhgfv 6y ago
> Do people say that? I've never heard anyone claim that Go is simple to write. The article we are discussing now has a big subtitle "A simple language."

Thaxll 6y ago

Go is very simple to read and to write, I'm not sure how one can argue against that. Without prior knowledge you can jump into any code base and won't be suprised by something you never seen before or does not understand what it does. The language is simple to grasp because it has just a few concepts and keywords.

egeozcan 6y ago
you cannot write a generic function that returns a modified slice without losing types. that, in my book, means hard to write. ...which makes it also very easy to read.
- Thaxll 6y ago
  Then you write 2 functions, what you're talking about is a different question.
  - adkadskhj 6y ago
    Maybe. If you have to remember two functions to _understand_ the code, is reading really easier? I imagine reading implies understanding, and while i definitely think Go is easier to read without understanding, i don't think that's the real implication.
  - egeozcan 6y ago
    if having to write a separate function for each type of container is easy for you, then I can only respectfully disagree :) I'm saying this as someone who is learning go for fun.
- hnlmorg 6y ago
  I don't see the point of cherry picking highly specific examples because for every argument there will be just as many counterarguments from other domains. To be more specific: the point isn't whether Go is "always" simpler to write but whether it is generally simpler to write. I think the latter is true for all the domains I've written code in Go and I've solved some pretty hard problems in Go (check out my Github repositories if you don't believe me). The awesome thing about programming languages is that you're free to pick another language if that is a better fit for any specific domain or even personal preference. Hence why I've worked in more than a dozen different programming languages over the years. So rather than moaning that Go doesn't fit a particular pattern where you need to rely on generics, perhaps use a language that has generics to solve that problem and save Go for the occasions you don't need generics (which, if we're all honest, isn't something we need to rely on half as much as people claim when moaning about the lack of features in Go). As a veteran developer, what really annoys me the most is people who pick a language that isn't well suited for solving the problem at hand and then moan that language needs to change, rather than developers picking the right tools for the job. I'd rather see a language lack features but focuses to serves its core demographic well than see everything and the kitchen sink is thrown at it and everyone using it even when they know they shouldn't simply because they're too afraid to learn anything new. What we need is more appreciation that "general purpose languages" doesn't mean "should be used to do practically anything in". Then I'd think we'd all get along better.
  - egeozcan 6y ago
    I meant it as a random example. I do not dislike go. As I've stated below, I actually am learning it (more like, the conventions around it), just for fun. I find it especially powerful for writing tools. That doesn't remove my rights to nitpick its shortcomings though.
- unchar1 6y ago
  I think the word you're looking for is "tedious". Go is both simple and tedious to write. I'd actually argue it's tedious _because_ of its simplicity.
  - nicoburns 6y ago
    But all that boilerplate also makes it hard to read. You have to pick out the meaning amongst a bunch of noise.
    - marcus_holmes 6y ago
      Not once you're used to it. Humans are good at spotting patterns, and once you're used to the patterns of the boilerplate it becomes easy to read and you only notice the anomalies. The famous "if err != nil {" boilerplate becomes expected after each call and you only notice if it changes.
- throwaway894345 6y ago
  I would argue that it only makes it hard to write type safe generic functions that return modified slices. If you're writing generic code for the sake of writing generic code, Go is probably going to give you a bad time, but if you're trying to solve real problems, you can get a very long way with slices, maps, and interfaces/functions.
  - erik_seaberg 6y ago
    filter/map/reduce are more productive than anything I could write without them.
    - fwip 6y ago
      Then you can go ahead and use one of the many code generation libraries out there to handle it for you in a type-safe way. Here are three options that were on the first page of google: * https://github.com/kulshekhar/fungen https://github.com/kulshekhar/fungen * https://github.com/awalterschulze/goderive https://github.com/awalterschulze/goderive * https://github.com/cheekybits/genny https://github.com/cheekybits/genny
    - throwaway894345 6y ago
      I’m very skeptical. This kind of argument only makes sense if your programming is bottlenecked by your typing speed. It’s trivial to write these functions as for loops, the only difference being the number of key presses.
      - erik_seaberg 6y ago
        filter is obvious at a glance, where all loops look similar. Generating a wall of boilerplate is easy, the problem is that we can’t just ignore it and read a summary. Essentially I’d like to decompile Go to what could have been written in a powerful language.
        throwaway894345 6y ago
        Wall? var out []X for _, x := range elts { if condition(x) { out = append(out, x) } } That’s so easy I typed it from my iPhone and anyone looking at it can infer at a glance that it’s filtering a list. If you are deeply worried about it, throw a comment at the top of the block. I too like terse code, but it’s because it makes me feel smart, not because it’s easier to read or more maintainable. I’m having a blast writing Rust for my hobby project, making everything super DRY and free from boilerplate, but I don’t pretend that I’m saving myself time or making things more readable or maintainable should someone else come across it.
- q3k 6y ago
  I've been writing Go full-time, professionally for around 4 years now. Backend software, mostly distributed stuff, tools and services - the bread and butter of what Go's designed to be good at. On the side, I occasionally write some Rust, Haskell, and other 'good' languages. I have kept a counter of many times I've told myself, over the past years, 'I wish Go had generics, this would really make my life easier right now'. It's currently at 5. In my experience, the supposed issue of a lack of generics is _extremely_ overblown with regards to real world use. Sure, it would be nice to have them. I would've really liked them to exist a month ago when I was writing a generic container. But they're not going to make the language that much better for me, and there's always going to be more things PL people lust after (usually the next candidate would be GADTs, “Go does not have algebraic data types!” coming to HN comments very soon).
  - rob74 6y ago
    > there's always going to be more things PL people lust after How about non-nullable types?
    - q3k 6y ago
      Sure, put that on the pile labeled “things that sometimes bother me, but I forget they're even an issue when I talk about Go with others”, next to generics.
  - morelisp 6y ago
    As a counterpoint: I also write Go in this same space. I like Go - I find most of its design goals align closely with my personal preferences (avoidance of syntactic noise, fast compile times, right-sized standard library, sufficient control over memory without having to worry about memory safety). If I kept a similar counter for the past 3 years, it would be at least five per day. Every time I `return x, err` and it's not a true tuple - and it almost never is - I wish I was returning an `Either<X, error>`. That's constant. Every time I use atomic.Value (often) or sync.Pool (less often) or sync.Map (almost never because I end up rolling my own stupid map+mutex). 90% of the time I want to say a pointer can't be null. 100% of the time I want to handle optional JSON or SQL fields. Fairly often, like > 30% of the time, when wrapping serdes or DTO conversions around data streams. I don't believe the level of generics required to support these use cases requires compromising the other goals of Go. The deficiency should have been obvious as soon as they introduced `sync.Map`.
MisterTea 6y ago
As someone who cut their teeth on programming via C and c++ Go did come surprisingly easy. My first interaction with it was a small change to a web thing and I had no trouble reading source code, understanding it, and making the necessary changes without ever learning to write a line of Go before. That alone is value. To me Go feels like a "modern" C language from 90's Bell Labs. Of course that is kind of true as Go is the spiritual successor to Alef and Limbo. Though it feels like it came out 10+ years too late.
- pjmlp 6y ago
  Yes, Go is what Java 1.0 should have been, in 1996.
  - MisterTea 6y ago
    That was supposed to be Inferno/Limbo but sadly it didn't happen.
    - pjmlp 6y ago
      Yes, not only it did not happen, most people aren't even aware of it as they keep praising Plan 9 instead. In any case, Go is Limbo with a bit of Oberon-2 facelift, and as such a bit too late to the party. At least they might finally support some level of generics and catch up with CLU.
      - MisterTea 6y ago
        Because plan 9 was developed naturally in the Lab as an evolution of Unix research. Inferno on the other hand was a blunt force attempt by Lucent to leapfrog Sun by halting Plan 9 development for a whole year forcing the team to instead work on Inferno. It was a commercial project to produce a product which was in stark contrast to the more academic/research oriented development of Plan 9. Unfortunately, this hamfisted attempt by Lucent left Inferno in a state of Limbo, pun intended. The target was more along the lines of embedded systems like set top boxes and early PDA's. The Dis VM also suffers from hard coded 32bit pointer magic which means it only builds on 32bit plan 9 or in a 32bit chroot under a unix-like for hosted mode. And finally, the Charon web browser has a bug that crashes the Dis VM. I have yet to see it boot on bare metal hardware in its entirety. These reasons are why Plan 9 gets all the love, it works out of the box on 386/amd64 and arm32/arm64 (Rpi, Zynq, etc) Though not all is lost. Someone is working on getting it to build on 64bit 9front and OpenBSD, though the code is very much a WIP (if interested, hop into #cat-v on freenode and ask about the Inferno 64 bit port). It's not completely dead. Patches welcome :-)
pxue 6y ago
it's simple to write ONCE you understand and learn the idiomatic code. some people call not having native string/int/whatever sorting methods is "hard to write". some people think the verbose `if err != nil` every other line is also "hard to write" again, there is an upstart cost, which is to integrate yourself into the language community.
- makapuf 6y ago
  Golang does have a few simple types sorting functions such as string and int https://golang.org/pkg/sort/#Strings https://golang.org/pkg/sort/#Strings. Now that generics will be out, could we even have generic sort functions ?
derefr 6y ago
If by "read" here we mean "grok" — i.e. to read and understand well-enough to be able to modify without breaking the abstract guarantees the code makes, without documentation — then I would say that the low level of Go's concurrency primitives (relative to other languages modelling the same actor-based architecture, e.g. Erlang) means it takes more effort to "read" production-quality (concurrent, fault-tolerant, no resource-leaks, no data races) Go code relative to production-quality code written in other languages. Sure, when reading Go, you aren't really encountering new language features; but you're often being forced to recognize things that should be language features, which are instead implemented as design patterns. (And, at that, often with those patterns reified into code by new-ish programmers who don't understand those design-patterns very well, rather than by language maintainers after much careful scrutiny.) It's like doing OOP in C, and having to mentally parse vtable structs into the object-model they represent — with every project having done its own vtable implementation, all slightly different. Except that OOP is unusual in C, while concurrent infrastructure is near-universal in Go. When reading Go, I'm essentially mentally "decompiling" it as I go into a higher-level representation within my mental-model. "These 50 lines are a parallel map-reduce; these 200 lines are a read-through cache with per-key synchronization to avoid duplicate work; etc." I'd rather just read that higher-level representation directly!

adkadskhj 6y ago

> I have seen that message distilled down into "Go is simple to read." I think the two are related, directly. However in my experience i don't even agree with Pike. Go is not easy to read. Yes, a single small function in Go is much easier to read (perhaps) than X lang. However Go requires a huge (brain)memory table to remember everything, because it spreads logic out. So you have to remember X function, scroll up, look at Y function remembering how it interacts with X, etcetc. > Whether or not it is successful in that is another topic for another day. I guess i bikeshedded, sorry :s

rob74 6y ago

> Pike, I believe [...], claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read." Yeah, it was Pike, and I have also seen it distilled (in bad faith) into "Go is a primitive language for inexperienced programmers, so it's beneath me to touch it". And yes, it is easier to write and read compared to other languages (old and new), but it does have some concepts that you should follow to write "idiomatic" Go code, e.g. don't throw panics as liberally as you would throw exceptions in other languages, use composition and interfaces where you would use inheritance in other languages etc. But I'm afraid people who have been indoctrinated with disregarding Go as "simple", but want to try it nevertheless (or are forced to use it), won't take the time to get into these details, and will see their preconceived opinions confirmed...

dvfjsdhgfv 6y ago

> Do people say that? I've never heard anyone claim that Go is simple to write. The article we are discussing now has a big subtitle "A simple language."