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

91–100 of 474 posts

Re: Rust is mostly safety

#91

Post by raverbashing »

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…

My criticism might be due to a bit of impedance mismatch, that's for sure

(Or maybe I'm just missing exceptions - because, as an example: I want to read a file and what I care about is getting a fd, anything before that "doesn't matter" and I don't want to care about every step)

On the subject, this page is good for those curious about it https://doc.rust-lang.org/book/error-handling.html

Re: Rust is mostly safety

#92

Post by macintux »

moomin wrote: post #70
camus2 wrote: post #28

Earlier quoted context omitted.

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

If you want to avoid data corruption in concurrent software, there's always Erlang as an option.

Re: Rust is mostly safety

#93

Post by steveklabnik »

Annatar wrote: post #89
steveklabnik wrote: post #44

Earlier quoted context omitted.

No programming language, even C or C++ or Java, lives up to that standard.

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 having it exist.

I'm not going to bother with the rest.

Re: Rust is mostly safety

#94

Post by agentgt »

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 balanced community approach to creating PL. Everything seems to be carefully thought out and iterated on. There is a lot to be said to this (although ironically I suppose one could call that safe)!

PL is more than the language. It is works, community and mindshare.

If Rust was so concerned with safety I don't think much work would be done on making it so consumable for all with continuous improvements of compiler error messages, easier syntax and improved documentation.

Rust is one of the first languages in a long time that makes you think different.

If it is just safety... safety is one overloaded word.

Re: Rust is mostly safety

#95

Post by pimeys »

kebolio wrote: post #65
steveklabnik wrote: post #51

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.

We've been using Rust on production since the summer and we only use the stable compiler.

These "popular or important libraries" are nice use cases what you might be able to do with Rust in future. But relying on them right now and using them in production is not really a good idea.

Re: Rust is mostly safety

#96

Post by steveklabnik »

kebolio wrote: post #86
steveklabnik wrote: post #74

Earlier quoted context omitted.

Serde does not require nightly, though it is nicer to use on nightly. That's the "will be stable as of the next stable release for Rust" I alluded to above. Rocket just came out; I think it's an extremely interesting library, but https://crates.io/crates/rocket shows that it's been downloaded 618 times. It hasn't exactly taken the world by storm yet. I think it shows great potential though! But it's not a good case o…

Over the last year of intermittently dossing around with Rust I encountered the need to use nightly regularly, with various crates refusing to compile (and usually I stopped my experimentation there as my barrier to entry was anything harder than pacman -S rust cargo). Yet I did not know until just now that Serde is moving off a dependency on nightly and it is encouraging that this is a trend with similar libraries;…

If you happen to remember which libraries those were, I'd be interested in hearing about them!

> my barrier to entry was anything harder than pacman -S rust cargo

Today, that also wouldn't be the case: "rustup update nightly" and "rustup run nightly cargo build" or whatever, with extra stuff to automatically switch per directory.

Re: Rust is mostly safety

#97

Post by p0nce »

pjmlp wrote: post #79
pron wrote: post #22

I completely agree. This is what I wrote on Reddit in response to Klabnik's post: Rust can make such an important contribution to such an important slice of the software world, that I really fear that trying to make a better pitch and get as many adopters as quickly as possible might create a community that would pull Rust in directions that would make it less useful, not more. Current C/C++ developers really do need…

The reason why Java lacks a primitive unsigned type is that Gosling asked around at Sun about unsigned arithmetic and almost everyone got it wrong.

Java definately made the best decision here. Sad that we still have to live with unsigned types and the promotion rules.

Re: Rust is mostly safety

#98

Post by jnbiche »

pjmlp wrote: post #60
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?

Ada still requires manual heap management, although it can be mostly automated. So you might occasionally see the unsafe package being used to deallocate memory, even though there are better ways to do it, e.g. controlled types. The other point, is that Rust prevents data races via the type system, while you can deadlock Ada tasks if the monitors aren't properly implemented.

> while you can deadlock Ada tasks if the monitors aren't properly implemented.

It's not clear to me if you're suggesting otherwise, but you can definitely deadlock Rust as well (although it's true that Rust statically prevents data races).

Re: Rust is mostly safety

#99

Post by mtgx »

Even if Rust adds increasingly more "unsafe" features in order to appeal to new developer groups, I agree that it should remain a "100% safe by default language", and they should continuously try to improve the performance of the safe code, rather than get lazy and say developers can just use the unsafe syntax if they want 3x the performance. This would only lead more and more developers to increase the usage of unsafe code. It would be even worse if Rust would allow unsafe code by default for any future feature.

Re: Rust is mostly safety

#100

Post by pimeys »

macintux wrote: post #92
moomin wrote: post #70

Earlier quoted context omitted.

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…

If you want to avoid data corruption in concurrent software, there's always Erlang as an option.

I haven't checked Erlang too well, but is it so that the concurrency in Erlang software is basically actors only? Of course in this space you can also use Akka and even Rust and C++ have actor libraries available.

But there are definitely use cases where you don't want to use actors, where you might want to compose several futures together without the overhead of actor mailboxes.

Post reply on HN