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

161–170 of 186 posts

Re: Fearless concurrency with Rust

#161

Post by kibwen »

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?

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++).

Re: Fearless concurrency with Rust

#162

Post by chowells »

zzzcpan wrote: post #121
nostrademons wrote: post #116

Earlier quoted context omitted.

Meta-comment: I believe the difference in opinion here (which seems to recur, over and over, and has for decades) is because the job title of "software engineer" actually encompasses many different job duties. For some engineers, their job is to "make it work"; they do not care about the thousand cases where their code is buggy, they care about the one case where it solves a customer's problem that couldn't previousl…

My point was: tools that prevent you from doing things should not do that without explicit permission. Because thinking is hard and any interruption by a tool or a compiler will impose unnecessary cognitive load and will make it even harder, which may lead to a logical mistake. It is much better to deal with the compiler after all the thinking is done, not during.

I'm pretty sure you've never used a language with a good type system then.

You describe a system where you have to keep everything a program is doing that's relevant in your head at once, and when you're forced out of that state, it's catastrophic. You seem to be assuming that's the only way to get productive work done while programming. I happen to know it's not.

If a language has a sufficiently good type system, it's possible to use the compiler as a mental force multiplier. You no longer need to track everything in your head. You just keep track of minimal local concerns and write a first pass. The compiler tells you how that fails to work with surrounding subsystems, and you examine each point of interaction and make it work. There is no time when you need the entire system in your head. The compiler keeps track of the system as a whole, ensuring that each individual part fits together correctly. The end result is confidence in your changes without having to understand everything at once.

So why cram everything into your brain at once? Human brains are notoriously fallible. The more work you outsource to the compiler, the less work your brain has to do and the more effectively that work gets done.

Re: Fearless concurrency with Rust

#163

Post by Jweb_Guru »

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.

> Type safety has nothing to do with software being more reliable or more secure.

It is true that type safety doesn't necessarily mean that software is more reliable and secure (it depends on the type system, the semantics of the language, and a host of other things), but saying it has "nothing" to do with it is incorrect. In particular, preventing undefined behavior certainly has an effect on security, whether or not it's through a static type system. As pcwalton has mentioned on several occasions, something like 50% of critical CVEs in Firefox exploited attack vectors that would have been prevented by Rust's type system.

Re: Fearless concurrency with Rust

#164

Post by vdaniuk »

kjksf wrote: post #134
Pxtl wrote: post #129

Earlier quoted context omitted.

Well, let's also not forget that a big factor in Go's success is Google. Google has much deeper pockets than Mozilla to build a language and infrastructure.

This meme really should die. It has never been true so there's nothing to forget. The number of full-time Rust people paid by Mozilla is roughly the same as number of Go people paid by Google. Mozilla is a wealthy company and while Google is even more wealthy, it doesn't mean that it spends all its money on Go. Both v8 and Dart are staffed with more people and Dart is not taking off the way Go is. People are trying t…

Let's make a small amendment to your simple statement.

>The simple explanation is: people use Javascript because it's a good language. That's the big factor in Javascript's success.

>The simple explanation is: people use PHP because it's a good language. That's the big factor in PHP's success.

Doesn't feel right, does it?

Google and corporate sponsors are incredibly important in building the ecosystem of programming language. Traction may be the single major defining characteristic of language success and one can certainly buy traction with money and influence.

Re: Fearless concurrency with Rust

#165

Post by ngrilly »

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++).

Yes, designing a proper module system and getting rid of the header system is the best way to improve compilation time. But it was not my point. There are other factors impacting compilation time. Look at Scala for example: it has a proper module system, but compilation is still relatively slow, even if better than C++. This is the reason why I'm interested in learning how Rust compiles generic functions, and what is the impact on the compilation time (because the compiler has to generate a version of the function for each possible T), the binary size, and the pressure on the CPU cache (because having many versions of the function makes harder to keep all of them in the cache at the same time).

Re: Fearless concurrency with Rust

#167

Post by zzzcpan »

Jweb_Guru wrote: post #163
zzzcpan wrote: post #157

Earlier quoted context omitted.

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

> Type safety has nothing to do with software being more reliable or more secure. It is true that type safety doesn't necessarily mean that software is more reliable and secure (it depends on the type system, the semantics of the language, and a host of other things), but saying it has "nothing" to do with it is incorrect. In particular, preventing undefined behavior certainly has an effect on security, whether or no…

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.

Re: Fearless concurrency with Rust

#168

Post by Animats »

threeseed wrote: post #141
kjksf wrote: post #134

Earlier quoted context omitted.

This meme really should die. It has never been true so there's nothing to forget. The number of full-time Rust people paid by Mozilla is roughly the same as number of Go people paid by Google. Mozilla is a wealthy company and while Google is even more wealthy, it doesn't mean that it spends all its money on Go. Both v8 and Dart are staffed with more people and Dart is not taking off the way Go is. People are trying t…

But it's true. Google's association is a big factor in its success. It's not the only reason nor likely the biggest now but it was important at least at the beginning. The fact is that every week we hear about new programming languages. Almost none of them end up being widely used. Having someone like Google, Mozilla, Apple, Microsoft etc behind it makes a big difference.

It's not so much that Google promotes Go. It's that Google uses Go internally for production code. Thus, the compiler, and the library modules used for web-type services, are thoroughly exercised, and used by in-house people who can insist that bugs be fixed quickly. It took Go far fewer years to achieve stable libraries than, say, Python.

Re: Fearless concurrency with Rust

#169

Post by Jweb_Guru »

zzzcpan wrote: post #167
Jweb_Guru wrote: post #163

Earlier quoted context omitted.

> Type safety has nothing to do with software being more reliable or more secure. It is true that type safety doesn't necessarily mean that software is more reliable and secure (it depends on the type system, the semantics of the language, and a host of other things), but saying it has "nothing" to do with it is incorrect. In particular, preventing undefined behavior certainly has an effect on security, whether or no…

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 block, Rust still reaps this benefit, because bugs in safe Rust shouldn't cause memory unsafety.

Finally, yes, bugs do have something to do with formal properties of a language. Really. They do. You can prove that software matches its specification, or fulfills certain properties. People have. SeL4 is a thing. Relying on a static type checker means you only need to trust the static type checker to be correct in order to enforce the appropriate properties, not all code written in the language, and "the Rust type checker" is a much smaller kernel to trust, and will be more widely exercised and heavily scrutinized, than "all other Rust code ever written." This is literally the entire point of static type systems.

I apologize, but this is going to be my last response to you, because I don't think we can have a productive conversation about this.

Re: Fearless concurrency with Rust

#170

Post by kibwen »

ngrilly wrote: post #165
kibwen wrote: post #161

Earlier quoted context omitted.

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++).

Yes, designing a proper module system and getting rid of the header system is the best way to improve compilation time. But it was not my point. There are other factors impacting compilation time. Look at Scala for example: it has a proper module system, but compilation is still relatively slow, even if better than C++. This is the reason why I'm interested in learning how Rust compiles generic functions, and what is…

The Rust compiler actually has built-in diagnostics to let you profile the time that each phase of compilation takes. On mobile but I believe that it's `rustc -Z time-passes`, and whenever I use it on my own code 95% of the time consists of LLVM performing codegen. Nearly every other compiler pass takes approximately 0% of the compilation time (coherence checking being the notable exception, for reasons I have the discern).
Post reply on HN