6 ms·

Go Is Not Good – A list of articles complaining that go isn't good enough

76 points by emersonrsantos 10y ago

tscs37 10y ago
I recommend adding a pile of salt as banner to symbolize the intention of the repository better.
- deleted 10y ago
  [deleted]
CSDude 10y ago
I taught Go to 3 fresh new computer engineers, where they had no real-life programming experience. It was different to them: channels, no traditional oop and no generics, but they picked it up very quickly, and with them we were able to produce a very large application. We tried to keep things as much as simple as possible, avoided coding magic as much as possible and using Go was a nice experience for us. Not saying this proves anything, it is just a real-life example from us. Most of the times people do not need all the interesting things you think you should have in a language, and may like their "opinoniated" way of approaching to problems.
- EpicEng 10y ago
  Just curious... If they had no prior programming experience, why was go 'different'? Different compared to what?
  - znpy 10y ago
    > Just curious... If they had no prior programming experience, why was go 'different'? Different compared to what? Probably compared to what they were shown in university/bootcamp/whatever. 'no programming experience' could esily mean 'no professional programming experience' which is very close to 'no programming experience'. I am enrolled in a computer engineering course, and I can tell you the amount of code we get to write is ridiculously low.
  - CSDude 10y ago
    They had only experience from university courses.
- johan_larson 10y ago
  A year and a bit into coding in Golang full time after many years in C++ and Java, I like the language too. Compared to both of those languages, it feels simple and clear, probably because it is fairly young and very opinionated. I can think of a few things I miss (single-line IFs, IMPLEMENTS clauses for structures, MAP/FILTER for collections, ...) but they are all fairly minor things.
jondubois 10y ago
I agree with the complaints about project structure (GOPATH), difficulty importing third-party modules/packages, upper-case/lower-case public/private scoping not ideal... But I think it's a very good, flexible language on the whole and I think its approach to OOP and pointers is really good (even though it's different from most other OO languages). Unlike some of the comments, I think it's actually not too verbose considering the flexibility it offers (it's much less verbose than C++). That said, for building web applications, I still prefer Node.js.
- ovao 10y ago
  I'm curious: what is it you don't like about importing packages in Go? With go get and goimports editor integration, I find third-party package integration pretty easy. If it's a question of versioning or package.json-style dependency management, I agree that Go still has some significant pain points that haven't been fully addressed directly.
  - parenthephobia 10y ago
    Not the GP, but I note it's difficult to, say, take some code which uses package xyz and substitute the source-compatible package abc without editing every file. e.g. Try compiling a large project with a custom version of 'os' swapped in. (e.g. To add tracing, or simulate random I/O failures.) Some package management systems can decouple what packages are called inside the code from what they're called outside.
camus2 10y ago
Go is good, it's just that its designers went half way through the design of the language and said "fuck it, we're done". They came up with implicit interfaces, they didn't make them covariant, and they barely used them in the std lib itself. They came up with multiple return values, they didn't think it would have been more useful for the programmer to get tuples and destructuring in practice. They came up with struct tags, they didn't think fully typed annotations would have been more useful. And then they exposed all the language internals in the reflect package,to make up for Go shortcomings with serializing,deserializing data, which made refactoring go internals in a backward compatible way an impossible task. The worst idea is go generate. It shouldn't even be here. Littering source code with pragmas and forcing people to write 3rd party executable and maintain manifests isn't simple,readable,maintainable or elegant. Macros with reification would have been a bit more honest. Go relies way too much on runtime behavior for a statically typed compiled language, This is absolutely undeniable. The irony is that Rust, with garbage collection instead the borrow checker, would have been a better implementation of Go than Go itself. But it seems we'll never get that language.
- swagpapi420 10y ago
  Have you heard of Scala or F#?
tomcam 10y ago
News you can use: one of the complaints is "weird mascot"
- prodigal_erik 10y ago
  That wouldn't go on my list, no. One wonders whether hammers and drills would have mascots if they were invented today.
deleted 10y ago
[deleted]
lobster_johnson 10y ago
After a couple of years with Go, I'm neither particularly happy about, not particularly unhappy. It's a decent language. Productivity is high, which trumps many other concerns. There has been so much controversy about generics, but one related area where Go is consistently annoying is when you want to define a sort of language of data types -- where in a different language such as Haskell would define algebraic data types. For example, an AST of syntax nodes: There's no way define this (simplified): data Node = Literal | Identifier | And | Or | Not | EQ | NEQ | ... Instead, you must define a bunch of structs and use a dummy interface that all nodes implement. Even then, Go has no pattern matching, so if you want to handle a node, you need a switch statement on type, then check the data with an if. And even then, there's no way to prove at compile time that the switch statement is exhaustive (you could do some runtime magic with reflection-based lookup tables, but it's still poor). If you want a generic mechanism to traverse and rewrite such deeply nested data structures, there's a lot of exhausting boilerplate in the way of the core logic, because, ahem, no generics. I'm in the middle of a project that has three sets of such data structures (a low level AST, a high level expression grammar, and a query plan graph), and it's an area where the Go development experience turns from pretty good to pretty dismal. I've considered writing a mini-DSL and using "go generate" to generate Go code, but I've not yet decided on the best design.
- jghn 10y ago
  Anecdata, but my experience has been that people who really enjoy Go either don't care about or don't want at all the kinds of language features you are describing. As with many language trade offs, at the end of the day people tend to gravitate towards languages that fit their own personal preferences
- gbersac 10y ago
  Maybe a language like scala should fit your needs better ? I am using it since 8 months and give me all those abstractions you speak about and its elegant synthax allow me to be very productive. I don't know if I am as productive as I would have been using go, but I am certainly more productive than using Java. But this not a language as easy to pick up as go (even though I didn't have much problem to pick it up right out of school). I also think it is much more difficult to write reliable software in go than it is in scala. The much stronger type system (generics, algebraic data type) help me to check the correctness of my program at compile time.
anonnyj 10y ago
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
fantastick 10y ago
Such a discussion makes no sense. You will see plenty of web pages where people bashing at Go, like they are bashing at Scala, Java, Ruby, C++, and all the other languages. I'm using the computer for over 30 years, writing in different languages, and I'm happy with Go, even it has his shortcomings here and there. If I have to write some loop which talks a certain protocol over a network (servers) Go is my first choice. The Internet is a funny thing, You will find a bunch of arguments that eggs are healthy and that they are not. Similar with programming languages.
jgalt212 10y ago
Here's my two cents after following Go and other programming languages for quite some time: Coders looking for a better C are generally happy. Coders looking for a better Java or C# are in general not happy. I don't think its worthwhile to compare Go to dynamic languages.
- prodigal_erik 10y ago
  > I don't think its worthwhile to compare Go to dynamic languages. I do think we should be making this comparison, because there's a trend in devops of moving from Python and Ruby (each of which have system-provided dependencies) to Go (which statically links a copy of everything). I see this as unfortunate because devops should be promoting taking full advantage of the system's well-understood and -tested libraries and services rather than avoiding them with approaches like container isolation. If you have a reason to avoid your distro's python, fix that.
  - jgalt212 10y ago
    You raise a good point. Perhaps I should have said it's a much greater challenge to compare Go to dynamic languages as there are too many moving parts. However, when you constrain the comparison to a specific domain, then the problem is more tractable. I don't have a ton of dev ops experience, so I won't weigh in on this matter. That being said, despite how far Python/pip has come there are still great challenges when installing certain packages. For this reason, I do see the value in statically linked copies of everything--even if it seems like overkill. Disk space is cheap, but does make remote installs take longer.
bsg75 10y ago
Is this the new "JavaScript, The Good Parts" ?

I recommend adding a pile of salt as banner to symbolize the intention of the repository better.

deleted 10y ago
[deleted]

I taught Go to 3 fresh new computer engineers, where they had no real-life programming experience. It was different to them: channels, no traditional oop and no generics, but they picked it up very quickly, and with them we were able to produce a very large application. We tried to keep things as much as simple as possible, avoided coding magic as much as possible and using Go was a nice experience for us. Not saying this proves anything, it is just a real-life example from us. Most of the times people do not need all the interesting things you think you should have in a language, and may like their "opinoniated" way of approaching to problems.

EpicEng 10y ago
Just curious... If they had no prior programming experience, why was go 'different'? Different compared to what?
- znpy 10y ago
  > Just curious... If they had no prior programming experience, why was go 'different'? Different compared to what? Probably compared to what they were shown in university/bootcamp/whatever. 'no programming experience' could esily mean 'no professional programming experience' which is very close to 'no programming experience'. I am enrolled in a computer engineering course, and I can tell you the amount of code we get to write is ridiculously low.
- CSDude 10y ago
  They had only experience from university courses.
johan_larson 10y ago
A year and a bit into coding in Golang full time after many years in C++ and Java, I like the language too. Compared to both of those languages, it feels simple and clear, probably because it is fairly young and very opinionated. I can think of a few things I miss (single-line IFs, IMPLEMENTS clauses for structures, MAP/FILTER for collections, ...) but they are all fairly minor things.

jondubois 10y ago

I agree with the complaints about project structure (GOPATH), difficulty importing third-party modules/packages, upper-case/lower-case public/private scoping not ideal... But I think it's a very good, flexible language on the whole and I think its approach to OOP and pointers is really good (even though it's different from most other OO languages). Unlike some of the comments, I think it's actually not too verbose considering the flexibility it offers (it's much less verbose than C++). That said, for building web applications, I still prefer Node.js.

ovao 10y ago
I'm curious: what is it you don't like about importing packages in Go? With go get and goimports editor integration, I find third-party package integration pretty easy. If it's a question of versioning or package.json-style dependency management, I agree that Go still has some significant pain points that haven't been fully addressed directly.
- parenthephobia 10y ago
  Not the GP, but I note it's difficult to, say, take some code which uses package xyz and substitute the source-compatible package abc without editing every file. e.g. Try compiling a large project with a custom version of 'os' swapped in. (e.g. To add tracing, or simulate random I/O failures.) Some package management systems can decouple what packages are called inside the code from what they're called outside.

camus2 10y ago

Go is good, it's just that its designers went half way through the design of the language and said "fuck it, we're done". They came up with implicit interfaces, they didn't make them covariant, and they barely used them in the std lib itself. They came up with multiple return values, they didn't think it would have been more useful for the programmer to get tuples and destructuring in practice. They came up with struct tags, they didn't think fully typed annotations would have been more useful. And then they exposed all the language internals in the reflect package,to make up for Go shortcomings with serializing,deserializing data, which made refactoring go internals in a backward compatible way an impossible task. The worst idea is go generate. It shouldn't even be here. Littering source code with pragmas and forcing people to write 3rd party executable and maintain manifests isn't simple,readable,maintainable or elegant. Macros with reification would have been a bit more honest. Go relies way too much on runtime behavior for a statically typed compiled language, This is absolutely undeniable. The irony is that Rust, with garbage collection instead the borrow checker, would have been a better implementation of Go than Go itself. But it seems we'll never get that language.

swagpapi420 10y ago
Have you heard of Scala or F#?

tomcam 10y ago

News you can use: one of the complaints is "weird mascot"

prodigal_erik 10y ago
That wouldn't go on my list, no. One wonders whether hammers and drills would have mascots if they were invented today.

deleted 10y ago

[deleted]

lobster_johnson 10y ago

After a couple of years with Go, I'm neither particularly happy about, not particularly unhappy. It's a decent language. Productivity is high, which trumps many other concerns. There has been so much controversy about generics, but one related area where Go is consistently annoying is when you want to define a sort of language of data types -- where in a different language such as Haskell would define algebraic data types. For example, an AST of syntax nodes: There's no way define this (simplified): data Node = Literal | Identifier | And | Or | Not | EQ | NEQ | ... Instead, you must define a bunch of structs and use a dummy interface that all nodes implement. Even then, Go has no pattern matching, so if you want to handle a node, you need a switch statement on type, then check the data with an if. And even then, there's no way to prove at compile time that the switch statement is exhaustive (you could do some runtime magic with reflection-based lookup tables, but it's still poor). If you want a generic mechanism to traverse and rewrite such deeply nested data structures, there's a lot of exhausting boilerplate in the way of the core logic, because, ahem, no generics. I'm in the middle of a project that has three sets of such data structures (a low level AST, a high level expression grammar, and a query plan graph), and it's an area where the Go development experience turns from pretty good to pretty dismal. I've considered writing a mini-DSL and using "go generate" to generate Go code, but I've not yet decided on the best design.

jghn 10y ago
Anecdata, but my experience has been that people who really enjoy Go either don't care about or don't want at all the kinds of language features you are describing. As with many language trade offs, at the end of the day people tend to gravitate towards languages that fit their own personal preferences
gbersac 10y ago
Maybe a language like scala should fit your needs better ? I am using it since 8 months and give me all those abstractions you speak about and its elegant synthax allow me to be very productive. I don't know if I am as productive as I would have been using go, but I am certainly more productive than using Java. But this not a language as easy to pick up as go (even though I didn't have much problem to pick it up right out of school). I also think it is much more difficult to write reliable software in go than it is in scala. The much stronger type system (generics, algebraic data type) help me to check the correctness of my program at compile time.

anonnyj 10y ago

There are only two kinds of languages: the ones people complain about and the ones nobody uses.

fantastick 10y ago

Such a discussion makes no sense. You will see plenty of web pages where people bashing at Go, like they are bashing at Scala, Java, Ruby, C++, and all the other languages. I'm using the computer for over 30 years, writing in different languages, and I'm happy with Go, even it has his shortcomings here and there. If I have to write some loop which talks a certain protocol over a network (servers) Go is my first choice. The Internet is a funny thing, You will find a bunch of arguments that eggs are healthy and that they are not. Similar with programming languages.

jgalt212 10y ago

Here's my two cents after following Go and other programming languages for quite some time: Coders looking for a better C are generally happy. Coders looking for a better Java or C# are in general not happy. I don't think its worthwhile to compare Go to dynamic languages.

prodigal_erik 10y ago
> I don't think its worthwhile to compare Go to dynamic languages. I do think we should be making this comparison, because there's a trend in devops of moving from Python and Ruby (each of which have system-provided dependencies) to Go (which statically links a copy of everything). I see this as unfortunate because devops should be promoting taking full advantage of the system's well-understood and -tested libraries and services rather than avoiding them with approaches like container isolation. If you have a reason to avoid your distro's python, fix that.
- jgalt212 10y ago
  You raise a good point. Perhaps I should have said it's a much greater challenge to compare Go to dynamic languages as there are too many moving parts. However, when you constrain the comparison to a specific domain, then the problem is more tractable. I don't have a ton of dev ops experience, so I won't weigh in on this matter. That being said, despite how far Python/pip has come there are still great challenges when installing certain packages. For this reason, I do see the value in statically linked copies of everything--even if it seems like overkill. Disk space is cheap, but does make remote installs take longer.

bsg75 10y ago

Is this the new "JavaScript, The Good Parts" ?