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

171–180 of 186 posts

Re: Fearless concurrency with Rust

#171

Post by zzzcpan »

Jweb_Guru wrote: post #169
zzzcpan wrote: post #167

Earlier quoted context omitted.

This is where I disagree and believe that such way of thinking about bugs cannot take us anywhere. Bugs have nothing to do with formal properties of the language. They are the result of people's thinking process. And type system may just as well be the thing someone was dealing with while making his next CVE-worthy mistake.

Factually , Rust's type system guarantees, if consistently upheld, would have eliminated those bugs. Empirically, we know that in typesafe languages like Java, these types of vulnerabilities are far less frequent. These are facts: you cannot "disagree" with them. Even if we assume that people write buggy code at about the same rate in C++ and Rust, as long as the vast majority of Rust code is not inside an unsafe blo…

> Factually, Rust's type system guarantees, if consistently upheld, would have eliminated those bugs.

You are missing my point. It doesn't guarantee to not cause other bugs. And saying that something eliminates some type of bugs is completely misleading, because this is not what matters. It matters to not cause other bugs as well as eliminate some bugs. Which is impossible to guarantee with formal methods. And which is why current academic approach to languages cannot bring us anything, until the whole system changes.

Psychological approach to programming language design is what has to happen. Anything else is broken.

Re: Fearless concurrency with Rust

#172

Post by FreeFull »

zzzcpan wrote: post #171
Jweb_Guru wrote: post #169

Earlier quoted context omitted.

Factually , Rust's type system guarantees, if consistently upheld, would have eliminated those bugs. Empirically, we know that in typesafe languages like Java, these types of vulnerabilities are far less frequent. These are facts: you cannot "disagree" with them. Even if we assume that people write buggy code at about the same rate in C++ and Rust, as long as the vast majority of Rust code is not inside an unsafe blo…

> Factually, Rust's type system guarantees, if consistently upheld, would have eliminated those bugs. You are missing my point. It doesn't guarantee to not cause other bugs. And saying that something eliminates some type of bugs is completely misleading, because this is not what matters. It matters to not cause other bugs as well as eliminate some bugs. Which is impossible to guarantee with formal methods. And which…

It's impossible to eliminate all bugs, no matter what you do. Psychological design will eliminate some bugs but not all. Static type system will eliminate some bugs, but not all. The best you can do is try to eliminate as many bugs as possible, by doing multiple things that give the best returns, given the bugs you're targeting.

Re: Fearless concurrency with Rust

#173

Post by dbaupp »

ngrilly wrote: post #158
dbaupp wrote: post #153

Earlier quoted context omitted.

The compiler reads the source code into an internal AST and manipulates that, never touching the external files again.

Ok, you're right, but we're playing with words here :) I understand the file containing the source code of the generic function is read only once, but I guess the AST of the generic function is processed many times, at least once for each instantiation of the function? And I'd venture in guessing that the biggest cost is in processing the AST and compiling it, not in reading/parsing the source?

It's not playing with words: the parser only runs once, and the processs/reprocessing AST is much faster than interpreting the original source multiple times (e.g. it can be indexed cheaply).

Re: Fearless concurrency with Rust

#174

Post by FreeFull »

Jweb_Guru wrote: post #66
pcwalton wrote: post #60

Earlier quoted context omitted.

Actually, atomics and locks (which are fully supported) are what avoid that issue in Rust. You can't borrow across multiple threads.

You can now with scoped threads, provided that you don't require mutation.

Actually, it's possible to share a &mut into a scoped threat too, and perform mutation through it. It's safe because the &mut only ever exists in one place at a time.

Re: Fearless concurrency with Rust

#175

Post by SamReidHughes »

kibwen wrote: post #161
ngrilly wrote: post #158

Earlier quoted context omitted.

Ok, you're right, but we're playing with words here :) I understand the file containing the source code of the generic function is read only once, but I guess the AST of the generic function is processed many times, at least once for each instantiation of the function? And I'd venture in guessing that the biggest cost is in processing the AST and compiling it, not in reading/parsing the source?

Generating specialized code from a generic AST is in no way analogous to the exponential-time explosion that is the C++ header system, which is what Go is referencing when it says that it has been designed to read each source file only once. All languages with proper module systems have this property (which is to say, basically all languages that aren't C or C++).

> the exponential-time explosion that is the C++ header system

No I don't think so.

Re: Fearless concurrency with Rust

#176

Post by kragen »

copsarebastards wrote: post #73
dilap wrote: post #64

Earlier quoted context omitted.

"Should have done" is a silly phrase to use here -- Rust is attempting to advance the state of the art, Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Perhaps some day we will see a successor language that follows the philosophy of Go using the new stuff we understand thanks to Rust.

> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Well-understood like code generators (go generate)? Were generics not well-understood enough, so they decided to go with something that's well-understood to be a poor solution to the problem?

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 telling my that my varargs are causing heap pollution in my generic static methods. (Which I can suppress, but instead I’m planning to delete those methods.)

Even OCaml, whose approach to parametric polymorphism is worlds simpler than any of the monstrosities mentioned above, just changed its approach by adding GADTs, which I still don’t understand fully despite the best efforts of generous HN commenters.

So I think that, given that Golang/Issue9 decided not to include inheritance, linear types, exceptions, or overloading (even of operators!), in large part because they aren’t well-understood, it’s entirely unsurprising that it decided not to include generics, either.

Re: Fearless concurrency with Rust

#177

Post by fny »

lambda wrote: post #81
fny wrote: post #27

Earlier quoted context omitted.

Never new Rust by Example existed until today actually! You really should link to it somewhere more prominent. I'm fairly far along, but would have loved the example book had I know about it sooner.

It is actually linked to from the front page of http://www.rust-lang.org/ ; it's the "more examples" link under the example. But I guess that's just far enough down to be easy to miss; it's just below the fold on my screen.

Oy: that's just poorly named. I've seen it a million times before, but never would I have thought that "More Examples" would lead to a book.

Re: Fearless concurrency with Rust

#178

Post by copsarebastards »

dietrichepp wrote: post #80
copsarebastards wrote: post #73

Earlier quoted context omitted.

> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Well-understood like code generators (go generate)? Were generics not well-understood enough, so they decided to go with something that's well-understood to be a poor solution to the problem?

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 not understand generics, but that doesn't mean generics aren't well-understood.

This is my core problem with Go: they clearly have no idea what a decent programming language would look like and they're getting undeserved attention becauase of their previous (admittedly impressive) work.

Re: Fearless concurrency with Rust

#179

Post by copsarebastards »

kragen wrote: post #176
copsarebastards wrote: post #73

Earlier quoted context omitted.

> Go was attempting to use only very-well-understood ideas to make a very-well-understood, simple language. Well-understood like code generators (go generate)? Were generics not well-understood enough, so they decided to go with something that's well-understood to be a poor solution to the problem?

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 erroneous warnings telling my that my varargs are causing heap pollution in my generic static methods. (Which I can suppress, but instead I’m planning to delete those methods.)

Just because you don't understand something, doesn't mean that nobody does?

Re: Fearless concurrency with Rust

#180

Post by copsarebastards »

zzzcpan wrote: post #79
copsarebastards wrote: post #72

Earlier quoted context omitted.

> Go has very different design goals than Rust, so very little that Rust does would actually be possible in Go, and vice versa. Oh give this lame argument a rest already. They're both supposedly general-purpose programming languages. Rust shoots for a little lower level than Go, but they can certainly be compared, and the comparisons are valid. > Having a complex type system would cut into compile times (an explicit…

> The fact is, these "idioms and best practices" will not be followed perfectly on projects of any reasonable size if they are not enforced by code. Why would you not enforce them with code? Compiler shall not be an obstacle to a man. We tried enforcing things before, many times. Things got abandoned.

Sophisticated type systems have not been abandoned by any stretch of the imagination.

We tried static code generators before, as well as linters and static code analysis on untyped code, and those have pretty well been proven to be ineffective. All of which are supposedly "new innovations" in Go. So if you want to defend Go that's not an approach you can really take.

Post reply on HN