Live data from Hacker News

Why Go Is Not Good (2014)

yager.io

421–430 of 466 posts

Re: Why Go Is Not Good (2014)

#421
There is a small discrepancy in the article:

> Go supports the := assignment operator, which works like this ... All this does is look at the return type of bar(), and set the type of foo to that.

This is a misunderstanding of the := operator and how type inference works in Go. If you look at the language spec (https://golang.org/ref/spec#Short_variable_declarations), you can see that the := operator is nothing more than a shorthand variable declaration.

x := "foo"

is shorthand for (and functionally equivalent to)

var x = "foo"

Type inference is orthogonal to the := operator and is a little more powerful than the author implies. For example, Go is able to infer the type of literals, including inferring the type of a numeric literal based on the presence of a decimal point or the symbol for the imaginary number, i (complex and imaginary numbers have native support). It can also infer the type when you assign a variable to an element in array, slice, or map or when you receive from a channel. Of course it can also infer types for values inside of a struct, map, slice, or array and for keys in maps. The only obvious difference I see between type inference in Go and Rust or Haskell is that in Go you must always define the return types for functions, but there may be more differences I am unaware of. See this playground example for a demo of a few different ways that types can be inferred in Go: http://play.golang.org/p/8ep340vLky.

(edit: formatting)

Re: Why Go Is Not Good (2014)

#422
post #324
post #249

Earlier quoted context omitted.

No ? Qt, Gtk, ... all do it.

Huh? Care to elaborate on this? As far as I know, GTK (and Qt IIRC) use a single threaded event loop. That's not at all the same thing (albeit can be used for similar things).

Qt and Gtk's single threaded event loop are akin to what Go calls it's scheduler. That scheduler in Go is also (partially) single threaded, but event handlers run in other threads.

Having event handlers run in separate threads is very much supported in both Qt and Gtk (they can't be UI event handlers in quite a few cases, but network events and file reading in separate threads scheduled by the central event loop like in Go is not a problem).

I will say that it's much better organised and with much less caveats in Go.

And a point of personal frustration : both Qt and Gtk support promises through the event loop, Go does not. I find that a much more natural way to work with threads.

Re: Why Go Is Not Good (2014)

#423
post #121
post #95

Earlier quoted context omitted.

I think some of that stems from the fact that the arguments against Go are often over emphasised matters of personal preference, or just so frequently raised that it becomes tiresome to read. I love Go. I know it's an imperfect language and because of that I do often hate specific Go idioms. So I definitely don't have a "bunker mentality" when it comes to Go; nor any other language. But in terms of "getting stuff don…

In the end there is no one true best language out there. Go is great for a subset of problems and making it better at other things is a balancing act. The most popular languages are generally accidents of history. Unix gave us C, browsers gave us JavaScript, and Databases gave us SQL, etc.

I think that your view, while true, misses the point (or doesn't make it explicit enough): tools are what really matter, languages are simply less important and ultimately interchangeable.

Re: Why Go Is Not Good (2014)

#424

Earlier quoted context omitted.

Most generic implementations are not Turing-complete, and looking at C++, this doesn't sound like a particularly tempting proposition. And while I'm not particularly familiar with Go, I don't see how you can get a feature set equivalent to a simple implementation like Java's out of Go interfaces ("you can just cast" is not a good answer).

I'm probably missing the use case. What is the problem that you are thinking of, you can't solve with a Go interface?

Say, a generic container.

Re: Why Go Is Not Good (2014)

#425

If there were GOOD language then all other languages will be dropped. Every language has its own disadvantage, but it doesn't mean its not good, thats just trade-off. For me main selling point of golang is small lightweight threads with event loop. You write sequential blocking code and you get concurrency built in.

That sort of total relativism is not a helpful perspective. There are definitely better and worse designs in the world, and the reason people do not drop the worse ones has to do with the network effects of adoption. Betamax was superior to VHS but adoption rates and support by movie publishers made VHS win.

Are people downvoting this because I didn't use a convincing enough example? Or because they think this is part of the anti-Go sentiment here? Or because they actually believe in total relativism? Sincerely curious. Maybe people aren't relativists but actually believe that markets are magic and always make the most deserving things win??

Re: Why Go Is Not Good (2014)

#426

If there were GOOD language then all other languages will be dropped. Every language has its own disadvantage, but it doesn't mean its not good, thats just trade-off. For me main selling point of golang is small lightweight threads with event loop. You write sequential blocking code and you get concurrency built in.

That sort of total relativism is not a helpful perspective. There are definitely better and worse designs in the world, and the reason people do not drop the worse ones has to do with the network effects of adoption. Betamax was superior to VHS but adoption rates and support by movie publishers made VHS win.

Semi-joke: If we consider type system of Rust superior to Go, then adoption rates in Go world should increase.

I love both languages, both has their advantages, but Rust lost community while changing syntax and versions were not stable until v1.

Its not about total relativism, its about trade-offs.

Re: Why Go Is Not Good (2014)

#427

Earlier quoted context omitted.

What do you think about goroutines and channels?

I think the way Go addresses concurrency is simple and straight-forward. It's trivial to write concurrent applications. If your target is writing semi-low-level infrastructure software I think Go is a great choice. It's definitely got a lot of fans in the world of people writing software for DevOpsy type applications. From a personal standpoint, it's missing a lot of the features I like, namely ADTs, list comprehensi…

"I think the way Go addresses concurrency is simple and straight-forward. It's trivial to write concurrent applications."

Except when it is not. Message passing style of concurrency is just a dual of the classical blocking concurrency with critical sections, mutexes, monitors and conditional variables. An actor is a dual of a critical section. Actor's mailbox is a dual of a mutex. Sending/receiving messages is a dual of wait/notify. With any complex CSP program you can have all the same problems: race conditions, starvation, deadlocks (livelocks) etc.

Re: Why Go Is Not Good (2014)

#428
post #161

Earlier quoted context omitted.

I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity. So why are people then surprised when criticisms over lack of features fall on deaf ears? And to be honest, this whole argument about pitchforks seems like a straw man. If anything, it's currently fashionable to dump on Go at every opportunity. Hell, it's fashionable to dump on everything arou…

Agreed. I foresee a great future for Rust, and also a great future for HN posts in the form: "I know I'll get downvoted for this, but Rust is a terrible language because it lacks the following features..."

While Rust in it's own little world is promising, it's issue is that it tries to solve problems C++ programmers were facing 10 years ago, but 'good practices' and C++ devs limiting themselves to a subset of features "solved" most of these problems for most C++ developers. And that's Rust's main target audience.

Go's target audience are 2 groups: people previously writing stuff in C/C++ because they didn't have much choice unless they wanted to bring a shitton of dependencies, but in reality didn't want the complexity this brings, and people coming from scripting languages like Python and Ruby. And for these things, go is pretty damn good. It has it's downsides - like any language, but it works. It's strongest point however is it's standard library with 'modern features' and transparency. For me it was the first language where diving into the source code of libraries - even the stdlib - was so effortless and has become a completely normal thing to do. In C/C++, the most you do is dive into the headers, and in the latter case, this is not always a good idea if you want to keep your sanity (hello Boost).

Rust could gain traction the moment it finds a market, and few high profile projects written in Rust that are widely used. But right now, I'm not aware of any.

Re: Why Go Is Not Good (2014)

#429
Maybe we should stop fighting over languages and focus on the things you can create with them ? I honestly see no point in creating blog posts about "Why this language sucks". It's quite always a subjective point of view, and the whole goal of this kind of article is generally to drag people away from a language.

People are using Go. They create content with Go, they create amazing stuff, sometimes they realize that Go isn't the best language to create this or that and so they switch to something else. What's the point there ? If a language doesn't fit your exact use cases, then it's a bad language ?

Stop the impossible standards of the perfect language. Real languages have flaws !

Re: Why Go Is Not Good (2014)

#430
post #270

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

Same for me. I tried really hard to enjoy Go, but it became an incredibly frustrating experience. The language itself was frustrating to me in many of the ways outlined in the article. The community was similarly frustrating. One anecdote that really stuck with me was when enquiring about explicit language support for the error handling pattern. E.g.: f, err := os.Open("foo.bar") if err != nil { log.Fatal(err) } It i…

This is exactly the pattern that Erlang handles the best:

1. Expect you call to os.Open to not fail 2. Then do stuff with it 2bis. Or the running process will crash, the error logged, bad state won't mess up the flow and a dev can always hot-patch it

Post reply on HN