Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

101–110 of 474 posts

Re: Rust is mostly safety

#101
post #66
post #7

Earlier quoted context omitted.

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…

Three deaths from the Therac-25: https://en.wikipedia.org/wiki/Therac-25.

Re: Rust is mostly safety

#102
post #66
post #7

Earlier quoted context omitted.

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…

Errors in the software of the radiation therapy machine Therac-25 directly lead to the death or serious injury of six patients. Three patients died within weeks or months. http://radonc.wdfiles.com/local--files/radiation-accident-th...

Errors in the software of a MIM-104 Patriot resulted in failure to locate and intercept an incoming missile and the death of 28 soldiers. http://www.gao.gov/products/IMTEC-92-26

Errors in the software of a Chinook helicopter may have lead to a crash that killed 29 people. http://www.publications.parliament.uk/pa/ld200102/ldselect/l...

Errors in the software of Toyota's throttle control system may have lead to the death of 89 people. https://betterembsw.blogspot.ch/2014/09/a-case-study-of-toyo...

More: http://www.baselinemag.com/c/a/Projects-Processes/Eight-Fata...

Re: Rust is mostly safety

#103
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?"

Even by solving safety, erros in software will still happen. The software errors cited are much more about bad engineering, something that can't be solved by safety only.

Re: Rust is mostly safety

#105
post #63

Earlier quoted context omitted.

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

I agree, but people seem to feel that their code should somehow be exempt from such advice, and so sacrifice safety for performance. This leads to today's sorry state of affairs.

Re: Rust is mostly safety

#106

Earlier quoted context omitted.

Go doesn't protect you against race conditions, it merely offers some concurrency tools. There is nothing to declare ownership of objects in memory. So the compiler doesn't (can't) complain if you share memory and access it simultaneously. At best, there are runtime checks. Rust does offer compiler protection against that. Edit: "merely", relatively to Rust :) on an absolute scale, still way better than C for concurr…

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…

Data races definitely happen in the real world and they are awful to track down, because they only happen n% of the time. All of my least favorite bug-fix experiences have been data races.

Re: Rust is mostly safety

#107
post #40
post #32

Earlier quoted context omitted.

> 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 is the language in the LXC, Docker, containerisation space.

Which is something I never understood. Since you are mainly wrapping OS API, why not take a higher level langage ?

Re: Rust is mostly safety

#108
post #82

Earlier quoted context omitted.

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…

It's also worth noting that you're a bit less likely to see rust users because the kind of software that wants rust instead of golang tends to be the kind that gets written by a large company with deep pockets and a preference for closed source repositories.

If only Go was useful in building closed source products. Google must not have gotten the memo about Rust yet.

Re: Rust is mostly safety

#109
post #65

Earlier quoted context omitted.

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.

This article has been unanimously qualified as FUD by the Rust user community. Nightly is for innovations and experimentations, not for real use :

- Rocket is an amazing example of innovation, but it's currently just an experimentation.

- Serde works on stable for a long time but they experimented a more ergonomic version on nightly. They iterated upon it with Rust developers to create a new and well thought stable API which will land in the next version of Rust (macro 1.1 in february).

Rocket is likely to follow Serde's path during 2017 and will eventually work on stable in 2018. Building a great langage takes time ;)

Re: Rust is mostly safety

#110
post #94

I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community. Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage. I have never seen a more disciplined and bal…

I absolutely agree.

If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature.

But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tasks, but it needs more than that to be on-par with the other languages. And Rust's got plenty of things going for it, so there's nothing wrong with stopping to play the safety card (since that is expected anyways) and painting Rust as a language that is actually fun to work with.

Post reply on HN