Hacker News Reader

Comment by mprovost | Hacker News Reader

I'm publishing a book which teaches Rust CLI programming by rewriting a BSD Unix utility in each chapter. I'm using the 4.4 release from 1992 but looking at the contemporary source from modern BSDs (Free/Open) they're totally recognisable and often basically unchanged. It's also amazing that some bugs persisted for 10-20 years before being fixed. I'm sure there are a few still to be discovered...

View on HN

I have this crazy idea that you could rewrite finger/fingerd in rust, and perhaps jail it for extra peace of mind and revive the service with some new, modern, even dare-I-say futuristic features. Haven’t spent any time on it this year but you just reminded me.

Not a crazy idea at all that sounds super fun! It would be much safer to write a server taking untrusted input from the network in Rust.

If you have any good ideas for interesting and fun features let me know, should be enough contact info in profile here!

Well. While advertising is generally frowned upon here on HN, I don't think nobody would mind if you gave us the name of your book and the date you expect it be available for purchase. :-)

"Rust From the Ground Up". I've been releasing it chapter by chapter on Leanpub - the first 220 pages are out and I'm finishing up another chapter ('cut'), hopefully by the end of the year.

https://leanpub.com/rust-from-the-ground-up/

A hilarious juxtaposition. Generally Rust programs' source are forwards incompatible and a program written by a rust dev $now won't even be able to be compiled on a rustc from 3 months ago. This is not an exaggeration or hyperbole but something that happened to me multiple times in 2020-2022 before I stopped even attempting to use rust source code. Whereas a Perl program written today could be interpeted and executed on a perl interpeter from 1999.

That hasn't been my experience with Rust over the past 5+ years. Maybe I haven't been poking into obscure features. When the language is as old as Perl I imagine the pace of change will slow but already it's been very slow moving and stable. There's a huge emphasis on backwards compatibility (editions are such a great concept).

Is that because you update your rustc every month or two by either, 1. using a rolling distro, or 2. pulling down a new one from out of repo sources using rustup... | sh, etc as is standard rust community practice? Or did you really use a normal non-rolling distro's packaged rustc and never run into problems in 5 years?

If the former, well... yeah. If the later, I'm impressed. I wasn't doing anything complex. I had it happen even with simple programs like a rust web scraper tool for web serials to epub and a rust FFT visualizer for software defined radio.

Just rustup update. The most frustrating part of the whole experience is the rate at which the clap argument parsing crate makes breaking changes. I've had to pin a specific version because they start deprecating features as soon as they make a release. So in my experience the crate ecosystem moves much faster and is less concerned with backwards compatibility than the compiler/core language. And compared to most languages the Rust standard library is fairly sparse (which I think was a smart move).

Reply on news.ycombinator.com