Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Channels Are Not Enough

gist.github.com

Post reply on HN
Print view View original

141–150 of 224 posts

Re: Channels Are Not Enough

#141

Post by cdoxsey »

skybrian wrote: post #35

Rather than arguing about generics in Go again, I'd be interested in reading about how experienced Go developers solve the problems posed in this article. (He may be wrong that there's no elegant solution.) Also, if it can't be solved elegantly, perhaps adding merge() and a few other important functions to the language would be good enough? After all, Go already has the magic append() function for slices and we get q…

In my experience solutions generally fall into two camps:

1) Create a "generic" version of the function using reflection / typecasts 2) Create a specific version of the function for your use-case

I don't have a ton of experience using channels. My code tends to be very imperative and I add the channel layer at the main application level rather than the library level.

So from his example:

> func merge[T](cs ...You can create a function:

   func merge(cs ...interface{}) interface{}
Then call it:

   merged := merge(c1, c2, c3).(
You lose type safety and pay some penalty for performance. Also merge is harder to write than it would be with generics.

But even languages with generics often have similar issues. For example you can't write a generic min/max in C# either.

Re: Channels Are Not Enough

#142

Post by frowaway001 »

gbog wrote: post #124
sriku wrote: post #57

Earlier quoted context omitted.

That's a weird stance. If there are complexities that programmers face that can be absorbed by a compiler, it must be, because that would pay off for every programmer , in every project, in every bug prevented.

> If there are complexities that programmers face that can be absorbed by a compiler, it must be Not sure. If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path. It looks like the go compiler in itself is a nice piece of engineering, like a F1 race car. And a…

> If absorbing it would make the compiler much slower, much more complex, or the compiled code less deterministic, or corner cases in the compiler much more numerous, I think it may be reasonable to not go this path.

Why would that be the case for Generics?

I think nobody says "Go needs Generics, but the implementation needs to be horrible."

Re: Channels Are Not Enough

#143

Post by frowaway001 »

eropple wrote: post #93
burntsushi wrote: post #59

Earlier quoted context omitted.

> If you write reusable, future-facing code, generic types without the erasure of interface upcasting is required. You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained. > And this worse-is-better attitude of the Go community gives me a dim view of its future The Go community act…

> You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained. You're right. Sorry. You can do it by enacting a fair approximation of stapling your eyelids to your hairline. I apologize for not being exhaustive. > The Go community actively embraces Worse-Is-Better. If your opinions are…

I think the real point is that Go just isn't a language meant for developers:

It's a language meant for sys admins (which explains why it is popular with users of other languages usually used for sys admin jobs).

If your job is glueing a few existing services together, you won't miss Generics much.

Re: Channels Are Not Enough

#144

Post by tel »

pmontra wrote: post #106
apta wrote: post #98

Earlier quoted context omitted.

> I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pretty ugly Sometimes ugliness is a sign that something is designed incorrectly, especially if the language aids in making that more visually evident. > (although not as ugly as converting your ints to float64 and using the stdlib min/max.) Not to mention incorrect. > it's u…

Plus all those dynamically typed languages which are intrinsically built on the concept of generics (JavaScript, Perl, PHP, Python, Ruby). /sarcasm Nobody uses them because nobody needs generics.

They are intrinsically built atop generics. Duck typing is row polymorphism. Dynamic languages often depend upon that flexibility to operate—and they enable it by allowing everything. Static languages without polymorphism are at a low point in that trade-off space since they restrict useful operations and provide no way to express the invariances needed to recover that flexibility.

Re: Channels Are Not Enough

#145

Post by NateDad »

eropple wrote: post #55
NateDad wrote: post #33

Earlier quoted context omitted.

I write go 40 hours a week and have been for over a year. There's been only a couple times I wanted generics and those are structures I haven't actually needed to reuse yet. I'm not guessing about not being generics much. Edit That being said, go is not for all projects. Some projects need a lot of generics. Don't use go for that.

Um, I've written Go. Nontrivial amounts, as it happens. In doing so, I recognized that I was regularly forced to write worse code in the pursuit of doing things idiomatically because I lacked the semantic richness of C++, let alone Scala. And this worse-is-better attitude of the Go community gives me a dim view of its future--and between its junk GC and its completely pedestrian semantic and syntactic propositions I…

It sounds like you were forced to write/maintain some Go code and are basing your opinion on that, an opinion heavily colored by the quality of the original code and your annoyance at your employer for making you work in something other than your preferred language(s).

It's even possible the software you were tasked with writing/maintaining was a bad fit for Go. I tried to mention that in my previous response. Such things certainly exist, and most Go enthusiasts will be more than willing to admit it.

However, saying you can't write reusable, future-facing code without generics is preposterous. To refute you, all I have to do is point you at the Go standard library. A huge body of code whose purpose is purely reuse, and not a generic to be found.

Or perhaps we could look at the thousands of reusable go packages found on godoc.org.

You don't like Go. That's a perfectly acceptable stance to take. But I don't think you've really given it a fair shake, either.

Re: Channels Are Not Enough

#146

Post by tomp »

enneff wrote: post #29
spion wrote: post #11

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…

> What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. That's not the claim. The claim is that generics add complexity to the language and its ecosystem. That, I'd hope, should be an undisputed claim. Go's lack of generics is a design tradeoff. The occasional piece of awkward code is worth the overall reduction of complexity a…

> The claim is that generics add complexity to the language and its ecosystem. That, I'd hope, should be an undisputed claim.

I strongly dispute/oppose that claim.

1) Generics don't add any complexity to the rest of the language. If you don'y use generics, you're back to the "plain Go". Especially since generics doesn't mean just "ML-style polymorphism"; I'm pretty sure that many people would be happy with a very limited implementation of generics, e.g. only for reference/pointer types (or even only for interfaces), with all types/generic arguments declared, not inferred. In that case, implementing generics would only require a change of the type-checker of the language, or in the case of Go, not even that, which brings me to the second point:

2) Generics are already implemented in Go (the compiler/the language/the libraries), via map/arrays/slices, it's just not accessible to user code. I really can't see how anybody could make an honest claim that "Go is avoiding generics because of added compiler complexity", when that complexity is already there.

Re: Channels Are Not Enough

#147

Post by frowaway001 »

burntsushi wrote: post #46
spion wrote: post #11

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…

You're claiming that they think generics have no value. That is incorrect. They just think there are other things that have more value.[1] In other words, they prefer a different set of trade offs than you do. I don't see how this could be reasonably considered "denial." [1] - http://research.swtch.com/generic

That link has been debunked over and over and over.

Why keep posting it? As you have seen in this thread, many people avoid Go not because it's not a very good language, but because of the way Go people deal with language problems and can't admit issues.

Being dishonest will just alienate even more people.

Re: Channels Are Not Enough

#148

Post by shadowmint »

burntsushi wrote: post #126
shadowmint wrote: post #92

Earlier quoted context omitted.

I am unsurprisingly frustrated with Go because I prefer more expressive languages, fwiw. (...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go frustrating; and it's not surprising what so ever that this is the case)

> I am unsurprisingly frustrated with Go because I prefer more expressive languages, fwiw. So? My point was not to claim the opposite of the OP, it was to point out that the generalization is false. > (...and no, I don't think it's particularly wrong to assert that this is the case for other people too; there's plenty of evidence to support that people find the lack of generics in a fully featured language like go fr…

or perhaps you know, people I know personally?

A majority of all people who use go? Certainly not.

...but consider that if you see lots of people complaining about something, its possibly not because they're all idiots, or pretentious self important HN posers (who certainly do exist).

The key issue being raised in this thread is that the golang community is dismissive of complaints, even when there are lots of them. and there are, quantitatively, lots of complaints.

That doesn't mean go is a bad language; it means its a popular language in the spot light, and its maintainers and community should probably make a bit of effort to be slightly more humble about that, rather than themselves becoming a pretentious 'there no problem here' self agreeing community.

I think thats a very valid concern, worth thinking about.

(and to be clear; I like go, but I dont visit golang-nuts anymore, because of the community there)

Re: Channels Are Not Enough

#149

Post by frowaway001 »

disputin wrote: post #128
spion wrote: post #11

Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…

"...incapable of admitting problems..." From the Go FAQ: Why does Go not have generic types? Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. https://golang.org/doc/faq#generics

If you read the link you posted, you would know why people say that Go devs are incapable of admitting issues.

Re: Channels Are Not Enough

#150

Post by tomp »

nf wrote: post #52
tomlu wrote: post #37

Earlier quoted context omitted.

They refer to the complexity of the compiler and language, not to user code complexity. Any given language has a complexity budget and they wish to expend it elsewhere. (Note that I am in disagreement - I do think generics should be added).

No, that is not what I was referring to. It is definitely user code complexity that turns us away from generics. People tie themselves in knots with generics all the time. Just look at pretty much any mature C++, Java, Scala, etc codebase.

People tie themselves in knots with classes/packages/interfaces/concurrency/computer code all the time. Just look at pretty much any mature codebase at all.
Post reply on HN