
I Love Go; I Hate Go - tominous
http://dtrace.org/blogs/ahl/2016/08/02/i-love-go-i-hate-go/
======
twblalock
The most frustrating thing for me, by far, is that Go won't let you import
unused packages. When you are commenting stuff out to debug a program, or
adding debug statements and removing them later, it constantly requires you to
go back to the top of the file and comment out the unused libraries, only to
uncomment them later when you've solved your problem.

The fact that there is not a compiler flag to disable this behavior, and that
the core team is opposed to adding such a flag
([https://golang.org/doc/faq#unused_variables_and_imports](https://golang.org/doc/faq#unused_variables_and_imports)),
is simply ridiculous and makes programming in Go a real pain in the ass.

I can't think of any other language that does this.

~~~
tptacek
I used to feel this way. It was my top complaint about the language. But it,
and, more importantly, the use requirement for variables, has saved me from
bugs repeatedly; I more and more notice the bugs it's protecting me from as I
keep coding in the language. I am rapidly coming to the conclusion that this
was very, very much the right call.

I get the sense that most Go programmers use "goimports" to work around the
annoyance. I have my Emacs configured to use it automatically. I never even
think about imports anymore.

~~~
buro9
> I get the sense that most Go programmers use "goimports" to work around the
> annoyance. I have my Emacs configured to use it automatically. I never even
> think about imports anymore.

You haven't yet encountered clashing names?

[https://golang.org/pkg/crypto/rand/](https://golang.org/pkg/crypto/rand/)

[https://golang.org/pkg/math/rand/](https://golang.org/pkg/math/rand/)

Or?

[https://golang.org/pkg/text/template/](https://golang.org/pkg/text/template/)

[https://golang.org/pkg/html/template/](https://golang.org/pkg/html/template/)

goimports is wonderful, but some care is needed to make sure it has added the
one you intended to add.

NB: Only an issue when new imports are added, not an issue if the correct
package is already referenced.

~~~
donatj
I have been using it since I switched to VSCode about 4 months ago and thus
far, knock on wood, it's always found the one I intend. I however do think it
considers what public members/methods you are calling.

~~~
buro9
"considers"?

It just finds a match and goes with it, and that does cause issue. Both of the
above have potential security implications.

Filippo suggests preferring crypto/rand over math/rand as a softfix in this
twitter conversation:
[https://twitter.com/filosottile/status/752210041709719552](https://twitter.com/filosottile/status/752210041709719552)

I'd probably prefer html/template over text/template as it's better to have
someone ask why their output was HTML escaped than to have someone render HTML
in plain text without explicitly wanting to do so.

------
dpc_pw
Oh. Go love-hate relationship post. My turn. So I really like channels and
coroutines built into language and used everywhere: it makes some patterns
compose nicely and language very productive.

But just as in the article - some of Golang choices are opinionated and IMO
just stupid. Lack of assertions is one: Sure programmers are prone to ignoring
errors, but Go is not helping at all. Just bans assertions and provides no
improvements. No `try!`&`Result` like Rust, not even warning by default if you
ignored returned error (IIRC, go lint or go vet checks it) . So what's the
point?

How do you decrement an atomic in Go?

AddUint32(&x, ^uint32(c-1))

That's how. Easy to read, and self-explaining.
[https://golang.org/pkg/sync/atomic/](https://golang.org/pkg/sync/atomic/) . I
mean... come on.

Unused errors being an error is super annoying, and changing variable
capitalization everywhere, because you want to change symbol visibility is
another daily frustration source.

Oh, and all my contacts with the community were very unpleasant (maybe it's
just me, or bad luck). Any questions ended with some form of "you must do it
one true way, otherwise you're stupid". Eg. once I was looking for a way to
terminate unit test in case of error, instead of writing `if err != nil {
t.Errorf(...) }` over and over again after every line, as in test, every error
is just terminating condition. In Rust I would just `.unwrap()` or
`.expect()`, which would fail the test, report backtrace, etc if anything
unexpected went wrong. All the help that I got was just snarky comments for
being lazy.

I will continue to use Go in some projects, as it gets the job done,
performance is OK, has some userbase, and ecosystem is quite vital, but
overall, it seems to me that it's rooted in same form of stubborn crudeness
that has no good reason in XXI century, ignoring years of research and good
ideas. For anything more demanding, or fun I would always go with Rust.

~~~
superswordfish
> ignoring years of research and good ideas

And people are falling over themselves to use Go in places that seem
inappropriate. Most of Go's strengths shine in a large team of mediocre
developers: Low build times, low abstraction, quick ramp-up, etc. So why do
startups choose Go? You're just shooting yourself in the foot. Use OCaml, use
C++, use Clojure, hell, use Swift or Rust, just use something that at least
pretends to care about expressiveness and abstraction. I actively avoid
working for shops that use Go heavily, it's an indicator of cargo-culting.

~~~
themihai
You don't know what you are talking about. Have you seen any Swift backend
used in production? Would you use C++ for a web API? Go was developed because
C++ is a horibble language and I'm glad it didn't adopt the expressiveness and
abstraction from C++.

~~~
coldtea
> _You don 't know what you are talking about. Have you seen any Swift backend
> used in production?_

He said "hell, use Swift" \-- which didn't imply that he's considering it the
first or best recourse.

That said:

1) There's far more Swift in production (on iOS devices as native apps, not as
backend, but still production code) than Go.

2) Merely 4-5 years ago nobody had seen Go in backend (web/server) production
either. Or at least very few.

3) There's already some support for server side Swift:
[http://perfect.org/](http://perfect.org/)

4) And more: IBM uses Swift for apps AND server side, and has open sourced a
Swift web framework/server: [https://github.com/ibm-
swift/kitura](https://github.com/ibm-swift/kitura)

> _Would you use C++ for a web API?_

If I needed the crude speed yes, and in fact lots of web APIs delegate to C++
behind the scenes (e.g. for task queues), whereas some are in C++ directly.

In fact Facebook itself used to transpile PHP to C++ and run that (through
their HipHop project).

> _Go was developed because C++ is a horrible language_

Go was developed because some old C/UNIX hackers didn't much like C++/Java and
wanted to do their own thing, bringing some Plan 9 flavor on.

C++, warts and all, has proven itself time and again.

Most of the things we depend on and use, from the browser you're using, to
JITS and compilers (LLVM for one, V8), to the Windows OS, nearly all major GUI
programs (all major DAWs, NLEs, Photoshop, 3D programs, KDEetc), to 99% of AAA
games, to Google's search engine core are written in C++.

And C++11/C++14 standards have made it a much better, even new, language. The
automatic C++ dislike is cargo cult from people who usually don't use it and
just repeat old wives tales.

~~~
themihai
>He said "hell, use Swift" \-- which didn't imply that he's considering it the
first or best recourse.

I've got that but it was too late... the comment was already posted. I've up-
voted his response.

The rest of your points are invalid. Development is not only about a http
server(which I'm sure is subpar compared with Go). You will burry your time
and energy in making basic things work. As developer that's great because you
can use your experience on your "next" project but as a start-up you are very
likely to fail. There may be some IBM developers that played around with the
language but I'm sure IBM has no swift powered service in production. Swift is
still a language in flux with many changes pending in the next 2 -3 versions.
Big corporations don't really like to invest in unstable environments. Maybe
in 3-4 years from now Swift will be able to compete with Go but today there is
really no reason to use Swift over Go for a backend service.

> Go was developed because some old C/UNIX hackers didn't much like C++/Java
> and wanted to do their own thing

I must say it again: C++ is a horrible language. It may perform well and it
may be widely spread but that doesn't change much as far as its design is
concerned. C++ competes mostly on its reach not on its merits. Hopefully that
will change as new platforms emerge(i.e Rust).

> In fact Facebook itself used to transpile PHP to C++ and run that (through
> their HipHop project).

Yeah, that's a pretty picture for what C++ is really good for. I rest my case.

Edit: I would also say "experienced hackers" instead of "old hackers". The C++
or Swift hackers are not younger anyway.

~~~
coldtea
> _The rest of your points are invalid. Development is not only about a http
> server(which I 'm sure is subpar compared with Go). You will burry your time
> and energy in making basic things work._

The same could be said, and was said for Go compared to Java C#, etc just a
few years ago. And it probably can still be said, as older languages have much
more stable, richer ecosystems, support, tooling, and use bases.

> _I must say it again: C++ is a horrible language. It may perform well and it
> may be widely spread but that doesn 't change much as far as its design is
> concerned. C++ competes mostly on its reach not on its merits. Hopefully
> that will change as new platforms emerge(i.e Rust)._

Well, it gets a lot of things right. Compatibility with C. Great performance.
Enough abstractions to be usable. Enough batteries built-in compared to C.
Great ecosystem and tooling, first class vendor support, etc. A language is
not just its syntax -- not even just its semantics.

~~~
themihai
>>The same could be said, and was said for Go compared to Java C#, etc just a
few years ago. And it probably can still be said, as older languages have much
more stable, richer ecosystems, support, tooling, and use bases.

I don't say that you should never use C++. Sometimes it's a necessary evil but
that doesn't make it a great/pleasant choice(at least for me).

>> Great ecosystem and tooling

I think it could be considered GREAT 20 years ago but now it is miserable
compared with the new languages. For example it has no kind of distribution
model(i.e package manager). Cross platform compiling is no fun... C++ parsing
is no fun either so you could say that its syntax is quite important if you
were to develop new tools.

------
EugeneOZ
> Contrast this with Rust whose errors read like mind-bindingly inscrutable
> tax forms.

It was "lol what?" for me. Rust's compiler error messages are very informative
and sometimes contains tips what to change in your code to make it work (not
just general words, but code you can use right now, with your
variables/functions etc.).

Borrow checker explains step-by-step where ownership starts, where it ends and
where you are trying to use it.

Panicking messages - another story, but it's not compiler's error messages,
it's runtime. In example of code Adam using as proof, author is using 'panic'
and 'unwrap' \- reasons to don't expect gentle behavior.

If you can't write code in idiomatic way, try to catch your panics and give
more descriptive runtime error message in your code - other users of language
shouldn't pay for it.

~~~
valarauca1
This was where I stopped reading. The author clearly hasn't worked with Rust.
Not only are the messages very descriptive, but you have an extended
explaination for each error in the form of:

    
    
        rustc --explain EXXX
    

Which pulls up a long form explaination, and code samples of what is
happening/why it is happening/how to fix it.

The blog explaining the author's disdain for Rust mostly just seems to whining
about the borrow checker.

~~~
masklinn
> The author clearly hasn't worked with Rust.

The author links to a previous post on the subject, from mid-2015, so they
clearly have at least tried Rust in the past.

And while many Rust messages are OK, one should be careful not to confuse
_familiarity_ with Rust's error messages[0] with Rust's error messages being
_good_ (being inherently informative and good).

Here's a clearer example (fixed since): [http://dbeck.github.io/My-First-
Steps-In-Rust/](http://dbeck.github.io/My-First-Steps-In-Rust/) note two
issues:

* the error message is _busy as all hell_ which is a common issue in Rust, before you've built the habit and learned how they're structured Rust error messages often look daunting. By comparison Elm makes much more extensive use of spacing and tries to avoid repeating the same information (e.g. file names) over and over.

* the suggestion it provides is just plain wrong, it suggests implementing Debug for T, but T is always a standard number which already implement Debug, what's missing is a trait bound. To a beginner that was _not_ a helpful suggestion as it would only send them on a wild goose chase (of trying to implement Debug on either T or i32/f32, and good luck with those).

> The blog explaining the author's disdain for Rust mostly just seems to
> whining about the borrow checker.

So? Just like monads in haskell, the borrow checker is _hard_ until it
"clicks" (and then it fundamentally shifts your understanding and it becomes
hard to understand _not_ getting it).

[0] and experience/understanding for the various possible sources of the most
common ones, but that you can build for any compiler, even G++'s pages of
template expansion garbage from the early aughts

~~~
EugeneOZ
So are you talking about error messages or about complexity of borrow-checker?
Because I can agree about borrow-checker, but not about error messages
(although there is a lot of noise, yes).

~~~
masklinn
> So are you talking about error messages or about complexity of borrow-
> checker?

Er… both? In separate sections of the comment?

> Because I can [not agree] about error messages

I've provided a clear example of an issue, are you denying objective reality
or are you asserting that providing incorrect suggestions leading beginners in
entirely the wrong direction is fine?

~~~
EugeneOZ
So you are trying to add some negative moment about borrow-checker, when my
comment is not about borrow-checker, but you need something negative. Cheap
trick.

~~~
masklinn
> So you are trying to add some negative moment about borrow-checker, when my
> comment is not about borrow-checker, but you need something negative. Cheap
> trick.

Now what the hell are you talking about?

I didn't reply to your comment I replied to valarauca1, they're the one who
mentioned the borrow checker, if you're unhappy about that whine to them don't
include me in your pity party.

~~~
EugeneOZ
Are you drunk? You are responding to the branch my comment started, comment
was about error messages and your response contain words:

"And while many Rust messages are OK, one should be careful not to confuse
familiarity with Rust's error messages[0] with Rust's error messages being
good (being inherently informative and good)."

So you will still try to pretend we are not talking about error messages here?

~~~
masklinn
> Are you drunk?

I'd appreciate you not insulting me, as well as you starting to make sense.

> You are responding to the branch my comment started

I was not, however, replying to your comment. As I already told you I was
replying to valarauca1's comment, which is why my own comment was threaded
below and in reply to it, and quoted it.

> So you will still try to pretend we are not talking about error messages
> here?

I'll repeat my previous query in a new context and with slightly more alarm:
what the hell are you talking about?

I never "tried to pretend"[0] we were not talking about error messages, my
answer[1] to your original query[2] specifically noted the opposite.

[0] and would again appreciate not being insulted

[1]
[https://news.ycombinator.com/item?id=12209010](https://news.ycombinator.com/item?id=12209010)

[2]
[https://news.ycombinator.com/item?id=12208873](https://news.ycombinator.com/item?id=12208873)

~~~
EugeneOZ
My question is not more offensive than your "what the hell you are talking
about". I regret I don't have "ignore" button for talks like this.

------
_ph_
I like Go quite a lot. Mainly I am a Lisp programmer, so I am not looking for
the next most high level programming language. I am looking for a language
which gets things done, where Lisp doesn't quite fit. For jobs, which
traditionally would have been done in C. Programs that run fast and have a
reasonable complexity. It brings back the virtues of the Wirth computer
language family back into modern times, as with strict type checking and the
module system. On top of that it adds memory safetey due to the presence of
GC.

Go it easy to learn, as its a moderately sized language, but it has just
enough abstractions, that your programs are not held back by the lack of
those, without opening the traps too "powerful" languages bring with
themselves, namely complexety.

On top of all, the whole infrastructure is very well thought out and a
pleasure to use. A very fast compiler which produces static executables, a
good module system without header files, a rich standard library, many things.
There are quite a few quirks, especially for the beginner, but the more I gain
insight, the more I agree with the choices made - with some I don't, but the
agree to disagree ratio is surprisingly high. And most of them don't get into
the way of writing good programs, which is what counts.

~~~
devishard
This post is yet another reinforcement of my assertion that the people who
like Go only like it because they have no idea what has happened in
programming languages for the last few decades. Case in point:

> It brings back the virtues of the Wirth computer language family back into
> modern times, as with strict type checking and the module system.

Strict type checking? Have you used _any other languages besides C_? Go's type
system is a joke.

Like literally, it's a joke. If you get a bunch of people who know about types
languages in a room discussing types, "What about Go?" is guaranteed to get a
laugh.

~~~
jsmith0295
Maybe if by "people who know about types languages" you mean "Haskell snobs"

~~~
spion
But also ML, Scala, C++, C#, Java, TypeScript, Hack, Dart, Swift, Objective C
(as of late), Visual Basic... and COBOL snobs.

~~~
jsmith0295
I was referring more to the "joke" part of this. Just because a type system
offers slightly more safety doesn't make it better. I'm primarily a Java
developer, and I would prefer Go's type system over Java's the vast majority
of the time. It does a much better job at staying out of the way.

~~~
spion
That may be true, but the joke part comes when you actually want to develop
new abstractions that are type-safe.

For example you cant write a thread-safe map container in Go without
sacrificing type safety (i.e. one that would not crash the program when there
are concurrent writes to the map).

The standard library doesn't offer one either.

This means you end up copy pasting the lock related code for every map you
want to make thread safe. You have to remember to declare and initialise its
lock, to use that lock every time you access it, and to remember to unlock it.

Now for some things, this cost isn't too bad. For others, it makes the
language a joke.

As a result, Go is a toy, or at least, a non-general-purpose language. If the
problem you're solving fits its limited set of built-in abstractions, its
great. Otherwise, its a disaster.

In my experience, well written programs evolve over time to gain new carefully
chosen abstractions that cleanly implement shared underlying concepts of the
problem domain. These abstractions often require the use of generics.

When this happens in a Go project, however, you're out of luck. Even worse,
developing primarily in Go means distorting your thinking to fit its limits.

This is more or less true in any language, and its not a binary thing.
Languages are all over the place on the ladder of abstraction (with lisps
being close to the top, Go near the bottom).

p.s. Java also suffers because it added generics too late: by the time they
were added there was already a clear picture painted of "idiomatic Java". To
make matters worse lambdas were also added way too late, and the verbosity of
type declarations is still staggeringly high. However, modern Java is a much
better language than Go.

------
cespare
GOEXPERIMENT=framepointer will be the default in 1.7, due out in a few days
(see [https://golang.org/issue/15840](https://golang.org/issue/15840)), so
using tools like perf (and presumably dtrace) will be somewhat improved out of
the box.

Edit: and the author mentions that at the end of the post. That's what I get
for commenting before I've read the whole thing.

------
dcw303
I'm a little confused by the author's belief Go needs to be more pragmatic.
All the points made in the "I Love Go" section (gofmt, the toolchain,
interfaces) display strong qualities of pragmatism to me. The article
literally describe interfaces as 'no-nonsense and pragmatic'. And, even if
they do not personally like the opinionated nature, it is a prime example of
solving questions in a practical way.

No language can be everything to everyone. One thing that encourages me to
keep writing Go is the team has done a very good job at communicating their
intentions for the language.

It's very clear to me when to write Go and when not to. That's a sign of
strength to me, as it shows the language has the confidence to tell you
"perhaps I'm not the best choice for this particular problem".

~~~
tuxt
>It's very clear to me when to write Go and when not to.

Would you care to elaborate on this? :)

~~~
dcw303
My main two use cases so far have been services and command line tools where
it's not worth taking the effort to manage memory. The former I would have
previously written in Java or C# (yeah, tie me to the cross right now language
hipsters, I don't care, I already said I'm a pragmatist), and the latter in
Ruby or Python.

I actually enjoyed going from dynamic to static typing for command line tools,
the compiler saves me a lot of time tracking down bone-headed errors, which
are typos in variables 95% of the time.

------
fauigerzigerk
My favorite little annoyance with Go is the way the := operator behaves with
multiple assignment. It declares a new variable if there is no variable of
that name in the current scope. But it refuses to do that if there are struct
fields involved.

    
    
      var t int
      t, err := someFunc() // that's fine
    

but this doesn't compile:

    
    
      var s struct{ x int }
      s.x, err := someFunc() // doesn't compile

~~~
garfij
I've run into that as well, but I've since come to favor avoiding that pattern
entirely as a code smell.

In your example, you end up modifying the struct value x, even if there was an
error. Maybe there are cases where that is the correct behavior, but even then
I would advocate for explicitly setting the struct value after handling the
error, to make it very clear that it was your intention to do so, rather than
doing it be accident.

------
crench
_Weak opinions are what turn languages into unreadable mishmashes of
overlapping mechanism._

Go's opinions were, for me, especially helpful while learning the language.

------
fuzzy2
I don't know, I found debugging with IntelliJ's Go plugin intuitive and well-
working. Pretty sure it uses Delve under the hood.

I think strong opinions are helping Go not being "yet another language". So
that's good. Like most things, it isn't for everyone.

------
jokoon
I have great hopes for D since Andrei Alexandrescu joined to work on it.

When you see all those new system languages, (go, rust, swift), D was there
before them, and did not pretend to be a new cool thing with good ideas, it
just tries to be a nicer C++ to work with.

I don't need to do things the right way, I just need a language that is usable
and doesn't try to do the job for me.

------
jefozabuss
Cached version in case of 503:
[http://webcache.googleusercontent.com/search?q=cache:VcehlYQ...](http://webcache.googleusercontent.com/search?q=cache:VcehlYQXduwJ:dtrace.org/blogs/ahl/2016/08/02/i-love-
go-i-hate-go/+&cd=1&hl=en&ct=clnk&gl=de)

~~~
iso-8859-1
archive.is: [https://archive.is/BdvtP](https://archive.is/BdvtP)

------
kalekold
My take on Go: [http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-
in...](http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-
programmers/)

I still use it but I also have a love, hate relationship with it.

------
andrewfromx
Here's a way to love go, write a language in it
[https://github.com/grubby/grubby](https://github.com/grubby/grubby)

~~~
the_duke
whatevs...

~~~
pjmlp
Yeah what were/are Xerox PARC, ETHZ, Microsoft, Apple, Google thinking in
their language departments!

~~~
millstone
What interpreters did these orgs write in GCed languages?

~~~
pjmlp
A few examples from Oracle/Sun using the Graal VM engine, written in Java:

[https://github.com/graalvm](https://github.com/graalvm)

From Microsoft:

[http://ironpython.net/](http://ironpython.net/)

[http://ironruby.net/](http://ironruby.net/)

[https://msdn.microsoft.com/en-
us/library/dd233052%28v=vs.110...](https://msdn.microsoft.com/en-
us/library/dd233052%28v=vs.110%29.aspx)

[https://msdn.microsoft.com/powershell](https://msdn.microsoft.com/powershell)

Xerox PARC used Cedar for the software implemented on Xerox 1132 (Dorado) and
Xerox 1108 (Dandelion) systems, including interpreters delivered on the
system:

[http://dl.acm.org/citation.cfm?id=17919.806844](http://dl.acm.org/citation.cfm?id=17919.806844)

~~~
millstone
These are just experiments on the margins. In each case, the flagship
languages are not implemented on top of GC'd runtimes or interpreters. Apple's
Objective-C and Swift runtimes are both C++. Microsoft's C# CoreCLR is C++.
Google's V8 and Dart have runtimes written in C++. Oracle's HotSpot is C++.
Go's core runtime is in a Go-minus-GC subset.

It didn't have to be this way - Swift could have been written atop the JVM, v8
could have been implemented via Boehm, etc. For whatever reason, when it
counts, the stuff under the hood doesn't use garbage collection.

~~~
pjmlp
The question was "What interpreters did these orgs write in GCed languages?".

It doesn't matter where those interpreters are being used, the fact is that
they exist.

> Microsoft's C# CoreCLR is C++.

Yes, but they have moved their compilers to C# with the Rosylin project with
MDIL and .NET Native moving more code to C# side.

Also check the Phoenix compiler framework, a LLVM like project from MSR using
C#.

> Go's core runtime is in a Go-minus-GC subset.

Of course, there needs to exist a Genesis for the GC, but once it is there,
99% of the remaining infrastructure makes use of it.

If you take Nashorn engine running on Jikes, it is an 100% Java stack running
a JavaScript interpreter.

> For whatever reason, when it counts, the stuff under the hood doesn't use
> garbage collection.

Most of the time it is just building on top of whatever already exists instead
of starting from scratch.

Taking Swift as an example bootstraping the language would increase the burden
designing it, as they are still far from fully stable design.

If they would throw away in man years invested into the LLVM, which happens to
be written in C++, it would take ages before pure Swift compilers would ever
manage to catch up.

However these shortcuts open the door for those not savvy in compiler design
to use as ammunition against secure languages.

~~~
millstone
> Yes, but they have moved their compilers to C#

A compiler is a different matter. GCed languages are very compelling for
static compilers. Even gcc uses GC internally.

The claim is that GCed languages make for poor interpreters - and also poor
JIT compilers and runtimes.

> If you take Nashorn engine running on Jikes, it is an 100% Java stack
> running a JavaScript interpreter

Nashorn gets participation points, but it's not competitive with any of the
major JS engines, all of which have C++ runtimes.

> Taking Swift as an example bootstraping the language would increase the
> burden designing it, as they are still far from fully stable design. If they
> would throw away in man years invested into the LLVM, which happens to be
> written in C++,

This still confuses the compiler with the runtime. The Swift compiler is
indeed written in C++ using LLVM, but it could have easily been written in a
GCed language without affecting much of anything.

But the runtime is separate, and it also happens to be written in C++. It's
possible to imagine the Swift runtime written in a GCed language, but that is
not what Apple chose to do.

~~~
pjmlp
> The claim is that GCed languages make for poor interpreters - and also poor
> JIT compilers and runtimes.

Have you ever spent time with Graal, Truffle, PyPy?

30 years ago I used to take the flak for arguing about C++'s suitability for
writing programming language tools in comp.compilers instead of C.

Yet here we are praising C++ virtues over other languages for writing
interpreters and JITs.

One thing I learned in all those years reading compiler related papers, is
that many times the main issues are actually human and not technical.

The majority just want to have something running, and take the shortcut of
using whatever works to achieve their goals, instead of taking the effort that
might bring the technology forward but would delay getting everything to work.

------
donatj
I think a persons opinion on Go really depends on where you're coming from and
what tooling they are used to. As a PHP/Node/Ruby dev I find Go does
everything PHP/Node/Ruby does, faster, and more reliably due to static typing.
Often more verbosely though.

I've simply never wanted for the things he asks as I've never had them. It's
all in the expectations is my point.

~~~
devishard
It's telling that the most sophisticated type system you've dealt with is
Ruby, though. I think that if you spent some time working in
OCaml/Nim/Rust/D/C# you'd learn a lot which would cause you to be a lot less
impressed with Go.

------
zzzcpan
Those are really small annoyances compared to everything else in Go. I don't
mind Go being opinionated, everything is like that anyway and it's kind of
nice in some ways. But don't mistake opinionatedness with misdesigned poor
quality libraries and experimental ideas.

Take net package for example, it's not opinionated, it's just completely
broken and misdesigned. There is so much mess with even the most basic things,
like timeouts and cancellations [1][2] that it's almost impossible not to fuck
up somewhere.

This is because the whole net library is synchronous and pushed onto
experimental ideas of goroutines and channels. Instead of having an actual
event loop underneath with timers, signals and everything and use asynchronous
writers and readers they just poll fds and wake goroutines when fds are ready,
forcing themselves to deal with typical multithreaded concurrency hell.

[1] [https://blog.cloudflare.com/the-complete-guide-to-golang-
net...](https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-
timeouts/) [2]
[https://github.com/golang/go/issues/16100](https://github.com/golang/go/issues/16100)

------
ahl
FWIW this is the project that pulled me down this golang rabbit hole:
[https://news.ycombinator.com/item?id=12211754](https://news.ycombinator.com/item?id=12211754)

------
simplehuman
Honest question: How does a post with just 4 points and posted 11 minutes ago
get to be on the front page? Even amazing it is number 2 right now.

~~~
dang
As Tomte and jdoliner pointed out, 4 points in 11 minutes would get you on the
front page at any time, let alone a slow time like this one. As for why the
post would get rapid votes, that's easy: moth-to-flame subject matter.

It's not great to post comments like this taking a thread so badly off topic,
let alone jumping to conclusions that the admins are manipulating what is
obviously (once you're familiar with it) baseline HN behavior. Love-hate-Go
posts are a drug here; and so are all things Rust, which is why those stories
are currently #1 and #2. If we did anything to posts like that it would be to
downweight them, but I'm tired, and a good pro-and-con language vent seems
like a fairly innocuous thing for HN to do overnight (with apologies for our
Pacific-timezone-centricity), so have at it.

~~~
Sylos
That seems like a dangerous system, though. Just a few coordinated upvotes can
get a post to the front page. And if it's so easy, you'll almost certainly
have people/companies abusing that to promote their content.

~~~
dang
Sure, but this problem has been around for years, and HN has developed many
mechanisms to deal with it. Some are obvious—if a post gets to the front page
without community interest, it will quickly attract flags, and probably a lot
of ornery comments too—and many more run silently beneath the surface. I think
the proof is in the pudding: we don't see a lot of this. Anybody getting away
with it regularly is probably being so devilishly clever as to deserve their
ill-gotten gains.

------
bubersson
I agree and disagree with the post title.

