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

181–190 of 511 posts

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

#181

Post by lacampbell »

steveklabnik wrote: post #66
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

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 have only used garbage collected languages.

Or is the memory management of rust so novel it can't be described in those terms? I find the concepts aren't very concrete to me.

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

#182

Post by pcwalton »

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…

This is only true for pure two-space copying collectors, which are rarely used in practice because of the absurd memory overhead. Once you introduce mark/sweep for some portion of the heap (like production GCs do), you reintroduce overhead proportional to the number of dead objects during the sweep phase.

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

#183

Post by coolsunglasses »

nercht12 wrote: post #88
CodeMage wrote: post #71

Earlier quoted context omitted.

True enough. However, I'm willing to bet that a non-trivial amount of nightmarish code in C++ comes from the language itself. Also, I'm willing to be that a Rust build would be an improvement over a C++ build. As an example, I'm really sick of header files.

Yes and no. Rust adds its own set of hassles. You think building becomes a synch? With Rust, you're fighting the compiler probably more than with C++. I'm sure some game developers would rather have an occasional crash they can fix down the road after their game is published than be forced to make a perfect system the first time. Remember, with game production, it's about time-to-market, not about perfect code.

Cinch, like cinching up a belt.

Synch is short for synchronization.

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

#184

Post by enqk »

__david__ wrote: post #117
enqk wrote: post #62

Earlier quoted context omitted.

Nevertheless these language specific solutions are completely opaque to an end user. These are software developer centric. As an end user I cannot inspect how these were applied and therefore develop trust in the end product. There's always an element of trust at the root of running a piece of software on my machine. I wish I could quickly inspect and be sure that say, the audio engine that mozilla firefox is running…

> However it does nothing, and probably cannot, address the security i.e. the impact on my own safety or that of my assets. Sure it can. It actively prevents certain type of errors (buffer overflows, integer overflows), which are prime security exploits. Less exploits == more security.

My standpoint is that: - Less exploits is an improvement in frequency - More security is a question of limiting impact

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

#185

Post by naasking »

dikaiosune wrote: post #170
naasking wrote: post #91

Earlier quoted context omitted.

> IMO it would be great to get folks who write the enormous base of existing realtime apps driving critical devices everywhere to sit up and take notice of Rust. Rust cannot make any latency guarantees either. Reference counting and its lifetimes also have pathological cases, ie. worst-case, an object can reference the entire heap which will take time proportional to the number of dead objects to free. Copying collec…

It's worth mentioning that there are several strategies for avoiding cascading deallocations like arenas or arena-backed graph abstractions. For example: https://crates.io/crates/typed-arena https://crates.io/crates/petgraph Rust's generics make this fairly pleasant to work with, and lifetimes/borrowck ensure safety when managing your own object allocations.

Indeed, if you can live with the wasted memory use of objects outliving their conceptual lifetime, regions/arenas are a good solution.

Note however that you'd probably still have to run destructors when destroying an arena (to free file handles for instance), so you can still see high latency. With an arena you can perhaps schedule this better though.

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

#186

Post by dj-wonk »

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.

Programming Rust by O'Reilly is in early release and I recommend it.

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

#187

Post by enqk »

AsyncAwait wrote: post #153
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.

Indeed it is a good thing. What I'm just a little bit weary of is equating that sort of improvement with increasing overall security. We went there already with Java and this hasn't stopped Java from being an attack vector.

The way this sort of reasoning affects the behavior of engineers and the products they put out in front of users.

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

#188

Post by dj-wonk »

harveywi wrote: post #64

The state of Rust editors continues to evolve [1], but I would be curious to learn more about the editors/IDEs that people are using for Rust development. Any stories or thoughts? [1] https://areweideyet.com/

I use Atom with the language-rust package. I'm very pleased. Before Atom I was using Emacs. I don't expect to go back to Emacs unless I need terminal-based editing.

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

#190

Post by Skalman »

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

For me the hump was from the get-go.

Following the book, I installed Rust directly, but then i realized that I should've installed it via Rustup. Next, I want a good editing environment, so I install VS Code and Racer, but then I find out that I can't use Clippy unless I use Nightly... and I'm not interested in using Nightly, so I'll wait.

Post reply on HN