Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust and the Future of Systems Programming [video]

hacks.mozilla.org

Post reply on HN
Print view View original

281–290 of 511 posts

Re: Rust and the Future of Systems Programming [video]

#281

Post by oldsj »

enqk wrote: post #45
erikbye wrote: post #41

Earlier quoted context omitted.

Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-tolerant is, you design your software (language, libraries and end program) in a way that will handle unforeseen errors and failures. Because in large systems there will always be bugs. http://erlang.org/download/armstrong_thesis_2003.pdf

That does sound rather interesting! (And anti-fragile, to use a talebian neologism)

Possibly, but is the system getting stronger on each failure(like a human muscle), or is it just recovering?

Re: Rust and the Future of Systems Programming [video]

#282

Post by josephg »

Matthias247 wrote: post #243
josephg wrote: post #163

Earlier quoted context omitted.

unwrap is proper error handling. It says "Try to do this. If it fails, panic". Its like an assert on an invariant that the compiler requires. If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available. If I wrote that logic myself I would just be awkwardly rewriting unwrap.

> If my script depends on a database connection, I might connect to a database and unwrap() it so the script errors out if the database isn't available. I think that's a bad example, as it is one of those things that can really fail at runtime and which should be properly handled. Even if handling means printing an error message and stopping the process with an exit code - but not crashing. I think unwrap is for thin…

Thats fair. I said script for that reason. A better example would be assert equivalents - if an API could return null (Option) under normal circumstances but you know it can never be null based on how you're using it, unwrap() makes sense. That contract could only be violated if there's a bug in the implementation. If thats the case all guarantees are out the window and usually the best / only thing you can do is to crash and allow the process to restart.

Also in those case (in my experience) having a human-readable error message is rarely useful. When assertions are violated I almost always have to consult the code anyway. And 80% of my asserts are never hit. I usually don't bother preemptively writing decent error messages. File name and line number is the right information, and panic provides that anyway.

Re: Rust and the Future of Systems Programming [video]

#283

Post by eggy »

gcp wrote: post #136
qwertyuiop924 wrote: post #106

Earlier quoted context omitted.

I wouldn't hold your breath for C to die though. C sucks at many things, but it's pretty good in embedded, if you're not writing ASM.

Actually, the only real advantage that C has over rust there is the availability of trimmed libcs.

C seems to be going through yet another renaissance.

C is a smaller language to learn.

There is tons of legacy code even for embedded systems.

Re: Rust and the Future of Systems Programming [video]

#284

Post by amelius »

pimeys wrote: post #19

Now I have four services running on production, all written with Rust. If it compiles, it usually works. Of course you have these late night sessions where you write that one unwrap() because, hey, this will never return an error, right? And bam... I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugl…

> I'm seriously waiting that tokio train to be stable and a unified way of writing async services without needing to use some tricks with the channels or writing lots of ugly callback code

By which [1] is meant, for those not knowing.

[1] https://github.com/tokio-rs/tokio

Re: Rust and the Future of Systems Programming [video]

#285

Post by duneroadrunner »

leshow wrote: post #246
duneroadrunner wrote: post #226

Earlier quoted context omitted.

Are you confusing SaferCPlusPlus with a different library? SaferCPlusPlus is a new library that makes it practical to stick to a memory safe subset of C++ (i.e. no native pointers, no native arrays, no std::array , no std::vector , etc.). Using the SaferCPlusPlus library to replace all uses of C++'s unsafe elements does result in code that is as memory safe as Rust, or any other modern language. The main shortcoming…

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

That's right. SaferCPlusPlus is not complete and does not yet include a static verifier/checker.

Without a static verifier, memory safety is not guaranteed, just dramatically improved. And for many cases where there is a large investment in an existing code base, this might still be a more expedient solution. Even if only an interim one.

For example, I would estimate that, with concerted effort, it would take a matter of weeks to "port" the existing Firefox C++ code base to SaferCPlusPlus. Presumably this would dramatically reduce "remote execution", and other memory bugs while we wait for the Rust implementation.

In cases where guaranteed memory safety is desired, you might think of it this way: In Rust, the static checker is built into the compiler. In C++, static checkers/analyzers are separate tools. You could choose to require that your C++ code must be verified to be safe by a static analyzer of your choosing. In C++, it can be difficult/inconvenient to write non-trivial code that fully appeases the static analyzer, just like in Rust. You can use SaferCPlusPlus to make it easier to fully appease the static analyzer (like the Rust language does).

I should also mention "Ironclad C++". It's similar in function to SaferCPlusPlus, but it uses garbage collection (where SaferCPlusPlus does not). It does include a static verifier/enforcer.

As a fan of "memory safety without using GC", I'm rooting for Rust. But I think the idea of achieving memory safety in C++ can be too quickly dismissed.

Re: Rust and the Future of Systems Programming [video]

#286

Post by staticassertion »

xorxornop wrote: post #236
wyldfire wrote: post #138

Earlier quoted context omitted.

But if we accept the premise that "it's acceptable in some cases to have unwrap() in code that targets 'production'" then it wouldn't make sense to have a production profile that bars its use. The word "production" is in the global namespace and I think you want something more specific to your use case. Rather, one could define a rust coding guide for themselves that deems unwrap() inappropriate for production use. (…

Seems like you'd want a lint rule where if unwrap is used, it must have a comment preceding it (of some formal syntax) describing why it's necessary or appropriate. Thus the build can have all uses of unwrap known as explicitly allowed, allowing all the possible sites of panics to be enumerated and known, a useful property to have

In that case you may want "expect" over unwrap.

Re: Rust and the Future of Systems Programming [video]

#287

Post by eggy »

swuecho wrote: post #122
djhworld wrote: post #50

I keep trying to learn rust but fail miserably. They do say on their website that there's a hump that you have to climb over before everything fits into place, which is probably applicable to everything you'll learn, but sometimes I think that hump is too much of a hurdle

same feeling here. There are docs here and there, but not good. I am waiting a good book on rust. similar to Haskell, I really did not get much until the book http://learnyouahaskell.com/ currently, "The book" is too dry.

I am having the same inertia.

I have resorted to using Nim for now, and it is going real well. I would like to rewrite the Nim stuff in Rust to compare for my own sake when I have done something substantial in it.

Re: Rust and the Future of Systems Programming [video]

#288

Post by steveklabnik »

papaf wrote: post #270
steveklabnik wrote: post #254

Earlier quoted context omitted.

Two things: If you click the little [-] button, you'll get an index for that page. If you use the search bar at the top, https://doc.rust-lang.org/std/vec/struct.Vec.html?search=vec... will let you go right to the method. (In this case, you have to know that it's slice::len though) Does that help? EDIT: UX is hard! Glad people are discovering this. It's the same symbol HN uses, incidentally...

Thanks, thats very helpful. I did not know about the minus sign. A polite suggestion - maybe the link marked [-], that takes you to the index, could be labelled "index".

Well, it's not so much that it's an index, it's that when you have a page with only signatures, it feels like an index. There's no redirect, just some JavaScript :)

Re: Rust and the Future of Systems Programming [video]

#289

Post by pcwalton »

duneroadrunner wrote: post #285
leshow wrote: post #246

Earlier quoted context omitted.

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

That's right. SaferCPlusPlus is not complete and does not yet include a static verifier/checker. Without a static verifier, memory safety is not guaranteed, just dramatically improved. And for many cases where there is a large investment in an existing code base, this might still be a more expedient solution. Even if only an interim one. For example, I would estimate that, with concerted effort, it would take a matte…

> In C++, static checkers/analyzers are separate tools. You could choose to require that your C++ code must be verified to be safe by a static analyzer of your choosing.

The problem is that, in C++, there is no such static checker in existence (except ones with GC).

Re: Rust and the Future of Systems Programming [video]

#290

Post by pcwalton »

braveo wrote: post #261
leshow wrote: post #246

Earlier quoted context omitted.

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper. It doesn't really matter if they both end up at the same place, which is safe software.

> Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper.

I don't care if the software is verified via libraries or compilers. The problem is that C++ verifiers don't work.

Post reply on HN