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

491–500 of 511 posts

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

#491

Post by fulafel »

kryptiskt wrote: post #340
hinkley wrote: post #339

Earlier quoted context omitted.

Where pretty much anything related to concurrency is concerned we've been busy reliving the 70's for most of the last decade. Locking, asynchronous I/O, you name it. Hell even Microsoft had I/O Completion ports back in what, 2003 or so? Or am I wrong and it was a lot earlier? The coolest things in Javascript land were all done by Microsoft first and everyone (me especially) can't bring themselves to acknowledge that.

IO completion ports were introduced in NT 4.0 in 1996.

Isn't the NT async IO API just a front for a kernel side thread pool though, and may block depending on worker thread availability? They say[1] "if you issue an asynchronous cached read, and the pages are not in memory, the file system driver assumes that you do not want your thread blocked and the request will be handled by a limited pool of worker threads"

Things may be different for socket IO, but there Unix had select() much earlier, around 4.2BSD (1983)

[1] https://support.microsoft.com/en-us/kb/156932

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

#492

Post by erikbye »

staticassertion wrote: post #461
erikbye wrote: post #41

Earlier quoted context omitted.

Reading your comment made me think of Erlang, where the guiding principle is the opposite: large systems will contain errors, and will fail. That is what fault-tolerant is, you design your software (language, libraries and end program) in a way that will handle unforeseen errors and failures. Because in large systems there will always be bugs. http://erlang.org/download/armstrong_thesis_2003.pdf

I'm also a fan of this approach, and am currently learning Erlang because of it. However, I do not feel that the approaches are exclusive. Erlang is dynamically typed and it is robust because Actors act as isolation boundaries and are managed by supervisors. So the approach is "bugs happen, always recover". You can also use type annotations in Erlang to get "bugs happen less, always recover".

Perhaps not mutually exclusive, all programmers try to introduce as few bugs as possible; but the philosophy is in fact "let it crash", then you reset to a stable state. Not only is the programmer unburdened of the cognitive load of trying to imagine every single point of failure, but also of the workload of a lot of defensive programming.

The whole reasoning behind this is what I said before: in large systems there will always be bugs, errors and failures will happen (some even outside of your code, e.g. power failure). Imagining every point of failure is impossible, so don't try to. Don't write preemptive code.

Yes, Erlang is dynamically typed, but not weakly typed.

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

#493

Post by erikbye »

oldsj wrote: post #281
enqk wrote: post #45

Earlier quoted context omitted.

That does sound rather interesting! (And anti-fragile, to use a talebian neologism)

Possibly, but is the system getting stronger on each failure(like a human muscle), or is it just recovering?

It's resilient and fault-tolerant. Not antifragile according to Taleb's definition. Though, no reason you could not spawn 2 (or more) new processes for every 1 that crash.

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

#494

Post by kzrdude »

Retra wrote: post #385
kzrdude wrote: post #354

Earlier quoted context omitted.

Any use of `unsafe` that breaks unrelated safe code is broken and buggy; if that scenario would happen like you describe it, the code is breaking Rust's aliasing rules: that's possible using `unsafe` but invalid and leads to UB.

I'm not talking about 'uses of unsafe', I'm talking about code that is unsafe. Much of that code is not even written in Rust, so there's no 'unsafe' to use.

Ok, so code that is memory unsafe (broken!). One must still say "unsafe" to bring it into Rust (to use ffi, or make a safe wrapper); so there is still a clear location in the Rust code that is to blame.

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

#495

Post by fjrieiekd »

pcwalton wrote: post #490
fjrieiekd wrote: post #477

Earlier quoted context omitted.

As someone getting into and loving Rust, I have a few: 1) Drop the semicolons and implicit returns in multiline functions (I.e. like Swift). Eliminates hard to understand errors around missing or present semicolons. 2) Allow silent lossless integer upcasts. Sprinkling as usize and friends everywhere is unergonomic. 3) ? For return is fine but the line should still have one "try" at the beginning for legibility. 4) Al…

Many of these are not possible due to backwards compatibility. Even if we could: 1. Most Rust users, including me, like the implicit returns. We would face a ton of pushback if we tried to drop them. Rust doesn't actually need that many semicolons: you can frequently leave them off. 2. This is tricky, because it can have surprising semantics if not done right (e.g. right shifts). There are proposals to do something l…

Hi pcwalton,

1) If you dropped semicolons like Swift, you could keep implicit returns.

I just don't see the advantage of having them in multiline functions at the cost of having to retain semicolons. IMO, a trailing value after a multiline function also just looks plain bizarre for newbies.

I agree it's probably too late for this, but you asked how Rust could be easier to learn and this is one of the ways.

2) It would certainly be much nicer to have this.

3) See Swift for an example of where this was done more nicely IMO than in Rust.

4) Unfortunate. Splitting out a helper function means we lose Rust's inference which already exists when used in a let statement, and requires adding dependent crates from libraries to the binary's Cargo.toml and importing them into the module and hard coding the types. The client shouldn't have to care about this.

5) Great!

I still enjoy the language just the same, but you asked how it can be easier to learn and this is how I see it.

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

#496

Post by tmzt »

Manishearth wrote: post #215
wyldfire wrote: post #142

Earlier quoted context omitted.

Sure, but in that case it would effectively elide it from the language spec! Who doesn't target "production" eventually?

> Sure, but in that case it would effectively elide it from the language spec! No. Some unwraps are necessary. You wouldn't be absolutist here; you could still allow some carefully-labeled unwraps. Also, not all production users need to care about panics that much.

Yes, I would envision an allow attribute of some sort.

This is simply a contract with compiler that you didn't copy and paste some example code somewhere in your codebase that fails with an unwrap. It's about extending the "if it compiles it runs" near-guarantee that we so love about Rust.

Ideally a program would fail fast and be restarted if it reached an unrecoverable state, with supervision trees like Erlang. Also ideally, unwrap would be used for exceptional states, not only ones that are unlikely to fail until something goes wrong, like a port being closed or a file unreadble or not present.

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

#497

Post by leshow »

braveo wrote: post #478
dbaupp wrote: post #475

Earlier quoted context omitted.

Suppressing the unused variable warning is: - unrelated to the dangling pointers - not suppressing a warning about a memory safety problem - not effecting the lack of warnings for the memory safety problems: remove the `(void)y;` line and there's still no warnings about the dangling pointers. Seriously, you are focusing on something irrelevant. Either pretend I didn't write that line, or pretend it was std::cout not…

> The fundamental fact remains that the compilers do not warn about the major problem of handling dangling pointers I'm going to quote myself, emphasis mine. "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." [snip] "C++ compilers tend to give pretty good warnings that you can treat as errors, and __coupled with good external tools__…

quoting pcwalton up above:

"I don't care if the software is verified via libraries or compilers. The problem is that C++ verifiers don't work."

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

#498

Post by fjrieiekd »

pcwalton wrote: post #448
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…

Do you have a proposal to achieve Rust's goals in a way that's easier to learn?

Hi pcwalton, I've seen a couple of your videos and want to know if you've posted any tutorials on integrating Rust with Xcode and using the native tools, or if others have? Some of us are coming from IDE Javaland, and while Rust is quite usable from a text editor, print debugging only goes so far, and gdb is incomprehensible gobbledygook for us.

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

#499

Post by Manishearth »

tmzt wrote: post #496
Manishearth wrote: post #215

Earlier quoted context omitted.

> Sure, but in that case it would effectively elide it from the language spec! No. Some unwraps are necessary. You wouldn't be absolutist here; you could still allow some carefully-labeled unwraps. Also, not all production users need to care about panics that much.

Yes, I would envision an allow attribute of some sort. This is simply a contract with compiler that you didn't copy and paste some example code somewhere in your codebase that fails with an unwrap. It's about extending the "if it compiles it runs" near-guarantee that we so love about Rust. Ideally a program would fail fast and be restarted if it reached an unrecoverable state, with supervision trees like Erlang. Also…

This is basically what https://github.com/Manishearth/rust-clippy/wiki#option_unwra... does

It doesn't work transitively (so if a crate you depend on unwraps you can't protect yourself), but https://github.com/llogiq/metacollect plans to fix that

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

#500

Post by dbaupp »

braveo wrote: post #483
tatterdemalion wrote: post #480

Earlier quoted context omitted.

unsafe blocks play no role in any kind of security aside from memory safety. You are communicating with extreme disingenuity.

Hey, you're right, getting memory usage correct doesn't affect safety at all. good day.

Reading an array out of bounds is definitely unlikely to be correct/be a security vulnerability. Memory safety is absolutely a prerequisite for any other sort of safety one might want.
Post reply on HN