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

151–160 of 466 posts

Re: Why Go Is Not Good (2014)

#151

Post by pcwalton »

coldpie wrote: post #125
pcwalton wrote: post #99

Earlier quoted context omitted.

func SameSideOfTriangle (p0 Point2D , p1 Point2D , a Point2D , b Point2D ) bool where N: Number { ba := Point2D(b.x.Sub(a.x), b.y.Sub(a.y)) p0a := Point2D(p0.x.Sub(a.x), p0.y.Sub(a.y)) p1a := Point2D(p1.x.Sub(a.x), p1.y.Sub(a.y)) cp0 := ba.x.Mul(p0a.y).Sub(p0a.x.Mul(ba.y)) cp1 := ba.x.Mul(p1a.y).Sub(p1a.x.Mul(ba.y)) dot := cp0.x.Mul(cp1.x).Add(cp0.y.Mul(cp1.y)) return dot >= 0 } Versus: func SameSideOfTriangle (p0 Po…

I didn't mean to imply that it is never useful, just that it's not worth the baggage in my experience. Genuinely asking: Why does this function need to be generic over Numbers? Couldn't you implement it once or twice for whatever actually-numeric types you need? How many different Point2D template instantiations do you actually have?

In my project, i32, u32, f32, and f64. Possibly others.

And that's only a small function (only one part of what's needed to check point-triangle intersection!) Copying and pasting e.g. Sutherland-Hodgman clipping or 4D/5D matrix math would get unsustainable quickly.

Re: Why Go Is Not Good (2014)

#152

Post by moultano »

gendoikari wrote: post #24
cmrdporcupine wrote: post #9

Earlier quoted context omitted.

I agree that operator overloading is probably a feature not wanted in a language with this target problem domain. However "working as intended" I think is also the response of Go to their lack-of-generics, which I think is kind of crap.

About generics, this is highly debatable. This is a design choice, it's not a decision made by accident. You'll surely gonna have boilerplate code in some cases, but all the language will be a lot more readable, and simple. Simplicity it's the most wanted feature of Go, from the designers perspective, I think. In the long term it's preferable to have explicit and simple code, instead of complex magic. This is a corre…

Without generics, you can never write a type safe datastructure. I can't imagine the hubris that thinks the language already contains all of the datastructures it needs.

Re: Why Go Is Not Good (2014)

#153

Post by kllrnohj »

coldpie wrote: post #63
justin_vanw wrote: post #48

Earlier quoted context omitted.

Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is no…

> Now, implement a function 'average' that can work on any of these three types. I'm not convinced this is such a large problem that its solution is worth the myriad downsides that operator overloading is chained to. There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. There's a few examples, like boost shared pointers are somewhat easier to read, but t…

Please elaborate on the myriad of downsides that operator overloading is chained to. I am honestly not aware of any downsides that are unique to operator overloading

Hint: Things like "they can be abused" or "you can do crazy things like have + return a dot product" are not unique to operators. I can very easily define .clone() in Java to return a dot product as well, or have .equals() do in-place addition.

Re: Why Go Is Not Good (2014)

#154

Post by trimbo »

Kapura wrote: post #108
microtonal wrote: post #85

Earlier quoted context omitted.

I've used Go for a few projects and I think that people who point out all of the things that Go doesn't have and Go doesn't support misunderstand the language. This is the standard Go defense. 'It's not Go, it's you.' I have written some larger projects in Go, and I am in full agreement with the article - Go is a relatively weak and repetitive language, similar to pre-generics Java. So, why does Go gain so much tract…

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?

Re: Why Go Is Not Good (2014)

#155

Post by bargl »

joshbaptiste wrote: post #17

https://news.ycombinator.com/item?id=7962345 << 527 days ago, 356 comments

Thanks for the link. I'm kinda happy this resurfaced because I missed it on it's first go around (pun intended) and I am happy I read the article. Its nice to see some of these language features that I want to see in my language as well.

Re: Why Go Is Not Good (2014)

#156

Post by tveita »

gendoikari wrote: post #4
cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

What do you think about goroutines and channels?

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, like Java.

Go has a weird thing going on where channels are sometimes used as a kind-of-replacement for iterators, which is error-prone since the "obvious" way to do it doesn't allow the consumer to stop the generator without a side channel. This can lead to buggy code that leaks goroutines, since goroutines can not be garbage collected.

One of the best ways to reduce the complexity of threaded code is immutability - preventing race conditions by making sure a structure never changes while being read. Curiously, Go has no way to mark an object as immutable, and does nothing to detect or prevent objects being unsafely accessed from different threads.

Re: Why Go Is Not Good (2014)

#157

Post by nanodano »

skybrian wrote: post #94

I think the answer for people who want this sort of thing is to write a Go++ that compiles to Go. If it's a good enough solution then it will convince the community to move forward, at least on some features.

Go is still young and I think it will expand over time. I think they wanted to start with a simple language and grow it carefully. One of the biggest complaints is generics and they compare it to Java but even Java didn't have generics at first.

Re: Why Go Is Not Good (2014)

#158

Post by cmrdporcupine »

digi_owl wrote: post #93
cmrdporcupine wrote: post #2

While many of these points (on generics especially) are completely legitimate, this article will fall on deaf ears. My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. It aims to be a pragmatic language. But IMHO the anemic nature of the type system is a practical handicap that they have mad…

> My impression of the Go community (both within Google and outside of it) is that there is a very ... moralistic? .... sense of "You don't really need that, we know best" going on. Thats not limited to the Go community. It seems to be an attitude that is sweeping the second(?) generation of FOSS developers. Seems like just working on code is not enough any more, it has to have some kind of social/fixing-the-world an…

There is a whole new generation of FOSS/hacker folks younger than me (I'm in my 40s) that I can't relate to. It's so much an ego and self-marketing thing ; everything you do is blogged, you do the speaker circuit, you're judged in interviews by how many stackoverflow questions you've answered, what you have in your github repo, etc.

It makes me feel very old. I just want to keep my head down and hack.

Re: Why Go Is Not Good (2014)

#159

Post by jinst8gmi »

m0th87 wrote: post #90
bndr wrote: post #56

Earlier quoted context omitted.

> Any critique of Go seems to be met with angry pitchforks in this place. You can say that about any language. The people that like the language will always defend it. e.g. PHP, C, Ruby. They all have flaws and yet when one talks about their shortcomings, the people get defensive.

I think the point they're making is that the Go community is unusually pitchfork-ey. Having used Go since pre-1.0 days, I certainly agree; there's a very strong sense of, "if you want , you're doing it wrong" - despite legitimate concerns, like the ones outlined in this article.

It reminds me of the Java community when Sun stopped adding significant features for years after 2004. Every feature which wasn't added was widely considered by most Java developers as being in the name of protecting us from ourselves. When Java 8 came out suddenly some of those bad/evil features became flavor of the week. There's a tendency to try and convince yourself that the language designers made the best decisions at every turn, which isn't a healthy way of thinking critically.

Re: Why Go Is Not Good (2014)

#160

Post by dvirsky »

skybrian wrote: post #94

I think the answer for people who want this sort of thing is to write a Go++ that compiles to Go. If it's a good enough solution then it will convince the community to move forward, at least on some features.

There were a few attempts to do this with generics, some seem decent. But I've always found myself preferring to write a few extra lines than using such a language extension.

It boils down to tool support for me. If you can't have code completion and things like gofmt, no one (well, at least not me) is going to use such a thing.

Post reply on HN