Rust and the Future of Systems Programming [video] • Hacker News Board

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

#151

Post by naasking » Wed, Nov 16, 2016, 8:09 PM UTC

steveklabnik wrote: post #140

Rusky wrote: post #137

Earlier quoted context omitted.

I suspect they're referring to graphs of Drop implementors, based on the sibling thread. If you for some reason have a linked-sea-of-nodes data structure that has to traverse itself on drop, that can behave similarly to dropping an Rc graph, though it still doesn't use lifetimes.

I guess that would make sense, but I'm not sure it's lifetime-specific though. C++ doesn't have lifetimes but would still have this problem.

Yes, C/C++ would also have this problem. The point I was trying to make is that incrementality/latency is a property of a runtime. If your program has deep ownership graphs, any kind of naive reclamation procedure is going to have high latency, even if it's written in C/C++.

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

#152

Post by bsder » Wed, Nov 16, 2016, 8:11 PM UTC

user5994461 wrote: post #57

kibwen wrote: post #42

Earlier quoted context omitted.

Rust doesn't need to stop C++ to be successful. The market for programmers is already large enough to successfully support dozens of programming languages, and that market will only continue to grow. PHP didn't "stop" Perl, Python didn't "stop" PHP, Ruby didn't "stop" Python, and yet all of these languages continue to be enormously successful. Why should we expect a monoculture on the systems side?

What's the place for Rust in the market? The distributed systems have already moved to Go (when it's not Java/C# :D). The system programming is done in either C or C++. (Depending on history and availability). The oldest stuff and/or most constrained is stuck with C. They're struggling to have anything moved over to C++. Rust is entirely out of question.

> What's the place for Rust in the market?

A language that is better than C that isn't C++.

Calling C++ a single language is like calling Chinese a single language. The various dialects share characters and that's about it. :)

C++ is at least 3 fundamentally different languages over the course of 20+ years. The C++ you would write to the current standard looks vastly different from the C++ you wrote even 10 years ago which itself looks different from the C++ of 10 years before that.

The problem is that even if you only write the modern stuff, you must understand the older stuff as your libraries are often written in it.

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

#153

Post by AsyncAwait » Wed, Nov 16, 2016, 8:12 PM UTC

enqk wrote: post #4

Although I am not against improving the safety of languages we use for system programming, the model that Rust advocates are pushing of "preventing mistakes" as a way to make systems secure doesn't convince me. Mistakes (and security breaches) happen. A system should be written in such a way as mistakes are few, indeed, however it is essential to also efficiently protect our users' assets (data) first, assuming that…

I don't get what you're saying here.

- Without Rust you program to protect users assets without guaranteed memory safety.

- With Rust you program to protect users assets, with the addition of guaranteed memory safety.

Sounds like a win win to me.

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

#154

Post by Narann » Wed, Nov 16, 2016, 8:14 PM UTC

leshow wrote: post #9

Rust is great. I've been following it since pre-1.0 and writing code with it for about as long also. It's really come a long way, my favorite language for pretty much anything except web development.

Wow! You've got my attention!

I mean, I feel many rust stuff (crates/dev/tools) seems to focus on high performance web so, as a low level guy enjoying bitwise ops and dynarec stuff I was wondering if rust what a good thing for me or if it would be better to stick in C. Can you tell me which kind of project you do in rust, what was your original language and why rust shine compared to your previous language?

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

#155

Post by bsder » Wed, Nov 16, 2016, 8:14 PM UTC

z3t4 wrote: post #2

when you can run javascript on a pebble watch it blurs the boundaries ... Want to concat an number and string ? JavaScript wont complain.

> when you can run javascript on a pebble watch it blurs the boundaries

And yet Javascript can't access a network socket or my flash storage in any useful portable way.

Javascript is hampered by everybody trying to bolt on "security" after the fact and basically hobbling usage of the language.

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

#156

Post by db48x » Wed, Nov 16, 2016, 8:15 PM UTC

rwj wrote: post #150

wyldfire wrote: post #121

Earlier quoted context omitted.

"Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" Unwrap implies "either this operation should succeed or we should panic". Doing anything other than panic seems like it's terribly difficult to determine what that should be. And I might've put unwrap() there because that's really what I want to happen. For `mv`: don't let's dare go ahead and do the unlink() if the link()…

I think the idea would be the program would fail to compile, and you would need to go back and replace the unwrap with proper error handling. The goal would be to allow the use of unwrap during development, but require the final polish before the code goes into production.

Sometimes unwrap is the proper error-handling behavior.

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

#157

Post by naasking » Wed, Nov 16, 2016, 8:17 PM UTC

qwertyuiop924 wrote: post #123

naasking wrote: post #115

Earlier quoted context omitted.

Absolutely, you have to be aware of the ownership graph depth in both C and Rust if you want to bound latency. You don't have to do this with tracing GC though, you just need a runtime that implements latency bounds.

Wait, why would you have to do that? Most ownership is determininstically resolved at compile time, so you can know exactly when a resource will be freed. What you do have to know is about the rare refcounted variable, and what edge cases require ownership checking at runtime.

The latency problem isn't caused by determining what to free, the latency problem is caused by actually freeing. Imagine an array with 2^31 pointers, and now fill it with with 2^31 distinct pointers to the remainder of the 2^32 bit address space. When that array goes out of scope, you can now enjoy 2^31 individual free operations, because reclamation for Rust lifetimes and reference counting are both proportional to the number of dead objects (copying collection takes zero time in this case).

If bounded latency is a goal, you have to bound the depth of of your ownership graph if you're working on a platform that doesn't impose global latency properties. C/C++ and Rust do not do this.

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

#158

Post by steveklabnik » Wed, Nov 16, 2016, 8:17 PM UTC

gue5t wrote: post #139

steveklabnik wrote: post #61

Earlier quoted context omitted.

unwrap has legitimate use-cases, and it's not clear what "disable" it would be, as it changes the type of the thing it returns. You could write a lint to fail the build, if you want, I guess...

.unwrap() is only the right choice if you need to optimize for binary size and can't afford the cost of the precise error message you would pass to .expect(). There are situations where you can't possibly continue running the application if an error occurs, but you shouldn't rely on a backtrace (which you might not manage to capture, e.g. if RUST_BACKTRACE is unset or you don't have symbols) as your only method of co…

This is not true. For example, consider this code:

    if foo.is_some() {
        let foo = foo.unwrap();
    } else {
        // other code
    }

Here, I _know_ that foo is some. The extra error message from expect will _never_ be seen.

Now, this is a contrived example, and would better be written with `if let` in today's Rust, but this is the _kind_ of situation in which unwrap is totally, 100% cool, but the compiler can't know.

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

#159

Post by steveklabnik » Wed, Nov 16, 2016, 8:18 PM UTC

naasking wrote: post #151

steveklabnik wrote: post #140

Earlier quoted context omitted.

I guess that would make sense, but I'm not sure it's lifetime-specific though. C++ doesn't have lifetimes but would still have this problem.

Yes, C/C++ would also have this problem. The point I was trying to make is that incrementality/latency is a property of a runtime. If your program has deep ownership graphs, any kind of naive reclamation procedure is going to have high latency, even if it's written in C/C++.

Quite fair! Thanks for elaborating.

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

#160

Post by bsder » Wed, Nov 16, 2016, 8:18 PM UTC

sidlls wrote: post #25

gcp wrote: post #8

Earlier quoted context omitted.

Nothing prevents you from doing both approaches. I mean, while Mozilla is increasing Rust usage, they're also rolling out more extensive sandboxing. Either of those by themselves are not a good enough solution though. Just trusting on Rust means you are vulnerable to Rust bugs or logic errors. Just trusting on sandboxing means you're hoping that your trusted code (written in C/C++) doesn't have any security bugs.

It also means trusting that the "unsafe" usage in the Rust code doesn't have any security bugs.

Sure, but the question is how wide the "unsafe" boundaries are.

If I'm writing an application that uses the network in a standard way, I should be able to write a program with NO unsafe blocks.

As always, things have bugs. Rust, itself, may have bugs that get exposed over time once adoption starts to increase. Rust gets some "security through obscurity" for the moment.

Once they start pushing Rust code into Firefox, that will change dramatically.