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

341–350 of 466 posts

Re: Why Go Is Not Good (2014)

#341

Post by jshen »

klodolph wrote: post #316
jshen wrote: post #277

Earlier quoted context omitted.

There is no rigor to this blog post. He didn't have two teams build the same project with and without generics or anything like that. The title is "why go is not good" which is drawing a conclusion based on an anecdote. It's the equivalent of walking outside in December, stating that it's cold, then drawing the conclusion that the globe isn't warming.

Calls for rigor are unproductive, I think. The unfortunate reality is that an experiment with the rigor you want would be prohibitively expensive. The big differences in productivity I suspect are going to be in larger projects over longer periods of time. You also can't figure anything out from small sample sizes, so you would need to take four large teams, split them randomly into two groups of two, and have each t…

I agree, but then we shouldn't assert conclusions with the level of certainty expressed in this blog post and many of the comments here.

Re: Why Go Is Not Good (2014)

#342

Post by nulltype »

vardump wrote: post #327
nevir wrote: post #270

Earlier quoted context omitted.

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…

Well, as a mainly C++ programmer, I'd trade exceptions for that any day. Much easier to understand what is going on, no need to find out if something in the call graph of the method I call throws or not. Also error handling code is where the error occurs, not some completely different place. Properly handled exceptions aren't any less code anyways. Unless you can just drop everything on the floor.

I think you mean you'd trade exceptions for that.

Re: Why Go Is Not Good (2014)

#343

Post by vardump »

omginternets wrote: post #336
vardump wrote: post #332

Earlier quoted context omitted.

Java doesn't actually have runtime generics. Just type erasure syntactic sugar. ArrayList is the same type at runtime as ArrayList .

This strikes me as a distinction without a difference, in the present case. How is this meaningfully different from the programmer's perspective?

You can't distinguish them at runtime from each other.

Your memory consumption is higher, because type erasure requires elementary types to be boxed. Since the boxed value is itself allocated somewhere else, there's indirection. Indirection means CPU stalls. Another consequence is data cache pollution. There are just 512 of 64 byte L1D cache lines.

Other than that, I guess nothing.

Re: Why Go Is Not Good (2014)

#344

Post by vardump »

nulltype wrote: post #342
vardump wrote: post #327

Earlier quoted context omitted.

Well, as a mainly C++ programmer, I'd trade exceptions for that any day. Much easier to understand what is going on, no need to find out if something in the call graph of the method I call throws or not. Also error handling code is where the error occurs, not some completely different place. Properly handled exceptions aren't any less code anyways. Unless you can just drop everything on the floor.

I think you mean you'd trade exceptions for that.

Fixed.

Re: Why Go Is Not Good (2014)

#345

Post by fauigerzigerk »

haldean wrote: post #266
exDM69 wrote: post #191

Earlier quoted context omitted.

> 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/

If "it" includes parallelism then no, libmill has not done it:

"Libmill is intended for writing single-threaded applications." http://libmill.org/documentation.html#multiprocessing

Re: Why Go Is Not Good (2014)

#346

Post by gendoikari »

wwweston wrote: post #321
the-tomster wrote: post #60

The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead. Go has specifically rejected the complexity that these features introduce, both in the implementation of the language and the writing of programs in it. If you want those features, just use a language that has them. Some other people might not car…

> The author says that "all the problems listed here have already been solved" by Rust and Haskell. Great, so let's stop complaining about Go and use those languages instead. I applaud your advocacy. Using other languages is pretty much my personal plan. The problem, though, is that like everybody else in the industry, I don't work in a vacuum. Other people may be making platform decisions for projects I work on. Com…

I don't think the whole industry chooses its tools randomly. I think that in the long term, if a tool emerges from the dust it's because of some actual reasons. If the simplicity of Go will win against the complexity of Rust, for example, I think we should think about the reasons. In my opinion the problem it's not about Go limits, but instead is about our perspective as developers using our tools. We do really need complexity? We do really need oop everywhere? If the answer will turn out to be "no", I will need to change my attitude toward Go.

Re: Why Go Is Not Good (2014)

#347

Post by Gankro »

masklinn wrote: post #247
jerf wrote: post #197

Earlier quoted context omitted.

"Not quite true, the language could implement checked over- or under-flows (I believe Swift does)" I am one of the apparently about ten people who thinks that should be the universal default. The vast bulk of people disagree, and I was trying not to poke the sleeping dog. :)

> I am one of the apparently about ten people who thinks that should be the universal default. There's a handful of us, a handful! FWIW Rust checks for overflow in debug mode, and while that's elided by default when compiling with optimisations it can be re-enabled with a -Z flag: > rustc test.rs > ./test thread ' ' panicked at 'arithmetic operation overflowed', test.rs:4 > rustc -O test.rs > ./test Overflowed! > rus…

"everything is floats" is also technically a solution, but with a curious fail-state.

Re: Why Go Is Not Good (2014)

#348

Post by parenthephobia »

pkulak wrote: post #161
hbex5 wrote: post #8

Earlier quoted context omitted.

Any critique of Go seems to be met with angry pitchforks in this place. As you say, the Go developers seem to have developed a kind of bunker mentality where they interpret legitimate criticisms of the language design as personal attacks, and respond by wearing Go's shortcomings as a badge of honour. It's not, I think, entirely healthy.

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…

> I think everyone who uses Go for anything is pretty clear about why they like it, and one of the major reasons is simplicity.

Nope. I like Go because:

* Interfaces

* A sane, fast, build system

* Concise syntax, mostly

* Garbage collection

* Excellent concurrency support

* A (for the most part) well-designed standard library

* Optional semicolons

* Compile-time type-checking

* Static binaries

I like Go because of the features it has, not because of the features it doesn't have.

On balance, although Go sucks, it sucks less than any other language for the sorts of problems I use it for.

> And to be honest, this whole argument about pitchforks seems like a straw man

If you don't notice that criticism of Go is immediately and vigorously argued against... Well, you can't be following the comments very closely.

Re: Why Go Is Not Good (2014)

#349

Post by gendoikari »

parenthephobia wrote: post #275
kentor wrote: post #262

Earlier quoted context omitted.

Javascript is pretty good.

Counterpoint: Javascript is pretty bad. There is a brilliant language that looks like Javascript that is the language you might be thinking of when you say "Javascript is pretty good". Unfortunately, that language only exists in people's heads. In practice, Javascript is full of crazy weird edge cases where it is required to behave in an insane manner because the browser vendors have all been juggling the idiot ball…

I like Javascript. I don't see any problem with the language itself. I see problems with the browser ecosystem as a whole, but that's another story. I understand the argument "popular != good", but I think that if in the long term a tool raises in popularity this is not random. There should be reasons for that.
Post reply on HN