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

Fearless concurrency with Rust

blog.rust-lang.org

Post reply on HN
Print view View original

181–186 of 186 posts

Re: Fearless concurrency with Rust

#181

Post by dragonwriter »

copsarebastards wrote: post #178
dietrichepp wrote: post #80

Earlier quoted context omitted.

Actually, now that you mention it, I think generics are poorly understood in general. C++, Java, and C# have major differences in their approach to generics, but they have similar syntax so most people gloss over the differences. I think doing generics well requires incorporating higher order types, higher kinded types, and other concepts which don't exist at all in the wild west of C++ templates. This clumsy impleme…

Generics are maybe poorly understood by the average programmer, but what I meant with my rhetorical question was that there is a lot of literature and there are a lot of people who understand generics very well. Maybe the creators of Go don't understand generics, but then again, maybe if you don't understand generics you shouldn't be developing a high-profile statically-typed programming language. The Go team might n…

I don't think the Go team has any problem understanding anything. I think they have different subjective goals for a programming language than many critics, which leads to a feature set which includes some things critics would leave out and excludes some things critics would prefer (like generics.)

I think Go has gotten fairly decent traction because there are roles for which real programmers find it reasonably well suited compared to existing alternatives, and I think that, not the previous work of the creators, is what drives attention to it.

OTOH, I think Go's period in the sun is going to be a lot shorter than, e.g., Rust's unless we see a Go 2.x that addresses some of the "not in the Go 1.x timeline" things with Go fairly soon.

Re: Fearless concurrency with Rust

#182

Post by mlitchard »

badsock wrote: post #131
mlitchard wrote: post #100

I can't wait for a mature idris+mature rust. It will be a better world then.

It makes me sad that Idris is (explicitly) never going to be an industrial language - so many nice things in it.

I think it will do just fine as an industrial language, when you have the senior architect being the idris expert. His job will be to write the DSL for the engineers to code in. Idris already has hooks into C and Java and who knows what else by then. It won't work well if you expect to replace your java brigade with an idris brigade. Why would you need one anyway? I wonder if I'm being naive.

Re: Fearless concurrency with Rust

#184

Post by kragen »

copsarebastards wrote: post #179
kragen wrote: post #176

Earlier quoted context omitted.

Code generators like RATFOR, lex, yacc, and the C preprocessor? I think it’s fair to say that those are well understood. Generics like Ada Generics, C++ templates, and Java Generics? I think it’s fair to say that we are only beginning to understand the benefits and drawbacks of that approach to code generation, which is why every time I recompile the Java application I’m currently working on, I get erroneous warnings…

> Code generators like RATFOR, lex, yacc, and the C preprocessor? I think it’s fair to say that those are well understood. Yes, that is exactly what I said in the post you are responding to. > I think it’s fair to say that we are only beginning to understand the benefits and drawbacks of that approach to code generation, which is why every time I recompile the Java application I’m currently working on, I get erroneou…

I guess you didn't understand the problem I was describing. I wasn't saying that the problem is that I don't understand parametric polymorphism, or for that matter its realization via code generation, although I’m sure e.g. Philip Wadler understands those things a whole heck of a lot better than I do. The problem was that the Java language designers didn't understand generics, and accidentally implemented varargs in 1.5 in a way that produced a completely unnecessary and avoidable collision with the parametric polymorphism system (designed by Wadler) that they also introduced in 1.5. And there are a variety of similar problems in various parametric-polymorphism systems, which leads me to think that the problem is not merely that some loser at Sun didn't understand these things (and didn't bother to ask Wadler, who surely could have warned him off the particular stupidity I mentioned) but rather that there is a general lack of understanding of parametric polymorphism.

Re: Fearless concurrency with Rust

#185

Post by copsarebastards »

dragonwriter wrote: post #181
copsarebastards wrote: post #178

Earlier quoted context omitted.

Generics are maybe poorly understood by the average programmer, but what I meant with my rhetorical question was that there is a lot of literature and there are a lot of people who understand generics very well. Maybe the creators of Go don't understand generics, but then again, maybe if you don't understand generics you shouldn't be developing a high-profile statically-typed programming language. The Go team might n…

I don't think the Go team has any problem understanding anything. I think they have different subjective goals for a programming language than many critics, which leads to a feature set which includes some things critics would leave out and excludes some things critics would prefer (like generics.) I think Go has gotten fairly decent traction because there are roles for which real programmers find it reasonably well…

I do agree that the problem relates to language goals, but their poor choices of goals to pursue do demonstrate a lack of understanding. Their stated goals are frequently solutions that don't really address good use cases. Take for example fast compilation time: the stated use case for that goal was compiling Google's massive C++ code base, which took too long to reasonably compile on a dev machine because of template expansions. Refusing to add generics is an idiotic solution to this problem:

1. Generics aren't templates, and are in fact a solution to this problem. They don't expand at compile time. 2. The long compilation times are indicative of deeper problems: an over complicated code base that should be refactored down, and lack of modularity which would allow partial compilation (only compile the changed modules). 3. Removing generics creates new problems with increased bugs and duplicated code. It's trading compile-time for development time, which has historically rarely been a good trade. 4. Even if this is a legitimate concern for Google (which I still don't think it is), it's not a legitimate concern for 99.9% of projects out there. How many projects actually have millions of lines of code that can't be factored down and modularized? If this is really Go's target then they should admit it's a highly specialized language and not a general-purpose programming language, and that most people shouldn't be using it.

Calling these goals "subjective" as if this justifies them is just a smarter-sounding way of saying "That's just, like, your opinion, man." Opinions can be wrong, and the opinions of the Go team are wrong.

Re: Fearless concurrency with Rust

#186

Post by copsarebastards »

zzzcpan wrote: post #157
aikah wrote: post #156

Earlier quoted context omitted.

> Go because it's a good language. Go fits a niche and is good enough, for now. But Go as a language is seriously flawed, and its flaws will become more and more obvious as the language gets more popular. People can certainly understand Go made the choice of "minimalism". But minimalism doesn't mean the language shouldn't have features people really need. The infamous "You don't need that in Go" sentence will not fly…

> that has type safety Actually, there is no need for that. Type safety has nothing to do with software being more reliable or more secure. There is, however, a need in language creators, who understand that large standard library with static binaries and cross compilation are super important in a fast moving world where many different operating systems live together on many different architectures.

> Actually, there is no need for that. Type safety has nothing to do with software being more reliable or more secure.

If you said this to me in an interview I would politely end the interview there and you would not be hired. A high school student with no programming knowledge at least can be taught. If you're confident in what you just said, you're both ignorant and unteachable.

I really can think of no more scathing indictment of Go than this is the thinking of a typical Go user.

Post reply on HN