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

91–100 of 224 posts

Re: Channels Are Not Enough

#91

Post by rdtsc »

enneff wrote: post #86
rdtsc wrote: post #62

Earlier quoted context omitted.

I think trade-offs have been made already. If they bring in "generics" they would have to back-pedal and now many in the community would have to in a way refute their previous excuses of why they didn't need generics. ("But I have been arguing on public forums for the last 2 years that generics are not useful, what do you mean we'll now implement generics....") There is also a chance that it will slow down compilatio…

You have it all backwards. We didn't build Go in order to have arguments on a mailing list. And I don't think the people saying "I don't need generics," are lying. I think they actually believe what they say, and I'm sure if we did introduce generics today many of them would say "I think this is a mistake." Yes, the tradeoffs have been made. The language has been designed. It is very unlikely that Go 1.x will see gen…

> And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along.

Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more.

> We didn't build Go in order to have arguments on a mailing list.

Not sure many popular languages were built for that. But arguments on mailing lists is what you get. Quite often the smarter people are, the better they are able to veil things like disappointments, personal dislikes, and others in technical arguments. I have seen it in private meetings and public discussion forums. The inertia of defending something vigorously and then having to back-pedals is unpleasant.

Re: Channels Are Not Enough

#92

Post by shadowmint »

burntsushi wrote: post #67
djur wrote: post #64

Earlier quoted context omitted.

I don't know what in my comment suggests that you can't love both Haskell and Go, but that's certainly not what I meant. Nothing I've said here is anything other than my own observation and opinion. Thank you for the advice. I'll keep it in mind.

> I don't know what in my comment suggests that you can't love both Haskell and Go I quoted it in my comment. You said: "but [Go is] unsurprisingly frustrating for people used to more expressive languages." I'm used to more expressive languages too, but I don't find Go frustrating. Therefore, your statement is false. You probably intended it to read like: "I am unsurprisingly frustrated with Go because I prefer more…

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)

Re: Channels Are Not Enough

#93

Post by eropple »

burntsushi wrote: post #59
eropple wrote: post #55

Earlier quoted context omitted.

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…

> 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 well formed enough that you know you want nothing to do with it, then what is your point exactly?

That I've had more than one long night dealing with an inherited Go application and it sucks and its developers should feel bad.

(OK, the last is mostly facetious. If they can't be bothered to use modern tooling, though, they should be tasked with maintaining their own crap...)

Re: Channels Are Not Enough

#94

Post by echaozh »

eloff wrote: post #83
spion wrote: post #21

Earlier quoted context omitted.

That really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much. In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. 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 pret…

I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.

Re: Channels Are Not Enough

#95

Post by MoOmer »

georgemcbay wrote: post #12

"I want all this Then perhaps Go is not the language for you. There are a lot of design decisions in Go that seem arbitrarily restrictive at first but are there, AFAICT, to (as much as is reasonable) force programmers to write code where what is happening is explicit and obvious without having to dive down into layers and layers of abstraction to find "the magic". This is, IMO, a feature and not a bug, but YMMV.

I pasted this in the gist comments, and I'll reproduce it here from Hoare's Communicating Sequential Processes: [0]

> But the dangers of convenient facilities are notorious. For example, the repetitive commands with input guards may tempt the programmer to write them without making adequate plans for their termination; and if it turns out that the automatic termination is unsatisfactory, reprogramming for explicit termination will involve severe changes, affecting even the interfaces between the processes.

[0]: http://www.cs.ucf.edu/courses/cop4020/sum2009/CSP-hoare.pdf

Re: Channels Are Not Enough

#96

Post by jesstaa »

eloff wrote: post #17
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…

Lack of generics != lack of abstractions. The Go community freely acknowledges that generics are a nice feature, and that lacking them is a pain point of Go sometimes. Although many Go developers will tell you that sometimes turns out to be not that often in reality, which has also been my experience. Rob Pike has outlined the tradeoffs inherent with generics here: http://research.swtch.com/2009/12/generic-dilemma.ht…

That is Russ' blog post, not Rob's.

Re: Channels Are Not Enough

#97

Post by apta »

echaozh wrote: post #94
eloff wrote: post #83

Earlier quoted context omitted.

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. 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 pret…

I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.

Or the fact that I actually saw someone on the mailing list also implement min() incorrectly due to copy-paste :)

> I never thought people will actually come up and defend code duplication.

Indeed. Some of the responses by some Go fans really leave me surprised to say the least.

Re: Channels Are Not Enough

#98

Post by apta »

eloff wrote: post #83
spion wrote: post #21

Earlier quoted context omitted.

That really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much. In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. 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 pret…

> 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 ugly, but programming is not art, it's engineering

Not mutually exclusive. A good language would make incorrect or inefficient code "ugly" or "uglier" than correct code.

> and Go is a language for engineers.

So are languages with generics like C++, Java, Rust, Haskell, etc.

Re: Channels Are Not Enough

#99

Post by notduncansmith »

eloff wrote: post #83
spion wrote: post #21

Earlier quoted context omitted.

That really depends on what you mean by "most of the time". After all, you only write a generics based library once, and you reuse it many times - therefore on the outside it appears that you don't really use generics all that much. In my opinion, depriving a "normal" language user of generics is like depriving a Lisp user of macros. Whatever it is, its definitely not just "bold".

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. 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 pret…

"My editor makes it really easy to do this terrible thing, so it's okay!"

I'm sorry, I quite enjoy many aspects of Go - but the argument that committing one of the cardinal sins of programming is okay because your editor makes it easy is worse than the actual language shortcoming itself.

Re: Channels Are Not Enough

#100

Post by StandardFuture »

echaozh wrote: post #94
eloff wrote: post #83

Earlier quoted context omitted.

I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. 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 pret…

I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.

Now you are shifting to a editing dilemma. Code duplication is not machine code duplication which is what really matters at execution time. Reading is also easier (even for non-Go programmers at least familiar with C) without templating-like syntax.
Post reply on HN