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

361–370 of 466 posts

Re: Why Go Is Not Good (2014)

#361

Post by jerf »

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…

Well, that's that then; now I just need a Rust project and I'll start learning it. (I'm only an early adopter of languages, not a bleeding-edge adopter.)

Re: Why Go Is Not Good (2014)

#362

Post by AnimalMuppet »

omginternets wrote: post #23
cmrdporcupine wrote: post #15

Earlier quoted context omitted.

Then it needs to stop calling itself a 'systems programming language.' Or maybe it doesn't, but others need to stop calling it that. To me, it's a replacement for Java, not C++. I think that's a reasonable target. Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -- these make it difficult to write safe and fast code for systems level or embedded type work.

>Then it needs to stop calling itself a 'systems programming language.' Why must a systems programming language be static and strongly typed? I don't mean to be flippant, but to me, 'systems programming language' means 'a language that facilitates productivity for systems programmers'. By that description, Go certainly qualifies. >Mandatory GC, lack of generics and therefore rampant use of downcasting & duck typing -…

Define "systems programming" (or "systems programmer").

Google's definition seems to be "building large systems". For the types of large systems Google wants to build, Go works very well.

But others define it as "building operating systems". Go is horrible for that because of garbage collection and inability to directly access the hardware.

Re: Why Go Is Not Good (2014)

#363

Post by AnimalMuppet »

vardump wrote: post #343
omginternets wrote: post #336

Earlier quoted context omitted.

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.

But if you're worried about that amount of memory consumption, why are you using Java? If you need that much control over memory, Java may not be the language for you.

Ditto if you're worried about the performance hit from cache misses.

Re: Why Go Is Not Good (2014)

#365

Post by masklinn »

steven2012 wrote: post #272

I hate blog posts like this. It sounds like the author wants to turn Go into Java or Haskell. If that's what the author's preference is, then just use Java or Haskell. I don't even use Go, but to me this post is simply just whining, but the author doesn't appear to understand the fundamental reason of how or why Go was designed. The creators of Go made opinionated decisions on how the language would behave. Generics…

> It sounds like the author wants to turn Go into Java

Go is already a Java. It's just that by and large it's an old Java, 1.0~1.1 style. Slightly better in some ways (local type inference), slightly worse in others (more magical builtins).

> Generics weren't left out because of oversight or accident, that was a conscious decision.

So were they in Java 1.0. Or C# 1.0 for that matter. Though for the latter it was because of time constraints, they were never under any illusion that they should do without.

Re: Why Go Is Not Good (2014)

#366

Post by mercurial »

gendoikari wrote: post #329
mercurial wrote: post #81

Earlier quoted context omitted.

How is code with generics more complex than without it?

For example the C++ templates rules are themselves a turing-complete language. If by generics you meant some really basic features, I think you can do pretty well with interfaces. They're already in the language. If by generics you meant the full-package, i think you could end up with something pretty complex all the time.

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).

Re: Why Go Is Not Good (2014)

#367

Post by evmar »

pcwalton wrote: post #303
evmar wrote: post #91

This sort of gratuitous takedown is unfortunately crack for HN -- pages and pages of "here's how this popular thing is not like this other thing I like", without any thought given to why things are they way they are. Go is missing a lot of my pet features too but I know its authors are smart so I don't just immediately jump to assuming they don't know what they're doing. Thought experiment: write a proposal that work…

> E.g. you'll want a "match" operator. And then that means you need all statements work as expressions. And you'll have to change how zero values work, which are pervasive throughout the language. You don't need to make everything an expression for pattern matching to work. See Bjarne's C++ proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n344... You might have to change zero values, although you cou…

Thanks (as always) for your informed comments!

I agree that you can make pattern matching work without expressions. My intuition is rather that it's not especially useful, because you need some way to make use of the result of the match.

Either you embed the rest of the function into the branch of the match statement, or you're back to stuff like:

    foo := ... # Some zero value ...perhaps nil?
    match get_foo() {
      Some(x) => foo = x
      None => return
    }
    # now use foo here
That is, to make use of the result of the pattern match you need a way to get the value out of the pattern match which puts you back in the kind of code where there's no pattern match. You could make just "match" be an expression but now the arms of your match must be expressions which runs again into the problem of Go being a statement-oriented language -- for example, you might want to construct a struct in your match arm but if you can't fit the struct construction into a single expression you're stuck again. (It's a similar problem to Python's lambda.)

There might be some other nice way to make this work, of course! All I am suggesting that if one does the effort of making a concrete proposal you'll find that any small feature like this brings in a bunch of related ideas (like Rust's semicolon) and is not as simple as "just add option types".

Re: Why Go Is Not Good (2014)

#368

Post by sanderjd »

jshen wrote: post #277
sanderjd wrote: post #238

Earlier quoted context omitted.

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,…

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.

I don't think this is a good analogy at all. The article is more akin to walking outside in December and stating "here's why December is too cold for my liking". The article is just a series of observations on the author's subjective opinion about a language, along with reasoning on how that opinion was formed. It should be read as "why Go is not good (in my opinion)".

This is a major problem that I struggle with: saying "I think" and "in my opinion" gets old really fast and makes everything you say sound waffle-y, but if you don't say things like that, some people will interpret your statements as if you are claiming to state objective fact.

My sense is that such a diminishingly small amount of the things people discuss is actual fact that I can usually prepend "I believe" to any sentence I read. I am pleasantly surprised when I find that this rule fails to work for something, but that doesn't usually happen on the internet.

Re: Why Go Is Not Good (2014)

#369

Post by sanderjd »

dkuntz2 wrote: post #267
sanderjd wrote: post #238

Earlier quoted context omitted.

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 woul…

I'm not sure that I've heard the argument that generics as a concept are bad, per se, but I believe I've heard the argument that they aren't very useful. I (again, non-empirically) disagree with that, but I don't know if it is a common belief in the Go community, and I don't disagree with you at all that generics wouldn't fit very well into Go's philosophy and design and probably don't belong in the language. I think that's a shame, but I still like Go a lot.

On the other hand, I do think the author is spot on about nils and multiple return types for error handling. Returning a container type that can represent either a successful or error value is simple (arguably, simpler!) and less error prone. It is something I would love to see in the language. (Somewhat ironically, if it were possible to make generic container types, this wouldn't need to be done in the language itself, but could be a library.)

Re: Why Go Is Not Good (2014)

#370

Post by jshen »

sanderjd wrote: post #368
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.

I don't think this is a good analogy at all. The article is more akin to walking outside in December and stating "here's why December is too cold for my liking". The article is just a series of observations on the author's subjective opinion about a language, along with reasoning on how that opinion was formed. It should be read as "why Go is not good (in my opinion)". This is a major problem that I struggle with: sa…

I agree, but then people can't complain much when other people, like the Go team, have different opinions and make different decisions than they would. We should encourage experimentation rather than discourage it. No one is forcing anyone to use Go, and there are plenty of languages that have generics, are immutable by default, etc, etc.
Post reply on HN