I look into all these old programs that work great after decades with lots of appreciation.
At the same time, I look into this plethora of web-and-AI-stuff that needs rewrite almost every year... just a massive facepalm situation.
We as a tech community really should go back to the basics when designing stuff, but it seems people just want to make on the highlights of the week for their startup to get some money to burn, and leave rubbish behind.
I think this speaks tremendous volumes to the legacy of these programs. Using this site, I fired up an old unix v6 on a simulated pdp11. I've never used a pdp 11 or unix v6.
I was able, within a few seconds, navigate the system and find the 'moo' game in /usr/games/moo. In other words, I was functional with SECONDS. The staying-power of that kind of technology just blows my mind.
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...
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.
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.
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).
Yeah, they usually compile fine. And if not, its not that hard to port them most of the time. Now try something reverse, like using modern language on old Unix. Good luck :)
Not really, I belong to those dreamers of systems programming languages with automatic memory management support.
Even though I don't really like most of Go's design decisions, I appreciate it can perfectly fine being used as C replacement, regardless of that anti-GC/RC folks say about it.
Perhaps a somewhat off-topic question but I'm early in my career and have found Go to be a rather pleasant language to work with so I'm really curious.
For example when I was working in a large microservice system, some of the java/typescript repos were a pain to work in because some of the developers had written crazy-looking oneliners. I mean it's possible to write difficult-to-read Go code as well, but I wasn't seeing it anywhere near as much.
Not the GP, but the error handling mechanism for one. You are less likely to silently/accidentally drop an exception vs Go's tuple return values. Thankfully, there’s linters for Go to catch some common mistakes, still feels fragile imho.
My experience has been the opposite. The idiomatic patterns is to have errors handled at the callsite, rather than bubble up. In java codebases I've worked on, you tend to have catch-everything parts of the code that are unable to address the specific problem, and mitigate it by restarting work, or just logging largely because they don't know what went wrong. Not that can't address the issue with exceptions more specifically (it happens all the time) but that often it is easier not to, and just to group all exceptions by their class and move on. In go codebases, In production go-codebases I've tended to see if/else logic for every case. This makes the code horrible to read IMHO, to get a general sense of what is happening, but make much more of specific logic explicit and directly handled.
You could imagine a language which discourages bubbling exceptions by forcing you to catch and either handle or rethrow each possible exception -- while still making it hard to accidentally forget to handle an exception.
Certainly, and go already comes pretty close that explicitness via returned errors. At that point, we are down to a style choice between exceptions and error returns.
Honestly I'm not sure it matters and depends upon other factors being balanced in the ergonomics of the language. I don't see any reason why you couldn't accomplish the objective in either style of language.
My point is that Go today, both as matter of language features and how it tends to be used via communal norms, incentivizes explicit error handling. The parent comment stated, "You are less likely to silently/accidentally drop an exception vs Go's tuple return values" and while I could easily imagine language features that discourage bubbling exceptions ... in practice, I think that tends to be more the norm than explicit handling of tuple returns.
In my experience go developers have no clue about signals, the concept that you shouldn't output colours when piped to a file, and a number of other things.
It's all possible to do, but the practitioners don't know how.
Plenty of people on the Internet, as for the meaning of systems, that is your interpretation.
In the 1980's writing a compiler and linker would be considered systems as in operating systems, as it would targeting bare metal workloads, all of which available in Go today, via the way it is bootstrapped, gccgo, TinyGo and TamaGO.
If we decided on an eternal user interface in 1999 then what would we do? Forbid capacitive touch screen? If we decide on one now, are we forbidding any development into VR/AR?
Even when I got my first UNIX computer in 1992, it was fun to explore the bin directories and try running all the different programs found there. Even then there was old stuff whose purpose it was hard to discern.
I remember typing “ss” at the shell (tcsh?!) in 1988 on a VAX running BSD 4.3+tahoe and being unable to exit the spreadsheet until someone opened the manpage or something and gave me some ideas. Probably made worse because I was on a monocoque adm3a and curses was … well, cursed … on that particular terminal type. Never did that again, ha ha.
At the same time, I look into this plethora of web-and-AI-stuff that needs rewrite almost every year... just a massive facepalm situation.
We as a tech community really should go back to the basics when designing stuff, but it seems people just want to make on the highlights of the week for their startup to get some money to burn, and leave rubbish behind.