13 ms·

I love Go, 90% of my company's codebase is in Go. But I can't ignore the Kool-Aid in this article. I don't see why people have perception of IDE being a bad th

by arihant 11y ago

I love Go, 90% of my company's codebase is in Go. But I can't ignore the Kool-Aid in this article. I don't see why people have perception of IDE being a bad thing. In past 15 years or so, I have never been in a situation where I was on a system where some IDE was not supported, and I wanted to use it. They are everywhere, just like vim. That's like mocking the Gmail cause it needs a browser, while praising mutt cause you can be lost in Jurassic World with an Apple II which cannot run Chrome. The build times of Go 1.5 are not that fast. That point is not that valid. I also don't see much point in have competition of build times among languages that compile to binary. Rust, Go, C are all fast enough. I'm sure he has good points below (I see testing as one), but he started out bashing Java, after which I genuinely did not want to read the article. I'm not a Java fan, but I find the language extremely non-assuming, very less opinionated and quite useful. If Go one day has half a million repos of libraries, given it's composability features, it will have names just as fugly as some Java classes. Java's standard libraries are actually very clean.

mseebach 11y ago
There's nothing wrong with an IDE per se -- but it's a smell when a language is so verbose that it effectively requires a machine to help you write it, which is definitely the case for Java. It's just a smell, it's not disqualifying, because, as you correctly state, rare are the times when you can't just run the IDE. But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE.
- threeseed 11y ago
  > but it's a smell when a language is so verbose You call it a smell I call it functionality. Get back to me when Go is at version 9 with decades of features added and then you can talk about verbosity. And this idea that you need an IDE to code Java is pure and utter rubbish.
- vanderZwan 11y ago
  In short, the IDE should be a productivity enhancer, not a crutch.
  - malnourish 11y ago
    Why? I hear a similar argument for things in the physical world ("well what if you lose your phone, how will you navigate then?") but this isn't an analogous situation. You won't be programming Go in a world where your IDE doesn't exist.
    - ryanong 11y ago
      No but when the GPS tells you to drive into the lake, you shouldn't drive into the lake.
- arihant 11y ago
  Well, Java isn't verbose. Certain codebases have gotten verbose because they are being maintained for years (decades?) with extremely functional tools. Give a Go team IntelliJ and 20 years, and then we can compare Go and Java codebases. > But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE. I would have to disagree with this point as well. To me, it feels like suggesting that computing is better with punch cards. Because, it is then also a fair point that a way of computing that can be done without a computer and editor is -- all other things being equal -- better than the way of computing that requires a computer and editor. I think that thinking this way will also help numb the next leap in methods of instructing computers, and performing computation. Whether that involves a programming language or not.
  - qooleot 11y ago
    "Well, Java isn't verbose." Maybe its just the code I've read, but its generally much longer than other languages to accomplish the same thing. A bunch of little things add up, such as "extends" instead of ":" for inheritance. Naming things is often longer - maybe its not the language core itself, but a counter example is python coding standards keeps them much shorter. With Go, there's duck typing to not have to declare obvious types (such as for strings). The goals of the programs in enterprise java apps probably differ by an emphasis on readability and not writing speed. I.e. lambdas are written quicker to write, but maybe a reader would understand a strategy pattern's goal quicker.
    - joshuacc 11y ago
      > With Go, there's duck typing to not have to declare obvious types Not a Go developer, but I think you mean type inference, not duck typing.
      - stonemetal 11y ago
        Not really, Go uses duck typing for interfaces. You declare an interface to require functions X, Y, and Z. Any type that has functions X, Y, and Z suddenly implements that interface whether you want it to or not.
- yokohummer7 11y ago
  > 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.
- ryandvm 11y ago
  > but it's a smell when a language is so verbose that it effectively requires a machine to help you write it Meh. People say the same thing right before starting a Node project with Sublime. Then they proceed to write an unmaintainable mess of JavaScript. With only the original author knowing who calls what, what gets returned, interface definitions, etc. I have yet to find a language that doesn't benefit from a capable, intelligent IDE.
  - adrusi 11y ago
    An IDE won't save you from writing a mess. For that you need good programmers, not good tools.
    - royjacobs 11y ago
      If a professional craftsman is building a house I'm sure he prefers using power tools to having to screw all screws in manually.
      - cwyers 11y ago
        Yeah. Good tools won't make a bad craftsman good, and that's as true for programming as it is for carpentry and plumbing. But that doesn't mean that good tools don't help good programmers.
      - adrusi 11y ago
        Prefers it, sure, but a great craftsman could build a better house using only manual tools than I could using any tool I want in the same amount of time. Also note that a carpenter building a house probably wouldn't choose the most powerful tools (tower crane, etc) even if financials were taken out of the equation. It doesn't make much sense to compare go's standard toolchain to building a house without power tools. What an IDE gets you over a more unix-like toolchain is integration, nothing more. They have all the same capabilities, but an IDE is designed to make a specific prescribed workflow seamless. There simply is no good analogy for this, carpenters don't have a universal tool that acts as a nailgun, drill, power screwdriver, wrench and saw at the same time.
realusername 11y ago
For the build times, I would say it's more that C++ is really slow and the others are indeed quite okay. If you have done some work in Qt or with a library using Boost, you just hate any slow build after that.
hakcermani 11y ago
And guess what Jetbrains will release a IDE for Go, written in Java ;-)
fit2rule 11y ago
The IDE question can be resolved, as itself as a political issue, with one question: do you have a USER? Because, actually, it doesn't matter a damn what tool or method you use to develop something - do you have a USER? No USER = failed project. I'm personally of the opinion that those who depend on an IDE, in and of itself, are doing the computer world a disservice - because they are perpetuating the 'special' nature of computing by stint of becoming competent with an IDE. IDE's require an investment, they require a portion of your life - investing that portion of life in a product specifically designed to impose limits on your freedom of speech is a gamble, plain and simple. Some people win from such an action - others complain bitterly. Either way, if your language and technology require a commitment of life, then it is either an enabling or an enslaving technology, to more or less a degree. Languages designed to free us from the requirement of using a specialized tool - which is what an IDE is - are of more or less value than languages that don't. And the key to this equation is: do you have a USER? In short: use an IDE if it is necessary for you to gain a USER. Beyond that point however, do not promote technologies with such dependencies. The best computer technologies do not require a big investment on the part of the user. This is true of IDE's. Corollary: the more you have to invest in a technology, the less valuable it is - on the basis of how many users you eventually gain as a result.
snapetom 11y ago
I'm a Python/PHP dev who got my first Go job a couple of months ago. I inherited a large, disorganized codebase. IntelliJ with the Go plugin has been huge for me. The ability to highlight something and select "Find Usages" or "Go to Declaration" has been critical in helping me understand this code.

by arihant 11y ago

mseebach 11y ago

There's nothing wrong with an IDE per se -- but it's a smell when a language is so verbose that it effectively requires a machine to help you write it, which is definitely the case for Java. It's just a smell, it's not disqualifying, because, as you correctly state, rare are the times when you can't just run the IDE. But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE.

threeseed 11y ago
> but it's a smell when a language is so verbose You call it a smell I call it functionality. Get back to me when Go is at version 9 with decades of features added and then you can talk about verbosity. And this idea that you need an IDE to code Java is pure and utter rubbish.
vanderZwan 11y ago
In short, the IDE should be a productivity enhancer, not a crutch.
- malnourish 11y ago
  Why? I hear a similar argument for things in the physical world ("well what if you lose your phone, how will you navigate then?") but this isn't an analogous situation. You won't be programming Go in a world where your IDE doesn't exist.
  - ryanong 11y ago
    No but when the GPS tells you to drive into the lake, you shouldn't drive into the lake.
arihant 11y ago
Well, Java isn't verbose. Certain codebases have gotten verbose because they are being maintained for years (decades?) with extremely functional tools. Give a Go team IntelliJ and 20 years, and then we can compare Go and Java codebases. > But I think it's a perfectly fair point that the language you can write effective in vi is -- all other things being equal -- better than the language that requires an IDE. I would have to disagree with this point as well. To me, it feels like suggesting that computing is better with punch cards. Because, it is then also a fair point that a way of computing that can be done without a computer and editor is -- all other things being equal -- better than the way of computing that requires a computer and editor. I think that thinking this way will also help numb the next leap in methods of instructing computers, and performing computation. Whether that involves a programming language or not.
- qooleot 11y ago
  "Well, Java isn't verbose." Maybe its just the code I've read, but its generally much longer than other languages to accomplish the same thing. A bunch of little things add up, such as "extends" instead of ":" for inheritance. Naming things is often longer - maybe its not the language core itself, but a counter example is python coding standards keeps them much shorter. With Go, there's duck typing to not have to declare obvious types (such as for strings). The goals of the programs in enterprise java apps probably differ by an emphasis on readability and not writing speed. I.e. lambdas are written quicker to write, but maybe a reader would understand a strategy pattern's goal quicker.
  - joshuacc 11y ago
    > With Go, there's duck typing to not have to declare obvious types Not a Go developer, but I think you mean type inference, not duck typing.
    - stonemetal 11y ago
      Not really, Go uses duck typing for interfaces. You declare an interface to require functions X, Y, and Z. Any type that has functions X, Y, and Z suddenly implements that interface whether you want it to or not.
yokohummer7 11y ago
> 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.
ryandvm 11y ago
> but it's a smell when a language is so verbose that it effectively requires a machine to help you write it Meh. People say the same thing right before starting a Node project with Sublime. Then they proceed to write an unmaintainable mess of JavaScript. With only the original author knowing who calls what, what gets returned, interface definitions, etc. I have yet to find a language that doesn't benefit from a capable, intelligent IDE.
- adrusi 11y ago
  An IDE won't save you from writing a mess. For that you need good programmers, not good tools.
  - royjacobs 11y ago
    If a professional craftsman is building a house I'm sure he prefers using power tools to having to screw all screws in manually.
    - cwyers 11y ago
      Yeah. Good tools won't make a bad craftsman good, and that's as true for programming as it is for carpentry and plumbing. But that doesn't mean that good tools don't help good programmers.
    - adrusi 11y ago
      Prefers it, sure, but a great craftsman could build a better house using only manual tools than I could using any tool I want in the same amount of time. Also note that a carpenter building a house probably wouldn't choose the most powerful tools (tower crane, etc) even if financials were taken out of the equation. It doesn't make much sense to compare go's standard toolchain to building a house without power tools. What an IDE gets you over a more unix-like toolchain is integration, nothing more. They have all the same capabilities, but an IDE is designed to make a specific prescribed workflow seamless. There simply is no good analogy for this, carpenters don't have a universal tool that acts as a nailgun, drill, power screwdriver, wrench and saw at the same time.

realusername 11y ago

For the build times, I would say it's more that C++ is really slow and the others are indeed quite okay. If you have done some work in Qt or with a library using Boost, you just hate any slow build after that.

hakcermani 11y ago

And guess what Jetbrains will release a IDE for Go, written in Java ;-)

fit2rule 11y ago

The IDE question can be resolved, as itself as a political issue, with one question: do you have a USER? Because, actually, it doesn't matter a damn what tool or method you use to develop something - do you have a USER? No USER = failed project. I'm personally of the opinion that those who depend on an IDE, in and of itself, are doing the computer world a disservice - because they are perpetuating the 'special' nature of computing by stint of becoming competent with an IDE. IDE's require an investment, they require a portion of your life - investing that portion of life in a product specifically designed to impose limits on your freedom of speech is a gamble, plain and simple. Some people win from such an action - others complain bitterly. Either way, if your language and technology require a commitment of life, then it is either an enabling or an enslaving technology, to more or less a degree. Languages designed to free us from the requirement of using a specialized tool - which is what an IDE is - are of more or less value than languages that don't. And the key to this equation is: do you have a USER? In short: use an IDE if it is necessary for you to gain a USER. Beyond that point however, do not promote technologies with such dependencies. The best computer technologies do not require a big investment on the part of the user. This is true of IDE's. Corollary: the more you have to invest in a technology, the less valuable it is - on the basis of how many users you eventually gain as a result.

snapetom 11y ago

I'm a Python/PHP dev who got my first Go job a couple of months ago. I inherited a large, disorganized codebase. IntelliJ with the Go plugin has been huge for me. The ability to highlight something and select "Find Usages" or "Go to Declaration" has been critical in helping me understand this code.