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

371–380 of 466 posts

Re: Why Go Is Not Good (2014)

#371

Post by wwweston »

gendoikari wrote: post #346
wwweston wrote: post #321

Earlier quoted context omitted.

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

> I don't think the whole industry chooses its tools randomly.

It may not choose entirely randomly, but that doesn't mean that it chooses reasonably. You mentioned OOP everywhere -- a philosophy that's driven several dominantly popular languages and has been seen as a mark of professionalism. If the industry is any guide, Go's break from the norm here already calls that decision into question.

(I happen to think this is one of several areas in which the industry is wrong, but then again I don't see the industry at large as particularly rational.)

> We do really need complexity?

No software developer wants complexity, every software developer is trying to manage and limit it to the extent of their resources.

The question is whether language simplicity leads to software simplicity.

It seems apparent Go's designers believe this is the case, and have offered a simple-ish language on a feature diet that avoids much in terms of type expressivity or facilities for abstraction that rise to the level of augmenting the language itself.

I think this can work for some problem domains, particularly one that is closely-fitted to built in types and libraries. But once your problem domain isn't close to native language facilities any more, you're forced to write more and more code to get around the limits of the language's expressivity. That ends up being more machinery and surface area to keep track of interactions between... which, in my experience, is where complexity creeps in rather than having to understand language features.

Re: Why Go Is Not Good (2014)

#372

Post by dkuntz2 »

sanderjd wrote: post #369
dkuntz2 wrote: post #267

Earlier quoted context omitted.

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 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 makes it more explicit by having compile-time errors when you don't deal with potential error responses.

Re: Why Go Is Not Good (2014)

#373

Post by sanderjd »

AnimalMuppet wrote: post #356
spion wrote: post #330

Earlier quoted context omitted.

As far as I can tell, conclusions are based on facts about the language as well as other languages. Maps, slices and channels are generics. I'd like to see code in Go written without maps, slices or generics. Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Go will never implement Futures / Tasks / Observables. Its impossible to write Fut…

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 8 Streams style collections functions, while ignoring the stuff that might be useful but is harder to implement or work with, like purity, immutability, laziness, or sophisticated type inference schemes. Go is definitely anachronistic in not following this particular trend. Of course, that's the prerogative of its designers! Note that Go doesn't need generics to have 100% of what lodash has, it would just have to be implemented in the compiler, similar to slice, range, map, etc.

I have no problem accepting that FP is not the only way to program, but it sure would be convenient for me personally to have nicer ways to work with collections in Go.

Re: Why Go Is Not Good (2014)

#374

Post by Veedrac »

vvanders wrote: post #212
Veedrac wrote: post #47

Earlier quoted context omitted.

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

Rust has many things that C++ doesn't have, and that's a good thing. I think you might want to spend a bit more time with Rust before considering it just another C++.

I know Rust has things C++ doesn't have, and vice-versa. I don't see how that changes my argument that it's competing, though.

Consider inheritance vs. traits. Rust isn't able to stick with just traits because there are some things, though few, that are slightly faster with inheritance. So Rust is going to get some form of inheritance (in whatever form it might take). For every bit of functionality in C++, there is or will be some alternative in Rust, and that's by design.

The same is not at all true for Go.

Re: Why Go Is Not Good (2014)

#375

Post by bliti »

SneakerXZ wrote: post #289
bliti wrote: post #233

Earlier quoted context omitted.

I've written and maintain various Go systems and agree. Go is like Rails was about 5 years ago. It ends up hurting the community members themselves in the end. I won't abandon the language because it works well for my use case, but I'm not pouring any open source efforts into it.

But Ruby is at least syntactically very powerful. Go feels like it was written to have fast parser but this they killed with the latest version.

Sorry, I meant the Rails community not Ruby or Rails itself. :)

Re: Why Go Is Not Good (2014)

#376

Post by Veedrac »

wyager wrote: post #213
Veedrac wrote: post #47

Earlier quoted context omitted.

I can't really see a world in which Rust is a "better Go". Rust is one of the more complex languages in existence, largely because it competes with C++ and thus can't afford to lose many features nor do many things the easy way. Go is one of the simplest languages in existence. It's on the other side of the charts.

> Go is one of the simplest languages in existence. By what metric? I can think of a lot of simpler languages. Lua, C, Forth, all the theoretical dead-simple combinator languages you don't want to use (Lambda Calculus, SKI calculus, etc.), etc...

> Lua, C, Forth

Are all simple, yes. That C is on your list is kind'a the point - Go is explicitly a spiritual derivative of C.

But go down on the TIOBE index[1] and tell me what fraction of languages there are as simple as Go. It's not a large fraction.

[1]: http://www.tiobe.com/index.php/content/paperinfo/tpci/index....

Re: Why Go Is Not Good (2014)

#377

Post by nevir »

acjohnson55 wrote: post #355
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.

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.

Re: Why Go Is Not Good (2014)

#378

Post by innocentoldguy »

thegeekpirate wrote: post #309
innocentoldguy wrote: post #299

Earlier quoted context omitted.

In relation to the blog we're discussing, Javascript is an excellent example, since one of the blog's points is that we shouldn't allow Go to become yet another Javascript.

Your post (and in turn, my reply) had absolutely nothing to do with the article. > I don't think a language's popularity has anything to do with it being a good, well-thought-out language. Just look at Javascript. My point is that it's popular because we've been forced into using it, and the web is now much larger than it used to be. I'm explaining why it became popular, despite it's downfalls. No other recent (past…

Furthermore, there are plenty of less-than-stellar languages out there that are popular for a time, so companies flock to them, build applications and services in them, and are then forced to maintain that code for years and years to come; which is one of the points of this article.

You are the only one who inferred Javascript's unique circumstances and then extrapolated an irrelevant argument with me based on your own misunderstandings.

Re: Why Go Is Not Good (2014)

#379

Post by innocentoldguy »

gendoikari wrote: post #322
innocentoldguy wrote: post #248

Earlier quoted context omitted.

I don't think a language's popularity has anything to do with it being a good, well-thought-out language. Just look at Javascript.

I didn't mean that. I meant that in the next years we'll see if some design decisions were bad or wise.

I see. I apologize for reading your post incorrectly.

Re: Why Go Is Not Good (2014)

#380

Post by burntsushi »

spion wrote: post #330
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.

As far as I can tell, conclusions are based on facts about the language as well as other languages. Maps, slices and channels are generics. I'd like to see code in Go written without maps, slices or generics. Go will never implement immutable data structures. Its impossible to write an immutable data structure library without generics. Go will never implement Futures / Tasks / Observables. Its impossible to write Fut…

You absolutely can implement those functions in Go, if you're willing to sacrifice both type safety and performance. e.g., https://godoc.org/github.com/BurntSushi/ty/fun

Javascript is unityped, and you can certainly pretend Go is unityped too, by using `interface{}` everywhere.

If you linked to a similar set of functions defined in, say, C++, then I'd agree that Go has no real way to achieve something similar.

> (errors can be modelled with a generic Result which forces you to check for error and allows chaining, generics would enable immutable data structures which are much safer for concurrent programming...)

Generics isn't sufficient for that though. You also need sum types, which Go doesn't have.

Lack of generics isn't objectively a flaw. It's a trade off. You may disagree with that trade off though!

Post reply on HN