Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust and Nix = easier Unix systems programming

kamalmarhubi.com

Post reply on HN
Print view View original

31–40 of 85 posts

Re: Rust and Nix = easier Unix systems programming

#31

Post by lmm »

zuzun wrote: post #19

I always find it a bit unfair when I see sloppy C programs used for shock value. What if the Rust developer uses fork().unwrap_or(default_value) in a hurry, or writes if let Some(child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } or if let Some(ForkResult::Child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } Now, if you're about to tell me that the examples above are to…

The difference is that in C the bad way is often the most concise/easiest way. So e.g. snippet examples tend to not check for errors, and the language guides you towards not checking. http://www.haskellforall.com/2016/04/worst-practices-should-... . IIRC C simply doesn't have a nice, standardized way to do "compose several possibly-error calls, resulting in either a single error or the successful result".

Re: Rust and Nix = easier Unix systems programming

#32

Post by Manishearth »

zuzun wrote: post #19

I always find it a bit unfair when I see sloppy C programs used for shock value. What if the Rust developer uses fork().unwrap_or(default_value) in a hurry, or writes if let Some(child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } or if let Some(ForkResult::Child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } Now, if you're about to tell me that the examples above are to…

The point is that nix-rs doesn't let you kill all the processes by accident, you have to be trying to do it in Rust. You also have to explicitly ignore the error. Whereas in C it's pretty easy to forget to check for the error and subsequently crash everything.

Sure, you can have the same higher level API in C. Though Rust will not compile if there's no exhaustive match, and you cannot access the `int ret` if it's in the wrong state, but it's close enough.

Re: Rust and Nix = easier Unix systems programming

#33

Post by Sean1708 »

SixSigma wrote: post #5

In reliability theory "X failed" is a poor error message. What we want to know is which failure mode has been triggered. The function of kill is to kill a given pid, so there are two failure modes : "the pid didn't exist" or "the pid didn't die"

"kill failed" isn't actually the message which is printed. What you get is

    thread '' panicked at 'kill failed: Sys(ESRCH)', ../src/libcore/result.rs:746
So you know that it failed because of ESRCH (no such process).

Re: Rust and Nix = easier Unix systems programming

#34

Post by wizeman »

k__ wrote: post #26
geocar wrote: post #12

I was very confused. I thought this had something to do with Rust and nix[1]. [1]: https://nixos.org/nix/

Same here. I thought "A match made in heaven" But it will probably never happen, because Cargo is too good, haha

What do you mean, it will never happen?

The nix package manager has (admittedly, undocumented) support for Rust / Cargo projects.

Re: Rust and Nix = easier Unix systems programming

#36

Post by barosl »

zuzun wrote: post #19

I always find it a bit unfair when I see sloppy C programs used for shock value. What if the Rust developer uses fork().unwrap_or(default_value) in a hurry, or writes if let Some(child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } or if let Some(ForkResult::Child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } Now, if you're about to tell me that the examples above are to…

  struct fork_status {
      enum { ERROR, PARENT, CHILD } state;
      int ret;
    };
I think the point of tagged unions (as in OP's example) is that you cannot access `child` if the call failed. Your example does have an exhaustive check (by a compiler warning), but it doesn't prevent you from misinterpreting `ret` as a pid. Does C have a method to enforce this restriction?

Re: Rust and Nix = easier Unix systems programming

#37

Post by masklinn »

SixSigma wrote: post #5

In reliability theory "X failed" is a poor error message. What we want to know is which failure mode has been triggered. The function of kill is to kill a given pid, so there are two failure modes : "the pid didn't exist" or "the pid didn't die"

> The function of kill is to kill a given pid

1. there are more failure modes than these (POSIX kill(2) can set 3 different errnos)

2. kill(2) signals process, it doesn't usually kill them (let alone kill them outright in such a way that this information could ever be returned)

3. kill(2) can signal process sets of cardinality > 1

4. the `unwrap` panic message will print the unwrapped value, which includes the ERRNO

Re: Rust and Nix = easier Unix systems programming

#39

Post by jernfrost »

sergiolp wrote: post #11

I can't help but think they're trying to fix something that isn't broken at all. Adding new abstraction layers rarely helps when doing systems programming. You (as in "the developer") want to be as near to the machine as possible. C does this pretty well. Perhaps I'm just getting old :-(

Then you are missing the whole point of Rust. The point of Rust IS to allow you to be close to the machine but while you maintain much higher level of safety. Rust is designed to do this with little overhead.

In this day and age with big software packages, security being an increased concern it really is high time programming languages do more to help us avoid bugs which expose us to hackers and crackers.

I do have an affinity for C, but as a Objective-C programmer currently coding in Swift, I am really seeing how many more bugs the compiler helps me uncover.

I think Rust is on the right track. It is a long overdue change to systems programming.

Re: Rust and Nix = easier Unix systems programming

#40

Post by justincormack »

barosl wrote: post #36
zuzun wrote: post #19

I always find it a bit unfair when I see sloppy C programs used for shock value. What if the Rust developer uses fork().unwrap_or(default_value) in a hurry, or writes if let Some(child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } or if let Some(ForkResult::Child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } Now, if you're about to tell me that the examples above are to…

struct fork_status { enum { ERROR, PARENT, CHILD } state; int ret; }; I think the point of tagged unions (as in OP's example) is that you cannot access `child` if the call failed. Your example does have an exhaustive check (by a compiler warning), but it doesn't prevent you from misinterpreting `ret` as a pid. Does C have a method to enforce this restriction?

Well pids should be pid_t not int. System calls should really return two values, return value and errno, but C doesn't handle that very well either.
Post reply on HN