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

221–230 of 511 posts

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

#221

Post by burntsushi »

rweichler wrote: post #202
jokoon wrote: post #147

Earlier quoted context omitted.

A good language should be like a good game: easy to learn, hard to master. We don't care about expert cases, we only care about getting productive ASAP, which means having students hoping into a language and learning it quickly. Solving the details is easy: just teach coding discipline and enforce good practice and do code reviews, and discourage "throwable" code. Security is not only the job of a programmer, it has…

LuaJIT + C have suited me just fine for systems programming. I don't care about security, so I find it hard to care about Rust. All I care about is lessening the burden on me as a programmer. I think Rust may be useful in cases like ripgrep, where you basically rewrite an existing, established tool or service used by many to be as performant and secure as possible. But other than that niche use-case, I don't think Ru…

As the author of ripgrep, I can assure you, the burden on me as the programmer was lifted quite a bit! I probably wouldn't have been able to build it otherwise. (Not because it's physically impossible, but because it would have taken too much time.)

It's not like I just rewrote grep. ripgrep is built on a large number of libraries that are reusable in other applications. You can see my progress on that goal here: https://github.com/BurntSushi/ripgrep/issues/162 (And those are only the ones I wrote, nevermind all of the crates I use that have been written by others!)

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

#222

Post by qwertyuiop924 »

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.

Why would you use libc embedded? Most of libc kind of expects an OS to be there.

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

#223

Post by wyldfire »

kibwen wrote: post #209
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.

To be more accurate, unwrap can be a legitimate means of error handling when used in an application, as opposed to a library. But if you're writing a library, then unwrapping rather than using Result is a surefire way to make your users hate you. :)

Ah! I stand corrected. "library" is a pretty sane use case for barring unwrap(), one that cargo knows is the current goal. I still don't think it's general enough but maybe it's worth a warning.

Aside: CPython's gdbm support is provided by libgdbm that calls exit() for you if if finds something it's not happy with (corrupted database, e.g.). O.o

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

#224

Post by Manishearth »

naasking wrote: post #179
akiselev wrote: post #174

Earlier quoted context omitted.

You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use, whether it's Rust or assembler. The point of Rust is that you have complete control over what you use and pay for. If your concern is the overhead of lifetimes then you need to evaluate if you can afford heap allocation in the first p…

> You will always have these pathological cases when you choose to use higher level memory management like simple reference counting or garbage collection no matter what language you use Not true, soft and hard realtime garbage collectors exist. Your runtime simply needs to bound the amount of reclamation work done at any given time. For instance, the cascading free behaviour Rust is currently susceptible to can be b…

> For instance, the cascading free behaviour Rust is currently susceptible to can be broken up into a bounded series of free operations interleaved with ordinary program execution.

You can probably make this work by plugging in a different allocator, if jemalloc doesn't do this already. The ability to batch up frees and mallocs isn't tied to GCs.

This won't reduce the perf impact of running a large tree of `Drop` impls, but it will reduce the free calls.

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

#225

Post by steveklabnik »

lacampbell wrote: post #181
steveklabnik wrote: post #66

Earlier quoted context omitted.

How are you trying? What are you getting stuck on? I'd love to improve things.

Not OP, but as someone who theoretically would like Rust - I'll bite. Maybe my usecase is a common one. I understand memory management in C. I understand it modern C++ (destruction when going out of scope, smart pointers etc). Basically, a description and discussion of borrow-checking for people who have already used system programming languages would be really helpful. I feel like the book is targeting people who ha…

It's trying to be accessible to those people, but not strictly for them. I don't think the issue here is that it's for GC'd users, but that it's trying to explain things from whole-cloth, where you're looking for a direct comparison, "c does this, rust does that."

I try generally to keep other languages out of Rust's docs for various reasons, but agree that these kinds of resources are useful; I wrote "Rust for Rubyists" after all!

I'm hoping that others will step in and fill this gap; the repo in my sibling is a great start.

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

#226

Post by duneroadrunner »

pcwalton wrote: post #173
duneroadrunner wrote: post #120

Earlier quoted context omitted.

If you're considering switching to Rust for code/memory safety reasons, SaferCPlusPlus[1] may be an easier/cheaper/low risk option. It allows you to add memory safety to your existing code base in a completely incremental way, with no dependency risk. (At the moment, standard library support is required though.) [1] https://github.com/duneroadrunner/SaferCPlusPlus

"Safer C++", like all C++ template libraries, is not memory safe.

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 at the moment is that it doesn't yet provide memory safe replacements for all of the standard library's unsafe elements, just the most commonly used ones.

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

#227

Post by steveklabnik »

nnethercote wrote: post #212
steveklabnik wrote: post #166

Earlier quoted context omitted.

We had significant compile-time improvements in the release yesterday, with more to come in the future. Also, you might want to give incremental recompilation a try, it's nightly-only for now, but being actively worked on. > add 5 crates and watch ur compile/run cycle climb to a cool 10+ second average. It should not recompile those crates each time, if it does, that's a bug. Please report them!

> It should not recompile those crates each time, if it does, that's a bug. Please report them! Depends on the inter-crate dependencies, alas. Touching one crate can easily cause multiple other crates to rebuild.

Only if you need to modify both crates; not if you're just adding them as dependencies, because then you're not modifying them. I was assuming that's what the parent was doing, due to their wording, but that might have been a bad assumption.

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

#228

Post by empath75 »

unethical_ban wrote: post #89
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?

Python in my mind has supplanted perl, and ruby seems only to live on for the sake of Rails.

Chef, too.

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

#229

Post by Nemo157 »

kibwen wrote: post #209
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.

To be more accurate, unwrap can be a legitimate means of error handling when used in an application, as opposed to a library. But if you're writing a library, then unwrapping rather than using Result is a surefire way to make your users hate you. :)

Sometimes you've proven some invariant in some other way, so you know that unwrapping is guaranteed to not panic. Although in those cases I prefer to use .expect("this will not fail because of blah") instead in the spirit of self-documenting code.

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

#230

Post by qwertyuiop924 »

naasking wrote: post #157
qwertyuiop924 wrote: post #123

Earlier quoted context omitted.

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…

Ah.

But C has this problem as well. If you've malloc(3)ed an array of 2^31 pointers, each pointing to an object, enjoy your 2^31 free(3)s, or prepare to start leaking RAM.

So what's your point?

Post reply on HN