Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

21–30 of 474 posts

Re: Rust is mostly safety

#21

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 would argue that if the Rust project would have just one mission statement, it wouldn't be "create a safe systems programming language". It would be "move towards a world where safe systems programming is the norm".

What's the difference? Both of the statements have the premise that Rust is – and ought to be – a safe systems programming language. However, the latter captures not only the REAL goal, but also the nuances and tensions: while safety is indispensable, we must do something else too, for the programming society to accept the safe tools we are trying to promote. That means ergonomics, that means performance, that means ease of use, that means wide availability – and that might also mean advocation of visions of a better world, which is what this blog post of Graydon's does.

Re: Rust is mostly safety

#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 more safety. They don't need a more pleasant language. Non C/C++ developers don't really need a language with no GC. Now, by "don't need" I absolutely don't mean "won't benefit from". But one of the things we can learn from James Gosling about language design is, don't focus on features that are useful; don't even focus on features that are very useful; focus on features that are absolutely indispensable... and compromise on all the rest. The people behind Java were mostly Lispers, but they came to the conclusion that what the industry really, really needs, is garbage collection and good dynamic linking and that those have a bigger impact than clever language design, so they put all that in the VM and wrapped it in a language that they made as familiar and as non-threatening as possible, which even meant adopting features from C/C++ that they knew were wrong (fall-through in switch/case, automatic numeric widening), all so they could lower the language adoption cost, and sell people the really revolutionary stuff in the VM. Gosling said, "we sold them a wolf in sheep's clothing". I would recommend watching the first ~25 minutes of this talk[1] to anyone who's interested in marketing and maintaining a programming language.

If Rust would only win over 10% of C/C++ programmers who today understand the need for safety, say, in the next 5-10 years, that would make it the highest-impact, most important language of the past two decades. In that area of the software world change is very, very slow, and you must be patient, but that's where Rust could make the biggest difference because that's where its safety is indispensable. A few articles on Rust in some ancient trade journals that you thought nobody reads because those who do aren't on Twitter and aren't in your circle may do you more good than a vigorous discussion on Reddit or the front page of HN. Even the organizational structure in organizations that need Rust looks very different from the one in companies that are better represented on Reddit/HN, so you may need to market to a different kind of people. So please, be patient and focus your marketing on those that really need Rust, not on those outside that group you think you can win over most quickly because they move at a faster pace.

[1]: https://www.youtube.com/watch?v=Dq2WQuWVrgQ

Re: Rust is mostly safety

#23

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 would argue that if the Rust project would have just one mission statement, it wouldn't be "create a safe systems programming language". It would be "move towards a world where safe systems programming is the norm". What's the difference? Both of the statements have the premise that Rust is – and ought to be – a safe systems programming language. However, the latter captures not only the REAL goal, but also the nua…

I really, really like this. Thank you. Well put.

Re: Rust is mostly safety

#24
post #6

In case you missed that there's a big disillusioned C++ crowd out there. Just hear the pain: https://news.ycombinator.com/item?id=13276351 And some of them are watching you with great interest.

Extraordinarily trivial C and C++ submissions see great traction on HN. A recent one -- pointer arithmetic -- saw a bit of confusion about how something so trivial was on here to see the HN zeitgeist argue that it's really because the critics felt so "stupid" from the submission that they had to strike out.

This place is not a representation of low level programmers at all, and sentiments about that realm are usually laughable caricatures as recited by beginners. HN is overwhelmingly junior devs and high level web devs who get amazed by bit shifting and pointer arithmetic.

Re: Rust is mostly safety

#25

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…

It becomes a problem when you're building applications with complex interactions, and is even worse with large codebases that are tough to debug and reason about.

Re: Rust is mostly safety

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

Re: Rust is mostly safety

#27
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.

It might be Go’s age overall from initial inception, but a typical point at which people start paying attention is the 1.0 release. In Go this was March 2012, for Rust it May 2015, over three years later.

Re: Rust is mostly safety

#28

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 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 concurrent language, well apparently it isn't.

Re: Rust is mostly safety

#29

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 the value is missing or an error occurred? Just call unwrap() and ready yourself for (completely safe!) crash reports. unwrap() is just a way to dynamically assert certain invariants.

Want a default value in those cases? Just call or() or or_else() on the Option or Result value you have.

Want to do something else? Use Rust's pattern matching features and branch depending on whether the value was obtained, on conditionals relating to the value (or error), and more!

Re: Rust is mostly safety

#30
Wow, I have to admit I have never seen anything pushed so aggressively here on Hacker News as Rust.

Rust: "everybody who writes in anything but our invention has security holes, but we don't, because we know what we're doing! And although we broke users' programs in the past, we don't do that any more! We're all grown up now! Trust us!"

Post reply on HN