Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

51–60 of 474 posts

Re: Rust is mostly safety

#51

Earlier quoted context omitted.

A little over 18 months ago, 1.0 was released. We've had very strong compatibility guarantees since then.

While that is true, in Go, almost no libraries are written to use non-stable features. This is not the case in Rust.

Right. Go and Rust have completely different development models, so that wouldn't make any sense.

To recap, in Rust, to make additions to the language:

1. Small additions mean make a PR.

2. Big additions mean make an RFC, then a PR if accepted.

3. These PRs go behind a feature flag that lets us track the feature, and only allows it on nightly.

4. People who desire the new feature try it out. (This is what you refer to.)

5. If any issues are found, they're fixed, or, in the worst case, the feature is removed.

6. The feature is made available to stable users, the feature flag is removed, and backwards incompatible changes can no longer happen.

What would be un-healthy is if everyone had to rely on nightly for everything. At the moment, most people use stable Rust. And of the people that use nightly, the largest single feature will be stable as of the next stable release for Rust. But some people are always going to be using nightly features, and that's a good thing: it means that by the time it hits stable, it's already undergone some degree of vetting.

Re: Rust is mostly safety

#52
post #49

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…

> Rust is about decreasing unsafetyness or whatever the correct word for that is. I think the word you're looking for is "safety". Safety is inherently relative and mostly about risk management. There's no such thing as 100% safe by definition.

"unsafety" rather ? ;) decreasing non-safety is not the same as increasing safety. One starts with the assumption that things are safe. The other does not.

Re: Rust is mostly safety

#53
post #5

> countless lives lost I have no doubt that people have had their lives ruined, or even died, as the result of flaws in system programming, but is anyone actually tracking this? Is it "countless?"

Yes as we move forward we should strive for more safety but 'countless lives lost' looks to blame software for that.

I think realistically we need to ask: would it be a better situation if no system program were allowed for lack of safety. Because I think humanity in general is better with existence of unsafe software vs no software exist at all unless it is safe as per rigorous safety standards.

Re: Rust is mostly safety

#54

Earlier quoted context omitted.

To be honest, Rust took so long to stop making breaking changes and stabilize, I sort of tuned out on it -- it was never at a point it made sense to start using. Has Rust actually settled down on some stability?

A little over 18 months ago, 1.0 was released. We've had very strong compatibility guarantees since then.

What constitutes a strong compatibility guarantee?

How many breaking changes happened in the past 18 months?

Re: Rust is mostly safety

#55
post #45

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…

> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your prog…

> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs.

Do you consider silently trimming value during mandatory explicit type conversion a type error?

Re: Rust is mostly safety

#56
post #45

Earlier quoted context omitted.

> The issue with safety is that nothing is really safe. There is a trade-off between safety and expressiveness. Clearly you can always shoot yourself in the foot if your language is expressive enough (like any Turing-complete language). But I think that is beside the point here. This is about eliminating whole classes of errors. A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your prog…

> A good type system (e.g Rust's, Haskell's..) can eliminate all type errors from your programs. It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors. The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language. Especially since the systems we use are often dynamic with changing requ…

> It will eliminate errors related to the use of a given programming language. It will not necessarily avoid systemic errors.

Like I said: It will eliminate a specific class of errors, namely all type errors. Your program will literally not compile if there are any type errors.

> The programming language is only one part of the problem. Safety is a wider issue than just the use of a programming language.

Sure, I don't disagree with that statement. But it's important to recognize that eliminating whole classes of errors is extremely valuable and allows us to focus on the important things.

Re: Rust is mostly safety

#57
post #20

The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.

> Currently Rust is about Go's age but nowhere close in usage.

Rust was released in 2015, it's merely one and a half years old, while Go was released in March 2012.

If you count the inception period of Rust (pre-1.0) you should also count Ken Thompson's and Rob Pike's work at plan9, which doesn't make more sense …

Fun fact: Go's first commit is 44 years old [1] ;)

[1] https://github.com/golang/go/commit/7d7c6a97f815e9279d08cfae...

Re: Rust is mostly safety

#58

I was surprised to see Ada in the list of unsafe languages, since it always was sold to me as being designed for safety. A bit of searching leads me to believe that Ada is better about memory even though it mostly uses types for safety, and better enforcement of bounds on array access should solve overflow issues regardless. Am I missing something?

I believe you have three choices with Ada:

1) No manual memory management, everything is static and you have memory safety

2) Garbage collection, you have memory safety

3) Manual memory management, you lose memory safety

Rust provides memory safety in the case of manual memory management.

Re: Rust is mostly safety

#59
post #37

The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another app…

True, they messed up in their PR a bit with bold claims about safety. It definitely would be better to be careful with the words they use. Like this "safe concurrency" claim sounds really fearless to me, even though I know they mean some guarantees towards thread safety and all that, not actual safe concurrency.

Yes, for instance, it's easy to create concurrent programs that are semantically wrong (in other words inadequate for use) albeit correct in terms of "types" because the coder made an erroneous assumption about determinism somewhere. The type systems that we see nowadays do not help with that.

Re: Rust is mostly safety

#60

I was surprised to see Ada in the list of unsafe languages, since it always was sold to me as being designed for safety. A bit of searching leads me to believe that Ada is better about memory even though it mostly uses types for safety, and better enforcement of bounds on array access should solve overflow issues regardless. Am I missing something?

Ada still requires manual heap management, although it can be mostly automated.

So you might occasionally see the unsafe package being used to deallocate memory, even though there are better ways to do it, e.g. controlled types.

The other point, is that Rust prevents data races via the type system, while you can deadlock Ada tasks if the monitors aren't properly implemented.

Post reply on HN