4 ms·

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 t

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.
  - fxtentacle 6y ago
    Let's go with "Go is easy if you use an appropriate IDE" Emacs is great for many things, but Go was clearly designed with GUI IDE tooling in mind. So if you decide to forfeit that huge benefit, of course it'll be a sub-optimal experience.
    - cy_hauser 6y ago
      > Go was clearly designed with GUI IDE tooling in mind. Surprisingly not. One of Go's authors commented many times in the early days that Go shouldn't need an IDE, only a text editor. He even commented that syntax highlighting/coloring were unnecessary distractions.
      - fxtentacle 6y ago
        He said: there was talk early in the project about whether Go needed an IDE to succeed. No one on the team had the right skill set, though, so we did not try to create one. However, we did create core libraries for parsing and printing Go code, which soon enabled high-quality plugins for all manner of editor and IDE, and that was a serendipitous success. Which I read as they considered IDEs important.
tankenmate 6y ago
The first one is an issue, not just for reading but also for writing; you'll find slightly similar ways of doing the same thing, and Murphy's (Real) Law kicks in "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." The rest of the issues seem to be tooling issues, not an issue with Go itself. There are tools out there that do the right thing (personally I'm old school and use gotags, warts and all), so I'd suggest get better tools that work for you (or write one if you can't find one you like).
sagichmal 6y ago
> Reading Go means that I keep having to read idioms (as posted in the article) and parse them back into the actual intent, What? I never have to do this... > I can't easily navigate to the definition of a function . . . I usually don't have tooling that can jump to definition What? You command-click on it... ? > 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 What? You obviously can't jump-to-definition of an interface, but in what way is this a limitation?
lhjn 6y ago
> 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. This. Also, this idea that simple(r) = easy to read just doesn't hold. Is brainfuck easy to read? It's very simple. Even without being so extreme, we could simplify go replacing loops and structured ifs with "if-gotos". Or remove list enumeration as in range(my list) and only allow using integer indexing. Would that make go easier to read or reason about?

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.
- fxtentacle 6y ago
  Let's go with "Go is easy if you use an appropriate IDE" Emacs is great for many things, but Go was clearly designed with GUI IDE tooling in mind. So if you decide to forfeit that huge benefit, of course it'll be a sub-optimal experience.
  - cy_hauser 6y ago
    > Go was clearly designed with GUI IDE tooling in mind. Surprisingly not. One of Go's authors commented many times in the early days that Go shouldn't need an IDE, only a text editor. He even commented that syntax highlighting/coloring were unnecessary distractions.
    - fxtentacle 6y ago
      He said: there was talk early in the project about whether Go needed an IDE to succeed. No one on the team had the right skill set, though, so we did not try to create one. However, we did create core libraries for parsing and printing Go code, which soon enabled high-quality plugins for all manner of editor and IDE, and that was a serendipitous success. Which I read as they considered IDEs important.

tankenmate 6y ago

The first one is an issue, not just for reading but also for writing; you'll find slightly similar ways of doing the same thing, and Murphy's (Real) Law kicks in "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." The rest of the issues seem to be tooling issues, not an issue with Go itself. There are tools out there that do the right thing (personally I'm old school and use gotags, warts and all), so I'd suggest get better tools that work for you (or write one if you can't find one you like).

sagichmal 6y ago

> Reading Go means that I keep having to read idioms (as posted in the article) and parse them back into the actual intent, What? I never have to do this... > I can't easily navigate to the definition of a function . . . I usually don't have tooling that can jump to definition What? You command-click on it... ? > 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 What? You obviously can't jump-to-definition of an interface, but in what way is this a limitation?

lhjn 6y ago

> 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. This. Also, this idea that simple(r) = easy to read just doesn't hold. Is brainfuck easy to read? It's very simple. Even without being so extreme, we could simplify go replacing loops and structured ifs with "if-gotos". Or remove list enumeration as in range(my list) and only allow using integer indexing. Would that make go easier to read or reason about?