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

381–390 of 466 posts

Re: Why Go Is Not Good (2014)

#381

Post by sanderjd »

dkuntz2 wrote: post #372
sanderjd wrote: post #369

Earlier quoted context omitted.

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

In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an error. The advantage of Optional over returning a value or null is partially that it makes the programmer more aware of the fact that they're dealing with something that might be null. The same thing would be true of an Errorable wrapper. I'd argue that Go mak…

The solutions are definitely similar, but the advantage is eliminating the potential for propagation of nil values.

> I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses.

Showing my ignorance: how does this work? Does the Go compiler check that you check the second return value from a method before doing something with the first return value? I thought you could just ignore the error return and pass along the returned value (which might be nil) as you please. If there's compiler support for avoiding nil propagation, that's great!

In the case of a container type like I'm suggesting, you get the compile-time checking from the type system – an error return value is not of the same type as the underlying type, so you have to explicitly get the underlying value out. Even if you accidentally propagate the container, you probably have more information than if you propagate a naked nil, because the error information is part of the container that was propagated, rather than a separate value that might be lost.

Re: Why Go Is Not Good (2014)

#382

Post by sanderjd »

jshen wrote: post #370
sanderjd wrote: post #368

Earlier quoted context omitted.

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.

> We should encourage experimentation rather than discourage it.

I made this point already, but to reiterate more succinctly: we should definitely do that, and we should definitely also write about our thoughts on how we think those experiments are going, which is exactly what the OP is doing.

Re: Why Go Is Not Good (2014)

#383

Post by AnimalMuppet »

trimbo wrote: post #154
Kapura wrote: post #108

Earlier quoted context omitted.

Certainly Go lacks some features (generics) which are more-or-less standard in other large languages, but I think that's a sacrifice to the code quality gods (not that you can't write shit code in Go). To use another metaphor: if C++ and Java are motorcycles, Go is more like a bicycle. Smaller, easier to maintain, and more portable, but there are times when you might really wish you had a motor.

> easier to maintain How do we know this? Has anyone written enough Go in an environment with a lot of engineers to make that determination?

Yes, I suspect that Google has, at a minimum. There may be others as well.

Re: Why Go Is Not Good (2014)

#384

Post by acjohnson55 »

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

To me, that just sounds like the designers really painted themselves into a corner. I have yet to run into a situation where everything-is-an-expression feels like a problem. Am I missing something?

> At some point if you really want Haskell you should just use Haskell. Or Rust. And then you will find out that those languages have problems too, and you will understand that engineering is a question of tradeoffs, not of feature checklists like this blog post.

I think it's clear that Go has contributed to the conversation. In really accessible ways, it made some powerful points on the benefits of auto-formatting, fast compilation, static binaries, and so forth. But there's just so much missing of the highly productive points made by other languages, and there seems to be so little energy in the community to progress on those points. In that sense, it feels to me like Go is a bit of a dead end.

Re: Why Go Is Not Good (2014)

#385

Post by masklinn »

nevir wrote: post #377
acjohnson55 wrote: post #355

Earlier quoted context omitted.

As a Scala coder, I'd say you can have it both ways by encoding the result as type that can have success or failure cases. No fancy control flow needed, just pattern matching.

Yeah, and you can implement that in C++ very easily, too. Googlers might recognize StatusOrReturn, and similar macros.

You don't get pattern-matching though, and I expect the implementation would be somewhat gnarly without native tagged unions. At least now that C++ has lambda expressions you can get all the nice HoF so the usage side of the equation has become less troublesome.

Still, a far cry from

    data Result a b = Err a | Ok b

Re: Why Go Is Not Good (2014)

#386

Post by fauigerzigerk »

sanderjd wrote: post #381
dkuntz2 wrote: post #372

Earlier quoted context omitted.

In practice I'm not sure I see where a PotentiallyErorredResponse object that wraps a response and error together is different from returning a response and an error. The advantage of Optional over returning a value or null is partially that it makes the programmer more aware of the fact that they're dealing with something that might be null. The same thing would be true of an Errorable wrapper. I'd argue that Go mak…

The solutions are definitely similar, but the advantage is eliminating the potential for propagation of nil values. > I'd argue that Go makes it more explicit by having compile-time errors when you don't deal with potential error responses. Showing my ignorance: how does this work? Does the Go compiler check that you check the second return value from a method before doing something with the first return value? I tho…

>If there's compiler support for avoiding nil propagation, that's great!

Yes, would be great, but there is no such compiler support. You can ignore errors completely. Maybe you could argue that compiler errors for unused variables are a very weak sort of compiler break on ignoring errors.

Re: Why Go Is Not Good (2014)

#387

Post by bmurphy1976 »

skj wrote: post #263
tveita wrote: post #156

Earlier quoted context omitted.

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…

Also, by default channels are zero length and block. What is a zero length queue in other languages? Doesn't even make sense!

Zero length channels are a key part of coordinating concurrent threads in Go.

Re: Why Go Is Not Good (2014)

#388

Post by jshen »

sanderjd wrote: post #373
AnimalMuppet wrote: post #356

Earlier quoted context omitted.

You're coming from the same bias as the author of the article: Haskell and Rust are what a language should look like; Go doesn't look like that, therefore Go is bad. Take one of your points: > Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Fine; I won't argue whether your statement is correct. But so what? That only turns into something…

I agree with most of your "so what?" point, but I think the lodash / FP thing is interesting because javascript is also not trying to be a functional programming language, and nor are the many other languages that have popular higher-order-function libraries (eg. Java, C#, Ruby, Python). There's a long trend of pulling in the ideas from functional languages that have proven to be generally useful, like lodash / Java…

As was mentioned before, you can absolutely do the same thing in Go that you see in lodash by giving up type-safety which javascript doesn't have anyway!.

Re: Why Go Is Not Good (2014)

#389

Post by blub »

vardump wrote: post #332
blub wrote: post #131

Earlier quoted context omitted.

No chance to replace Java, when Java is all about ecosystem, tooling, maturity and talent pool. And it has generics. I mean I am no Java expert, but e.g Android Studio is miles ahead anything the go team will be able to ship in the next few years. And I don't think they're even focusing on building such tools since they seem to be stuck on building a debugger right now.

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

Sure, but I'll take it if that means I can at least use some type of generics. :)

In my experience it's decent, even if not as powerful as C++ templates. Being able to specialize containers is a basic comfort for me.

Re: Why Go Is Not Good (2014)

#390

Post by jshen »

sanderjd wrote: post #382
jshen wrote: post #370

Earlier quoted context omitted.

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.

> We should encourage experimentation rather than discourage it. I made this point already, but to reiterate more succinctly: we should definitely do that, and we should definitely also write about our thoughts on how we think those experiments are going, which is exactly what the OP is doing.

Sure, but don't be surprised when people have different opinions and aren't convinced by anecdotes. Reading the comments here you can find tons of people that are shocked, SHOCKED, that not everyone agrees with them on generics, immutability, etc. I think it's important that we remember that these are all opinions with no empirical data to support them, on either side.
Post reply on HN