7 ms·

Go is easy != easy to read. I personally do think Go is easy to read. The fact that I don't get bitten in the ass by hidden behaviours and there's no inheritan

Go is easy != easy to read. I personally do think Go is easy to read. The fact that I don't get bitten in the ass by hidden behaviours and there's no inheritance to step through 5 files of. The fact that everyone's Go code looks more or less the same (unless you're an absolute beginnner) because there's only so many ways to do something. Compared to C# where reading someone else's code means I have to take a shot to calm my nerves and then take a guess at which permutation of language features they decided to use today. A simple language is easier to read. This doesn't mean it's going to be easy for anyone who isn't a Go developer. There's no claims of that. But given a week to understand syntax and getting used to reading files, I don't think there's many places where you'd get stumped. >Go is an open source programming language that makes it easy to build simple, reliable, and efficient software. This still holds true for me. A simple language builds simple software. No noob Go dev is going to have a good time, but that's true in almost every language. Once you understand how everything works, how interfaces work, how channels work, you can simplify down most problems and build them with ease. Needing to write a few extra lines of code doesn't mean you can't write simple, reliable and efficient software. Neither of those quotes say Go is an all round easy language. It's not like you can throw it at a baby and get back Kubernetes. It's not easy to do custom containers, it's not easy to do manipulate lists, it's not easy to do a bunch of things you'd do in one line in something like C#. But I think these are small hurdles for the mental burden you're relieved of when you see that the rest of the language is equally as simple and benefits from it.

rswskg 6y ago
I think c# is an unfair comparison in this instance. You are right, c# does too much. But Go makes it far more work to do basic things - list comprehension for example (what is everyones obsession with for loops?). An opinated language with one way to do things sounds great, but not at the expense of basic niceities you get in other languages.
- nmfisher 6y ago
  For what it's worth, I'll take for loops over list comprehensions any day of the week. I just find it a lot easier to read.
  - random5634 6y ago
    Agreed! Check out pythons move with walrus operators inside list comprehensions - I think u can do that now - starts to be line noise
  - simiones 6y ago
    So you are claiming this arr2 := []int{} for i := range arr1 { if arr1[i] > 9 { arr2 = append(arr2, arr1[i] * 2) } } Is more readable than these? var arr2 = arr1.Where(x => x > 9).Select(x => x*2); var arr2 = from x in arr1 where x > 9 select x*2; arr2 = [x * 2 for x in arr1 where x > 9] (setf arr2 (loop for x across arr1 when (> x 9) collect (* x 2))) I honestly can't imagine by what measure any of the latter ones could be harder to understand the former. And as the complexity of the expression increases, I only see the advantage increasing typically (though often it pays to split it into multiple comprehensions, just like a loop that does too much).
    - nmfisher 6y ago
      Personally? Yes (except for the first example you gave, which I don’t classify as “list comprehension”). It’s not inherent complexity though, just personal preference. I grew up writing for loops so they’re second nature to me and I grok them instantly in a single pass, whereas some list comprehensions require a re-read (particularly if they’re nested). Different strokes, that’s all.
      - simiones 6y ago
        Fair enough!
  - rswskg 6y ago
    It's exactly this sort of comment that gives go lovers a bad name.
Nullabillity 6y ago
As someone who reads a lot more Go than I write, Go is awful to read. Reading Go means that I keep having to read idioms (as posted in the article) and parse them back into the actual intent, rather than just reading the intent directly. But I can't even trust that, since the nth rewrite of the idiom might have screwed it up subtly. Reading Go means that I can't easily navigate to the definition of a function, because it implicitly merges folders into a single namespace, so I have to try them one by one. Reading Go means that I usually don't have tooling that can jump to definition, because there are umpteen different dependency management tools, and Gopls only supports one of them. Reading Go means that even when I have tooling available, and it feels like working today, jump-to-definition becomes impossible as soon as interfaces are involved, because structural typing makes it impossible to know what is an intentional implementation of that interface.
- deleted 6y ago
  [deleted]
- Philip-J-Fry 6y ago
  >Reading Go means that I can't easily navigate to the definition of a function, because it implicitly merges folders into a single namespace, so I have to try them one by one. Not sure what you mean here >Reading Go means that I usually don't have tooling that can jump to definition, because there are umpteen different dependency management tools, and Gopls only supports one of them. There's 1 dependency management tool though. It's go modules. Unless you live 2 years in the past? >Reading Go means that even when I have tooling available, and it feels like working today, jump-to-definition becomes impossible as soon as interfaces are involved, because structural typing makes it impossible to know what is an intentional implementation of that interface. You just right click in VS Code and click "Go to implementations". Or if you use Goland it's right there on the gutter. Reading comments like this really makes me wonder if anyone complaining about Go has actually used it.
  - Nullabillity 6y ago
    > Not sure what you mean here In Rust, if I see a call to `foo::bar::baz()`, I instantly know that `foo/bar.rs` or `foo/bar/mod.rs` (and only one will ever exist) contains either a `fn baz()` (in which case I'm done) or a `pub use spam::baz;` (in which case I can follow the same algorithm again). In Go, if I see a call to `import ("foo/bar"); bar.baz()`, all I know is that ONE of the files in the folder `foo/bar` contains a function `baz`, with no direction on which it is. > There's 1 dependency management tool though. It's go modules. Unless you live 2 years in the past? As I said, 99% of my interaction with Go is reading the code that other people wrote. I don't make the decisions about which dependency management tools they use. > You just right click in VS Code and click "Go to implementations". Or if you use Goland it's right there on the gutter. I use Emacs, but VS Code still uses the same broken Gopls. > Reading comments like this really makes me wonder if anyone complaining about Go has actually used it. Can't really say I disagree, I guess.
joelfolksy 6y ago
"A simple language is easier to read." "A simple language builds simple software". It's become a cliche to bring up brainfuck here, but it really is a direct refutation of these ideas, being a maximally simple language that produces maximally complicated code.

rswskg 6y ago

I think c# is an unfair comparison in this instance. You are right, c# does too much. But Go makes it far more work to do basic things - list comprehension for example (what is everyones obsession with for loops?). An opinated language with one way to do things sounds great, but not at the expense of basic niceities you get in other languages.

nmfisher 6y ago
For what it's worth, I'll take for loops over list comprehensions any day of the week. I just find it a lot easier to read.
- random5634 6y ago
  Agreed! Check out pythons move with walrus operators inside list comprehensions - I think u can do that now - starts to be line noise
- simiones 6y ago
  So you are claiming this arr2 := []int{} for i := range arr1 { if arr1[i] > 9 { arr2 = append(arr2, arr1[i] * 2) } } Is more readable than these? var arr2 = arr1.Where(x => x > 9).Select(x => x*2); var arr2 = from x in arr1 where x > 9 select x*2; arr2 = [x * 2 for x in arr1 where x > 9] (setf arr2 (loop for x across arr1 when (> x 9) collect (* x 2))) I honestly can't imagine by what measure any of the latter ones could be harder to understand the former. And as the complexity of the expression increases, I only see the advantage increasing typically (though often it pays to split it into multiple comprehensions, just like a loop that does too much).
  - nmfisher 6y ago
    Personally? Yes (except for the first example you gave, which I don’t classify as “list comprehension”). It’s not inherent complexity though, just personal preference. I grew up writing for loops so they’re second nature to me and I grok them instantly in a single pass, whereas some list comprehensions require a re-read (particularly if they’re nested). Different strokes, that’s all.
    - simiones 6y ago
      Fair enough!
- rswskg 6y ago
  It's exactly this sort of comment that gives go lovers a bad name.

Nullabillity 6y ago

As someone who reads a lot more Go than I write, Go is awful to read. Reading Go means that I keep having to read idioms (as posted in the article) and parse them back into the actual intent, rather than just reading the intent directly. But I can't even trust that, since the nth rewrite of the idiom might have screwed it up subtly. Reading Go means that I can't easily navigate to the definition of a function, because it implicitly merges folders into a single namespace, so I have to try them one by one. Reading Go means that I usually don't have tooling that can jump to definition, because there are umpteen different dependency management tools, and Gopls only supports one of them. Reading Go means that even when I have tooling available, and it feels like working today, jump-to-definition becomes impossible as soon as interfaces are involved, because structural typing makes it impossible to know what is an intentional implementation of that interface.

deleted 6y ago
[deleted]
Philip-J-Fry 6y ago
>Reading Go means that I can't easily navigate to the definition of a function, because it implicitly merges folders into a single namespace, so I have to try them one by one. Not sure what you mean here >Reading Go means that I usually don't have tooling that can jump to definition, because there are umpteen different dependency management tools, and Gopls only supports one of them. There's 1 dependency management tool though. It's go modules. Unless you live 2 years in the past? >Reading Go means that even when I have tooling available, and it feels like working today, jump-to-definition becomes impossible as soon as interfaces are involved, because structural typing makes it impossible to know what is an intentional implementation of that interface. You just right click in VS Code and click "Go to implementations". Or if you use Goland it's right there on the gutter. Reading comments like this really makes me wonder if anyone complaining about Go has actually used it.
- Nullabillity 6y ago
  > Not sure what you mean here In Rust, if I see a call to `foo::bar::baz()`, I instantly know that `foo/bar.rs` or `foo/bar/mod.rs` (and only one will ever exist) contains either a `fn baz()` (in which case I'm done) or a `pub use spam::baz;` (in which case I can follow the same algorithm again). In Go, if I see a call to `import ("foo/bar"); bar.baz()`, all I know is that ONE of the files in the folder `foo/bar` contains a function `baz`, with no direction on which it is. > There's 1 dependency management tool though. It's go modules. Unless you live 2 years in the past? As I said, 99% of my interaction with Go is reading the code that other people wrote. I don't make the decisions about which dependency management tools they use. > You just right click in VS Code and click "Go to implementations". Or if you use Goland it's right there on the gutter. I use Emacs, but VS Code still uses the same broken Gopls. > Reading comments like this really makes me wonder if anyone complaining about Go has actually used it. Can't really say I disagree, I guess.

joelfolksy 6y ago

"A simple language is easier to read." "A simple language builds simple software". It's become a cliche to bring up brainfuck here, but it really is a direct refutation of these ideas, being a maximally simple language that produces maximally complicated code.