Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go Is Not Good (2014)

yager.io

Post reply on HN
Print view View original

261–270 of 466 posts

Re: Why Go Is Not Good (2014)

#261

Post by slantedview »

meshko wrote: post #226
mrcwinn wrote: post #207

Earlier quoted context omitted.

I wouldn't call myself part of the Go community in any real way. There are people doing much more than I am. I personally like Go. We use Go at Creative Market (and do so increasingly). I will say the my impression of Rob Pike and some members of the community is that they just put on earmuffs and say, "no, you're doing it wrong, you don't need that" (generics). I think this article clearly demonstrates that working…

It's funny that you set Java aside based on something that it does which you do not need. I am not convinced that Go solves any problem that Java can't solve, other then it doesn't have a baggage of 20 years worth of bad open source libraries and a culture of writing 20 layers of abstraction where no layers are needed.

"it doesn't have a baggage of 20 years worth of bad open source libraries"

Give Go some time. It's inflexibility will inevitably yield some interesting baggage of its own.

Re: Why Go Is Not Good (2014)

#263

Post by skj »

tveita wrote: post #156
gendoikari wrote: post #4

Earlier quoted context omitted.

What do you think about goroutines and channels?

Goroutines are for all practical purposes threads. Threaded code is generally thought to be difficult to write correctly, in ways that can't be solved just by making the threads cheaper to spin up. Queues ("channels") are a good way to limit complexity of threaded code by treating each process as an agent. Besides some syntactical sugar Go doesn't really support this better than most other languages with threading, l…

> Queues ("channels") are a good way to limit complexity of threaded code by treating each process as an agent. Besides some syntactical sugar Go doesn't really support this better than most other languages with threading, like Java.

The magic of channels comes with select{}. Considering them to be only threadsafe queues is really missing out.

Supporting select{} in other languages is possible, but difficult and rare.

Re: Why Go Is Not Good (2014)

#264

Post by lohengramm »

I like the article. It is well written and very informative. However, one could just omit the word "Not" in the title, becoming "Why Go Is Good", and it would still be a valid article.

In short, the author just points out features that Go could have but doesn't, which is not a good argument for saying that Go is "unconditionally" bad. All those missing features are missing on purpose, they are not bugs nor there is some kind of inherent defect in the language.

To me, the only two things that really bother me in Go are: 1) sometimes, the lack of generics, particularly when dealing with data structures and 2) the lack of a proper and official dependency manager. (The go tool has so many officially supported auxiliary tools, why not also a dep manager supporting versions etc.?)

Re: Why Go Is Not Good (2014)

#265

Post by sesteel »

High level programming languages exist, first, to help us instruct computers on how to process data and second, to allow us to communicate with humans on how we intended to have the computer process data. For the most part, Go works well in both of these cases. I appreciate the fact that I can read other people's code and understand what is going on.

Re: Why Go Is Not Good (2014)

#266

Post by haldean »

exDM69 wrote: post #191
hackcasual wrote: post #14

Earlier quoted context omitted.

Using go for goroutines and channels is a bit like using Perl for regular expressions. The features have been added in a way that makes them easy to use and serves as a nice idiomatic platform, but fundamentally it's functionality other languages can provide via library support.

> but fundamentally it's functionality other languages can provide via library support. Implementing goroutines and channels requires language and runtime support for green threads that are n:m multiplexed on top of native threads. It can not be implemented as a library in most languages, at least not efficiently. Any language with thread support can set up threads and put a concurrent queue between them, but that's…

It's been done in C; check out libmill[0], which even matches the syntax pretty well.

[0]: http://libmill.org/

Re: Why Go Is Not Good (2014)

#267

Post by dkuntz2 »

sanderjd wrote: post #238
jshen wrote: post #199

Earlier quoted context omitted.

The problem is that there is no empirical evidence to support any of the claims. Even looking at generics, the limited studies I've see show that generics make people a little more productive when using a generic library, but far less productive when trying to write a generic library. In short, these are entirely anecdotal and subjective points of view, so after the 1000th person says, "you are stupid, generics are a…

I agree with a lot of this, but where things get muddy with empirical evidence, is that it implies a certain "default". In this case that can either be something like "generics are useful" or something like "not having generics is useful". I don't think either hypothesis is supported by much of the sort of empirical evidence you're looking for. Basically, I share your sense that this is all anecdotal and subjective,…

At least in the Go community, it doesn't seem like people are ever saying generics as a concept are bad, but that there are very real tradeoffs involved in adding them to Go, and they're the kinds of tradeoffs the language designers and maintainers have decided they don't want to make.

I really like how simple Go is, but I also think generics are super useful, and that if Go could implement them in a Go-y way, I would be incredibly excited, and probably use it even more than I currently do. But I'd rather see the language focused on doing what it currently does well, and making sure it keeps doing things well, over seeing it try to throw in a poorly designed generics system like Java.

Re: Why Go Is Not Good (2014)

#269

Post by oscargrouch »

Filligree wrote: post #198
TeeWEE wrote: post #75

Earlier quoted context omitted.

Ever wrote a big program in python? Then you know it works at runtime. Not at compile time. Go comes with more typesafety while being a bit more verbose. Its a tradeoff.

And yet Rust has more type safety, while being more concise, more expressive and faster. Which is the article's point.

Yes, but is less productive than go. You need more to express te same.

Rust is like a phone with a lot of buttons and commands, give you more options and freedom of choice. Go is like a simple phone with very few buttons which has enough to enable you the real purpose of the phone, to make phone calls.

Its just more pragmatic, and that doesnt make it a sin.

Particularly, i like to have options.. its good we have them all, and we can choose the right tool for the job.

Re: Why Go Is Not Good (2014)

#270

Post by nevir »

cmrdporcupine wrote: post #2

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 is something you perform extremely frequently, and it takes up an incredible number of lines of code. The response from the Go team was (paraphrased) "We don't see the value in making this pattern more terse when you can just write a macro for your editor to automate it".
Post reply on HN