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

301–310 of 474 posts

Re: Rust is mostly safety

#301

Post by curun1r »

p0nce wrote: post #97
pjmlp wrote: post #79

Earlier quoted context omitted.

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.

Perhaps they made the right decision with int, short and long, but there's one case where they absolutely made the wrong decision: byte.

Having signed bytes is extremely obnoxious. Doing any sort of bit- flipping/shifting requires you to add a ton of "& 0xFF" operations that would be completely unnecessary if byte was unsigned. The main use case for bytes is to represent data, not integers and bytes shouldn't have been treated that way.

Re: Rust is mostly safety

#302

Post by Animats »

Manishearth wrote: post #283
Animats wrote: post #245

Earlier quoted context omitted.

You keep making that claim without backup. Two days ago I posted links to extensive use of "unsafe" in matrix libraries. (Some of that code was clearly transliterated from C. Raw pointers all over the place.) That's entirely for performance; all that code could be safe, at some performance penalty. I'd suggest using only safe code for whatever matrix/math library gets some traction, and then beating on the optimizer…

I just gave you backup; I grepped my whole .cargo cache dir (both the one used by servo and my global one). You have also made your claim without backup -- you have repeatedly claimed that this is an endemic problem in Rust, with only individual crates (most of them obscure ones) to back it up, and I only usually make my claim in response to claims like yours -- the burden of proof is on you. Anyway, I do provide som…

I looked at a few.

"itoa" is clearly premature optimization. That uses an old hack appropriate to machines where integer divide was really expensive, like an Arduino-class CPU. It's unlikely to help much on anything with a modern divide unit.

"httpparse", "idna", "serde-json", and "inflate" should be made 100% safe - they all take external input, are used in web-facing programs, and are classic attack vectors.

Not much use of number-crunching libraries; that reflects what you do.

I'll look at some more later. How to deal effectively with incoming UTF-8, especially bad UTF-8, may need some thinking.

Re: Rust is mostly safety

#303

Post by johnny22 »

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.

Re: Rust is mostly safety

#304

Post by rcthompson »

zerofan wrote: post #282
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…

Have you done much skydiving? I used to go three days a week, for a couple years, between 4-10 jumps a day at a place that had world class experts. My experience is that only beginning skydivers are constantly preaching safety. They go around (vocally) judging everything they see, and I think they do it because it alleviates their own fear. Instructors would teach safety, but really only to their own students. I thin…

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.

Re: Rust is mostly safety

#305

Post by jwn »

kibwen wrote: post #263
agentgt wrote: 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…

I think this comment and the OP are both correct. The point of Rust is safety, in the sense that memory safety should be the default for all programming languages, and has been the default for all non-systems languages since the 90s. The only holdouts have been because people used to claim that memory safety wasn't possible without making a language unusably slow, which Rust has disproven. In all my years of teaching…

I really want to love Rust, and while I understand the Rust borrow checker in theory, actually using it in practice has been a major headache. I tried Rust on a simple terminal-based project, and after a week of feeling that I was getting nowhere I switched to Go and had a proof of concept in several hours.

With that said, can you recommend a good source to really understand best practices and patterns for ownership and borrowing? I feel that's the biggest hurdle to using Rust (at least in my case).

Re: Rust is mostly safety

#306

Post by tormeh »

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…

I disagree. Popularity is everything. Grab the developers you can get first. Once you have a popular language with ready-to-be-hired developers big hardware companies will be far more willing to entertain using the language.

When choosing languages people look at community, libraries, existing in-house expertise and availability of programmers. All these require popularity.

Re: Rust is mostly safety

#307

Post by prodigal_erik »

p0nce wrote: post #97
pjmlp wrote: post #79

Earlier quoted context omitted.

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.

The right choices are bounds checking or autoboxing. I very rarely want arithmetic modulo n (and when I do, I want to choose n), but never do I ever want signed overflow quietly giving wrong answers.

Re: Rust is mostly safety

#308

Post by Manishearth »

Animats wrote: post #302
Manishearth wrote: post #283

Earlier quoted context omitted.

I just gave you backup; I grepped my whole .cargo cache dir (both the one used by servo and my global one). You have also made your claim without backup -- you have repeatedly claimed that this is an endemic problem in Rust, with only individual crates (most of them obscure ones) to back it up, and I only usually make my claim in response to claims like yours -- the burden of proof is on you. Anyway, I do provide som…

I looked at a few. "itoa" is clearly premature optimization. That uses an old hack appropriate to machines where integer divide was really expensive, like an Arduino-class CPU. It's unlikely to help much on anything with a modern divide unit. "httpparse", "idna", "serde-json", and "inflate" should be made 100% safe - they all take external input, are used in web-facing programs, and are classic attack vectors. Not mu…

Yeah, this was basically my conclusion too.

I'm somewhat okay with the parsing ones using unsafe if we can be very sure that the unsafe code actually has a performance impact, and be very careful about it. Some of them already do this, but not all.

Re: Rust is mostly safety

#309

Post by bjz_ »

jwn wrote: post #305
kibwen wrote: post #263

Earlier quoted context omitted.

I think this comment and the OP are both correct. The point of Rust is safety, in the sense that memory safety should be the default for all programming languages, and has been the default for all non-systems languages since the 90s. The only holdouts have been because people used to claim that memory safety wasn't possible without making a language unusably slow, which Rust has disproven. In all my years of teaching…

I really want to love Rust, and while I understand the Rust borrow checker in theory, actually using it in practice has been a major headache. I tried Rust on a simple terminal-based project, and after a week of feeling that I was getting nowhere I switched to Go and had a proof of concept in several hours. With that said, can you recommend a good source to really understand best practices and patterns for ownership…

Alas, I think a week is too short to give Rust. Go will get you more pay-off in the short term, but as you internalise the rules of Rust you'll really start to reap the benefits. Unfortunately being an experienced user, I'm not aware of a single online source for learning this stuff - I mainly teach people directly in person or on IRC.

Re: Rust is mostly safety

#310

Post by bjz_ »

dom0 wrote: post #134
agentgt wrote: 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.

Although others don't see the 'dark cloud', as a long time user of Rust it has definitely put me off pushing for it too hard at work. That said, Diesel and Serde are now the only big libs that require nightly, but this is due to them relying on syntax extensions which are going to be stabilized in the next release. So if I were to start a new microservice using those libs it would be ready to go on stable in a few weeks time, which is super exciting. The only other thing would be async IO. Tokio is making big strides in that direction - not sure what the time-frame is on being able to use it on a server nicely though.
Post reply on HN