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

161–170 of 474 posts

Re: Rust is mostly safety

#161

Post by steveklabnik »

pron wrote: post #156
steveklabnik wrote: post #138

Earlier quoted context omitted.

We are doing some work like that, but not a ton yet. You need connections to do so, in my experience, and that's tough.

Doesn't Mozilla have good connections? It's not like you're a small, unknown organization.

Rust and Mozilla are two different things, even though a team at Mozilla (myself included) heavily contributes to Rust.

Mozilla is a big place, so that means, in order to take that route, I'd have to figure out how to make connections within Mozilla to know the people who'd know those people. You're right that this might be helpful, but it's not something that happens overnight, that's all I'm saying.

Re: Rust is mostly safety

#162

Post by agumonkey »

I think that safety is often doing small things clearly. When you read about thread safe computing, you end up with many rules FP make impossible. So even it's mostly safety, it encompasses a larger area in disguise.

Re: Rust is mostly safety

#163

Post by alkonaut »

Its the safe and performant that attracts me.

If you look at Rust from C then the point is safety, but if you look at it from the other direction, e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) but without the GC and heap overhead.

Re: Rust is mostly safety

#164

Post by now »

steveklabnik wrote: post #93
Annatar wrote: post #89

Earlier quoted context omitted.

ANSI Common LISP lives up to that standard. POSIX AWK lives up to that standard. C's versioning lives up to that standard. ksh93 lives up to that standard. All of those are backward compatible, and can churn through older versions of their own syntax with no problem. But that's not the point, and you know it: the point is you guys were hacking like crazy, without any engineering. That's why the syntax of Rust is insa…

> C's versioning lives up to that standard. C has introduced breaking changes into newer versions of the standard. I don't know as much about ANSI Common Lisp or AWK. By "formal" spec, that depends; do you mean "a spec", or "a spec proven with formal methods"? The latter is undergoing work at various universities. The former doesn't exist yet, but is a goal of next year, and we've already taken some steps towards hav…

Out of interest, what breaking changes have been introduced to C in C99 and C11 (I’m assuming we’re using C89 as a baseline) beyond changes in corner cases in tokenization due to the introduction of “//” comments (and perhaps the removal of gets)?

Re: Rust is mostly safety

#166

Post by robohamburger »

kincardine wrote: post #159
dom0 wrote: post #134

Earlier quoted context omitted.

> In my opinion Rust is about doing things right. On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.

I'm sorry your comment has gotten the response it has. The looming dark cloud of stable vs. nightly only looks like a dark cloud to those outside the Rust community. The article that made its way up Hacker News awhile ago ( https://news.ycombinator.com/item?id=13251729 ) got pretty much no traction whatsoever in the Rust community.

I have found the split has only gotten better with time. It used to be most package maintainers assumed you were using nightly/beta. The last holdouts I see are diesel and serde which have instructions for using nightly. Even then they realize no one wants to ship code on nightly so they provide directions for making a building using stable rust. Once the procedural macros stuff is stabilized they can stop.

I have been extremely pleased with the rust community and the rust maintainers.

And no I was not paid by them to say this... :)

Re: Rust is mostly safety

#167

Post by zzzcpan »

iopq wrote: post #152
zzzcpan wrote: post #55

Earlier quoted context omitted.

> 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?

No, because if you explicitly converted to another type, that's what you wanted.

Sometimes you want it to be lossy, but not most of the time, and yet there is no choice. I had a bug caused by that, that's why I remember it. Silent explicit type conversions are essentially unsafe.

Re: Rust is mostly safety

#168

Post by nercury »

rcthompson wrote: post #122

I think Rust is mostly about safety in the same way that skydiving is mostly about safety. 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. (I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier th…

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 moved in any way in memory while this is happening.

While it is certainly possible to do this in C and C++, the development cost there is way higher. In C++, one would be sensible to stick to a slower version that copies and allocates data, unless he/she is really sure that the need for performance justifies the code complication.

Meanwhile, juggling the references this way in Rust is common and almost sloppy: the hashmap contains references to strings because it was probably created from iterator that iterated over references. The developer might not even need to notice it unless the string reference in result might be kept around longer than original. The compiler will tell about the type mismatch, and the developer will then create a new string from the reference, and then he/she will move on.

There is a similar story when such code needs to be refactored. The word "sloppy" still works here, but in a good way: offloading "being very, very careful" stuff to compiler is deliciously fun.

Re: Rust is mostly safety

#169

Post by wyager »

alkonaut wrote: post #163

Its the safe and performant that attracts me. If you look at Rust from C then the point is safety, but if you look at it from the other direction, e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) but without the GC and heap overhead.

> e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more)

As a big rust fan, I wouldn't go that far. You can offload a lot more work to the type system in a language like F# or Haskell. Rust is very safe from e.g. a memory perspective (excepting unsafe operations), but there are additional levels of assurance you can get by aggressively forcing the type system to catch logic errors for you that you can't really do in Rust.

As for performance, I agree, although a more accurate description would be that it's much easier to get C-level performance with Rust code while you have to put in some more effort to get it in any high-level functional language.

Re: Rust is mostly safety

#170

Post by curun1r »

tomjakubowski wrote: post #29
raverbashing wrote: post #18

Rust is great, however the safety aspect gets in the way sometimes The right granularity for error handling is important, as well as making it easy to handle (abort? providing a default value? doing something else?) It's not that it is not important, but code usability is important as well, lest it goes on the way of C++ hell (though I don't think it can get that bad, there are some warts - like "methods" and traits)

> The right granularity for error handling is important, as well as making it easy to handle (abort? providing a default value? doing something else?) Option and Result achieve just about the best level of granularity I could imagine for error handling. Suppose you're trying to fetch a value from a map (use case for Option ), or read some value over some fallible I/O stream (use case for Result ). Want to abort if th…

I can see Option and Result irking people who don't want to embrace a more functional (programming) mindset. They can be kind of a pain to deal with procedurally without the and_then, or_else, map and such. The new '?' construction will definitely help with this.

The appeal of exceptions, to me, has always been that they allow you to largely separate your error handling from your procedural logic since the catch block can usually go at the end of the method/function and can usually be written later. This means you can write and test code and then come back and handle error conditions after you've gotten the success path working. Option/Result force you to at least acknowledge the possibility of an error at the point when you're writing your logic. Whether that's ?/try!, .unwrap(), a match or writing in a more functional manner, error handling can't literally be an afterthought the way it is with unchecked exceptions.

I'm not arguing that this is a bad thing, and it may be a push in the right direction for many programmers. But it's still a push and many don't enjoy being pushed.

Post reply on HN