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

131–140 of 511 posts

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

#131

Post by steveklabnik »

cbHXBY1D wrote: post #102
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 specifically about your book, but I would love if there was a quicker way to find methods in the docs. Right now, if I want to find the methods used by BTreeMap you have to wade through a good amount of information until you can find how to just get the keys. I'm currently on mobile where the issue is more prominent.

Are you missing the search bar at the top? Typing "keys" in shows BTreeMap's keys right away, even https://doc.rust-lang.org/stable/std/?search=keys

That said, yeah, I hear you. It can still be tough sometimes. At some point, I'd love to work with some sort of information design / UX person to totally re-do rustdoc's output. There's a surprising number of thorny problems there. But there's always so much to do...

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

#132

Post by webkike »

naasking wrote: post #110
Rusky wrote: post #98

Earlier quoted context omitted.

Lifetimes are compile-time only and do not do any reference counting. So Rust has the same latency guarantees as C, for example.

> Lifetimes are compile-time only and do not do any reference counting. I never said they did, I said lifetimes and reference counting both have this pathological case. C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well. It's a total myth that you need C in realtime domains due to "latency". Maximum pause times are a property of a particular runtime , not a language.

Regardless there is no overhead for lifetimes. It is a data flow analysis problem used solely to verify correctness of the code.

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

#133

Post by foota »

naasking wrote: post #115
qwertyuiop924 wrote: post #103

Earlier quoted context omitted.

Rust itself can't, but you as the programmer can. It's not quite C, but you can do a lot of reasoning about what the compiler will do with your code, and avoid pathological cases.

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.

I believe their point is that an object can own potentially many objects, and when it is dropped it could cause a cascade of dropping. Which may not be expected by someone.

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

#134

Post by geodel »

pron wrote: post #51
hinkley wrote: post #40

Earlier quoted context omitted.

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.

What for? If you have the extra RAM and power for a GC, you don't need Rust for safety. HotSpot's next-gen (JIT) compiler is written in Java and is absolutely amazing.

Will that next-gen JIT be enabled by default for Java 9 or 10?

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

#136

Post by gcp »

qwertyuiop924 wrote: post #106
shandor wrote: post #55

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. It would, and definitely should, move into the direction of safer languages than C. The biggest problem I see is tooling and legacy. Tooling, because there's a ginormous amount of testing and design software that "works with C" (whatever that means in the co…

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.

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

#137

Post by Rusky »

steveklabnik wrote: post #128
naasking wrote: post #110

Earlier quoted context omitted.

> Lifetimes are compile-time only and do not do any reference counting. I never said they did, I said lifetimes and reference counting both have this pathological case. C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well. It's a total myth that you need C in realtime domains due to "latency". Maximum pause times are a property of a particular runtime , not a language.

What is the pathological case with lifetimes? You're saying it takes "time proportional to the number of dead objects to free", but as the parent said, lifetimes are a compile-time construct, so they have no runtime properties. (I'm not saying that for sure there are none, I'm saying that it seems like you're talking about refcounting only, the lifetime bit is unclear to me.)

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.

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

#138

Post by wyldfire »

tmzt wrote: post #93
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...

Right, it would likely use clippy but it would essentially be a --production target or profile, intended for builds where the binary will be run in production. And by 'and friends' I mean calls that panic for the same reason as unwrap, such as expect or ok. The goal is to stop code from reaching production inadvertently, not to prevent all sources of panics.

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. (and in that case use the lint Steve suggests).

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

#139

Post by gue5t »

steveklabnik wrote: post #61
tmzt wrote: post #49

Earlier quoted context omitted.

Would it make sense to have a cargo/rustc flag to disable unwrap and friends when building for production?

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 communication with your future self.

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

#140

Post by steveklabnik »

Rusky wrote: post #137
steveklabnik wrote: post #128

Earlier quoted context omitted.

What is the pathological case with lifetimes? You're saying it takes "time proportional to the number of dead objects to free", but as the parent said, lifetimes are a compile-time construct, so they have no runtime properties. (I'm not saying that for sure there are none, I'm saying that it seems like you're talking about refcounting only, the lifetime bit is unclear to me.)

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.
Post reply on HN