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

51–60 of 85 posts

Re: Rust and Nix = easier Unix systems programming

#51

Post by kod »

sickbeard wrote: post #50
masklinn wrote: post #22

Earlier quoted context omitted.

> What if the Rust developer uses fork().unwrap_or(default_value) in a hurry The point here is that the language's tools and APIs can significantly better drive the developer towards the safe/right solution, that's a large point of type theory and static type systems after all. In this case rust's type system is used to split out the various "result cases" and notify the developer upfront of the various cases to hand…

This has been proven to be wrong over and over again with the many variations of languages that came after C. Newer "safer" languages don't improve bugs

Where's this "proof" you speak of?

By contrast, strong static typing does in fact prove the absence of certain errors.

Re: Rust and Nix = easier Unix systems programming

#52

Post by dkersten »

vog wrote: post #35
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/

Indeed, using "nix" as a (Rust) library name is a very bad choice, given the increasing popularity of the Nix package manager.

I think we're now at the point where it is very difficult for any name not to clash with the name of something else.

So I no longer worry about it.

Re: Rust and Nix = easier Unix systems programming

#53

Post by sitkack »

masklinn wrote: post #47
justincormack wrote: post #40

Earlier quoted context omitted.

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.

> Well pids should be pid_t not int. pid_t isn't a newtype, it's just a typedef, so that doesn't really make a difference. > System calls should really return two values, return value and errno, but C doesn't handle that very well either. Most system calls want to return either , not both. And C doesn't handle that at all.

Appropriate tangent: Remember that part where null terminated strings save at most three-bytes per string? And if the allocator is long word aligned it saves none-bytes. The first to arrive sets a disproportionate amount of the direction.

Re: Rust and Nix = easier Unix systems programming

#54

Post by agentultra »

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…

It's trivial to write an incorrect program in C because its a language that expects you, the programmer, to know what you're doing. I assume that if you're going to use the `fork()` and `kill()` syscalls on your OS that you're going to read about them and consider their consequences... not write the first trivial example that comes to mind and ship it.

An example program written like that is not endemic to C or a logical consequence of its design. It's ignorance. Such examples frustrate me too. It's practically a straw-man argument.

> By the way, you can also write your own wrapper functions in C

And your own abstractions to provide more safety guarantees... it really depends on your judgement to balance risk, reward, and goals. It's possible to write a system that does all of the checks for you but you'll sacrifice the time and energy to do so (and will still find users blowing off their feet regardless of your best efforts).

Rust is doing very cool things but it's not going to make systems programming magically easier. Someone still had to write nix and you should still understand your programs.

Re: Rust and Nix = easier Unix systems programming

#55

Post by sitkack »

spiralpolitik wrote: post #43
jernfrost wrote: post #39

Earlier quoted context omitted.

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 a…

The proposition that Rust is offering is not new. In the 90s Modula-2 was touted as "a better, safer way" of doing system programming than C. It failed to get traction outside of education because it failed to offer a compelling reason for people to migrate. Those that do not study history are doomed to repeat its mistakes. In the example given it's possible to write a similar library in C to protect against unwanted…

Different language, but Modula-3 is actively maintained again. https://github.com/modula3/cm3

Re: Rust and Nix = easier Unix systems programming

#56

Post by luckydude »

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 :-(

I tend to agree with you with one caveat. We did a C like scripting language and added one thing that C was missing, a variable value that is "undefined" which is not the same as zero. Really simple but now you can do stuff like

pid_t p;

if (defined(p = fork()) { // parent / child stuff here } else { // fork error here }

It's pretty much the same as try / catch, we just implemented it as part of the variable. And any scalar or complex type can be undefined.

I suspect if C had this a lot of these code samples would be a little more clear. Maybe? Dunno, it's worked well for us. And we like C a lot.

Re: Rust and Nix = easier Unix systems programming

#57

Post by kalmar »

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…

Author here. This is a really valid criticism of the post, and I think it'll inform the next post I write on the topic. Thanks!

Re: Rust and Nix = easier Unix systems programming

#58

Post by peterwwillis »

"the return value is conveying three different things all at once. [...] That’s a lot of information for one poor little pid_t—usually a 32-bit integer—to convey!"

Someone never had to bit-pack their programs to save memory, disk space, or bandwidth. In fact, it's a huge waste of memory; if you only need 3 bits, a 'char' would have sufficed. Saves 24 bits!

Of course, we could use nibbles to make data structures where the fork return value only takes up 3 bits instead of a whole byte, but that could be considered micro-optimizing. (the compiler may do this for us anyway, though)

Re: Rust and Nix = easier Unix systems programming

#59

Post by GhotiFish »

superobserver wrote: post #44

This gets me thinking how awesome it would be to have functional programming on *nix systems, like Haskell (specifically). At least then it might be forcibly designed to be made more useful and ultimately get more people on board. One can dream.

Kinda like turtle! https://hackage.haskell.org/package/turtle

Oh by the way, I accidentally hit downvote on your post and HN doesn't let me undo that action... I was just trying to hide it! Sorry!

Re: Rust and Nix = easier Unix systems programming

#60

Post by xaduha »

dkersten wrote: post #52
vog wrote: post #35

Earlier quoted context omitted.

Indeed, using "nix" as a (Rust) library name is a very bad choice, given the increasing popularity of the Nix package manager.

I think we're now at the point where it is very difficult for any name not to clash with the name of something else. So I no longer worry about it.

It's still easy enough, there are many hundreds of geographical locations in many tens of languages alone. Just make some effort.
Post reply on HN