6 ms·

>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 t

>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.
      - simiones 6y ago
        To be fair, we then had to throw all of those "high-quality" plugins in the garbage where they belonged, and go with Microsoft's Language Server architecture instead to really have a usable Go IDE experience in something like Emacs or vim (GoLand from JetBrains is of course much better, and that might be using some of the built-in Go tools?).
      - cy_hauser 6y ago
        I'll accept that as a reasonable conclusion. Then he also said the following: https://usesthis.com/interviews/rob.pike/ https://usesthis.com/interviews/rob.pike/ https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3BHV6QFfIJ https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B... (and some other stuff about syntax highlighting from around that time (?) I couldn't find.) So maybe it was a bit of both.
  - prussian 6y ago
    What makes Emacs not a GUI IDE?
  - morelisp 6y ago
- sangnoir 6y ago
  > 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. This is a code smell for poor file organization in your "foo/bar" module - in a well organized project, it should be obvious which file in a module contains a given function[1]. Go doesn't force file=module paradigm (preferring the folder to be the basis), however, it doesn't preclude having one file per module, if that's what you prefer. If you're reading someone else's poorly organized code, you can always use grep. 1. Say, you have an `animal` module, the first place you check for `NewCow()` is `animal/cow.go`
  - Nullabillity 6y ago
    > Go doesn't force file=module paradigm (preferring the folder to be the basis), Yes, this is what that complaint was about? > however, it doesn't preclude having one file per module, if that's what you prefer. > 1. Say, you have an `animal` module, the first place you check for `NewCow()` is `animal/cow.go` This whole subthread was about reading other people's Go code. Of course your own code is going to look organized to yourself! > If you're reading someone else's poorly organized code, you can always use grep. Yeah, ripgrep tends to be what saves me in the end. Still annoying to have to break it out all the time.
    - sangnoir 6y ago
      > Yes, this is what that complaint was about?...This whole subthread was about reading other people's Go code. So the complaint, restated is "Go doesn't prevent other people from writing bad code?" Am I getting you right? If so, well, I have nothing to say about that. edit: I do actually have something to say. I just remembered having to work with an 82,000-line long Perl module file that would defeat any IDE. Fun times. No language can save you from poorly organized projects, whether the modules are file-based or folder-based.
      - Nullabillity 6y ago
        I would say it's closer to "Go doesn't do a really simple thing that nudges people towards writing more readable code, while having basically no tradeoffs". Considering the far more tedious tradeoffs that Go does force on users in the name of supposed readability (for example: the lack of generics), I'd consider that a pretty big failure. I don't expect them to be perfect. I do expect them to try.
- yencabulator 6y ago
  > In Rust, if I see a call to `foo::bar::baz()`, I instantly know that `foo/bar.rs` or `foo/bar/mod.rs` In Rust, you would see `Bar::baz()` and have no clue where `Bar` is defined. The common style is `use something::somewhere::Bar`.
  - thayne 6y ago
    but if you see `Bar::baz` you can just go to the top of the file, and find the `use something::somewhere::Bar`, and then know what file `Bar` is defined in. In go, the import line only tells you what module/folder it is in, and you either need some tool or some intuition on how the module is organized into files to know what file to look for the definition in.
    - yencabulator 6y ago
      And then in Rust, that file ends up just saying `pub use ...`, and the real code is in a different module.

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.
    - simiones 6y ago
      To be fair, we then had to throw all of those "high-quality" plugins in the garbage where they belonged, and go with Microsoft's Language Server architecture instead to really have a usable Go IDE experience in something like Emacs or vim (GoLand from JetBrains is of course much better, and that might be using some of the built-in Go tools?).
    - cy_hauser 6y ago
      I'll accept that as a reasonable conclusion. Then he also said the following: https://usesthis.com/interviews/rob.pike/ https://usesthis.com/interviews/rob.pike/ https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3BHV6QFfIJ https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B... (and some other stuff about syntax highlighting from around that time (?) I couldn't find.) So maybe it was a bit of both.
- prussian 6y ago
  What makes Emacs not a GUI IDE?
- morelisp 6y ago
sangnoir 6y ago
> 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. This is a code smell for poor file organization in your "foo/bar" module - in a well organized project, it should be obvious which file in a module contains a given function[1]. Go doesn't force file=module paradigm (preferring the folder to be the basis), however, it doesn't preclude having one file per module, if that's what you prefer. If you're reading someone else's poorly organized code, you can always use grep. 1. Say, you have an `animal` module, the first place you check for `NewCow()` is `animal/cow.go`
- Nullabillity 6y ago
  > Go doesn't force file=module paradigm (preferring the folder to be the basis), Yes, this is what that complaint was about? > however, it doesn't preclude having one file per module, if that's what you prefer. > 1. Say, you have an `animal` module, the first place you check for `NewCow()` is `animal/cow.go` This whole subthread was about reading other people's Go code. Of course your own code is going to look organized to yourself! > If you're reading someone else's poorly organized code, you can always use grep. Yeah, ripgrep tends to be what saves me in the end. Still annoying to have to break it out all the time.
  - sangnoir 6y ago
    > Yes, this is what that complaint was about?...This whole subthread was about reading other people's Go code. So the complaint, restated is "Go doesn't prevent other people from writing bad code?" Am I getting you right? If so, well, I have nothing to say about that. edit: I do actually have something to say. I just remembered having to work with an 82,000-line long Perl module file that would defeat any IDE. Fun times. No language can save you from poorly organized projects, whether the modules are file-based or folder-based.
    - Nullabillity 6y ago
      I would say it's closer to "Go doesn't do a really simple thing that nudges people towards writing more readable code, while having basically no tradeoffs". Considering the far more tedious tradeoffs that Go does force on users in the name of supposed readability (for example: the lack of generics), I'd consider that a pretty big failure. I don't expect them to be perfect. I do expect them to try.
yencabulator 6y ago
> In Rust, if I see a call to `foo::bar::baz()`, I instantly know that `foo/bar.rs` or `foo/bar/mod.rs` In Rust, you would see `Bar::baz()` and have no clue where `Bar` is defined. The common style is `use something::somewhere::Bar`.
- thayne 6y ago
  but if you see `Bar::baz` you can just go to the top of the file, and find the `use something::somewhere::Bar`, and then know what file `Bar` is defined in. In go, the import line only tells you what module/folder it is in, and you either need some tool or some intuition on how the module is organized into files to know what file to look for the definition in.
  - yencabulator 6y ago
    And then in Rust, that file ends up just saying `pub use ...`, and the real code is in a different module.