400 days of Go(philipotoole.com)
philipotoole.com
400 days of Go
http://www.philipotoole.com/400-days-of-go/
111 comments
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.
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.
> 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?)
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?)
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.
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.
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.
> 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.
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.
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.
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.
> Go wants your code to always be fully realized and clean, which just doesn't mesh with reality.
It certainly meshes with my reality.
It certainly meshes with my reality.
Sure. Great. However, there are other realities outside yours.
...yes, of course. Acknowledging the diverse set of realities is the point of my original comment :)
...But the fact that it is diverse is the exact problem that Go doesn't address.
A language isn't obliged to serve all realities equally. Quite the opposite: a language, a framework, a system -- a product -- should carve out a set of contexts that it's explicitly targeting, and fiercely guard those boundaries.
Otherwise, you get terrible products that are nothing more than the lesser sum of their features, like JIRA, or Scala.
Otherwise, you get terrible products that are nothing more than the lesser sum of their features, like JIRA, or Scala.
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
> But I couldn't work in go without: https://github.com/bradfitz/goimports
I think this statement makes both points simultaneously.
I think this statement makes both points simultaneously.
Indeed, I use this Sublime plugin, which wraps it: https://packagecontrol.io/packages/GoImports.
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.
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.
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.
In short, the IDE should be a productivity enhancer, not a crutch.
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.
No but when the GPS tells you to drive into the lake, you shouldn't drive into the lake.
> 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.
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.
An IDE won't save you from writing a mess. For that you need good programmers, not good tools.
If a professional craftsman is building a house I'm sure he prefers using power tools to having to screw all screws in manually.
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.
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.
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.
I couldn't agree more. I see a ton of code that's not formatted correctly, doesn't have proper docblocks and a whole bunch of other stuff that was obviously left out because the creators were too lazy and didn't have the proper tools that would make fixing small things like that simple and easy. This almost always comes from people who claim they don't need an IDE. If you truly don't need an IDE and can write code that's up to par with people that do have one, that's fine. But most of the time, I just hear excuses of why the code isn't clean, and I automatically assume that these people just don't care about their work at all because they're not even interested in tools that will better their code. Needless to say, I try never to work with them again.
EDIT: Other stuff that's often gotten wrong are short variable/function names and spacing.
EDIT: Other stuff that's often gotten wrong are short variable/function names and spacing.
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.
> 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.
"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.
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.
Java programs got that way not because of language, but because teams of thousands of developers managing same codebase for decades. Explicitness and non-magicness are extremely valued in that environment.
Imagine you're refactoring a code written by employee #12340 that was written 10 years ago. With Go, you'd go file after file decomposing the program to finally figure out that if he just used a word to implement an interface, you only had to read that file and a javadoc. Long class names are still easier to look than signatures of functions.
Java emphasises abstraction. Go emphasises composition. Both have its uses, but what I was refuting was people claiming that Go is better than Java which I think is extremely uninformed conclusion.
Imagine you're refactoring a code written by employee #12340 that was written 10 years ago. With Go, you'd go file after file decomposing the program to finally figure out that if he just used a word to implement an interface, you only had to read that file and a javadoc. Long class names are still easier to look than signatures of functions.
Java emphasises abstraction. Go emphasises composition. Both have its uses, but what I was refuting was people claiming that Go is better than Java which I think is extremely uninformed conclusion.
> Explicitness and non-magicness are extremely valued in that environment.
This is not my experience with Java programs.
Enterprise Java programs often have many layers of magic abstraction, like Aspect-Oriented Programming, dependency injection, IOC.
Furthermore, people love using configuration files over code to determine program behaviour (see servlet configs, etc).
This is not my experience with Java programs.
Enterprise Java programs often have many layers of magic abstraction, like Aspect-Oriented Programming, dependency injection, IOC.
Furthermore, people love using configuration files over code to determine program behaviour (see servlet configs, etc).
If you had said this comment 5 years ago, I would agree. I think you should take a look into today's Java development environment. It's world class, and light-years ahead of anything else out there.
Good to hear. I haven't programmed in Java in about that much time :)
> 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.
Not a Go developer, but I think you mean type inference, not duck typing.
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.
As I understand it, the correct term for that is "structural typing." Duck typing is similar, but applies exclusively to dynamic languages. See: https://en.wikipedia.org/wiki/Duck_typing#Structural_type_sy...
> 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.
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.
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.
And guess what Jetbrains will release a IDE for Go, written in Java ;-)
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.
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.
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.
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:
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)
I cannot upvote this enough. Go's dependency management is horrible. The fact that I have to encode my current github account to make things `go get`able is crazy! When projects move accounts or hosts it breaks everything. Not to mention that no one doing Go seriously actually uses `go get` to download dependencies. But, if you want the broadest audience for a library it needs to support `go get`!
There is furthermore, no way to build release packages that people can just install. There are no tarballs or jars or anything else that can be simply downloaded and depended on. So not only is everything tied to my github account I can't even release stable versions in any sane way. I never thought I would say "Man Java is really doing it right" but in comparison to Go it is!
I love writing in the language, but I solve this problem by mostly depending on only stuff I have written. That way I can at least control the problem. I have even started using submodules again! At least that way I can pin my dependencies to specific versions without having to use a third party tool. Insanity!
There is furthermore, no way to build release packages that people can just install. There are no tarballs or jars or anything else that can be simply downloaded and depended on. So not only is everything tied to my github account I can't even release stable versions in any sane way. I never thought I would say "Man Java is really doing it right" but in comparison to Go it is!
I love writing in the language, but I solve this problem by mostly depending on only stuff I have written. That way I can at least control the problem. I have even started using submodules again! At least that way I can pin my dependencies to specific versions without having to use a third party tool. Insanity!
Yeah. Lately there's been a lot of people recommending that you just copy and paste code. Dependency management for the future.
Maybe that's just poor documentation on the author's part. If you simply try and go get the package (running Go 1.5 here):
Yes, Go does not have a culture of versioning, but it _does_ have a culture of _vendoring_. You should be getting your reproducible builds by vendoring your dependencies. That way, you don't need to do any hunting or git-bisect shenanigans.
~ $ go get -u github.com/otoolep/syslog-gollector
warning: code.google.com is shutting down; import path code.google.com/p/log4go will stop working
warning: code.google.com is shutting down; import path code.google.com/p/snappy-go/snappy will stop working
~ $
Yes, Go does not have a culture of versioning, but it _does_ have a culture of _vendoring_. You should be getting your reproducible builds by vendoring your dependencies. That way, you don't need to do any hunting or git-bisect shenanigans.
Except in your example your command will update the vendored code, potentially (and in some cases probably) breaking dependencies.
It is a fact, that the go dependency management story is weaker than nearly any of the other modern development environments there are. It is getting better through time, and probably won't a problem long term (and for many people isn't a problem now). But lets not act like it isn't a weakness.
It is a fact, that the go dependency management story is weaker than nearly any of the other modern development environments there are. It is getting better through time, and probably won't a problem long term (and for many people isn't a problem now). But lets not act like it isn't a weakness.
> You should be getting your reproducible builds by vendoring your dependencies.
As I said, I've been working with code I didn't write: I've effectively been taking other people's *hub code and vendoring it for them, because they haven't. This is not optimal.
And this isn't trivial projects, either, e.g. https://github.com/influxdb/influxdb/ (also connected to the author!) still uses trivial go get, and doesn't make any effort to help with vendoring.
As I said, I've been working with code I didn't write: I've effectively been taking other people's *hub code and vendoring it for them, because they haven't. This is not optimal.
And this isn't trivial projects, either, e.g. https://github.com/influxdb/influxdb/ (also connected to the author!) still uses trivial go get, and doesn't make any effort to help with vendoring.
You can't fight a cargo cult because they are proud of their irrational beliefs—they tie their backwards rituals into their private self image. You can't out rationalize them because you aren't fighting their tools—you are fighting their perception of themselves. That's a thing people will die for.
The only way out is to get them focusing on a new cult instead, thereby changing their self-ego attachment to less broken and less dangerous ideas.
edit: lol downvotes
The only way out is to get them focusing on a new cult instead, thereby changing their self-ego attachment to less broken and less dangerous ideas.
edit: lol downvotes
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?
What language ecosystems do you feel have good dependency management?
Haskell has a pretty cool new dependency management tool called stack (https://github.com/commercialhaskell/stack).
It's based on the curated package server https://stackage.org which server sets of packages that are tested for compatibility.
It's based on the curated package server https://stackage.org which server sets of packages that are tested for compatibility.
Anecodtal, but over 2 years I've never had a problem with Clojure's dependency management.
.net is good to me
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/ and 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.
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/ and 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.
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.
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.
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.
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.
It's probably the ~5 years of Ruby I did prior to Go that inoculates me from that; I'd rather have "father knows best" than the opposite.
As somebody who's done a lot of Ruby, I can sympathize with that. But the rationalization is typically very religious: it often turns out that every decision made in the language is obviously the right decision. If you disagree, then you're wrong, and you should just accept it and stop questioning it. (This is not hyperbole. People actually say this.)
The Go community can be really problematic and condescending. Which is another reason why Elixir appeals to me: you get treated like a person.
The Go community can be really problematic and condescending. Which is another reason why Elixir appeals to me: you get treated like a person.
Well, if I'm in a position to re-write the language, then how I think they should do it matters. If I'm in a position to select which language gets used on a project, then which language does it the way I prefer matters.
But if I'm in the middle of a project in language X, trying to do Y, then "shut up and do it the way we do Y in X" really might be the correct answer. Work with the tool, not against it...
But if I'm in the middle of a project in language X, trying to do Y, then "shut up and do it the way we do Y in X" really might be the correct answer. Work with the tool, not against it...
For the record. It is never not the case that if you find a way of doing something very difficult in a particular language, you should look for a way to do it in that language that is not difficult.
That may sound trite, but it's not as bad as it sounds I think. As an example: People want to make their own map (or have a library that provides map) in go, but go just will not play ball. The algorithms and writing styles people had in mind that use map shouldn't be written, and if you legitimately cannot express a concept concisely without it, than that makes go a worse language.
That may sound trite, but it's not as bad as it sounds I think. As an example: People want to make their own map (or have a library that provides map) in go, but go just will not play ball. The algorithms and writing styles people had in mind that use map shouldn't be written, and if you legitimately cannot express a concept concisely without it, than that makes go a worse language.
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.
The fact that Go doesn't have an official IDE is actually what stops me from going near the language.
> Stopped reading after author considered IDE's to be a code smell.
That's not what the article claims, however. The author critizes languages that _require_ an IDE, not the availability of IDEs.
That's not what the article claims, however. The author critizes languages that _require_ an IDE, not the availability of IDEs.
He is just in love with the shiny toy: Go is good, Go doesnt have and IDE => IDE is bad.
I have seen a guy on HN saying that debuggers are bad and logging debug messages is superior :). Future is here, but it is sooo unevenly distributed.
I have seen a guy on HN saying that debuggers are bad and logging debug messages is superior :). Future is here, but it is sooo unevenly distributed.
For certain classes of software development, specifically distributed systems, debuggers are bad (or, at least, effectively useless) and logging debug messages is superior (because it's the best way to rebuild a chain of causality).
It's all about context. Go is a great tool for certain things. Understand the boundaries of those domains, rather than castigating the tool.
It's all about context. Go is a great tool for certain things. Understand the boundaries of those domains, rather than castigating the tool.
That's another good point - no official go debugger. Additionally IDE's give you breakpoints, line highlighting, contextual variable inspection and so on.
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.
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.
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.
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.
I think his point is that writing Go with a simple editor is just fine. Some languages are a pain to write without an IDE.
On the other hand, I'm with you on the fact that not having a good IDE is actually a bad thing. If you want to code with a single editor, that's fine, but IDEs boost productivity a lot once you learn how to use them. Not having a proper IDE is a minus for a language in my opinion.
On the other hand, I'm with you on the fact that not having a good IDE is actually a bad thing. If you want to code with a single editor, that's fine, but IDEs boost productivity a lot once you learn how to use them. Not having a proper IDE is a minus for a language in my opinion.
Link is "Needing an IDE should be a code smell".
Nothing controversial there.
Nothing controversial there.
IDEs can be a crutch. To me vim is genuinely faster at text navigation and manipulation to the point that none of the benefits of an IDE are worth the trade. Plus you can add many of the features you mentioned to vim quite easily but adding an accurate an useful vim-clone mode to an IDE can be difficult. Being able to select a block of code with a keyboard shortcut and then apply a complex regular expression search and replace inside that block and reformat the block in pure fast keyboard shortcuts is too powerful. Really the only time I ever end up in an IDE these days is if I need to build a GUI. Even then I usually drop back to vim for the code editing.
Relying on the accuracy of a VIM mode implies that the best way to do with VIM does is to do exactly what VIM does, when there may be better, but less familiar ones.
Go does have IDE features in it's tooling though (eg gofmt). A lot of text editors use Go's official tooling and basically end up functioning a lot like a cut down IDE (eg Sublime has autocompletion, build tools, etc). There's even vim plugins to run these tools.
So it's a little deceptive when some within the Go community argue that they don't need an IDE because half the time they're basically running their text editor as a lightweight IDE.
As an aside note there's also LiteIDE which, at one point, was the "unofficial official" Go IDE - if you will. A de facto recommendation for anyone new to Go and fancying an IDE. I'm not sure if anyone still uses it for any serious Go development but that supported a few more features that the average Go-enabled text editors didn't at that time.
So it's a little deceptive when some within the Go community argue that they don't need an IDE because half the time they're basically running their text editor as a lightweight IDE.
As an aside note there's also LiteIDE which, at one point, was the "unofficial official" Go IDE - if you will. A de facto recommendation for anyone new to Go and fancying an IDE. I'm not sure if anyone still uses it for any serious Go development but that supported a few more features that the average Go-enabled text editors didn't at that time.
Why on Earth was this down voted?
There's a Go plugin for IntelliJ but I haven't used it in a while. There are plugins for vim and emacs too. Currently I use Sublime Text with a Go plugin. It has autocompletion and runs the formatter on save. I've built a couple of personal websites with Go.
http://thespanishsite.com and http://www.h4labs.com (on AppEngine)
I love the performance. They were in Python before. You'll notice the difference once you start to build things with lots of data like my little Swift "search engine":
http://www.h4labs.com/dev/ios/swift.html
http://thespanishsite.com and http://www.h4labs.com (on AppEngine)
I love the performance. They were in Python before. You'll notice the difference once you start to build things with lots of data like my little Swift "search engine":
http://www.h4labs.com/dev/ios/swift.html
[deleted]
You can have basically all the "official IDE" behavior you are listing with Vim or Emacs extensions (of the editors I know of).
If you are not going near a language for the lack of an "official IDE", you are really limiting your options.
If you are not going near a language for the lack of an "official IDE", you are really limiting your options.
Yes, but at that point, aren't they just text based IDEs?
Yes, that's my point.
Why would you need an official IDE, since many advanced text-editors can offer similar functionality ?
Why would you need an official IDE, since many advanced text-editors can offer similar functionality ?
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.
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.
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! :)
re spring class names, this is always fun http://java.metagno.me/
shows generally reasonable names, but still some gems like
"ComplexPortletApplicationContext.MyHandlerAdapter"
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.
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.
IntelliJ has a good vim plugin. It is the best of both worlds for me.
> 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
I've written a go-style concurrency library for C for people who share this sentiment: http://libmill.org
> 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.
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.
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.
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.
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/), 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.
There are some being worked on, like 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.
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.
I also pretty much debug crashes from just the traceback (in Python), but a debugger (pudb is awesome) has been invaluable in quickly figuring out what's breaking in third-party code. You don't have to read all of the code, just step through a bit until the crash and you're done.
Yes, a stack trace at a particular point is often the most helpful bit of debugging info.
I'm not sure if it would be nearly as helpful in Go to step through an chunk of unknown code that crashed, since python's execution is generally linear, whereas Go usually has a high degree of concurrency.
I'm not sure if it would be nearly as helpful in Go to step through an chunk of unknown code that crashed, since python's execution is generally linear, whereas Go usually has a high degree of concurrency.
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
Build tool and language are somewhat separate concepts.
[1] https://getgb.io
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.
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.
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.
Several of the "why Go is good" points aren't unique to Go.
> Key data structures built-in
Yet a decimal data type is missing.
Yet a decimal data type is missing.
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?)
It's not the definitive default number only because performance reasons and because of C influence in language design.
If most languages had Decimals, I am sure only C/C++/Java diehards would use ints/floats instead. In fact most modern scripted languages should have them.
Regarding go, as it is a relatively new language, and having to interact with databases, with Decimal being a fundamental SQL type, yes, it should have Decimal.
If most languages had Decimals, I am sure only C/C++/Java diehards would use ints/floats instead. In fact most modern scripted languages should have them.
Regarding go, as it is a relatively new language, and having to interact with databases, with Decimal being a fundamental SQL type, yes, it should have Decimal.
Floats are not for C/C++/Java diehards but for rather science, engineering, signal processing, financial modeling, computer graphics ...
> Why do you consider that a key data structure?
In real world applications, it is one of the more essential non-collection types.
In real world applications, it is one of the more essential non-collection types.
Some scientific and accounting software require it. Python has a decimal data type [1].
[1]: https://docs.python.org/3/library/decimal.html
[1]: https://docs.python.org/3/library/decimal.html
Sure. But that doesn't make it "key" in the sense that, say, lists and maps are.
> 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.
No, its more like "key" in the way that ints are.
Well, not quite -- less than ints, but more than floats.
Decimals have a limited application. They basically just pander to the need to have the machine conform to some hokey pencil-and-paper arithmetic rules remotely linked to the number of fingers on two hands.
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?)
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.
Exact rationals are in a similar situation.
"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...
Also, nothing says "use the standard way" like making the built-ins the only thing that's generic...
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.