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

111–120 of 224 posts

Re: Channels Are Not Enough

#111

Post by jesstaa »

nine_k wrote: post #105
StandardFuture wrote: post #100

Earlier quoted context omitted.

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.

Machine code duplication is spending a few extra megabytes on perfectly valid, if duplicate, machine code. Source code duplication is a risk of spending an hour, or maybe a day, of developer's time to detect the duplication, change it in concert in several places, with an occasional need of detecting and fixing a subtle discrepancy between the copies. RAM is $0.015 per megabyte. Developer time is $50 per hour.

You could also spend that developer time trying to untangle code reuse between various components, or the more subtle breakages caused by changes that don't account for the expectations of all callers. Code reuse is still a tradeoff.

Re: Channels Are Not Enough

#112

Post by pjmlp »

rdtsc wrote: post #62
spion wrote: post #30

Earlier quoted context omitted.

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

C++ currently compiles slowly due to lack of modules.

Eiffel, Ada, D, Modula-3, Active Oberon, FreePascal, Delphi... enjoy fast native code compilers and do have generics.

Re: Channels Are Not Enough

#113

Post by pjmlp »

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

Because they focus on Java and C++ on their arguments while forgetting other languages.

Re: Channels Are Not Enough

#114

Post by pjmlp »

georgemcbay wrote: post #16
dkarapetyan wrote: post #14

Earlier quoted context omitted.

What exactly do you mean by "magic"? Most of the time when I hear people talk about "magic" they usually mean a theory or abstraction that they don't understand or don't want to understand. Are generics magical in your opinion?

What makes things magical or not (the way I think of magical) isn't about the theory of the feature but rather how they are implemented and how much is hidden from the person using them in terms of code complexity and just overall work being done relative to what they think they did. I'm perfectly comfortable with the "theory of generics", but when generics first came on the scene for C++ back during the time period…

Generics appeared in programming languages with CLU back in 1974 followed by many others, C++ was hardly the first language to get them.

The first version of STL was actually done in Ada.

Don't mistake generics in programming languages with what C++ does.

Re: Channels Are Not Enough

#115

Post by haberman »

zaphar wrote: post #45
haberman wrote: post #40

Earlier quoted context omitted.

> 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. For what it's worth, I have had a similar experience. One time I expressed a personal opinion on G+ about something I don't like about Go personally. A Go fan re-shared this in the Go community and it turned into a debate. https://plus.google.com/+RalphCorderoy/po…

I'll just leave these here: https://groups.google.com/forum/#!msg/golang-dev/ZTD1qtpruA8... https://github.com/clipperhouse/gen I'm sorry you got the impression of that there is a strong bias against admitting problems. I haven't seen that bias at all myself. Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.

> I'll just leave these here

Are these links in relation to generics? Generics weren't the issue I had been posting about.

> Instead I've seen a willingness to look at different approaches to the problem and an unwillingness to compromise the other design goals of the language.

For what it's worth, if the people responding to me had said "yes, what you say is a potential downside of our approach, but we think that the advantages of our approach outweigh the disadvantages," that would have been fine. There would have been no need to debate anything further.

The reason the argument went on is because the Go advocates were dismissing the possibility that my concern had any validity whatsoever.

Re: Channels Are Not Enough

#116

Post by nknighthb »

pjmlp wrote: post #102
apta wrote: post #97

Earlier quoted context omitted.

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.

It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.

It's fine that you don't agree with our tastes, but it would be nice if you could stop coming into every Go thread and being condescending about it.

Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.

Re: Channels Are Not Enough

#117

Post by pjmlp »

nknighthb wrote: post #116
pjmlp wrote: post #102

Earlier quoted context omitted.

It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.

It's fine that you don't agree with our tastes, but it would be nice if you could stop coming into every Go thread and being condescending about it. Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.

Except, I also talk good about Go in what concerns using it to replace C, specially in possible uses for real systems programming in a GC enabled language.

After all, when compared with the first Oberon version, Go only needs a few more primitives in runtime and unsafe, Kernel and SYSTEM in Oberon respectively.

This is what attracted me to the language in first place.

Re: Channels Are Not Enough

#118

Post by ben0x539 »

nknighthb wrote: post #116
pjmlp wrote: post #102

Earlier quoted context omitted.

It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.

It's fine that you don't agree with our tastes, but it would be nice if you could stop coming into every Go thread and being condescending about it. Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.

Look, we gotta keep busy while waiting for the rustc build to finish. :(

Re: Channels Are Not Enough

#119

Post by Svip »

pjmlp wrote: post #107
enneff wrote: post #84

Earlier quoted context omitted.

Implementation complexity is not the issue. The issue is that a programmer needs to understand how the generics model works and how it interacts with every other feature of the language. That makes the language more complicated, which (as you say) leaks into the higher levels. Generics is just one of many features that Go could have, but does not because it makes the language bigger.

Simple languages shift complexity to the programmer's shoulders.

Writing more code is not the same as more complexity. Irritating, perhaps, but not more complexity. A larger language overhead to keep in mind is more complexity.

Re: Channels Are Not Enough

#120

Post by JulianMorrison »

Pxtl wrote: post #42
ufo wrote: post #24

Earlier quoted context omitted.

Correct me if I'm wrong but doesn't the current state of affairs (using Interface{}) have all the downsides of Java's boxing but without any of the type safety?

It reminds me of the wonderful fun days of Java 1.2 - anybody remember how proud Sun was of how everything derived from object so you could use the untyped containers for everything?

The main difference with casting to Object is that you can use type switches or safe casts which return an additional success boolean, to restore type safety quickly after taking the item out of its container. Yes, you can type-test in Java before you type-cast, but it isn't idiomatic, and it isn't syntax.
Post reply on HN