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

71–80 of 85 posts

Re: Rust and Nix = easier Unix systems programming

#71

Post by cmrdporcupine »

agentultra wrote: post #54
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 log…

I often see these precise points in code review arguments, by developers doing something 'risky' in their code: "It's only risky if you don't know what you're doing."

Half the time the same developer has made a mistake in the same code.

With software being so complex, so full of human error -- almost any tool and practice that can help remedy this situation is welcome in my books.

Re: Rust and Nix = easier Unix systems programming

#72

Post by laughinghan »

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…

I don't think this is unfair. In order to fail as badly as the sloppy C program, the Rust developer would have to explicitly pass in -1 as the default_value, like fork().unwrap_or(-1), right? The developer might do that anyway, but that's certainly an improvement over -1 happening implicitly; they'd have to think about it, and alarm bells would go off as soon as they re-read the kill() manpage, rather than only upon re-reading both the kill() and fork() manpages.

Similarly, neither of your "if let Some() = fork()" examples would fail as badly as the sloppy C program, right?

All the examples you could come up with of sloppy Rust code fail less poorly or make it harder to fail as poorly as the sloppy C code, and you were deliberately trying make your Rust code sloppy, whereas the sloppy C code was based on examples from the wild: http://rachelbythebay.com/w/2014/08/19/fork/

Still seems like a good argument that Rust's design is an improvement.

Re: Rust and Nix = easier Unix systems programming

#73

Post by agentultra »

cmrdporcupine wrote: post #71
agentultra wrote: post #54

Earlier quoted context omitted.

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

I often see these precise points in code review arguments, by developers doing something 'risky' in their code: "It's only risky if you don't know what you're doing." Half the time the same developer has made a mistake in the same code. With software being so complex, so full of human error -- almost any tool and practice that can help remedy this situation is welcome in my books.

Programming is hard because thinking is hard.

I think it's entirely reasonable to write security-focused software in a highly restricted language with concrete formal semantics.

The problem with trivial examples is that they're often constructed to prove a point and don't represent what a real developer would write if they were to seriously consider the problem in C.

Re: Rust and Nix = easier Unix systems programming

#74

Post by oldmanjay »

agentultra wrote: post #73
cmrdporcupine wrote: post #71

Earlier quoted context omitted.

I often see these precise points in code review arguments, by developers doing something 'risky' in their code: "It's only risky if you don't know what you're doing." Half the time the same developer has made a mistake in the same code. With software being so complex, so full of human error -- almost any tool and practice that can help remedy this situation is welcome in my books.

Programming is hard because thinking is hard. I think it's entirely reasonable to write security-focused software in a highly restricted language with concrete formal semantics. The problem with trivial examples is that they're often constructed to prove a point and don't represent what a real developer would write if they were to seriously consider the problem in C.

Tell that to the silly mistakes I've made a career out of fixing (many of them mine!)

Re: Rust and Nix = easier Unix systems programming

#75

Post by Rusky »

peterwwillis wrote: post #58

"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 return value is going to stay in a register the whole time anyway, so a char won't save you anything.

But regardless, the point of that sentence is nothing to do with memory usage, but with semantics. Whether you or the compiler packs all the information into 3 bits or 3 words, that's fine, as long as the language helps you distinguish the parts.

Re: Rust and Nix = easier Unix systems programming

#76

Post by sitkack »

usefulcat wrote: post #68
sitkack wrote: post #53

Earlier quoted context omitted.

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.

Not sure how you get that. Let's assume that memory is allocated in sizes that are multiples of 4, and length-prefixed strings have a 4 byte length prefix. str len: c-str bytes: size-prefix bytes: difference: 1 1+1 (4) 4+1 (8) 4 2 2+1 (4) 4+2 (8) 4 3 3+1 (4) 4+3 (8) 4 4 4+1 (8) 4+4 (8) 0 5 5+1 (8) 4+5 (12) 4 6 6+1 (8) 4+6 (12) 4 7 7+1 (8) 4+7 (12) 4 8 8+1 (12) 4+8 (12) 0 So, for example: "ABCDE" as a C-style string w…

Thanks for the clarification, but I believe neither has said anything in error (replace most with average). I wonder what the breakdown of string lengths in say, clang or nginx is?

Re: Rust and Nix = easier Unix systems programming

#78

Post by bogomipz »

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…

Modula2 was from an era before the internet was ubiquitous and everyone had computers in the pocket. To compare lack of uptake of a "safer language" from a time when the internet and attack surface was so much smaller to now seems disingenuous. C and UNIX go hand in hand, nobody is disputing their worth or tenacity. I fail to see how a proposition that is not new detracts from Rust.

Re: Rust and Nix = easier Unix systems programming

#79

Post by pjmlp »

sitkack wrote: post #55
spiralpolitik wrote: post #43

Earlier quoted context omitted.

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

Modula-3 descends from Modula-2, although not directly.

Some of the Xerox PARC Mesa/Cedar researchers went to work for DEC (later Compaq) and created Modula-2+ with feedback from Niklaus Wirth. Which had actually used Mesa as inspiration for Modula and Modula-2.

Eventually Modula-2+ evolved into Modula-3.

Nowadays I would say part of its ideas live on C#.

Re: Rust and Nix = easier Unix systems programming

#80

Post by pjmlp »

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…

Safe systems languages already existed before C was a thing.

Modula-2 is just one example.

Burrough B5000 was programmed in safe systems programming in 1961.

https://en.wikipedia.org/wiki/Executive_Systems_Problem_Orie...

https://en.wikipedia.org/wiki/NEWP

"NEWP is a block-structured language very similar to Extended ALGOL. It includes several features borrowed from other programming languages which help in proper software engineering. These include modules (and later, super-modules) which group together functions and their data, with defined import and export interfaces. This allows for data encapsulation and module integrity. Since NEWP is designed for use as an operating system language, it permits the use of several unsafe constructs. Each block of code can have specific unsafe elements permitted. Unsafe elements are those only permitted within the operating system. These include access to the tag of each word, access to arbitrary memory elements, low-level machine interfaces, etc. If a program does not make use of any unsafe elements, it can be compiled and executed by anyone. If any unsafe elements are used, the compiler marks the code as non-executable. It can still be executed if blessed by a security administrator."

Sounds similar to modern practices? Done before C and UNIX were a thing.

C and UNIX have survived this long, because they go together as one, just like JavaScript is the king of the browser, C was the only way to go when coding on UNIX systems.

Post reply on HN