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

181–190 of 474 posts

Re: Rust is mostly safety

#181

Post by oconnor663 »

childintime wrote: post #175

I think Rust is not about safety, but about reusability. Do you like to take on a dependency on someone's code when it is in C? The answer is: roll your own code. Rust means the end of that. Rust means software that can be written once and used "forever". Thus it enables true open source. In comparison C/C++ pay a mere lip-service, by also giving you, along with the code, lots of reasons to worry. This is the real in…

To be fair to C, I think C's answer here is dynamically linked shared libraries. They have lots of problems, but still they're very widely used. Even Rust programs dynamically link libc by default.

Re: Rust is mostly safety

#182

Post by oconnor663 »

zzzcpan wrote: post #37
bassislife wrote: post #31

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.

The docs are very clear about what safety means, but agreed that the subtleties can get lost in advertising. https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me...

Re: Rust is mostly safety

#183

Post by djsumdog »

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?

Well there is this famous Ada failure:

http://www.math.umn.edu/~arnold/disasters/ariane.html

Although that was not a failure of language safety, but an overflow issue. The software was designed successfully for another rocket, and was reused for a rocket that didn't match the original specification.

Re: Rust is mostly safety

#184

Post by zanny »

krakensden wrote: post #104

What about stack overflows? I heard that rust no longer protects against those for benchmark reasons.

There is a reason Rust has debug and release builds as well to what other commenters have said. In the debug builds there are safeguards against almost everything at performance cost, the way you are supposed to use it is to test your debug builds thoroughly and then you can trust the release builds to be safe because your code doesn't change, the compiler just doesn't insert as many guards.

Re: Rust is mostly safety

#185

Post by stymaar »

VexorLoophole wrote: post #19
nothrabannosir wrote: post #11

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…

I don't know why you are downvoted since your question is legit.

I'll answer given my own experience :

At my former company, we had a websocket-based service that allowed symetric communication between the clients. We had around 10% connection failures, and we thought it was causes by websocket well-known incompatibilities with some network stack, and we had a fallback to ajax polling.

Several month later, someone touched this part of the code and found a data race. After we fixed it, the failure rate dropped to 5%.

Is 5% of failure big ? It depends on your business. In our case it wasn't too bad because we had a backup plan. But if every customer have a 5% chance of application breakage each time he connects, you may have trouble building a big user-base.

Re: Rust is mostly safety

#186

Post by nemo1618 »

blacksmythe wrote: post #157
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. However, Go has been suitable for production projects for several years longer than Rust. Rust sits in a very useful niche not served by other languages, and in steady state will probably be more popular than Go. Go has a very well designed ecosystem. I like it, use it, and am very impressed with everything about it I have seen. However, I don't see use…

Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the Go team has been so conservative re: generics: If they aren't implemented carefully, they could unacceptably complicate the language.

Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.

Re: Rust is mostly safety

#187

Post by jfaucett »

svckr wrote: post #110
agentgt wrote: 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 tas…

IMO the biggest plus for rust is actually cargo. Building, versioning, and sharing modular code is essentially copy/paste in C/C++, and compared to that cargo is lightyears ahead.

I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years to come if ever there.

Re: Rust is mostly safety

#188

Post by djsumdog »

VexorLoophole wrote: post #19
nothrabannosir wrote: post #11

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…

I've had to deal with several race conditions. They're easy to miss and difficult to debug once you have a system that starts scaling up to millions of transactions per day.

Re: Rust is mostly safety

#189

Post by djsumdog »

This is a little off topic, but when I looked at his post I thought, "Wait .. is that LiveJournel?" .. and yes it is apparently. Or at least a fork of it called DreamWidth.

Interesting to see forks of older OSS Perl web apps still in use today.

Re: Rust is mostly safety

#190

Post by nullc »

bluejekyll wrote: post #15
steveklabnik wrote: post #2

I'll probably be writing a slightly longer response post to this later, but for now... EDIT: here it is: http://words.steveklabnik.com/fire-mario-not-fire-flowers I think the core of it is this: > Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it. But you just did! That is, I think "fearless concurrency" is a b…

> I think "fearless concurrency" is a better pitch... I would go a step further, "fearless programming". Though I would hesitate on 'easy'. Rust gives you fearlessness in all the things, but it does mean learning new style and discovering new solutions to old problems. To fully understand 'Send' vs. 'Sync', for example, means really groking the Rust type system. Once you get the type system, then fully utilizing it w…

Making software free of data races and memory safe (assuming you don't use any unsafe code...) is still a long way from being free of serious defects.

Rust is cool enough that it doesn't need to be promoted with excess hype.

Post reply on HN