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

31–40 of 511 posts

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

#31

Post by pron »

wyldfire wrote: post #3

> GC pause ... sufficiently low power hw .. cheap phone Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. 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. EDIT: I mean to say that many of my colleagues who write realtime software…

> even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive.

That's true, but high-powered, abundant-RAM realtime applications can use approaches that are cheaper than Rust's. See, e.g., the interesting work currently being done updating realtime Java[1]. The idea is that memory is composed of a few kinds of lifetimes: eternal, scoped and GCed-heap. Scoped memory is basically nested arenas, and GCed heap contains objects that are used by non-realtime portions of the app (which, even in realtime systems, may comprise the majority of code, especially when the system runs on large servers).

An approach like Rust's, however, is crucial when the application is RAM and/or energy constrained.

[1]: https://www.aicas.com/cms/en/rtsj

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

#34

Post by cryptrash »

shmerl wrote: post #29
cryptrash wrote: post #28

I'll never use rust for anything important. Too dangerous, unstable, badly organized, toxic development community, the list goes on.

Huh? Did you mix it up with something else? Rust community is one of the best. And what's "dangerous and unstable" there?

Of course I didnt. Klabnik is practically a communist, lots of anti-American sentiments, etc. Pcwalton has been spamming HN for ages about rust. They're all terrible. I've heard rumors of memory vulns in rust as well.

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

#35

Post by noir_lord »

shmerl wrote: post #29
cryptrash wrote: post #28

I'll never use rust for anything important. Too dangerous, unstable, badly organized, toxic development community, the list goes on.

Huh? Did you mix it up with something else? Rust community is one of the best. And what's "dangerous and unstable" there?

Check his comment history and draw your own conclusions ;).

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

#36

Post by allengeorge »

cryptrash wrote: post #28

I'll never use rust for anything important. Too dangerous, unstable, badly organized, toxic development community, the list goes on.

Of all the invectives to level at Rust, "toxic development community" would be the least applicable. Frankly, I've found the Rust community super welcoming and willing to answer questions from a newbie.

As for the rest of your points - I don't think they're applicable as well. I've found Rust to be super solid and the ecosystem a pleasure to work with. Could you give examples to support your claim?

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

#37

Post by steveklabnik »

cryptrash wrote: post #34
shmerl wrote: post #29

Earlier quoted context omitted.

Huh? Did you mix it up with something else? Rust community is one of the best. And what's "dangerous and unstable" there?

Of course I didnt. Klabnik is practically a communist, lots of anti-American sentiments, etc. Pcwalton has been spamming HN for ages about rust. They're all terrible. I've heard rumors of memory vulns in rust as well.

I make it a strong point to keep my personal politics outside of Rust; there's actually many people who work within Rust and its community that I would fight bitterly with about politics, but we instead focus on the technology and work together in a productive manner.

If you see me acting inappropriate within Rust project spaces, please report me to the moderation team: the core team is subject to moderation just like anyone else,and no core team members are allowed to be part of moderation for exactly that reason.

  > I've heard rumors of memory vulns in rust as well.
Please report these to https://www.rust-lang.org/security.html, as we care deeply about fixing them, if any. Otherwise, that's just FUD.

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

#38

Post by kibwen »

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…

  > assuming that mistakes are being made
Mozilla isn't using Rust as an excuse to skimp on security elsewhere. For example, Servo sandboxes tabs as you'd expect from a modern browser, despite being written in Rust from day one. Defense-in-depth is fundamental to good security, and being able to rely on the safety properties of your language adds yet another layer of defense.

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

#39

Post by SkyMarshal »

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…

The name of the game for the software industry is to continually create better tools that systematically, inexorably reduce the attack surface of apps built with them.

Haskell does this in an interesting way by quarantining all side-effect code into Monads and preventing data races with immutability. Rust does it by making memory errors and race conditions impossible via its ownership mechanism.

Think of it as guiderails that reduce the cognitive load on the programmer by ensuring some classes of mistakes/errors/bugs simply cannot get past the compiler. Compared to C/C++, the programmer has less to think about since the compiler handles that for them. That is immensely valuable.

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

#40

Post by hinkley »

pron wrote: post #31
wyldfire wrote: post #3

> GC pause ... sufficiently low power hw .. cheap phone Yeah, but even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. 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. EDIT: I mean to say that many of my colleagues who write realtime software…

> even high-powered hardware can take a "major" hit from a GC pause when your application is extremely latency sensitive. That's true, but high-powered, abundant-RAM realtime applications can use approaches that are cheaper than Rust's. See, e.g., the interesting work currently being done updating realtime Java[1]. The idea is that memory is composed of a few kinds of lifetimes: eternal, scoped and GCed-heap. Scoped…

If I had infinite free time, I'd love to explore the problem space of implementing interpreters for GC-based languages on top of Rust. It's quite hard to get the concurrency right, and indeed we see a number of major languages that gave up on even trying.
Post reply on HN