Live data from Hacker News

Rust is mostly safety

graydon2.dreamwidth.org

141–150 of 474 posts

Re: Rust is mostly safety

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

"Current C/C++ developers really do need more safety. They don't need a more pleasant language. "

The number of C++ developers griping in HN threads about language-level problems effecting their work tends to disagree. It's not as if they wanted C++ to be designed that way. It was just only one with big companies' support that had zero-cost abstractions for programming in the large & great compatibility with C libraries. Many would love a better language. Matter of fact, they tell us in Rust threads here.

" Non C/C++ developers don't really need a language with no GC."

They might benefit if the app is aiming for max performance (esp HPC), memory efficiency (eg embedded), or minimal latency (eg real-time. From there, they basically choose among C, Objective-C, C++, or Fortran. Rust has features superior to those in terms of safety & abstractions. On HPC side, Julia is already showing the kind of takeup a language can get if it's faster than Python/NumPy but not C or Fortran.

"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."

I agree. Let's hope it happens. With that on the demand side, we'd also see tools like Frama-C, Saturn, Astree, and so on start popping up for the unsafe part of Rust. On top of a shitload of libraries doing things the safer way since community encourages it. It's really the network effects that matter in programming languages. I think Rust might have good, network effects if it takes off.

Re: Rust is mostly safety

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

And there's a tired security crowd watching Rust with great hope; C++ and C have created innumerable security holes at the expense of "convenience". Cryptographic libraries, codec libraries, image conversion libraries, OS kernels, sandboxes, virtual machines, browsers, (the list is endless) have all suffered glaring security holes from the lack of memory hygiene afforded by C and C++. Any time your code takes in untr…

There's also the tired sysadmin crowd who are tired of rebooting thousands of hosts for kernel, shell, libc, etc. patches. And tired of patching web, mail, dns, etc servers. I'm sure there are really smart C and/or C++ developers out there that never make mistakes but I've spent a large part of my career patching/upgrading really smart peoples code.

For me, safety is the killer feature in Rust. It's also exciting because it brings systems level programming to a new generation of programmers without all the risk.

Re: Rust is mostly safety

#143
post #134
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…

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

How so? Most big projects have both stable releases and nightly builds that contain unfinished features. Why is it particularly troublesome for Rust?

Re: Rust is mostly safety

#144
post #134
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…

> 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 am not sure it's really a split when you can build stable on nightly. Nightly is great for experimentation.

Re: Rust is mostly safety

#145

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 the problem is that Graydon is better at technology than marketing. Getting language adoption is largely a marketing problem combining what those in control of the language push and how those in the community pull. Rust's success comes from doing that dynamic correctly.

If it was just safe and not C/C++, it would be another Ada, Modula-2, D, etc. It's important to market all the key benefits of it in a way that lets potential users know it will help them solve problems faster and with less trouble down the road.

Re: Rust is mostly safety

#146
post #134
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…

> 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 don't see a split here. I know lots of cool ideas have been posted to Hacker News lately, that showcase something possible in future versions of Rust. But I seriously hope people keep these libraries as showcases, not production-quality tools. I'd say this nightly/stable split is a bit out of proportion.

In 2017 we'll get Tokio and lots of Tokio-ready libraries. Some of them already work and compile with stable Rust. And maybe in the end of the year we can take a proper look what we can do with Rocket, or Diesel...

Re: Rust is mostly safety

#147
post #134
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…

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

There's little evidence for a "dark cloud" on the horizon because of Rust nightlies, besides people complaining of dark clouds. I'd suggest providing evidence of problems with nightlies and filing bugs about things that need to be stabilized.

Re: Rust is mostly safety

#148

Earlier quoted context omitted.

> 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

That sounds like a good use case for the ? operator in Rust 1.13+.

Re: Rust is mostly safety

#149

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

That's incorrect. On some platforms, stack probes are not yet implemented because the patch to LLVM hasn't been merged, and we need it to do this properly. Someone is working on getting that through right now.

And stack probes are one corner case of stack overflow. Rust protects against stack overflow in most cases, on all platforms, in every case on Windows, and is intended and designed to protect against all stack overflow, but it has a bug due to missing features in LLVM that nobody has taken the time to fix.

Re: Rust is mostly safety

#150

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…

Think about effort in vs results gained. Example:

You can drive nails with a knife by holding the nail and hitting it with the side of the knife. It takes work to do right with you occasionally cutting yourself. Some people will even loose a hand.

You can use a hammer. You will get the nails in smoother with less rework required. You occasionally hurt yourself but not as bad as a knife. You can also smash the nerves to point you don't feel anything.

You can use a nailgun with safety switch. It's ultra-fast and can't hurt you if you're aiming where the nails go. It cost a bit more. It can hurt you if you turn the safety off or aim it at yourself. Simpler than mental effort into using knives or hammers safety. Less tiring, too. Some people even think they're fun.

That's C, C++, and languages that are memory-safe respectively. Rust's advantage of no GC is like a nail-gun that costs same as a hammer. It has the benefits but not the primary disadvantage. If you're a craftsman, you're time and energy are valuable. Use the best tools you can for whatever work you're doing. That is, what gets it done quickly, done right, and easy to fix later w/ smaller problems.

Post reply on HN