4 ms·

I think the question is "what is the cost" of the more novel rust safety features? In my experience, the cost is pretty high. When you set Rust next to, e.g.

I think the question is "what is the cost" of the more novel rust safety features? In my experience, the cost is pretty high. When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). That's really my issue with it.

pcwalton 12y ago
> When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. Swift is totally garbage collected: every object is atomically reference counted. (This is necessary for compatibility with Objective-C.) So Swift is essentially in the same category as Go, Java, and most other languages as far as memory management is concerned. Garbage collection is simply not a cost that we wanted to pay with Rust, in order to reach performance parity with C++. > I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. I don't understand "you just promise the compiler that it's safe". Rust prevents you from accessing data in a non-thread-safe way without a mutex or atomics. This is in fact something that just fell out of the memory safety features above and didn't require any extra features: see [1] for an elaboration on this point. > Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). We have been measuring developer cost all along, by writing hundreds of thousands of lines of code in the language as we've been developing it: the Rust compiler is written in Rust, and we've been developing Servo as well. [1]: http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-the-connection-between-memory-management-and-data-race-freedom/ http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-t...
- TazeTSchnitzel 12y ago
  Well, Swift uses reference-counting. There aren't GC pauses, for example.
  - pcwalton 12y ago
    Not to turn this into an argument about definitions, but reference counting is a form of garbage collection [1]—tracing garbage collection is the one that has pauses (but of course has many advantages over reference counting). [1]: http://www.memorymanagement.org/glossary/g.html#term-garbage-collection http://www.memorymanagement.org/glossary/g.html#term-garbage...
    - TazeTSchnitzel 12y ago
      I know it's a form of garbage collection, yes. My point is that it lacks some of the issues that other types of collectors have.
      - pcwalton 12y ago
        It's not just a question of definitions: I wouldn't characterize reference counting as "striking a bargain" at all. RC is just a form of garbage collection, and in its atomic form (like in Swift) it has serious downsides relative to tracing GC. Reference counting helps latency (important in mobile, which is why Apple's choice is defensible) but it pays enormous costs in throughput when compared with tracing (not to mention the problem of cycles), so much so that tracing is usually considered the superior approach unless you have special requirements. Rust's approach of manual memory management is designed to eliminate the tradeoff by allowing prompt reclamation without all the overhead of managing reference counts, which is why it's in a separate category entirely.
- drewcrawford 12y ago
  Swift is not garbage collected in the slightest. ARC is not garbage collection. http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-9.44.43-PM.png http://sealedabstract.com/wp-content/uploads/2013/05/Screen-... Once upon a time Objective-C had a real garbage collector but that temporary interlude has not, nor ever will be supported from Swift. Finally, Swift objects (can be, as compiler decides) laid out on the stack, so unless you have some super sweet stack garbage collection technology you'd like to share with us, they aren't garbage collected. In any case, I don't see what garbage collection has to do with safety or the borrow checker. > I don't understand "you just promise the compiler that it's safe" Perhaps you'd like to read the Rust Book: > When a type T implements Sync, it indicates to the compiler that something of this type has no possibility of introducing memory unsafety when used from multiple threads concurrently. I think "you just promise the compiler that it's safe" is an accurate summary of that feature. > We have been measuring developer cost all along, by writing hundreds of thousands of lines of code in the language as we've been developing it: the Rust compiler is written in Rust, and we've been developing Servo as well. Would you be satisfied if you wrote a language that is productive only for language designers writing web browsers and compilers? Because that is all your measurements prove. I'm telling you, as an intermediate Rust developer doing neither of those things, that I am not sure if I am more productive in Rust or C. Rust is certainly safer, but I am not convinced that safety is worth returning to C-like productivity. Performance is, but I can achieve good performance in Swift. Rust assumes that I value performance and safety equally; e.g. that I am willing to give up productivity for either one. In reality I am only willing to give up productivity for performance. There are some low-hanging safety fruit that I want (like optionals) but the higher-cost fruit like multithread safety I don't want. I think those features are Bad (TM).

pcwalton 12y ago

> When you set Rust next to, e.g. swift, swift is phenominally more productive and similarly performant. And it is also quite safe (relative to C) without having all of the Rust safety features that make me want to kill the borrow checker with a rusty spoon. Swift is totally garbage collected: every object is atomically reference counted. (This is necessary for compatibility with Objective-C.) So Swift is essentially in the same category as Go, Java, and most other languages as far as memory management is concerned. Garbage collection is simply not a cost that we wanted to pay with Rust, in order to reach performance parity with C++. > I really wish Rust walked back on the more esoteric forms of safety (like thread safety, which you can't really verify anyway, you just promise the compiler that it's safe) and it tried to drive a bargain like Swift. I don't understand "you just promise the compiler that it's safe". Rust prevents you from accessing data in a non-thread-safe way without a mutex or atomics. This is in fact something that just fell out of the memory safety features above and didn't require any extra features: see [1] for an elaboration on this point. > Rust really isn't satisfied to adopt the safety features that are "fairly low effort", it wants to break new ground without really measuring developer cost (hard to do since it's not widely used). We have been measuring developer cost all along, by writing hundreds of thousands of lines of code in the language as we've been developing it: the Rust compiler is written in Rust, and we've been developing Servo as well. [1]: http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-the-connection-between-memory-management-and-data-race-freedom/ http://smallcultfollowing.com/babysteps/blog/2013/06/11/on-t...

TazeTSchnitzel 12y ago
Well, Swift uses reference-counting. There aren't GC pauses, for example.
- pcwalton 12y ago
  Not to turn this into an argument about definitions, but reference counting is a form of garbage collection [1]—tracing garbage collection is the one that has pauses (but of course has many advantages over reference counting). [1]: http://www.memorymanagement.org/glossary/g.html#term-garbage-collection http://www.memorymanagement.org/glossary/g.html#term-garbage...
  - TazeTSchnitzel 12y ago
    I know it's a form of garbage collection, yes. My point is that it lacks some of the issues that other types of collectors have.
    - pcwalton 12y ago
      It's not just a question of definitions: I wouldn't characterize reference counting as "striking a bargain" at all. RC is just a form of garbage collection, and in its atomic form (like in Swift) it has serious downsides relative to tracing GC. Reference counting helps latency (important in mobile, which is why Apple's choice is defensible) but it pays enormous costs in throughput when compared with tracing (not to mention the problem of cycles), so much so that tracing is usually considered the superior approach unless you have special requirements. Rust's approach of manual memory management is designed to eliminate the tradeoff by allowing prompt reclamation without all the overhead of managing reference counts, which is why it's in a separate category entirely.
drewcrawford 12y ago
Swift is not garbage collected in the slightest. ARC is not garbage collection. http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-9.44.43-PM.png http://sealedabstract.com/wp-content/uploads/2013/05/Screen-... Once upon a time Objective-C had a real garbage collector but that temporary interlude has not, nor ever will be supported from Swift. Finally, Swift objects (can be, as compiler decides) laid out on the stack, so unless you have some super sweet stack garbage collection technology you'd like to share with us, they aren't garbage collected. In any case, I don't see what garbage collection has to do with safety or the borrow checker. > I don't understand "you just promise the compiler that it's safe" Perhaps you'd like to read the Rust Book: > When a type T implements Sync, it indicates to the compiler that something of this type has no possibility of introducing memory unsafety when used from multiple threads concurrently. I think "you just promise the compiler that it's safe" is an accurate summary of that feature. > We have been measuring developer cost all along, by writing hundreds of thousands of lines of code in the language as we've been developing it: the Rust compiler is written in Rust, and we've been developing Servo as well. Would you be satisfied if you wrote a language that is productive only for language designers writing web browsers and compilers? Because that is all your measurements prove. I'm telling you, as an intermediate Rust developer doing neither of those things, that I am not sure if I am more productive in Rust or C. Rust is certainly safer, but I am not convinced that safety is worth returning to C-like productivity. Performance is, but I can achieve good performance in Swift. Rust assumes that I value performance and safety equally; e.g. that I am willing to give up productivity for either one. In reality I am only willing to give up productivity for performance. There are some low-hanging safety fruit that I want (like optionals) but the higher-cost fruit like multithread safety I don't want. I think those features are Bad (TM).