4 ms·

> it's a smell when a language is so verbose that it effectively requires a machine to help you write it The funny thing is that this feature also explains wha

> it's a smell when a language is so verbose that it effectively requires a machine to help you write it The funny thing is that this feature also explains what Go is. Go relies heavily on the various tooling just to overcome the deficiencies of the language. It's just that they didn't choose IDE as a primary target, but instead various ad hoc tools. For example, when I find the unused imports being a hard error inconvenient, a typical suggestion from Gophers is "just use an editor plugin that automatically handles that". This is exactly the same attitude that can be found in the IDE lovers. And that's why I don't like Go anymore. In the name of the simplicity of the language, they concentrate on building more and more tools, rather than fixing the language. I'm pretty sure if Go acquires generics someday, it will have the form of code generation, which is proven to be awkward. (I heard "go generate" already does a part of that?)

sagichmal 11y ago
Those "various ad hoc tools" are literally the UNIX philosophy applied to language design. It's cool if you don't like it, but call it what it is, and realize you're really objecting to a whole ethos, not just a single instance of it.
- Cthulhu_ 11y ago
  Not to mention that most IDE's (Eclipse, IntelliJ) are more frameworks to tie together various ad hoc tools into a sorta-unified UI, often even calling the underlying Unix-style binary.
- lobster_johnson 11y ago
  The example the parent picked — unused imports being an error — isn't an instance of Unix philosophy at all. Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the most basic of which involves printing. Having to add, remove, then re-add "fmt" or "log" just to keep the compiler happy is not a Unix-philosophical issue around language design, it's just an unnecessary strictness. Go is "opinionated", but it tends to err on the side of impracticality, a kind of distorted, prematurely-optimized YAGNI that disrupts developer efficiency in the name of simplicity. "go get"'s obstinate simplicity is firmly in this category. Go gets a lot of stuff right, of course. And the tools — the "go" tool, compiler toolchain, gofmt, debugger, godoc etc. — are clearly good Unix citizens, of course.
  - kasey_junk 11y ago
    Not commenting on the bigger picture about philosophy. But I couldn't work in go without: https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports
    - lobster_johnson 11y ago
      Indeed, I use this Sublime plugin, which wraps it: https://packagecontrol.io/packages/GoImports https://packagecontrol.io/packages/GoImports.
    - StavrosK 11y ago
      > But I couldn't work in go without: https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports I think this statement makes both points simultaneously.
  - sagichmal 11y ago
    > Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the most basic of which involves printing. This sentence has baked into it a context which is not universal. Namely that "during developing" you are "work[ing] with a lot of tentative code". That's simply not how I, nor many others, develop. Even on the very first sketch of a program, I'm writing complete, valid types and functions. I code all of the error paths completely as I encounter them. For very large first drafts, I'll often stub methods or types, but I never leave the program in an invalid state and "try it out". (Tangentially, for what I suspect are similar reasons, I never quite understood why anyone would care so much about REPLs.) All of the tentativity, so to speak, has been expressed and explored in my head and on paper beforehand. Go is a language that rewards, perhaps even demands, this style of development. If that's not how you operate, Go will feel like it's fighting you. But that's not a universal critique of the language, that's a very specific critique of your specific operating context.
    - lobster_johnson 11y ago
      I'm pretty sure you are in the minority — REPLs are provably immensely popular, for example (I've never heard anyone criticize their usefulness). Sometimes I write code like you do. At other times I'm "feeling out" a solution and want the language to not fight my half-baked, messy (but syntactically valid!) program. At other times I'm writing a quick and dirty script I will use today and never after; it doesn't need to be pretty, only functional. But Go wants your code to always be fully realized and clean, which just doesn't mesh with reality. We don't need "universal critiques". Everyone has a style, and a good, mainstream programming language needs to be receptive to those styles.
maerF0x0 11y ago
IMO as engineers we're going to eventually need to get used to more productive modes than doing it all ourselves. If a piece of software can give my team a 1% speedup, it'd be worth $40k a year. Multiply that by lots of teams, we can see there is a big market on making engineers more productive.

sagichmal 11y ago

Those "various ad hoc tools" are literally the UNIX philosophy applied to language design. It's cool if you don't like it, but call it what it is, and realize you're really objecting to a whole ethos, not just a single instance of it.

Cthulhu_ 11y ago
Not to mention that most IDE's (Eclipse, IntelliJ) are more frameworks to tie together various ad hoc tools into a sorta-unified UI, often even calling the underlying Unix-style binary.
lobster_johnson 11y ago
The example the parent picked — unused imports being an error — isn't an instance of Unix philosophy at all. Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the most basic of which involves printing. Having to add, remove, then re-add "fmt" or "log" just to keep the compiler happy is not a Unix-philosophical issue around language design, it's just an unnecessary strictness. Go is "opinionated", but it tends to err on the side of impracticality, a kind of distorted, prematurely-optimized YAGNI that disrupts developer efficiency in the name of simplicity. "go get"'s obstinate simplicity is firmly in this category. Go gets a lot of stuff right, of course. And the tools — the "go" tool, compiler toolchain, gofmt, debugger, godoc etc. — are clearly good Unix citizens, of course.
- kasey_junk 11y ago
  Not commenting on the bigger picture about philosophy. But I couldn't work in go without: https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports
  - lobster_johnson 11y ago
    Indeed, I use this Sublime plugin, which wraps it: https://packagecontrol.io/packages/GoImports https://packagecontrol.io/packages/GoImports.
  - StavrosK 11y ago
    > But I couldn't work in go without: https://github.com/bradfitz/goimports https://github.com/bradfitz/goimports I think this statement makes both points simultaneously.
- sagichmal 11y ago
  > Unused imports flagged as an error is great for production code, but infuriating during developing, when you need to work with a lot of tentative code, the most basic of which involves printing. This sentence has baked into it a context which is not universal. Namely that "during developing" you are "work[ing] with a lot of tentative code". That's simply not how I, nor many others, develop. Even on the very first sketch of a program, I'm writing complete, valid types and functions. I code all of the error paths completely as I encounter them. For very large first drafts, I'll often stub methods or types, but I never leave the program in an invalid state and "try it out". (Tangentially, for what I suspect are similar reasons, I never quite understood why anyone would care so much about REPLs.) All of the tentativity, so to speak, has been expressed and explored in my head and on paper beforehand. Go is a language that rewards, perhaps even demands, this style of development. If that's not how you operate, Go will feel like it's fighting you. But that's not a universal critique of the language, that's a very specific critique of your specific operating context.
  - lobster_johnson 11y ago
    I'm pretty sure you are in the minority — REPLs are provably immensely popular, for example (I've never heard anyone criticize their usefulness). Sometimes I write code like you do. At other times I'm "feeling out" a solution and want the language to not fight my half-baked, messy (but syntactically valid!) program. At other times I'm writing a quick and dirty script I will use today and never after; it doesn't need to be pretty, only functional. But Go wants your code to always be fully realized and clean, which just doesn't mesh with reality. We don't need "universal critiques". Everyone has a style, and a good, mainstream programming language needs to be receptive to those styles.

maerF0x0 11y ago

IMO as engineers we're going to eventually need to get used to more productive modes than doing it all ourselves. If a piece of software can give my team a 1% speedup, it'd be worth $40k a year. Multiply that by lots of teams, we can see there is a big market on making engineers more productive.