Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

Post reply on HN
Print view View original

61–70 of 474 posts

Re: Rust is mostly safety

#61

Post by ekidd »

nordsieck wrote: post #46
steveklabnik wrote: post #34

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.

There are really only two popular Rust libraries that use unstable features:

1. serde, the best serialization/deserialization library. This works on stable now using the `serge_codegen` crate and a custom `build.rs` script. This will Just Work on stable with no extra setup once Macros 1.1 lands, theoretically in about 5 weeks. But I'm using it on stable now in a half-dozen projects, thanks to a `build.rs` script.

2. Diesel, the high-level ORM library for Rust. This works on stable using a `build.rs` script, and 90% of it will work on stable without the `build.rs` script once Macros 1.1 ships.

There are a few other experimental libraries like Rocket (which looks very slick) that only work on nightly Rust. But I don't think any of them are particularly popular yet.

Personally, I maintain something like two dozen Rust crates and applications, and only two use nightly Rust. Both need Macros 1.1, which should be on stable in about 5 weeks.

Re: Rust is mostly safety

#62

Post by steveklabnik »

SomeStupidPoint wrote: post #54
steveklabnik wrote: post #34

Earlier quoted context omitted.

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?

I wrote this out yesterday: https://news.ycombinator.com/item?id=13267399

Re: Rust is mostly safety

#63

Post by moxious »

Ar-Curunir wrote: post #12
koja86 wrote: post #6

In case you missed that there's a big disillusioned C++ crowd out there. Just hear the pain: https://news.ycombinator.com/item?id=13276351 And some of them are watching you with great interest.

And there's a tired security crowd watching Rust with great hope; C++ and C have created innumerable security holes at the expense of "convenience". Cryptographic libraries, codec libraries, image conversion libraries, OS kernels, sandboxes, virtual machines, browsers, (the list is endless) have all suffered glaring security holes from the lack of memory hygiene afforded by C and C++. Any time your code takes in untr…

> Any time your code takes in untrusted input, it should not be written in an unsafe language.

So basically just about all programs, all of the time?

https://www.owasp.org/index.php/Don't_trust_user_input

Re: Rust is mostly safety

#64

Post by SloopJon »

lmm wrote: post #32
geodel wrote: 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. Citation? I see a lot of people talking about both, but not very many public projects in either. Rust at least has a "killer app" on the way in the form of Servo, whereas I haven't heard of any user-facing programs in Go.

FWIW, Go and Rust are 16 and 43, respectively on the TIOBE index:

http://www.tiobe.com/tiobe-index/

A Github search turned up 2,658 Go repositories with more than 100 stars:

https://github.com/search?l=go&q=stars%3A%3E100&type=Reposit...

compared to 348 Rust repositories:

https://github.com/search?l=rust&q=stars%3A%3E100&type=Repos...

Notably, Docker has more stars than Go itself.

Edit: you may also be interested in IEEE Spectrum's interactive list of the top programming languages:

http://spectrum.ieee.org/static/interactive-the-top-programm...

With the default parameters, Go and Rust are 10 and 26, respectively.

Re: Rust is mostly safety

#65

Post by kebolio »

steveklabnik wrote: post #51
nordsieck wrote: post #46

Earlier quoted context omitted.

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 t…

> Most people use stable Rust.

However, many popular or important libraries like Serde or Rocket require the use of nightly. I recall the article a very short while ago on the front page that noted how Rust has effectively diverged into two languages, stable and nightly.

Re: Rust is mostly safety

#66

Post by moxious »

ragebol wrote: post #7
jMyles wrote: 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?"

Well, if no one is tracking it, there is no count and that would thus be countless. But in all seriousness, I am curious about this as well.

It's not "countless" it's "uncountable" because we couldn't agree on what a software caused death was.

In my CS program we had an ethics class that included stories of bad X-ray machine software that overdosed people. Bad, bad bad. I don't think many people died as a direct result, but 10 years later there was probably a spiked cancer incidence. Did software kill people? Well yeah....kinda.

In airplane systems, there have been a number of cases where bad alerting / warning systems basically either misled the pilot or lulled them into a false sense of security prior to events that caused crashes. Did software kill people? Uhm, yes, I think, sort of, but not directly?

It's only when we get fully sentient AI that arms itself and decides to clean up the human pestilence that we'll be able to draw a straight line there. :)

Re: Rust is mostly safety

#67

Post by pjmlp »

staticassertion wrote: post #58
yjftsjthsd-h wrote: post #26

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.

GC was dropped from the Ada2005 standard, because no Ada83 compiler ever implemented it.

Ada provides more ways to automate memory management, though.

Controlled types are Ada's version of RAII, used for arenas and smart pointers.

Also in Ada you can dynamically allocate everywhere, so a common pattern is to use a subroutine parameter to do stack allocation. If it fails, by throwing an exception, recall the subroutine with a smaller size.

Re: Rust is mostly safety

#68

Post by pjmlp »

stymaar wrote: post #57
geodel wrote: 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/7d7c6a97f815e…

Well, Go is Limbo with some Oberon-2 touches.

Re: Rust is mostly safety

#69

Post by geodel »

lmm wrote: post #32
geodel wrote: 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. Citation? I see a lot of people talking about both, but not very many public projects in either. Rust at least has a "killer app" on the way in the form of Servo, whereas I haven't heard of any user-facing programs in Go.

Go: https://github.com/golang/go/wiki/GoUsers

Rust: https://www.rust-lang.org/en-US/friends.html

Without counting Go usage roughly looks 10 times more than Rust.

Re: Rust is mostly safety

#70

Post by moomin »

camus2 wrote: post #28
VexorLoophole wrote: post #19

Earlier quoted context omitted.

As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production. Sure thing, some applications need to be safe-super-safe. But is it worth to switch over from go to rust as a beginner, since go is the unsafer language? I know, that there is no ultimate language. But i always asked myself i am missing a poi…

> i am always asking myself, how often "little" things like race conditions break something in production It can basically corrupt the whole program. I bet half go apps out there have data race. People who boast about Go's simplicity can't even see the elephant in the room. A simplistic type system doesn't fix unsafe concurrency. You'd think that safe concurrency would be an important design goal for a highly concurr…

Speaking as an experienced programmer: all the time, in subtle ways, sometimes that you don't notice for a long time. Sometime benign, sometimes your data has been being corrupted for months before you notice.

My standard advice on concurrency is, quite simply, don't. It always looks way simpler than it actually is. If you're doing something that _requires_ it, get all the help you can. Type-level enforcement sounds _excellent_ to me.

Post reply on HN