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

341–350 of 474 posts

Re: Rust is mostly safety

#341

Post by dbcurtis »

johnny22 wrote: post #303
dbcurtis wrote: post #291

What about bare-metal options? Is there any development effort in that direction? Most of the C that I do these days is Arm Cortex-Mx work. Realtime cooperative multi-tasking using an RTOS on the bare metal. It seems like Rust would be a great option for that kind of work if the low-level ecosystem were complete enough.

https://github.com/hackndev/zinc is one effort in that vein. I'm not sure what else exists though.

That actually looks very good. They are supporting STM32F4, which is one part I use a lot. I see they are using the GNU linker (and presumeably binutils) which makes total sense. No reason to reinvent all of that, and that tool chain is robust.

Re: Rust is mostly safety

#342

Post by yawaramin »

Manishearth wrote: post #203
nercury wrote: post #168

Earlier quoted context omitted.

Rust safety is ultimately a productivity boost. For example, if I have a big string, I may create a hashmap where both keys and values are references to some portions to that original string. Then, I may pass this hashmap to another function that will transform this hashmap into structs that contain reused portions of those string references. Rust compiler will make sure that the original string is not destroyed or m…

I wrote about this concept a bit in http://manishearth.github.io/blog/2015/05/03/where-rust-real... , with an example of a situation where in Rust I was able to make things work but in C++ I'd be totally terrified and use a shared_ptr or something. I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.

C++ users would say that shared_ptr is the idiomatic way to handle this scenario, and it's no more unsafe than Rust is in general use.

Re: Rust is mostly safety

#343

Post by Manishearth »

yawaramin wrote: post #342
Manishearth wrote: post #203

Earlier quoted context omitted.

I wrote about this concept a bit in http://manishearth.github.io/blog/2015/05/03/where-rust-real... , with an example of a situation where in Rust I was able to make things work but in C++ I'd be totally terrified and use a shared_ptr or something. I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.

C++ users would say that shared_ptr is the idiomatic way to handle this scenario, and it's no more unsafe than Rust is in general use.

Right, but there's a runtime cost associated with it, unlike the borrowed pointer in the rust version. Using shared_ptr is not "toeing the line", it's stepping back from the line in fear you will cross it.

Re: Rust is mostly safety

#344

Post by yawaramin »

zerofan wrote: post #330
dllthomas wrote: post #318

Earlier quoted context omitted.

> I think the safety aspect of Rust appeals to a lot of beginning programmers. Maybe, but it also appeals a lot to many of us experienced programmers who know how hard things can bite us. It's not so much that we can't get things right. It's that it's really expensive to revisit old assumptions when circumstances change, and it's phenomenal to be able to document more of these in a machine-checked way.

Please don't get me wrong - I would take safe over non-safe if everything else were equal. It's just that Rust made many other choices that are worse for me than what's in C++. Also, I think it would be very painful trying to explain some of Rust's features to my coworkers (who are generally very smart, but generally not interested in clever programming languages). > It's that it's really expensive to revisit old ass…

I think it's a misconception to classify type-safety and memory-safety techniques as 'clever', they should be seen as the bread-and-butter of day-to-day coding. To put it another way, Rust's memory safety is no more clever than C++'s smart pointers, the only difference is what people mistakenly believe about the two.

Re: Rust is mostly safety

#345

Post by yawaramin »

ocschwar wrote: post #259
geodel wrote: post #253

Earlier quoted context omitted.

I know and I would also try Rust if I can make some small but useful things at work. But I mostly deal with various combinations of XML, SOAP, HTTP, LDAP etc. Rust does not have anything over Java, which I use currently, in my usecases.

I have to deal with a pre-REST, pre-SOAP XML API, which I would love, love, to be able to handle in Rust. But until Serde-XML is able to deserialize more of that stuff and preferably handle XSDs, I'm stuck too.

Maybe you could call out to a C XML library in the interim?

Re: Rust is mostly safety

#346

Post by theseoafs »

sh_tinh_hair wrote: post #334

Safety stopped here: "curl https://sh.rustup.rs -sSf | sh" So did my interest.

There's nothing stopping you from downloading the script and peeking at it yourself. There's also nothing stopping you from using the many other installation methods available.

Re: Rust is mostly safety

#347

Post by bjz_ »

nickpsecurity wrote: post #313
bjz_ wrote: post #311

Earlier quoted context omitted.

Any idea on what the status of ParaSail is? Seems to have been pretty quiet lately :(

Have no idea. Contacting Taft et al about that and some other things... especially adding Rust's dynamic or concurrency safety to Ada... is on my backlog for now.

I think it's important to continue to do research in this area. I use Rust now because it is a great language with a strong community, tooling, and momentum, in spite of it's flaws and blind spots, but I see it more as a stepping stone to even better, safer, more expressive systems languages. Rust has challenged our preconceptions on what is possible - I think we may be able to push it even further. My preference is to try to move more towards Idris and the lambda calculus, but it would be interesting to see what an Ada-spin on it would look like.

Re: Rust is mostly safety

#348

Post by zerofan »

yawaramin wrote: post #344
zerofan wrote: post #330

Earlier quoted context omitted.

Please don't get me wrong - I would take safe over non-safe if everything else were equal. It's just that Rust made many other choices that are worse for me than what's in C++. Also, I think it would be very painful trying to explain some of Rust's features to my coworkers (who are generally very smart, but generally not interested in clever programming languages). > It's that it's really expensive to revisit old ass…

I think it's a misconception to classify type-safety and memory-safety techniques as 'clever', they should be seen as the bread-and-butter of day-to-day coding. To put it another way, Rust's memory safety is no more clever than C++'s smart pointers, the only difference is what people mistakenly believe about the two.

> I think it's a misconception to classify type-safety and memory-safety techniques as 'clever'

I didn't call Rusts type-safety of memory-safety clever. The clever stuff is lifetime specifications, a multitude of string types, traits as indications to the compiler for move vs copy, Box Ref Cell RefCell RefMut UnsafeCell, arbitrary restrictions on generics, needing to use unsafe code to create basic data structures, and many other things.

If I tried to advocate Rust in my office, many of my coworkers would simply say, "I didn't have to do that in Fortran, and Fortran runs just as fast. Why are you wasting my time?!"

Re: Rust is mostly safety

#349

Post by dbaupp »

keldaris wrote: post #338

As someone looking at this influx of discussion from the point of view of a curious bystander, I can't help but be annoyed by two persistent misconceptions that keep being perpetuated in many statements of this kind. 1) Memory safety is or should be a top priority for all software everywhere. The OP goes so far as to state: "When someone says they "don't have safety problems" in C++, I am astonished: a statement that…

Memory safety is important for everything because it is a prerequisite for any other form of correctness. There's no guarantee that a violation of memory safety will result in a crash, memory corruption is just as possible, resulting in a bad numerical computation or a broken game. It may be that the risk of an actual problematic memory safety violation in numerics/gaming is small enough to not worry, but it is still something to consider.

The rayon library offers similar functionality to OpenMP, including a parallel map/reduce (etc) over a vector, all in safe code for the user.

I believe a operations that allow -ffast-math style optimisations were recently added to the floating-point types, allowing one to specify individual places where reassociation (etc) is OK. This obviously isn't as automatic as -ffast-math, but usually one has only a few small kernels where such things are relevant anyway.

Lastly, two smaller points:

- C++ doesn't do tail call optimisation just as much as Rust doesn't do it. Compilers for both can (and do) perform TCO, the languages just don't guarantee it.

- C++ doesn't do explicit vectorization either, not in the standard. If you're willing to move into vendor extensions then nightly Rust seems somewhat equivalent and does allow for explicit SIMD.

Re: Rust is mostly safety

#350

Post by rcthompson »

zerofan wrote: post #333
rcthompson wrote: post #304

Earlier quoted context omitted.

No, I haven't done any skydiving. After writing my comment, I suspected my analogy might not hold up if I knew more about skydiving. I guess just imagine an abstract form of skydiving where you just need to have fun in the sky and then open your chute at the right altitude, and you'd like to wait as long as you can before opening it. I still think the point is valid, though, even if the analogy isn't.

Fair enough. I'm sorry about calling you out on the metaphor. Instead I'll call you out on the point itself :-) > Having safety features that you know you can rely on allows you to take risks that you normally wouldn't in order to accomplish some really awesome things. Unless you rush to publish a public facing version of your code, I can't see why you'd be afraid to take risks in any language. What's so scary about…

I think it's more like: since you know the compiler won't let you write a buffer overflow, use-after-free, data race, etc., you no longer have to waste time worrying about whether your code might contain such problems, which frees up more mental bandwidth for other concerns. But unlike other languages, you still have confidence that your code will compile to equally performant machine code (e.g. No GC overhead).

The scary thing isn't causing a segfault on your local machine. The scary thing is writing code that could segfault but doesn't do in testing until after you've deployed it publicly. If your compiler rejects code that can segfault, this is no longer a concern. (Or replace segfault with a buffer overflow that leaks your private keys or something equally bad.)

I guess the analogy would be that you can have more fun cavorting across the sky if you knew with 100% confidence that your parachute automatically would deploy itself at the appropriate time (and not a moment sooner).

Post reply on HN