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

61–70 of 224 posts

Re: Channels Are Not Enough

#61

Post by xixixao »

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…

> A similar problem with CoffeeScript (conflation of declaration and assignment + scope rules)

That's an issue you simply cannot fix in CS, you need a new language/fork (not having var/let is at the heart of the language's syntax). I wouldn't compare it with Go's lack of generics.

Re: Channels Are Not Enough

#62

Post by rdtsc »

spion wrote: post #30
enneff wrote: post #29

Earlier quoted context omitted.

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

I think that the "complexity" cost of generics is overstated, really. Can you explain how generics make user code more complex?

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 compilation and or runtime. Java, C++ and other code compiles slower. Is it because those languages are stupid and slow and made by idiots? Not necessarily, it is because they have more features. Many added later (with added complexity of keeping backwards compatibility). The fear I think, is if Go gains those new features, its compilation and/or execution speed or claims of simplicity will not hold any more.

Re: Channels Are Not Enough

#63

Post by rdtsc »

zak_mc_kracken wrote: post #49

Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics, which completely drowns the discussions about Go. As a result, the material on the web about Go has a very high noise/signal ratio, which is unfortunate. Hopefully, the Go team will see this as one more reason to add generics to their language, but until they do that, Go will remain a niche language w…

> Pretty much every article that is posted about Go ends up in a never ending discussion about the absence of generics

Well either a lot of developers there looking at Go code are crazy, whiny and in general unpleasant human beings that like to make others' lives difficult or ... maybe it is a problem worth discussing.

Re: Channels Are Not Enough

#64

Post by djur »

burntsushi wrote: post #48
djur wrote: post #41

Earlier quoted context omitted.

Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own. This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

> but it's unsurprisingly frustrating for people used to more expressive languages Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust. There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how…

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.

Re: Channels Are Not Enough

#65

Post by djur »

nknighthb wrote: post #44
djur wrote: post #41

Earlier quoted context omitted.

Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own. This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

If there's any magic on that list, it's limited to the garbage collector, and to whatever extent it's magic, that magic would vanish if it were based on strict automatic reference counting. The others are conveniences to avoid subtle bugs and millions of developers writing the exact same code in every project. I've mentioned this before, but my experience is that "expressive" is synonymous with "obfuscated". Go helps…

Generics also are a convenience to avoid subtle bugs and millions of developers writing the exact same code in every project. That's precisely what they're for.

Any abstraction can be "magic" to people who don't find it appealing or useful. Go includes some of those abstractions and excludes others, like any language. I don't know of any consistent criteria by which the abstractions Go provides are non-magic and the ones it eschews are magic.

Re: Channels Are Not Enough

#66

Post by atombender »

burntsushi wrote: post #48
djur wrote: post #41

Earlier quoted context omitted.

Go has plenty of "magic": garbage collection, maps, slices, channels, goroutines. It just wants you to stick to the abstractions provided by the language and not create your own. This is fine, it's a design goal of the language, but it's unsurprisingly frustrating for people used to more expressive languages.

> but it's unsurprisingly frustrating for people used to more expressive languages Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust. There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how…

I find your response condescending and hostile, actually. The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people.

People de facto speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.

Re: Channels Are Not Enough

#67

Post by burntsushi »

djur wrote: post #64
burntsushi wrote: post #48

Earlier quoted context omitted.

> but it's unsurprisingly frustrating for people used to more expressive languages Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust. There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how…

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 expressive languages."

Many of your other comments are similarly phrased. The read as if you are privy to some truth that people who like Go do not understand.

Re: Channels Are Not Enough

#68

Post by latch »

sriku wrote: post #57
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).

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.

In the Go FAQ [1], when they list the purpose of the project, the first answer they give isn't about concurrency (as some might suspect), it's:

  "It is possible to compile a large Go program in a few seconds on a single computer."
They've been consistent about this. It's a major design goal and, for some, compilation speed is worth more than support for Generics.

[1] http://golang.org/doc/faq#What_is_the_purpose_of_the_project

Re: Channels Are Not Enough

#69

Post by jordwest »

dkarapetyan wrote: post #10
chimeracoder wrote: post #6

It's funny that OP uses Twitter as the case study at the end. I wrote what was then the first (and think still the only) Go Twitter client library that works with v1.1 of Twitter's API[0]. It implements automatic rate-limiting/throttling behind the scenes, and it returns values of concrete types (not interfaces) ready for immediate use. Keep in mind that, were I to write this again today from scratch, there are a num…

I'm curious to see this general purpose function of yours. You are also addressing a different point than the article. The main point is that patterns like parallel map are impossible to implement in Go in a type-safe manner. This is a valid complaint depending on what is meant by type-safe and at this point the arguments for/against Go usually devolve into name calling and matters of culture. If you could factor out…

It looks like this is the function: https://github.com/ChimeraCoder/anaconda/blob/master/twitter...

This looks like a good example of interface{} used correctly - the consumer of the apiGet function passes in their strongly typed object, which then is handed in to json.Decode. No type safety is lost from the perspective of the consumer, while the json.Decode can operate on any struct type.

Sure this addresses a different issue, but for all the complaints about interface{} I think this is a good use-case.

Re: Channels Are Not Enough

#70

Post by burntsushi »

atombender wrote: post #66
burntsushi wrote: post #48

Earlier quoted context omitted.

> but it's unsurprisingly frustrating for people used to more expressive languages Speak for yourself. I know you certainly don't speak for me. I love Go. I love Haskell. I love Rust. There are things in all languages that frustrate me. I can appreciate the particular trade offs made in each language. Believe it or not, I think the language specifications for both Haskell and Go are things of beauty. It's amazing how…

I find your response condescending and hostile, actually. The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people. People de facto speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.

> I find your response condescending and hostile, actually.

I don't follow. The rest of your comment posits an argument for why you think I was wrong. If you're going to accuse me of being condescending and hostile, then I think you at least owe me the courtesy of explaining why.

> People de facto speak in the form of opinions

I agree.

> and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.

I did not say we should do that.

> The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people.

In a discussion of design trade offs, it is important to distinguish between technical fact and opinion. In language design in particular, it is too easy to conflate these things. This thread, for example, is full of it. (For and against Go, FWIW.)

Post reply on HN