3 ms·

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "

by sidlls 10y ago

I'm sorry, I have plenty of gripes about the Rust team touting safety as much as they do but your comment just misses the mark, in my opinion. To begin with, "safety" isn't solved by just using const. It simply isn't feasible to write safe code in C without restricted feature usage to the point of being crippled. It's much easier in C++, but requires an incredible level of focus and "cruft constructs" like ' 'const &' and such. Arguably until move semantics were standardized with C++11 it was a challenge to write safe code. I will agree that Rust's developers have perhaps come down too far on the side of "YOU ARE DOING SOMETHING DANGEROUS BY USING A POINTER." But I think you're exaggerating a bit about how hard it is.

dreta 10y ago
My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.
- sidlls 10y ago
  I haven't, either. I've come across plenty that would save me from having painful gdb sessions to fix code inexperienced (or lazy) developers write.
- Manishearth 10y ago
  Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It prevents memory safety bugs.
  - sidlls 10y ago
    > nor does it claim to be. "It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it. Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things. Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.
    - Manishearth 10y ago
      > But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it. While you may be right, I have never seen this happening (and I participate a lot in online discussions about Rust); people seem to be very careful about saying that Rust prevents memory safety bugs, not bugs in general. People do say that the type system _helps_ prevent general bugs, but that's only to the extent that any similar or more powerful type system (Haskell, xML, etc) can. > Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things. I mean, yeah. No language can (unless it avoids FFI entirely). See https://news.ycombinator.com/item?id=12877136 https://news.ycombinator.com/item?id=12877136 Rust gives you the tools to prevent yourself from doing unsafe things (and still be able to write software). You can get a lot of stuff done in safe Rust. When you need to drop down to unsafe Rust, you can design safe abstractions around the unsafe code, and manually verify the safety of the abstraction. This has a human component, so it's not perfect, but it's pretty close :) The unsafe feature isn't just there for explicitness, it is designed to provide the ability to do this -- the ability to design safe abstractions. > for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. Designing an operating system low level enough? There are a bunch of initiatives to write an OS (both serious and as a learning project) in Rust. As far as I've seen, all of them avoid unsafe code like the plague and design safe abstractions around everything so that they only need a smattering of unsafe code. os.phil-opp.com has a bunch of blog posts on OS design in Rust, some of which explicitly demonstrate this pattern (e.g. the page table one). When you say "When one uses exclusively (or almost exclusively) the "memory safe" features of the language", you're talking about basically the entire target audience of Rust, and this includes low level users. Rust isn't supposed to be used with lots of unsafe everywhere; and folks have tried hard to make it so that this isn't necessary even for low level applications (the Zinc project, while no longer maintained, is an example of this for embedded software). Of course there are areas where you'll be using more unsafe code than others, but you're still supposed to be "almost exclusively" using safe Rust code. If you need unsafe everywhere for your low level application then that's something you should bring up with the Rust community. (To be clear, the Rust ecosystem and language right now has some issues that crop up in low level development, but these are being worked on) In fact, there is only one place where I've seen unsafe code being sprinkled around liberally, and that's when binding to a C/++ library. Currently my job involves a lot of this, and I'm trying to make it safer (largely succeeding!), but it's still has a higher density of unsafe code than, say, Phil's Rust OS (or I think Redox, but I haven't looked at that in a while). In this case, though, you're already talking to C/++ and there's inherent unsafety there (plus an impedance mismatch), so you can't always blame Rust for it :) ------ I guess you're right that "Rust prevents memory safety issues" isn't 100% accurate because `unsafe` exists. "Rust gives you the tools to prevent memory safety issues" might be more accurate, but still misses nuance. I think for a soundbyte on Rust it's accurate enough to say (because it prevents these issues more or less as much as possible without being useless for writing software), but it's a caveat that we should probably mention more.
xenadu02 10y ago
Supposedly Swift 4 is introducing an optional borrow-checker. Types can opt-in and you get the same kind of lifetime guarantees and semantics as Rust. If you don't opt-in you get copying for value types and reference counts for reference types. I'm curious how either approach will work out in the long run. I understand why Rust made the decisions it did wrt ditching built-in GC/non-GC support but it will definitely hamper its adoption for writing GUI applications. If Swift manages to thread the needle in supporting systems-level / kernel programming with borrow-checked types while not imposing that mental and maintenance cost on GUI apps it will be an amazing thing. In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.
- pjmlp 10y ago
  > In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT. Check Modula-2, Oberon, Component Pascal, Modula-3, Eiffel, Ada, Delphi... It was a mistake to have Java and .NET go JIT only on their first days, instead of AOT/JIT from day one. They are finally steering the boat in the right direction, but it will take a couple of years, assuming they don't loose focus.

by sidlls 10y ago

dreta 10y ago

My point was that i haven’t come across a Rust feature i felt would save me from creating a bug.

sidlls 10y ago
I haven't, either. I've come across plenty that would save me from having painful gdb sessions to fix code inexperienced (or lazy) developers write.
Manishearth 10y ago
Rust isn't a panacea, nor does it claim to be. It doesn't prevent bugs. It prevents memory safety bugs.
- sidlls 10y ago
  > nor does it claim to be. "It" doesn't do anything. But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it. Besides, right now a lot of the "memory safety" of Rust has much more to do with selection bias (it is used primarily by people who are explicitly interested in using its safety features). When one uses exclusively (or almost exclusively) the "memory safe" features of the language, of course things implemented in it will be free of "memory safety" bugs. Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things. Here's how I see Rust: it's far and away already superior than C++ for a certain class of systems application programming (e.g. performant desktop/native application code that sits at the systems boundary). Rust code that seriously competes with C or C++ for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. If it gains traction "in the wild," my prediction is we'll start seeing plenty of "memory safety" bugs in that area. The question then is how easily they're spotted and rectified.
  - Manishearth 10y ago
    > But some of its fans conflate "prevents memory safety bugs" with "panacea", at least by implication, as I perceive it. While you may be right, I have never seen this happening (and I participate a lot in online discussions about Rust); people seem to be very careful about saying that Rust prevents memory safety bugs, not bugs in general. People do say that the type system _helps_ prevent general bugs, but that's only to the extent that any similar or more powerful type system (Haskell, xML, etc) can. > Rust helps make doing unsafe things explicit. It doesn't prevent one from doing unsafe things. I mean, yeah. No language can (unless it avoids FFI entirely). See https://news.ycombinator.com/item?id=12877136 https://news.ycombinator.com/item?id=12877136 Rust gives you the tools to prevent yourself from doing unsafe things (and still be able to write software). You can get a lot of stuff done in safe Rust. When you need to drop down to unsafe Rust, you can design safe abstractions around the unsafe code, and manually verify the safety of the abstraction. This has a human component, so it's not perfect, but it's pretty close :) The unsafe feature isn't just there for explicitness, it is designed to provide the ability to do this -- the ability to design safe abstractions. > for "low level" systems programming is going to have to make use of plenty of Rust's "unsafe" constructs. Designing an operating system low level enough? There are a bunch of initiatives to write an OS (both serious and as a learning project) in Rust. As far as I've seen, all of them avoid unsafe code like the plague and design safe abstractions around everything so that they only need a smattering of unsafe code. os.phil-opp.com has a bunch of blog posts on OS design in Rust, some of which explicitly demonstrate this pattern (e.g. the page table one). When you say "When one uses exclusively (or almost exclusively) the "memory safe" features of the language", you're talking about basically the entire target audience of Rust, and this includes low level users. Rust isn't supposed to be used with lots of unsafe everywhere; and folks have tried hard to make it so that this isn't necessary even for low level applications (the Zinc project, while no longer maintained, is an example of this for embedded software). Of course there are areas where you'll be using more unsafe code than others, but you're still supposed to be "almost exclusively" using safe Rust code. If you need unsafe everywhere for your low level application then that's something you should bring up with the Rust community. (To be clear, the Rust ecosystem and language right now has some issues that crop up in low level development, but these are being worked on) In fact, there is only one place where I've seen unsafe code being sprinkled around liberally, and that's when binding to a C/++ library. Currently my job involves a lot of this, and I'm trying to make it safer (largely succeeding!), but it's still has a higher density of unsafe code than, say, Phil's Rust OS (or I think Redox, but I haven't looked at that in a while). In this case, though, you're already talking to C/++ and there's inherent unsafety there (plus an impedance mismatch), so you can't always blame Rust for it :) ------ I guess you're right that "Rust prevents memory safety issues" isn't 100% accurate because `unsafe` exists. "Rust gives you the tools to prevent memory safety issues" might be more accurate, but still misses nuance. I think for a soundbyte on Rust it's accurate enough to say (because it prevents these issues more or less as much as possible without being useless for writing software), but it's a caveat that we should probably mention more.

xenadu02 10y ago

Supposedly Swift 4 is introducing an optional borrow-checker. Types can opt-in and you get the same kind of lifetime guarantees and semantics as Rust. If you don't opt-in you get copying for value types and reference counts for reference types. I'm curious how either approach will work out in the long run. I understand why Rust made the decisions it did wrt ditching built-in GC/non-GC support but it will definitely hamper its adoption for writing GUI applications. If Swift manages to thread the needle in supporting systems-level / kernel programming with borrow-checked types while not imposing that mental and maintenance cost on GUI apps it will be an amazing thing. In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT.

pjmlp 10y ago
> In any case it is exciting to see high-level languages with memory safety proving you can have something much better than C without going full-on virtual machine, runtime, and JIT. Check Modula-2, Oberon, Component Pascal, Modula-3, Eiffel, Ada, Delphi... It was a mistake to have Java and .NET go JIT only on their first days, instead of AOT/JIT from day one. They are finally steering the boat in the right direction, but it will take a couple of years, assuming they don't loose focus.