
Go Is Not Good – A list of articles complaining that go isn't good enough - emersonrsantos
https://github.com/ksimka/go-is-not-good
======
camus2
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
Have you heard of Scala or F#?

------
lobster_johnson
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.

~~~
gbersac
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.

~~~
lobster_johnson
Scala is too overengineered for my taste — the combination of Java-style OO
with functional programming doesn't sit right. I like the functional part,
less the other stuff. I also want a slim, natively compiled language without a
VM.

~~~
StavrosK
So, Rust?

~~~
paulddraper
Rust has a ton of complexity so it can remove GC. It's a big leap, and
something Swift and Scala don't attempt.

Haskell would be a closer match.

~~~
StavrosK
Hmm, is it "a ton"? I've only written a few things in Rust, so I'm not overly
familiar with it, but, for the few things I wrote, it was straightforward to
at least reason about why something might not work (even though I may not know
how to actually make it work). I imagine that, in a few weeks, one can become
so familiar that the compiler won't have too many remarks about one's code.

------
CSDude
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
Just curious... If they had no prior programming experience, why was go
'different'? Different compared to what?

~~~
znpy
> 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.

------
jondubois
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
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
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.

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

------
fantastick
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.

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

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

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

------
jgalt212
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
> 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
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
Is this the new "JavaScript, The Good Parts" ?

