10 ms·

400 days of Go

131 points by selvan 11y ago

oweiler 11y ago
I once tried to write Java code using vim, and the runaway proliferation of source files, of AbstractSingletonProxyFactoryBeans, quickly made an IDE required I can't stand reading this crap anymore. I'm using Spring for at least 3 years and never had to deal with such class names. Though I agree that writing Java in vim is quite painful.
- kapilvt 11y ago
  re spring class names, this is always fun http://java.metagno.me/ http://java.metagno.me/ shows generally reasonable names, but still some gems like "ComplexPortletApplicationContext.MyHandlerAdapter"
- scalesolved 11y ago
  Agreed, with Lombok/Spring/Spring Data and zero xml config these days Java project verbosity has dropped crazily low. It's just nice to hate on it, I'd still always use an IDE because I can't remember the exact APIs for everything! :)
- smacktoward 11y ago
  The good news is that Java has gotten much less verbose than it used to be. The bad news is that umpty million programmers tried Java before that happened, decided they hated it, and now will never look at it again. As the saying goes, you never get a second chance to make a first impression.
- Sikul 11y ago
  IntelliJ has a good vim plugin. It is the best of both worlds for me.
shurcooL 11y ago
If you don't like GOPATH workspace and use a separate GOPATH for each project, you should just use gb [1] which was designed and built with that use case as a goal. Build tool and language are somewhat separate concepts. [1] https://getgb.io https://getgb.io
- lobster_johnson 11y ago
  gb is promising, but doesn't feel like the complete solution quite yet. The author only hesitantly added support for managing dependencies, which is done through a separate "plugin", gb-vendor. It maintains an internal manifest file which only the gb-vendor tool is supposed to manage. It's not like NPM or Ruby's Bundler where you the manifest file (package.json, Gemfile) is what you edit to produce the vendor tree. Support for branches and tags seems to missing, as does any notion of versioning, so of course semver is not on the table. I understand the Unix philosophy of keeping dependency management and building separate tools, but I suspect that what most Go developers want is a fully integrated solution. I know I do.
hacker_9 11y ago
Stopped reading after author considered IDE's to be a code smell. I mean honestly - they are there to make life easier and speed up writing code. 99% of the time I only have to type 2 chars + [TAB] and autocomplete completes the word for me. Now I have a descriptive word that I can read and write in less than a second. How is this bad? Coupled with contextual member browsing on typing a '.', and contextual rename refactoring, and contextual errors/warnings underlining... The fact that Go doesn't have an official IDE is actually what stops me from going near the language.
- deleted 11y ago
  [deleted]
- ane 11y ago
  Even if it's not official the IntelliJ Go plugin is quite good. It recently added support for a debugger, and it has a lot of static analysis capabilities and refactoring. I would say it is on par with other environments for most serious languages. The Emacs go-mode and vim-go are good enough but not as great. There is a general attitude in the Go community eschewing all sorts of complexity be it in the language itself or tooling and this attitude is toxic and stupid. It will prevent Go from becoming a serious language unless this nonsense about "simplicity" is left to perpetuate. There is nothing wrong with keeping a language elegant--cue a brouhaha about generics in 1... 2... 3...---but forcing this attitude to tooling is not a wise thing to do. A significant majority of professional devs do not write their code in vim without syntax highlighting, which is what some eminent members of the Go community seem to be in favour of. They need auto-completion, refactoring (which search and replace isn't), automated deployment and testing, debugging and project support.
  - adrusi 11y ago
    For the state of the art vim and emacs go support, look at gocode, which runs an auto completion daemon. I don't know what you mean by "forcing this attitude on the tooling". The only thing that people tend eschew a tool for is if it's too big, like ides tend to be. Go has a plan9 heritage, and therefore a unix heritage. People like the tools to be small and designed to integrate. The reason that I like writing go is because save for C, nothing else feels as unixy, as vague as that sounds. It sounds like you ran into some hostility. If people are railing on others about their IDE usage, they're assholes, and assholes do tend to stick out. Go is opinionated, and while that tends to make for a cohesive ecosystem, it also attracts assholes unfortunately. Most go developers, though, while they aren't interested in an IDE for themselves, have no problem with someone else using one if they prefer that mode of working.
pif 11y ago
> So if there is one word to summarize Go, it’s productive. > ... > boilerplate ... This can make code maintenance more difficult. These two sentences can't be both right. Most of the work in software development is maintenance. A tool that lets you ship bad code faster is going in the wrong direction.
- Willyfrog 11y ago
  it's not "bad code faster", but "a lot more bad code faster" as you should copy&paste your wrongly implemented functions for every different type.
- yxhuvud 11y ago
  They can both be true at the same time, because productivity is not a boolean, it is a float.
  - darkr 11y ago
    bool and float32, surely. If you'd have been using an IDE...
clessg 11y ago
I've used Go for numerous web projects, and I dislike it progressively more as time goes on. There are a lot of things that I really like about it, but I feel as though its advocates have a bit of stockholm syndrome. If Go makes X difficult or clumsy, then clearly X is a bad idea and you should Do It The Go Way™. I hope that doesn't come across as too dismissive; it's just been my experience. I really like some of the decisions around Go, but I don't like Go itself, as a language. For web apps, at least. I've been looking at http://elixir-lang.org/ http://elixir-lang.org/ and http://www.phoenixframework.org/ http://www.phoenixframework.org/ and I really hope that they gain steam before Go does. I will continue to use Go for command-line apps, which I think it is very well suited for.
- laumars 11y ago
  I get what you mean there. For the stuff Go is good at, it's very nice to work with. But for the stuff it's not so great at, it's often just a pain. While this is true for most / all languages, it feels more apparent in Go since it's very inflexible outside of the Go idiom. I guess a fair comparison would be like Linux how the many flavours others users variety and freedom, but it also complicates and often introduces subtle incompatibilities (albeit usually resolvable if you know what you're doing). And similarly the Go idiot is a double edged sword that sometimes enables it's users, and sometimes hinders.
- tptacek 11y ago
  If you replace "X is bad" with "X is not the right way to solve the problem in Go programs", you end up with a much more reasonable statement. Lots of good, even great things don't make sense in every program. The notion that every good thing should be available to every program seems more unreasonable to me than the inverse notion.
  - kasey_junk 11y ago
    Absolutely, but there is certainly a very large strain of "father knows best" in the golang language and community. Which can be very off putting.
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.
al2o3cr 11y ago
"By building both in, it has resulted in a standard and systematic way for Go programmers to deal with these data structures" Also, nothing says "use the standard way" like making the built-ins the only thing that's generic...
bsaul 11y ago
I think everybody agrees on the quality of go standard lib. Has anyone tried to reimplement it with a different language ? I'm thinking maybe D, Rust, nimrod, java, scala, or even swift ( in anticipation to its open sourcing in a few months) could make good candidates.
atilaneves 11y ago
Several of the "why Go is good" points aren't unique to Go.
ciupicri 11y ago
> Key data structures built-in Yet a decimal data type is missing.
- AnimalMuppet 11y ago
  Why do you consider that a key data structure? (It may be key for your application, but should it really be key for the language as a whole?)
  - ciupicri 11y ago
    Some scientific and accounting software require it. Python has a decimal data type [1]. [1]: https://docs.python.org/3/library/decimal.html https://docs.python.org/3/library/decimal.html
    - AnimalMuppet 11y ago
      Sure. But that doesn't make it "key" in the sense that, say, lists and maps are.
      - dragonwriter 11y ago
        > Sure. But that doesn't make it "key" in the sense that, say, lists and maps are. No, its more like "key" in the way that ints are. Well, not quite -- less than ints, but more than floats.
        AnimalMuppet 11y ago
        You think that, across computing in general, decimal data types are used more than floats are? I am extremely skeptical. (Or do you have data?)
        dragonwriter 11y ago
        No, I'm not saying they are used more often, but they are more important in major application domains. Floats are used more often, but often not because they are domain-appropriate, often as a premature optimization, or as a matter of developer convenience because many major tools (languages and libraries) make float use more convenient. Exact rationals are in a similar situation.
rumcajz 11y ago
> Now I may underestimate the work GC is doing for me — quite possibly — but if I had to track the memory myself, and still write Go code, I don’t think I’d really mind. I've written a go-style concurrency library for C for people who share this sentiment: http://libmill.org http://libmill.org
ldite 11y ago
Go get is an astonishing demonstration of failing to learn the lessons of the past; it's bad enough watching Python, Ruby, Node, Java et. al. painfully re-invent the wheel of dependency management, but at least they seem to have gained the notion of versioning. Go seems to have taken a look at the carnage of decades of dependency hell and decided "if we make no effort to provide a system then people will be forced to produce sane stable APIs". I've picked the short straw of trying to reproducibly build and package Go based projects for internal projects. The combination of go get and the Go ecosystem's cultural lack of versioning and stability are giving me a deep dislike of the language. First you have to play git-bisect on the dependencies (after you've hunted them down because of repo renames) in order to find the most recent one it builds against (and who knows if that was the one written against!) Then you have to futz around to add in either some custom or third party vendoring script, and then you have to rinse and repeat for second order dependencies. For example, take the author's own first linked project. Following the build instructions: ~ $ mkdir ~/syslog-gollector ~ $ cd ~/syslog-gollector ~/syslog-gollector $ export GOPATH=$PWD ~/syslog-gollector $ go get github.com/otoolep/syslog-gollector package github.com/otoolep/syslog-gollector imports code.google.com/p/log4go imports github.com/otoolep/sarama imports code.google.com/p/snappy-go/snappy: unable to detect version control system for code.google.com/ path ~/syslog-gollector $ go install github.com/otoolep/syslog-gollector src/github.com/otoolep/sarama/snappy.go:5:2: cannot find package "code.google.com/p/snappy-go/snappy" in any of: /usr/lib/golang/src/code.google.com/p/snappy-go/snappy (from $GOROOT) /home/ldite/syslog-gollector/src/code.google.com/p/snappy-go/snappy (from $GOPATH) Well, I'm shocked.
- hellbanner 11y ago
  I gave up Go from Google's tutorial level 1 when I had a compile error. What language ecosystems do you feel have good dependency management?
  - alexro 11y ago
    .net is good to me
  - escherize 11y ago
joesmo 11y ago
Interesting, but what I'd really like to know about and the author didn't mention is the debugging situation. The debugging tools and styles available on a platform are truly a make it or break it deal for me. It's a huge factor in productivity, sometimes the main one. Maybe someone with experience in this area can delve into this topic a bit further? I think the availability of third party libraries in various areas is another huge factor that the author missed.
- ominous_prime 11y ago
  Not that there's anything wrong with using a debugger as a tool, but I find it hard to understand why it's such a stringent requirement for some. I've never really had the need for one outside of a few instances over many languages, and I know many others that feel the same, which covers a much greater range of languages and styles of programming. Even so, I'm eagerly awaiting a good Go debugger when one arrives. There are some being worked on, like delve (https://github.com/derekparker/delve/ https://github.com/derekparker/delve/), which might be the most ambitious, but it's only recently becoming usable. The problem is partly due to my first statement, there's not a huge demand for these in the language ecosystem, so development has been slow.
  - joesmo 11y ago
    After using a proper debugger, I can almost say I'll never go back to a language without one. It's such a useful tool, I use it a lot even when writing code. I think if you asked a functional programmer to give up their REPL, they might not be so happy. The debugger is essentially the REPL of imperial languages (because a REPL by itself is not enough for imperial languages since all the state has to be set up). Also, it's extremely useful when learning a new codebase as well as actually debugging bugs. I also think it's necessary to have one for a language to gain mainstream support.
    - Shorel 11y ago
      By "imperial languages" do you mean "imperative languages", right?

131 points by selvan 11y ago

I once tried to write Java code using vim, and the runaway proliferation of source files, of AbstractSingletonProxyFactoryBeans, quickly made an IDE required I can't stand reading this crap anymore. I'm using Spring for at least 3 years and never had to deal with such class names. Though I agree that writing Java in vim is quite painful.

kapilvt 11y ago
re spring class names, this is always fun http://java.metagno.me/ http://java.metagno.me/ shows generally reasonable names, but still some gems like "ComplexPortletApplicationContext.MyHandlerAdapter"
scalesolved 11y ago
Agreed, with Lombok/Spring/Spring Data and zero xml config these days Java project verbosity has dropped crazily low. It's just nice to hate on it, I'd still always use an IDE because I can't remember the exact APIs for everything! :)
smacktoward 11y ago
The good news is that Java has gotten much less verbose than it used to be. The bad news is that umpty million programmers tried Java before that happened, decided they hated it, and now will never look at it again. As the saying goes, you never get a second chance to make a first impression.
Sikul 11y ago
IntelliJ has a good vim plugin. It is the best of both worlds for me.

shurcooL 11y ago

If you don't like GOPATH workspace and use a separate GOPATH for each project, you should just use gb [1] which was designed and built with that use case as a goal. Build tool and language are somewhat separate concepts. [1] https://getgb.io https://getgb.io

lobster_johnson 11y ago
gb is promising, but doesn't feel like the complete solution quite yet. The author only hesitantly added support for managing dependencies, which is done through a separate "plugin", gb-vendor. It maintains an internal manifest file which only the gb-vendor tool is supposed to manage. It's not like NPM or Ruby's Bundler where you the manifest file (package.json, Gemfile) is what you edit to produce the vendor tree. Support for branches and tags seems to missing, as does any notion of versioning, so of course semver is not on the table. I understand the Unix philosophy of keeping dependency management and building separate tools, but I suspect that what most Go developers want is a fully integrated solution. I know I do.

hacker_9 11y ago

Stopped reading after author considered IDE's to be a code smell. I mean honestly - they are there to make life easier and speed up writing code. 99% of the time I only have to type 2 chars + [TAB] and autocomplete completes the word for me. Now I have a descriptive word that I can read and write in less than a second. How is this bad? Coupled with contextual member browsing on typing a '.', and contextual rename refactoring, and contextual errors/warnings underlining... The fact that Go doesn't have an official IDE is actually what stops me from going near the language.

deleted 11y ago
[deleted]
ane 11y ago
Even if it's not official the IntelliJ Go plugin is quite good. It recently added support for a debugger, and it has a lot of static analysis capabilities and refactoring. I would say it is on par with other environments for most serious languages. The Emacs go-mode and vim-go are good enough but not as great. There is a general attitude in the Go community eschewing all sorts of complexity be it in the language itself or tooling and this attitude is toxic and stupid. It will prevent Go from becoming a serious language unless this nonsense about "simplicity" is left to perpetuate. There is nothing wrong with keeping a language elegant--cue a brouhaha about generics in 1... 2... 3...---but forcing this attitude to tooling is not a wise thing to do. A significant majority of professional devs do not write their code in vim without syntax highlighting, which is what some eminent members of the Go community seem to be in favour of. They need auto-completion, refactoring (which search and replace isn't), automated deployment and testing, debugging and project support.
- adrusi 11y ago
  For the state of the art vim and emacs go support, look at gocode, which runs an auto completion daemon. I don't know what you mean by "forcing this attitude on the tooling". The only thing that people tend eschew a tool for is if it's too big, like ides tend to be. Go has a plan9 heritage, and therefore a unix heritage. People like the tools to be small and designed to integrate. The reason that I like writing go is because save for C, nothing else feels as unixy, as vague as that sounds. It sounds like you ran into some hostility. If people are railing on others about their IDE usage, they're assholes, and assholes do tend to stick out. Go is opinionated, and while that tends to make for a cohesive ecosystem, it also attracts assholes unfortunately. Most go developers, though, while they aren't interested in an IDE for themselves, have no problem with someone else using one if they prefer that mode of working.

pif 11y ago

> So if there is one word to summarize Go, it’s productive. > ... > boilerplate ... This can make code maintenance more difficult. These two sentences can't be both right. Most of the work in software development is maintenance. A tool that lets you ship bad code faster is going in the wrong direction.

Willyfrog 11y ago
it's not "bad code faster", but "a lot more bad code faster" as you should copy&paste your wrongly implemented functions for every different type.
yxhuvud 11y ago
They can both be true at the same time, because productivity is not a boolean, it is a float.
- darkr 11y ago
  bool and float32, surely. If you'd have been using an IDE...

clessg 11y ago

I've used Go for numerous web projects, and I dislike it progressively more as time goes on. There are a lot of things that I really like about it, but I feel as though its advocates have a bit of stockholm syndrome. If Go makes X difficult or clumsy, then clearly X is a bad idea and you should Do It The Go Way™. I hope that doesn't come across as too dismissive; it's just been my experience. I really like some of the decisions around Go, but I don't like Go itself, as a language. For web apps, at least. I've been looking at http://elixir-lang.org/ http://elixir-lang.org/ and http://www.phoenixframework.org/ http://www.phoenixframework.org/ and I really hope that they gain steam before Go does. I will continue to use Go for command-line apps, which I think it is very well suited for.

laumars 11y ago
I get what you mean there. For the stuff Go is good at, it's very nice to work with. But for the stuff it's not so great at, it's often just a pain. While this is true for most / all languages, it feels more apparent in Go since it's very inflexible outside of the Go idiom. I guess a fair comparison would be like Linux how the many flavours others users variety and freedom, but it also complicates and often introduces subtle incompatibilities (albeit usually resolvable if you know what you're doing). And similarly the Go idiot is a double edged sword that sometimes enables it's users, and sometimes hinders.
tptacek 11y ago
If you replace "X is bad" with "X is not the right way to solve the problem in Go programs", you end up with a much more reasonable statement. Lots of good, even great things don't make sense in every program. The notion that every good thing should be available to every program seems more unreasonable to me than the inverse notion.
- kasey_junk 11y ago
  Absolutely, but there is certainly a very large strain of "father knows best" in the golang language and community. Which can be very off putting.

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.

al2o3cr 11y ago

"By building both in, it has resulted in a standard and systematic way for Go programmers to deal with these data structures" Also, nothing says "use the standard way" like making the built-ins the only thing that's generic...

bsaul 11y ago

I think everybody agrees on the quality of go standard lib. Has anyone tried to reimplement it with a different language ? I'm thinking maybe D, Rust, nimrod, java, scala, or even swift ( in anticipation to its open sourcing in a few months) could make good candidates.

atilaneves 11y ago

Several of the "why Go is good" points aren't unique to Go.

ciupicri 11y ago

> Key data structures built-in Yet a decimal data type is missing.

AnimalMuppet 11y ago
Why do you consider that a key data structure? (It may be key for your application, but should it really be key for the language as a whole?)
- ciupicri 11y ago
  Some scientific and accounting software require it. Python has a decimal data type [1]. [1]: https://docs.python.org/3/library/decimal.html https://docs.python.org/3/library/decimal.html
  - AnimalMuppet 11y ago
    Sure. But that doesn't make it "key" in the sense that, say, lists and maps are.
    - dragonwriter 11y ago
      > Sure. But that doesn't make it "key" in the sense that, say, lists and maps are. No, its more like "key" in the way that ints are. Well, not quite -- less than ints, but more than floats.
      - AnimalMuppet 11y ago
        You think that, across computing in general, decimal data types are used more than floats are? I am extremely skeptical. (Or do you have data?)
        dragonwriter 11y ago
        No, I'm not saying they are used more often, but they are more important in major application domains. Floats are used more often, but often not because they are domain-appropriate, often as a premature optimization, or as a matter of developer convenience because many major tools (languages and libraries) make float use more convenient. Exact rationals are in a similar situation.

rumcajz 11y ago

> Now I may underestimate the work GC is doing for me — quite possibly — but if I had to track the memory myself, and still write Go code, I don’t think I’d really mind. I've written a go-style concurrency library for C for people who share this sentiment: http://libmill.org http://libmill.org

ldite 11y ago

Go get is an astonishing demonstration of failing to learn the lessons of the past; it's bad enough watching Python, Ruby, Node, Java et. al. painfully re-invent the wheel of dependency management, but at least they seem to have gained the notion of versioning. Go seems to have taken a look at the carnage of decades of dependency hell and decided "if we make no effort to provide a system then people will be forced to produce sane stable APIs". I've picked the short straw of trying to reproducibly build and package Go based projects for internal projects. The combination of go get and the Go ecosystem's cultural lack of versioning and stability are giving me a deep dislike of the language. First you have to play git-bisect on the dependencies (after you've hunted them down because of repo renames) in order to find the most recent one it builds against (and who knows if that was the one written against!) Then you have to futz around to add in either some custom or third party vendoring script, and then you have to rinse and repeat for second order dependencies. For example, take the author's own first linked project. Following the build instructions: ~ $ mkdir ~/syslog-gollector ~ $ cd ~/syslog-gollector ~/syslog-gollector $ export GOPATH=$PWD ~/syslog-gollector $ go get github.com/otoolep/syslog-gollector package github.com/otoolep/syslog-gollector imports code.google.com/p/log4go imports github.com/otoolep/sarama imports code.google.com/p/snappy-go/snappy: unable to detect version control system for code.google.com/ path ~/syslog-gollector $ go install github.com/otoolep/syslog-gollector src/github.com/otoolep/sarama/snappy.go:5:2: cannot find package "code.google.com/p/snappy-go/snappy" in any of: /usr/lib/golang/src/code.google.com/p/snappy-go/snappy (from $GOROOT) /home/ldite/syslog-gollector/src/code.google.com/p/snappy-go/snappy (from $GOPATH) Well, I'm shocked.

hellbanner 11y ago
I gave up Go from Google's tutorial level 1 when I had a compile error. What language ecosystems do you feel have good dependency management?
- alexro 11y ago
  .net is good to me
- escherize 11y ago

joesmo 11y ago

Interesting, but what I'd really like to know about and the author didn't mention is the debugging situation. The debugging tools and styles available on a platform are truly a make it or break it deal for me. It's a huge factor in productivity, sometimes the main one. Maybe someone with experience in this area can delve into this topic a bit further? I think the availability of third party libraries in various areas is another huge factor that the author missed.

ominous_prime 11y ago
Not that there's anything wrong with using a debugger as a tool, but I find it hard to understand why it's such a stringent requirement for some. I've never really had the need for one outside of a few instances over many languages, and I know many others that feel the same, which covers a much greater range of languages and styles of programming. Even so, I'm eagerly awaiting a good Go debugger when one arrives. There are some being worked on, like delve (https://github.com/derekparker/delve/ https://github.com/derekparker/delve/), which might be the most ambitious, but it's only recently becoming usable. The problem is partly due to my first statement, there's not a huge demand for these in the language ecosystem, so development has been slow.
- joesmo 11y ago
  After using a proper debugger, I can almost say I'll never go back to a language without one. It's such a useful tool, I use it a lot even when writing code. I think if you asked a functional programmer to give up their REPL, they might not be so happy. The debugger is essentially the REPL of imperial languages (because a REPL by itself is not enough for imperial languages since all the state has to be set up). Also, it's extremely useful when learning a new codebase as well as actually debugging bugs. I also think it's necessary to have one for a language to gain mainstream support.
  - Shorel 11y ago
    By "imperial languages" do you mean "imperative languages", right?