Live data from Hacker News

Why Go Is Not Good

yager.io

221–230 of 367 posts

Re: Why Go Is Not Good

#221

For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language. The problem of 'summing any kind of list' is not a problem that is solved in Go via the proposed kind of parametric polymorphism. Instead, one might define a type, `type Adder Interface{Add(Adder)Adder}`, and then a function to add anything you want is fairly trivial,…

>For fear of disagree downvotes: I would say that many of the qualms brought up in this article are problems that are encountered fighting the language.

If that's so, it's because it's a language that also fights lots of things a modern programmers wants to do/have.

Re: Why Go Is Not Good

#222
post #219

Earlier quoted context omitted.

> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!) Why is Rust too complicated to allow you to do low-level hacking?

I don't think it's bad, but to me(and only to me), disappointing. I'm a long time mozilla fan...heck a Netscape fan really. Go was a pleasure to learn, there were no 'gotchas' initially...just a small, easy to reason about language. Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain. I'd love to be proven wrong and try again, but the docs aren't the best. And I kn…

>Rust...with its arrows, angle brackets, pattern matching, etc. seemed just so complex to fit in my brain.

It's 2014 already. Angle brackets, arrows, and pattern matching are 1990 level language technology.

Heck, even a dynamic front-end language like Coffescript has these kind of things nowadays.

Re: Why Go Is Not Good

#223
post #50

There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." But, for systems programming, abstractions suck. They always, always have a cost. When abstractions break, you not only have to deal with a broken system but the broken ab…

> These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." These languages have built-in abstraction tools (templates) that you can use to create your own abstractions. What I like about Go is the abstraction tools are primitive and allow for consistent & precise expression. The expression may not be as concise in cert…

>What I like about Go is the abstraction tools are primitive and allow for consistent & precise expression.

Well, not really consistent.

For example, try having a range loop for your own structures. Or something like make for them.

And not really precise. The need for interface{} and type switches in idiomatic Go code throws preciseness out of the window.

Re: Why Go Is Not Good

#224
post #123

Earlier quoted context omitted.

> Rust, C++, Haskell, Scala will never be good at that because they're too damn complicated (although each of them make the nasty parts a little less painful!) Why is Rust too complicated to allow you to do low-level hacking?

I mean too complicated for writing, reading, and maintaining and generally just working with from day to day. It costs too much time to do the same thing.

Can you be any more vague?

Re: Why Go Is Not Good

#225
post #187
post #122

Earlier quoted context omitted.

Correct. I have to duplicate much of the code for in64 keys and values, the lack of generics hurts there.

You seem to be brushing this off as a minor nuisance, when in many cases it is a showstopper. Need it for floats, duplicate it again. This is a solved problem -- the fact Go doesn't have the solution reflects very poorly on Go.

There are some batshit crazy "solutions" offered from Go fans, like "no biggie, just use a templating engine to generate the code for the types you want and compile it".

Re: Why Go Is Not Good

#226
post #24
post #3

This was a good read. Can anyone comment on whether they find the problems outlined in the article to really be painful in day-to-day go development? From my initial dabblings with the language, it feels like its constraints may not actually be a big deal in practice, and may even be more of a help than a hindrance in large projects. It would be nice to get some commentary from more experienced go users.

I'm an experienced Go user. I'm also a lover of Haskell and Hindley Milner type systems. and in practice these complaints are not that big of a deal. Generics may or may not get added in the future but in practice you can go a long way with just slices and maps. And while the Hindley Milner type system is a wonder to behold and I love working in languages that have them sometimes those same languages introduce a non-…

>Go's single best feature and the one around which almost every decision in the languages is centered is an almost total lack of developer friction. If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used.

Unless you want to do generics. Of extend the language to have custom operators, for things like scientific computing. Or tons of other things.

Re: Why Go Is Not Good

#227
post #83

Earlier quoted context omitted.

>The correct solution is for people to implement languages like Haskell and Clojure in Go, making them execute as fast as possible. Uh, what? Haskell already compiles to native code, and is faster than Go in many cases. Also, if you were implementing a programming language, there are much better languages to do it in than Go.

Depends on your particular value of "better." If you're optimizing for programmer time, writing a language in Go is not a bad tactic. You get out of having to write your own GC, you can incorporate a few nice concurrency features with little effort, and you still get pretty good performance. (Admittedly, far from the best performance, though.)

>You get out of having to write your own GC

No, you really don't. The built-in GC is nothing like the GC needed for lots of other languages.

Re: Why Go Is Not Good

#228
post #157

Earlier quoted context omitted.

Just curious : how does one run go without a linux kernel ? (without a kernel at all, please, I know about the freebsd port)

You'll probably be looking for a Go runtime that fills a kernel shaped hole. Without a kernel, where do all your syscalls go?

Yes but the point of the parent poster was that go can work on minimal embedded systems, which to my knowledge it cannot, so I enquired.

Re: Why Go Is Not Good

#229

Earlier quoted context omitted.

> These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen." These languages have built-in abstraction tools (templates) that you can use to create your own abstractions. What I like about Go is the abstraction tools are primitive and allow for consistent & precise expression. The expression may not be as concise in cert…

> What I like about Go is the abstraction tools are primitive and allow for consistent & precise expression. Well, not really consistent. For example, try having a range loop for your own structures. Or something like make for them. And not really precise. The need for interface{} and type switches in idiomatic Go code throws preciseness out of the window.

They claim this is a feature, not a bug. It means that range will never block or do weird stuff. Except of course when it does (bastard question for those who think they know : what does range do on a nil channel ?)

Despite all these clarity claims, go has significant pitfalls, like the nil channel above (and you will enounter nil channels). There's other things, like "what is a pointer in Go", if your answer involves "*", I urge you to reconsider (hint : what's the difference between []int and [5]int ? Is one of them a pointer ? What about channels (of course I talked about nil channels) ? Maps ?

But every type can be typedeffed to a pointer type of itself, like in Pascal (lots of things look like pascal), and result in completely unpredictable reference or value semantics (or my favorite : partial reference semantics).

Does go have generics ? YES (make, range, ...). Go has something no other language has : return type generic function types (meaning a functions meaning changes depending on what you assign the result to, like range). Does Go have operator overloading ? Is Go object oriented ? YES (including single inheritance). YES. Does go have (complicated language feature X) ? Probably yes. But all of these features are only accessible to Rob Pike, who has apparently decided that nobody has any use for any kind of tree or graph data structures, matrices, complex numbers, or so.

In practice you can catch the go team themselves in errors on the language semantics in their presentations, so I think a VERY strong case can be made that it's not at all that obvious.

But the truth is : this language, due to politics (high position of it's inventor) has 10 or so FTE behind it, with lots of paid people contributing various small bits. Is it anything more than some guys idea of his own favorite programming language ?

The honest answer is simply : no.

The only real advantage Go has is a small, yet functional and pretty complete standard library (like C++ had in the 1980s). It is an advantage that will fade, just like it's faded for every other language.

Re: Why Go Is Not Good

#230

Sheesh. A laundry list of issues. So why use Go at all? Quit yer whining and just use Haskell or whatever. Go works for some people, not for others. Why hang around and complain? Move on, use something else.

>Go works for some people, not for others. Why hang around and complain?

Because if everybody was selfish and self-absorbed enough to do that there wouldn't be any evalutation of languages outside the personal level?

The way things move forward is through (1) criticizing stuff, (2) fixing stuff, (3) making new stuff (in that order). And all three steps are necessary.

Post reply on HN