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

301–310 of 511 posts

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

#301

Post by dbaupp »

braveo wrote: post #261
leshow wrote: post #246

Earlier quoted context omitted.

Correct me if I'm wrong, but it looks like this just provides some 'safe' alternatives to unsafe C++ things. It's still up to the diligence of the programmer to not use those things and nothing is getting statically verified. By contrast, when I write Rust, memory safety (and type safety) are verified by the compiler.

Sometimes I think Rust people lose the forest for the trees. The end goal isn't for the compiler to verify the safety, the end goal is for the software itself to be safe in a way that's cheaper. It doesn't really matter if they both end up at the same place, which is safe software.

You're 100% correct that the end goal is safe software in a way that's practical to achieve. However, having the computer check one's code is generally regarded as a great way (even the best way) to do this: NASA's JPL doesn't accidentally recommend[0] turning on all compiler warnings and using static analysis tools, and it seems a little unlikely that most major tech companies would be spending millions on static analysers and statically-typed languages if they didn't think it helped them write correct code.

[0]: https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...

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

#302

Post by shmerl »

steveklabnik wrote: post #300
shmerl wrote: post #299

Earlier quoted context omitted.

Wasn't there some other effort in Rust to enable asynchronous I/O?

There's been a few; this one is built on top of mio, one of the most popular previous ones.

I meant this one which I saw mentioned recently: https://github.com/alexcrichton/futures-rs

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

#303

Post by worik »

naasking wrote: post #205
worik wrote: post #198

Earlier quoted context omitted.

"C also doesn't provide latency guarantees, as the same pathological programs can exist in C as well." But you have to code them. They are predictable, or you let them in by allowing data structures to grow indefinitely With C you can make latency guarantees. You can write code that does not have such guarantees but it is your choice With GC you are not in control so there are fewer choices. You will not be able to m…

> With GC you are not in control so there are fewer choices. You will not be able to make guarantees. Not true. Hard and soft realtime GCs with sub-microsecond latencies exist. Latency is a property of a runtime, not of manual vs. automatic storage reclamation.

That is a misunderstanding of latency.

"Very fast" is still latency.

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

#304

Post by dbaupp »

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.

Rust has libcore, which is, in many ways, more featureful than libc despite also having zero dependencies. From my perspective, the main advantage of C is the way in which chip manufacturers only provide (poorly supported/bug-ridden) C compilers, but this is likely to become less important as ARM takes over more and more of the world: it is only getting easier and cheaper to throw a full ARM chip into a device, due to economies of scale.

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

#305

Post by dbaupp »

Matthias247 wrote: post #260
takeda wrote: post #82

Earlier quoted context omitted.

Lack of extra RAM and power to run GC is not the problem. The problem is that GC makes code behavior not predictable.

However that's not something that is automatically solved by manual memory management. Using malloc/free on a desktop OS does also not provide a predictable runtime behavior, although unexpected pauses might be smaller than with most GCs. The safest bet for predictable memory management and latency is the approach that is used by lots of embedded and realtime software: Don't allocate at all. Or at least don't do it i…

I think this is the point that is obscured when discussing "manual memory management" vs "GC" languages and just focusing on the behaviour/life-cycle of an individual allocation: the former generally provide tools and features that make easier/more natural to avoid allocations, whereas the latter makes the assumption that allocation is usually OK (which is, of course, a perfectly acceptable trade-off for the domains those languages target).

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

#306

Post by steveklabnik »

shmerl wrote: post #302
steveklabnik wrote: post #300

Earlier quoted context omitted.

There's been a few; this one is built on top of mio, one of the most popular previous ones.

I meant this one which I saw mentioned recently: https://github.com/alexcrichton/futures-rs

Ah yes. Basically, tokio is mio + futures.

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

#307

Post by zanny »

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/

KDE recently broke off the syntax highlighting from Kate, so I'm super hopeful for eventual Rust support using racer in KDevelop soon, since its semantic highlighting is second to none.

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

#308

Post by gcp »

qwertyuiop924 wrote: post #222
gcp wrote: post #136

Earlier quoted context omitted.

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.

Uh? There are definitely trimmed libc's (not GNU libc!) that run on bare metal. Such as the one used by avr-gcc for example...

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

#310

Post by fizzbatter »

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

It's worth it, imo. I was in your boat a few months back and hated every minute of it. With that said, i'm still not 100%. I semi-regularly see syntax that makes me go "Wat is what!?", but then i sit for a moment and understand it. Rust introduces a lot of visual baggage and that seems to cause me syntax blindness.. not enjoyable.

Unfortunately though, i'm back on Go. I want to be on Rust, but i had to pick a language for work and i can't ask my Team to go through what i did. Rust, despite the safety, is too unnatural for our larger codebase.

Luckily i think Rust has seated itself as the language we will use if the need is truly there. Unfortunately though, not everything.. just the specific things that need it.

Post reply on HN