4 ms·

It seems Rust sacrifice too much for the sake of safety. If Swift will evolve to truly cross-platform language, I think it is in the golden middle of safety vs

by zerr 11y ago

It seems Rust sacrifice too much for the sake of safety. If Swift will evolve to truly cross-platform language, I think it is in the golden middle of safety vs usability trade-off (without requiring non-deterministic GC like D).

autoreleasepool 11y ago
I think after about Swift 4.0, if you're writing a native application in [systems language] and you're using Arc/Rc/shared_ptr all over the place you need to seriously take a step back and ask yourself why you're not using Swift. If Swift had structural references (for all intents and purposes in Swift, all structs are value types and all classes are automatically reference counted pointers) and move semantics Swift would absolutely kill it. It's an exciting time to be a PL nerd.
- kibwen 11y ago
  I'm a Rust fan, but I'll still be excited if Swift manages to add some sort of borrow checker to the language in a future revision (C++, D, and Nim have all also at least alluded towards such a direction, but only C++ has made any progress so far). From what I've seen though, I'm still not sure that Chris Lattner has given serious thought to such an addition. I'm waiting for a concrete proposal before getting my hopes up, because Rust had to make put significant effort into tailoring the base language to borrow checking and implementing such an analysis after the fact runs the risk of serious divergence (or worse, breakage) in the ecosystem. (There's also the fact that, as of the hypothetical Swift 4k, none of the library ecosystem will be leveraging the borrow checker and so Rust will still have a substantial head start for people who want thoroughly static ownership.) Other than that I'm a bit dismayed that Swift just punts concurrency to GCD, given how many other new languages make concurrency such a major focus (especially Rust).
gnuvince 11y ago
> It seems Rust sacrifice too much for the sake of safety. Like what? Given the constraints that Rust has, I don't see much that could radically be changed. Little things like the ? operator (equivalent to try!()) can improve the common tasks, but how do you ensure memory safety in the absence of a garbage collector without the programming being explicit about what he wants to do?
pcwalton 11y ago
How is this related to the article? And what, exactly, does Rust sacrifice for safety?
- zerr 11y ago
  > How is this related to the article? The article compares Rust vs C++. No surprise that the [potential] language in the middle of these two extremes is mentioned.... > And what, exactly, does Rust sacrifice for safety? Clarity, usability... Here is Alexandrescu's quick overview of it: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why https://www.quora.com/Which-language-has-the-brightest-futur...
  - pcwalton 11y ago
    I've addressed the "bulging muscle" criticism many times before. Suffice it to say that it has nothing to do with safety and everything to do with a cultural difference between untyped and typed generics. C++ and D use untyped generics, while pretty much every other language in existence, Rust included, uses typed ones. It's a tradeoff, and I think Rust made the right choice. In fact, Rust chose "clarity" and "usability" over the expressive power of C++ and D templates!

by zerr 11y ago

autoreleasepool 11y ago

I think after about Swift 4.0, if you're writing a native application in [systems language] and you're using Arc/Rc/shared_ptr all over the place you need to seriously take a step back and ask yourself why you're not using Swift. If Swift had structural references (for all intents and purposes in Swift, all structs are value types and all classes are automatically reference counted pointers) and move semantics Swift would absolutely kill it. It's an exciting time to be a PL nerd.

kibwen 11y ago
I'm a Rust fan, but I'll still be excited if Swift manages to add some sort of borrow checker to the language in a future revision (C++, D, and Nim have all also at least alluded towards such a direction, but only C++ has made any progress so far). From what I've seen though, I'm still not sure that Chris Lattner has given serious thought to such an addition. I'm waiting for a concrete proposal before getting my hopes up, because Rust had to make put significant effort into tailoring the base language to borrow checking and implementing such an analysis after the fact runs the risk of serious divergence (or worse, breakage) in the ecosystem. (There's also the fact that, as of the hypothetical Swift 4k, none of the library ecosystem will be leveraging the borrow checker and so Rust will still have a substantial head start for people who want thoroughly static ownership.) Other than that I'm a bit dismayed that Swift just punts concurrency to GCD, given how many other new languages make concurrency such a major focus (especially Rust).

gnuvince 11y ago

> It seems Rust sacrifice too much for the sake of safety. Like what? Given the constraints that Rust has, I don't see much that could radically be changed. Little things like the ? operator (equivalent to try!()) can improve the common tasks, but how do you ensure memory safety in the absence of a garbage collector without the programming being explicit about what he wants to do?

pcwalton 11y ago

How is this related to the article? And what, exactly, does Rust sacrifice for safety?

zerr 11y ago
> How is this related to the article? The article compares Rust vs C++. No surprise that the [potential] language in the middle of these two extremes is mentioned.... > And what, exactly, does Rust sacrifice for safety? Clarity, usability... Here is Alexandrescu's quick overview of it: https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why https://www.quora.com/Which-language-has-the-brightest-futur...
- pcwalton 11y ago
  I've addressed the "bulging muscle" criticism many times before. Suffice it to say that it has nothing to do with safety and everything to do with a cultural difference between untyped and typed generics. C++ and D use untyped generics, while pretty much every other language in existence, Rust included, uses typed ones. It's a tradeoff, and I think Rust made the right choice. In fact, Rust chose "clarity" and "usability" over the expressive power of C++ and D templates!