How to maintain code for a century: Just add Rust

One of the delicious promises of open source software is eternal life. In literature from Gilgamesh on, this has been a classic trap for the careless and greedy, but this is FOSS so it must be true. No package ever dies. Proprietary code goes unpublished: if its host company dies, it probably dies with it the moment the servers …

[Doctor Syntax]

"One person's itch to learn and code found its salve in a project that few thought needed to be done."

On the basis that if it ain't broke, don't fix it, many will think it a project that ought not to be done. Once somebody decides to take that back off something there's always the temptation to fiddle with this or that.

As to whether, in a few decades time, coreutils will need to be available in Rust or Go or some future contender to replace C, none of us know.

[Anonymous Coward]

"As to whether, in a few decades time, coreutils will need to be available in Rust or Go or some future contender to replace C, none of us know."

Isn't there a touch of "why copy VHS to CD-ROM, my Ferguson Videostar still works fine" about this statement?

[An_Old_Dog]

Media/Language Migration

Your analogy is better than you may have realized.

For media, the question is not "Should I migrate from VHS to CD-ROM?", it's, "Should I migrate from VHS to CD-ROM, to DVD, to HD-DVD, to DAT, to WORM, to Blu-ray ...?" People who chose the HD-DVD option are now sad monkeys.

Rust is just another "Ooh, look, new-and-shiny!" The EXCUSE given by Rust proponents for using Rust is memory safety. If memory safety is truly what they wanted, they could simply have used the Ada programming language, which has been around for a few decades. But that's not new, cool, and sexy.

[captain veg]

Re: VHS to CD-ROM

My father did this with all his old camcorder videos, mostly of his grandchildren when they were infants. Over time the discs have degraded, and none of them play any more. The camcorder cassettes are long gone.

-A.

[DS999]

There's something to be said for

"If it ain't broke, don't fix it"

Maybe having coreutils be in C when most programmers don't know C would be a good thing - they wouldn't mess with coreutils. But re-implementing it in the hot language of the moment just brings more attention to it, and there will be more contributions for "improvements" than there have been. Improvements are a good thing, but too often they bring bugs with them.

A patch that changes the behavior of something in coreutils changes the behavior of countless shell scripts, with unknown consequences. Maybe "improved" coreutils ought to be a separate package, so those who prefer "classic" coreutils would have the choice of using those instead.

[Roland6]

Re: There's something to be said for

> Maybe having coreutils be in C when most programmers don't know C would be a good thing

That would be aligned with the thinking behind Unix and C….

[Abominator]

I think Zig is better than Rust and long term will have more legs.

[Charlie Clark]

You seem to have missed the point: it's not really that Rust is better than C, or whether Zig is better than both or which will still be around in 50 or a 100 years (C definitely will be); but how hobby projects can grow into something quite important. This is how many classic open source packages start and I don't think any of the original authors would have anything against it. Rust isn't intrinsically better than C it's many programmers find it easier and safer to work with. Just as important: automated testing didn't exist 50 years ago but has become considered essential in software development. Having created an extensive test suite (the fuzzing is a nod to exploits that only appeared years after code that could be considered bug free were discovered through new techniques) means that adding features such as progress bars can be done without the fear of breaking something in a codebase that no-one really understands any more.

[Caspian Prince]

Easier?

I don't think even a seasoned Rust programming is going to tell you it's *easier* than C. Probably safer and more correct, yes. Easier, no. This is the primary impediment to Rust entering mainstream acceptance.

[Headley_Grange]

Re: Easier?

I had a play with Rust. I would classify it as more annoying than C, not harder.

[cornetman]

Re: Easier?

> I had a play with Rust. I would classify it as more annoying than C, not harder.

I actually kind of agree with that sentiment. I would like to get into Rust more (as a C/C++ programmer primarily) and I did dip my toe into the water a little while ago to see what it was like. Some of the aspects of the language I found a little frustrating and the unfamiliarity was gnawing. After a little while, I realised that the difficulty that I was facing was having to think more up-front about memory lifecycle etc was what was legging me up. It is something that we have to consider when writing in pretty much any language, but Rust primarily enforces that effort and I think that is what will make better programs in the long run.

[cdegroot]

Re: Easier?

Rust does not need mainstream acceptance. Heck, it should not even be necessary to write coreutils in such a low level language.

There's plenty of excellent languages where the stack takes all thinking of memory management away from you, and a low level language like Rust (or C) can be used to bootstrap such a language but that's where you should stop using it. Maybe in some performance critical plugins andproba ly there are some oddball use cases, probably in fintech, where this level of control is required.

That won't stop the unwashed masses from jumping on this bandwagon, like with C or C++, and use it everywhere, appropriate or not.

But let's not pretend that that is how things should be.

Rust should be a niche language used by a couple of specialists. The other 99.99% of coders should stick with high level languages, with a runyime with garbage collection and all that jazz.

[Charlie Clark]

Re: Easier?

I've met a few who've said it is easier and I think it's a premise of the article. But I suspect it depends on how you define it.

[that one in the corner]

but no FOSS package ever dies

Oh yes they do - and have.

Nowadays, the bulk of FOSS is shoved into GitHub and will be available - for as long as GirHub bothers to run its servers[1].

Back in the day, Tarballs and Arc files were downloaded direct from the author's site and then you were expected to mirror it if it was important to you.

Then the Web was "discovered" by more and more people and for some reason the mirroring stopped and changed to just dropping in a link to "the" download location - and of course, we then learnt that URLs have a half-life.

As public version control servers came online - and people started to trust them - we saw materials on something safer than a personal site, or the pages of a company that vanished overnight (sometimes the entire company vanished, sometimes just the project)[2].

If you are lucky, the Internet Archive grabbed a copy and you can try one of the dead URLs there; patience can be required[4].

If you are really lucky, somebody has put a copy into GitHub[5] - although you can open yourself up to flames because your copy "doesn't compile for me"[6]

And what about the FOSS that is practically single-sourced by being published in that JavaScript compost heap? Was LeftPad() also available from GitLab? Some of it is handled properly (p5.js oooh, squiggly and probably safe from vanishing).

Of course, any FOSS that does fall through the cracks "is not important" - after all, all the Linux distros keep their own copies of source packages, "so we are not actually reliant on GitHub at all, Corner you fool."

Not important. Well, you never know. Literally, you never know, it has gone now.[7]

[1] Then we'll have to go back and pull the older version from SourceForge.

[2] As a few others did I like the old "Elegant" library & util from Philips Labs - good luck finding that, on the Philips site - or doing a web search for it available elsewhere[3]

[3] stop giving your projects names that are normal words!

[4] not being able to find something is, in all practical terms, the same as the thing no longer existing at all. Take note when organising your backup copies...

[5] really must put my compiling copy of Elegant up on GitHub

[6] so maybe I won't put Elegant up, as I only have Makefiles for My Own Build System and am fed up telling people how to write build scripts for their favoured build tools. Seriously.

[7] "Important" is a relative term[8]. Maybe it is really important to *you* to generate an awful lot of Elegantly laid out syntax diagrams in the next day or you can't pay for Tiny Tim's new clutches, he is growing so fast nowadays, at least the one leg is.

[8] see so very many commentards "well, my PC is ok so this is a non-issue" and the response to same

[9] Footnotes FTW. Be more Pterry!

[Throatwarbler Mangrove]

Re: but no FOSS package ever dies

"GirHub"

I know this is a typo, but now I want to see a source repo powered by Gir, the robot from Invader Zim. It will ideally throw nonsensical errors and function murkily, just like git, but in a high-pitched squeaky voice.

"It was ME! I was in the source code all along!"

[Michael Wojcik]

Re: but no FOSS package ever dies

Thanks. I will now mentally read git error messages in a high-pitched, squeaky voice. That is not inappropriate.

[bemusedHorseman]

Re: but no FOSS package ever dies

"A merge conflict?! You shall now face the mighty wrath of ZIIIIIM!"

"Time to sing the doom song! Doom doom doom..."

[Bebu]

I am not too sure...

about the "immortality" of FOSS code.

Looking at the C code in Lions Unix (v6) commentary the code is pretty rough by any standard and certainly when compared with contemporary Linux and BSD code. I imagine in 50 years time that code will look peculiar too.

Long ago having ported quite a lot of open source code between System V and BSD systems (and from VAX/VMS) I can say a lot of it was pretty ghastly and could only be immortal in the sense of a vampire or zombie.

Scientific and Engineering Fortran code, mostly numerical analysis or numerical algorithms does seem immortal. I have had to deal with 40+ year old fortran source which with a bit of compiler tweaking and a couple of (automated) edits compiled cleanly and passed its test suite.

Whether Rust, Go etc etc are still in extended use in 20 years time is probably 10:1 against.

PL/1, Simula67, and even Ada while not gone aren't exactly in common use.

Human perversity will probably ensure people are still hacking away in ISO C42 and using -std=c89 to retain K&R function definitions.

I suppose I could reimplement coreutils in SPARK (Ada). ;)

[Charlie Clark]

Re: I am not too sure...

It's often said that open source is where code goes to rot…

This is somewhat tongue in cheek as we've got to used to the opposite. But it does happen, as soon as the developers lose interest or "move on". The same happens with commercial code we just don't get to see it as often.

[Doctor Syntax]

Re: I am not too sure...

I can think of a few places where commercial code goes to be squeezed dry.

[CowHorseFrog]

Re: I am not too sure...

To be fair 9 / 10 programmers shouldnt be programming in the first place. They produce shite from the very beginning...

[Charlie Clark]

Re: I am not too sure...

To be fair 9/10 statistics I make up are complete bullshit.

[CowHorseFrog]

Re: I am not too sure...

Have you had a look at public OSS on github or gitlab and these are the projects those same people wish to share with the world

Because these have been shared with the world you would think these would be examples of their better stuff and they shoudl be not sharing their worse stuff.

Well have you had a look ?

[BrBill]

Re: I am not too sure...

I don't agree with your assumption of how people use OSS source control. We often publish them there not just to share, but to invite the community to help us make it better. It's difficult for one person to know how to do everything, and having a good idea doesn't mean that one is capable of bringing that idea to fruition all by oneself.

[CowHorseFrog]

Re: I am not too sure...

br: I don't agree with your assumption of how people use OSS source control.

cow: So what is wrong w/ my observation ?

Are you saying that people post their best or their worst examples ?

br: We often publish them there not just to share, but to invite the community to help us make it better.

cow: That still doesnt change the problem i was highlighting...Just because you want others to help that doesnt mean you write terrible code to begin with. THere are really basic things that shoudl always be done well like:

- comments

- error messages that actually have meaning and share context... eg

Invalid value X is < 0"

No-message

Bad

There is no excuse for writing 2 and 3, its not that had to write a message like 1

brill: and having a good idea doesn't mean that one is capable of bringing that idea to fruition all by oneself.

cow: My comment was about the basics. People on github cant even get the basics done well...

How many libs have shitty or no error messages ?

How many projects dont check parameters and just continue and when they fail you havent a clue where the original mistake was ?

[Throatwarbler Mangrove]

Re: I am not too sure...

To be fair, you have an almost perfect record of being a complete arse.

[CowHorseFrog]

Re: I am not too sure...

Big words from someone who calls people names, and is so pathetic they cant even share an example, but then again i guess you stay with your strengths and thats why you call names.

[JLV]

Re: I am not too sure...

> so pathetic they cant even share an example

Well, that did seem harsh but maybe the guy is familiar with your postings. I'll defer judgement...

>the guy in charge doesnt know how to program.

>What a joke...

...for about 3 minutes. Ledru does seem like he knows his shit. Whereas you confuse your arse with your mouth when you talk. OP didn't have to share an example, you did.

[CowHorseFrog]

Re: I am not too sure...

JLV: Well, that did seem harsh but maybe the guy is familiar with your postings. I'll defer judgement...

cow: Just like them you cant actually write an example to back your statement, all you share is petty 5 yo insults.

JLV: for about 3 minutes. Ledru does seem like he knows his shit. Whereas you confuse your arse with your mouth when you talk. OP didn't have to share an example, you did.

cow: Theres a thing called time....

The article clearly says he did not know RUST at the time he was writing commentary ...

NOW v THEN, very different contexts, and he had very different knowledge about RUST.

But hey give you cant even form a sentence hardly a shock you cant grasp the concept of "time".

[Throatwarbler Mangrove]

Re: I am not too sure...

Fine. Here are several examples.

[CowHorseFrog]

Re: I am not too sure...

Learn to write like an adult...

Quote what i said and then make a statement and reason WHY its wrong.

Others are not wrong because YOU say they are wrong w/out reason, this isnt North Korea and you dont have a gun at osmeones head.

[Michael Wojcik]

Re: I am not too sure...

To be fair, you have an almost perfect record of being a complete arse.

Perhaps, but I'm inclined to agree with the direction, if not necessarily the magnitude (and then only because I haven't tried to measure it), of CHF's original claim. I have read, debugged, fixed, adapted, and maintained a lot of open-source (and proprietary) code over the past few decades, and most of it is moderately to severely terrible.

That seems to hold independent of language, platform, purpose, etc.

Many of the programmers I've encountered haven't read the specifications of the languages they use. They don't read the documentation for frameworks and APIs they use. They don't try to write maintainable code. They don't prefactor or refactor. They're sloppy at applying design patterns, if they use them at all. They don't check for failures. They manage to commit any number of sins against security. They attempt things they don't understand. They have a poor understanding of issues such as race conditions and deadlock.

The industry has set the bar for software development very, very low.

[CowHorseFrog]

Re: I am not too sure...

Thanks for your observations....

THeres a parallel beetween comments against me here and OPENED source control... in both cases we can see how piss poor the efforts are to write comments with some thought. Just look at the replies against me, here soo many pathetic childish names, they all claim how i am wrong here, and yet they cant even form a single sentence that proves how my statements are wrong.

Most people here cant even write more than a line, and the best they can write is calling me names... its exactly the same in software they cant even write a proper validation of inputs and messages, because writing a few lines here or there is just too much effort.

[CowHorseFrog]

Re: I am not too sure...

michael

Perhaps, but I'm inclined to agree with the direction, if not necessarily the magnitude (and then only because I haven't tried to measure it), of CHF's original claim. I have read, debugged, fixed, adapted, and maintained a lot of open-source (and proprietary) code over the past few decades, and most of it is moderately to severely terrible.

cow:

isnt moderately to severly terrible that different from my comment ?

You obviously picked the better projects to enhance (lets call it that) and you have made a comment how poor they are... So what about the other projects that you skipped ?

THere are several easons why you skipped them,

1. they dont solve your problem.

2. they do solve your problem but they are crap.

You have basically confirmed my statement that most softaware engineers are very poor at their work.

If you wish to reply, please comment on the very basics, dont even try and worry about design patterns and their application, please comment about how "poor" messages are, where messages can be for logs, output, validation fails etc...

[Dostoevsky]

Re: I am not too sure...

I've ported some FORTRAN numerical analysis code to more modern languages (including Rust!) and I can testify that FORTRAN is arcane, but still amazing.

[Rafael #872397]

Human perversity...

Human perversity will probably ensure people are still hacking away in ISO C42 and using -std=c89 to retain K&R function definitions.

Human perversity will probably ensure that in some years we will have several languages to choose from, each a candidate to replace C.

Quoting from memory: "To the person who, even now, is creating the next great computer language" -- Bruce Eckel.

(and where's the icon for old fart??)

[rgjnk]

Evangelism

Maybe I've become too cynical but 'isn't this thing fantastic because reasons' always hits me as based more on faith than reality. Good for those who believe, though I lean more towards cold reality.

Open source isn't forever, it just gives you a better option than starting from nothing. *Someone* still has to understand and maintain the stuff even to resurrect it, and for any non-trivial project that can be hard work especially if you only think you understand why and how things were done which isn't always obvious.

And Rust certainly isn't the great saviour however hard people push, just like the many past hypes haven't been. It's just another option, not necessarily better just different.

As for porting existing old stable projects, I guess it's something to do if you're bored enough but who wants to spend the effort and risk the inevitable new quirks from fiddling with something old, stable and tested? Good for a play but reinventing the wheel with the new shiny shouldn't be an end in itself.

[jonha]

What about APIs?

In theory that is all well and good and I agree that FOSS has great potential to live forever (and I do think the language doesn't matter as much as some believe). However, it all depends on how the code is actually structured. Code which sits directly on the API layer is possibly faster and perhaps can do "fancier" things than code living on one or more layers of abstraction but if the API layer changes, or worse, disappears altogether, will become harder and harder to maintain or becomes obsolete.

Even for code using abstraction layers, there can be huge differences between the depth and breadth of the underlying abstractions, directly influencing the expected "lifetime" of the source code.

[Howard Sway]

All current code relies on an ecosystem of languages, skills, tools and, above all, relevance

And like any ecosystem, Darwinian rules apply. So if something new is found to be clearer / more secure / easier to program / more functional, it will be gradually adopted and slowly replace whatever went before. It will be subjected to lots of real life use and properly tested, so it will only become the new standard once it's proved itself as a worthwhile improvement. Otherwise it will be a pointless mutation and go extinct. This is the most idealistic theory of FOSS.

The main danger is that human nature has a tendency to go "ooh look! new! shiny!" and mistakenly fall en masse for something new but inferior, so it's vital that quality control is kept paramount to avoid marrying in haste and repenting at leisure.

[Anonymous Coward]

The delicious promise of open source software is eternal life :o

The main benefit is that one can contact the programmer directly if one has a problem installing and running the code. And you won't have some software company performing a forced audit on your business.

[klh]

Re: The delicious promise of open source software is eternal life :o

That benefit is sadly one of the primary reasons FOSS maintainers burn out.

Also there should be forced audits, you'd be surprised how many times even senior programmers don't bother checking licenses and put (A)GPL code into proprietary software.

[Charlie Clark]

Re: The delicious promise of open source software is eternal life :o

I normally ignore direct e-mails regarding my projects unless people want professional support.

[CowHorseFrog]

> Ledru started the project for very personal reasons: as a director at Mozilla, he was surrounded by Rust creators in an entirely managerial job, and he wanted to learn Rust.

the guy in charge doesnt know how to program.

What a joke...

Just think how much better the world would be if we didnt have bullshitters and idiots *IN CHARGE*...

How much waste is there in the world due to idiots at the top, w/ their bullshit and fake bad advice.

[sgj100]

If you had taken the time to use the search engine of your choice before writing an intemperate post you would have discovered that the "idiot in charge" is very much a programmer.

https://sylvestre.ledru.info/CV_sylvestre_LEDRU_english.php

[Roland6]

A simple reading of the article, as opposed to a quick skim, would also have led to the same discovery.

[CowHorseFrog]

And if you read the article you will see he was in CHARGE about a language he didnt know at the time.

Maybe its me, but i would rather a surgeon has the skills BEFORE they start operating on people.

[Anonymous Coward]

So a (highly) competent programmer who hired people who have specific skills he does not (but is clearly able to learn on his own time) and who can take time to discuss any specific detail before it is acted upon; which action can be reverted.

You truly expect us to equate that to a person engaged in cutting into a human body: no time for debates and white board sessions, no way to revert the slice just made.

Just a highly emotionally charged strawman, meant to evoke a knee jerk response from the audience.

[CowHorseFrog]

AC:

Anonymous Coward

So a (highly) competent programmer who hired people who have specific skills he does not (but is clearly able to learn on his own time) and who can take time to discuss any specific detail before it is acted upon; which action can be reverted.

cow: thats not what the article said. Ever heard of quotes ? Try quoting next time rather than rewriting words giving a totally different meaning.

[Youngdog]

Huh?

You are having a pop about someone being innately curious enough to learn a new programming language? It's not like he went on record saying "Code? I'd rather eat my own feet. What do you think we pay these weirdos to do all day!"

[CowHorseFrog]

Re: Huh?

No i have a problem with a person being assigned as a subject expert making decisions on a topic they dont know have experience or knowledge.

THe experience and knowledge should come before the decision making responsibility.

I would have thought that was obvious ?

Do you really want surgeons to operate on people BEFORE they learn and get qualified in their craft ?

[Anonymous Coward]

Re: Huh?

Repeating the same deliberately emotionally charged strawman.

I Name Thee: CowHorseFrig, POLITICIAN!

[CowHorseFrog]

Re: Huh?

No im not repeating im challenging you to actually take up the intellectual challenge and quote one of the wrong things i have said and then introduce your own commens that prove me wrong.

So why cant you manage that ?

Go on, i dare you... QUOTE a single statement i have made from my comments, and do a proper job, QUOTE enough text to provide context and then make your points... no petty insults like a 5yo...

[klh]

Re: Huh?

Have you never worked in a company with directors? They are so far from development it doesn't matter if they know the specific language used - they don't make decisions at that level.

[CowHorseFrog]

Re: Huh?

Thats part of the problem im highlighting...

You just admitted idiots are making decisions because they are uninformed and you cant even make a comment how wrong that is.

[CowHorseFrog]

Re: Huh?

article: Ledru started the project for very personal reasons: as a director at Mozilla, he was surrounded by Rust creators in an entirely managerial job, and he wanted to learn Rust.

klh: Have you never worked in a company with directors? They are so far from development it doesn't matter if they know the specific language used - they don't make decisions at that level.

cow: How exactly does a "director" direct a company if they havent a clue how it all works ?

[Anonymous Coward]

Re: Huh?

No i have a problem

If only you had stopped there. The guy does have experience and might well have subject matter expertise - this could well be why he was in a managerial role. His actions in taking the initiative to learn Rust also suggest he readily recognized his limitations in that aspect of the work, and had a good appreciation of what his people doing the work were bringing to the table.

You on the other hand are demonstrating a narrow-mindedness that suggest that you would be a nightmare to work with, particularly in any management role.

[CowHorseFrog]

Re: Huh?

AC: The guy does have experience and might well have subject matter expertise

COW: He DIDNT have rust experience at the time he was MAKING DECISION ABOUT IT.

Im not talking about NOW, im talking about THEN... two totally different TIME periods.

[Anonymous Coward]

Re: Huh?

I don 't know the guy but there is the website that has been posted elsewhere. But my knowledge of the guy is not important as I would be willing to bet you don't know him either. What I find particularly egrigious is your assertion that he being not experienced with Rust made him incapable of making sound decisions with respect to a particular program that he was managing. From what I have read I believe he was a manager sufficiently experienced with programming and other project matters to make sound decisions.

It is a general truth that effective managers need not be experts in every aspect of a project. What they need to be able to do is assess the information they are being given by the experts they have put in place and to balance their needs against competing needs, the objectives of the project, and an assessment of the risks involved to reach a decision. The most effective managers I have worked with have been those who are able to follow a reasoned argument and apply logic. I have not always agreed with their decisions - but then sometimes there is no clear cut solution to real life problems, and my preferred choice did not get put to the ultimate test. Sometimes broader 'political' concerns trump local narrow concerns.

I find your persistent narrow focus in your assessment of this concern entirely insipid. It leads me to conclude your points have no merit. If you were arguing your point in a project meeting I would dismiss it. No great hardship I am sure, but for the love of god - read the room.

[Anonymous Coward]

>> he wanted to learn Rust.

Note that - learn Rust.

> the guy in charge doesnt know how to program.

No, he wanted to learn Rust - which he did by reading C code. He already knew how to program, just not in Rust.

> What a joke...

True, your ability to read and understand is s joke. But your posts always give us a good laugh, as you strawman away.

Guessing you want enough strawmen around to win the village fete; but will you ever find enough old scarves?

[klh]

I would hope he didn't actually read the coreutils code while making the Rust version. That would make it a derivative work.

[Michael Wojcik]

No, it would not. Certainly not under US copyright law (Title 17).

[CowHorseFrog]

Yes he wanted to learn RUST, so why is he incharge of making decisions about using RUST when he had no knowledge AT THAT TIME ?

[SCP]

Because he is an experienced programmer capable of assessing the advice of his experts regarding the merits of a new programming language and balancing that with other programme needs.

[heyrick]

While C and its offspring remain popular, it is losing relevance.

Just count the number of Hot New Shit trendy languages that have come, and some gone, since C. Once upon a time Java was going to change the world. Or Swift. Or Python. Ruby. Go... Not to mention all those languages with punctuation symbols stuck on the end. Now it's the turn of Rust. And just when we're about to settle down to a nicely oxidised life, some Hot New Shit will be released which will be a fix for everything that is wrong in Rust, and this cycle will start all over again...except maybe by this time it'll be half done by humans (the bits that work) and half done by AI (the rest).

[Charlie Clark]

Re: While C and its offspring remain popular, it is losing relevance.

I'm pretty sure C will be around for a long time, but so will most of the other languages you mention. Programming covers more domains than it used to and is used by an increasingly diverse set of people for tasks that you wouldn't want to use C for.

But Rust does seem to have come the closest so far to replacing C in some of its key domains.

[Michael Wojcik]

Re: While C and its offspring remain popular, it is losing relevance.

Python is hugely successful, particularly in scientific computing. It's currently at #1 in the TIOBE index.

Go is at #5, just below Javascript.

Swift is down to #17, while Rust is currently #13.

Swift might be a bit of a niche language at this point, but Rust is doing just fine.

Yes, new languages are invented. Some of them become successful; others remain obscure. Why people feel the need to whinge about this obvious fact over and over again is beyond me.

[b0llchit]

Waiting for systemd to intervene

When coreutils are eventually systemd'ed, then we're running.

/s

[bazza]

Re: Waiting for systemd to intervene

That systemd is written in C is something like a bad joke. There were myriad better languages for the job at the time they kicked off the project, but no, Poettering chose C and has stuck to it. Talk about maximising the chance of security flaws leaching into the code (which is what’s happened).

With the a Linux kernel adopting Rust, systemD is going to start looking very obsolete, very unmaintainable, and very dangerous as well as completely unloved. Who is going to want to work on that project in the future? And unlike coreutils I can’t see a major rewrite project wanting or enjoying simply recreating systemd in Rust. I know there’s small projects doing just that, but surely a major project would take the opportunity to fully de-Poettering it once and for all.

[Paul Crawford]

Re: Waiting for systemd to intervene

systemD is going to start looking very obsolete, very unmaintainable, and very dangerous as well as completely unloved

You mean its not already?

[Doctor Syntax]

Re: Waiting for systemd to intervene

The problem with systemd isn't the language.

[bazza]

Re: Waiting for systemd to intervene

SystemD is indeed riddled with problems.

Even if one were a fan of it, most would probably agree that writing it in C in the modern era (or even at the time of its creation) is not a good idea.

[martinusher]

How about PL/M?

I did some work for BT in the early 80s and while the development systems used 8" floppies (!) the code deliverables included giving them copies of the source code on mylar punched tape. This was reckoned at the time -- and likely still is -- one of the few relatively permanent mediums. Paper tape will deteriorate, Mylar's for the ages and, worst case, you can read it by hand.

(BTW -- PL/M is simple enough to be able to reconstruct a compiler. Or we could just translate the source into 'C'. Whatever.)

[yetanotheraoc]

details

"There are 60 to 70 of them, most of which you'll never use."

info coreutils on my system shows 103, starting with arch and ending with yes. Can do a lot in text with only those! Although I suppose manipulating audio and video media is lacking. At a quick read and going only from memory I have recently (last 5 years) used 64 of those in a terminal or script. But as the package name suggests, probably _all_ the Gnu/Linux OS depends on them in some way or other.

"had some performance advantages"

I was wondering how this could possibly be true? At best it would be equal. I guess if you are in Rust code and need to shell out to a coreutil, that's when having a Rusty coreutil available will be more performant.

It's all cool though. If Rust or some other language is ever to make C "antique" (not saying this will happen or that I want it to happen), re-implementing coreutils and other low-level bits is a necessary step.

[Michael Wojcik]

Re: details

I suppose manipulating audio and video media is lacking.

Lacking? What's wrong with base64, cut/echo/etc, base64 back to binary? That's how Real Programmers do it.

[vaibhavsunder]

But this

Tell this to archive.org and its owner who are struggling to save old IBM and open source data. :)

[G40]

So when I port

Coreutils to modern c++, I can expect to read a similarly unquestioning review?

[Dave559]

Tardigrades

Regardless of anything else in this article - and don't get me wrong, the story is a fascinating enough read in tself - it deserves an upvote just for the mention of, and comparison with, tardigrades, very hardy wee beasts that they are!

[fg_swe]

Myopic UNIX View

A thorough study of computer history will reveal that C, Unix and Windows are by no means the only "basis" of systems programming.

Rather, C and Unix (and Windows) can be seen as the Hamburger of computing. Quick and dirty, unhealthy creators of the Cyber War Domain.

Algol was already a memory safe alternative to C and Unix in the 1970s. It contained a lot of solid European technology. The beef steak with hand made noodles and a proper salad, in the meals analogy.

Unlike C and Unix, Algol mainframes were not given away "for free" though.

[Anonymous Coward]

Re: Myopic UNIX View

What was the point you are trying to make?

TFA was about someone who happened to be au fait with coreutils and used them as an entirely voluntary and personal choice to learn Rust, out of personal interest because he happens to have colleagues who use Rust. Then it seems he did a good enough job in his learning exercise that others are interested.

How is that tale in any way myopic? He reacted to his personal situation.

Are you complaining about the focus of the rest of the article? Which uses the example, explains what coreutils are all about and then uses that to make a wider point about FOSS and code longevity. A point which is not in any way limited to just the specific example of coreutils and how the are used.

By all means, have some kudos for reminding us of ALGOL and that it is still around (just like previous comments have pointed out that FORTRAN is still around, as is COBOL).

But do you want to explain the title and strange non-sequitur initial sentence? Or were you just feeling peckish and wanted to talk about food, apropos of nothing?

[fg_swe]

Re: Myopic UNIX View

My opinion is that C should be taken down a notch or two. Some commenters depicted it as a forever-standard.

That was the objective of my post.

[that one in the corner]

Re: Myopic UNIX View

> My opinion is that C should be taken down a notch or two.

As soon as there is something as easily portable to as many targets[1], and with as at least equal ability to produce efficient code, that is easier to use and standardised, then C will quietly lose its ground. You don't need to do anything to make that happen, other than give your all to help create that new tool: calling use of C myopic[2] - or any other rude comments - will not affect its usage one iota.

> Some commenters depicted it as a forever-standard.

Given we are talking about longevity of code, and the current existence of 50 years of C code, even if a viable replacement tool comes into full fruition next Sunday (and Rust isn't grown up enough, yet; soon, maybe) C compilers *MUST* stay in existence for decades to come, if only to allow all the extant code to remain compilable until it is *ALL* replaced by new code.

C has a standard (unlike some...) and compilers to that will exist for longer than you or me. Which is Good Thing. Just as Fortran compilers still live on and have their forever niche.

[1] BTW, note that "many targets" includes all of the microcontrollers; and although there are increasingly large MCUs available, which can run greedier code for hobbyists/small run production, mass production runs will always want to save pennies on BOM.

[2] again, a weird thing for you to have said, as TFA was explicitly about someone who HAS made great strides in moving some code away from C! And Unux (well, Linux) is THE place where Rust has more traction, trying to move away from C!

[Doctor Syntax]

Re: Myopic UNIX View

Unlike C and Unix, Algol mainframes were not given away "for free" though.

You seem a little muddled - C and Unix are software, whatever hardware they run on, mainframes, whatever languages might be available on are hardware. it's not normal for non-mainframe hardware to be given away either. I'm bretty sure IBM doesn't give away its Z-series mainframes, not even if they're running Linux - which is available for them.

Initially it wasn't even allowed for AT&T to sell software due to the settlement of a monopoly investigation. What they did do was give away copies to Universities under extremely controlled conditions. Many of those who used those academic installations came to want to use them in their everyday work and many of those who didn't use them in that context (including myself who was already a bit long in the tooth to have had that experience) but had heard of them also wanted to use them in their everyday work. Disregarding the distribution of BSD, when it became possible for AT&T Unix to be licenced it most certainly wasn't given away "for free" (whatever your weasel quote marks might mean) - it was sold for Real Money. In fact, if SCO hadn't been so expensive it's possible Linux might never have got off the ground.

I spent a good part of my working life also earning Real Money from businesses who had most definitely paid for their Unix systems. The manglement of one of them never the less seemed to share your view of their value. That manglement's preferred platform was VAX/VMS which for years was always going to swallow our Unix systems' functionality in six month's time. I wonder how that worked out for them in the long run (the Unix systems were completing their 2nd migration to ever bigger boxes when I left).

[fg_swe]

Errata

Must read "Algol system software was never given away for free, Unlike C/Unix"

[fg_swe]

Algol Use

https://stackoverflow.com/questions/1463321/was-algol-ever-used-for-mainstream-programming

[John Klos]

Fifty years?

Rust from two years ago can't compile rust (the toolchain itself) now. Do we really have so little foresight and such bad memory that we'd believe that rust code written now will still be compilable 50 years from now?

[that one in the corner]

Re: Fifty years?

Much as I wish for a Rust that is less of a moving target, your point is misaimed.

The specific case you cite is absolutely normal when bootstrapping any language's compiler.

> Rust from two years ago can't compile rust (the toolchain itself) now.

For Language X, Compiler V1 is coded in - anything you like, even BASIC. V2 is coded in V1 and adds features F2. V3 is coded in V2, using features F2, adding F3. V4, coded in V3 using F3, adding F5. And so on and so forth.

Trivial observation: compiler V1 can not build compiler V3; V2 can not build V4; and so on and so forth.

> rust code written now will still be compilable 50 years from now?

BUT, unlike bootstrapping, where you are asking if older compiler can manage newer code, NOW you are asking if newer compiler can build older code.

To which the answer, as you already know from existing examples, is: YES!

In the Good Case, it is really easy, because the compiler, over the next 50 years, added backwards compatibility flags: take a look at GCC. Nice and easy.

In the Bad Case, you have to dig up an older copy of the compiler. Drat, all the hardship of getting the release from GitHub (or wherever) and looking up articles in the Way Back Machine.

[John Klos]

Re: Fifty years?

You're not wrong, but that's not the point I was making.

gcc 10 can compile gcc 11, gcc 12, gcc 13. It's quite normal to have a toolchain in use from several years ago that's still relevant and useful now.

rust from a year ago can't compile Firefox. rust from a year ago can't be used to bootstrap rust from now. So if you have a modern system that was 100% up to date a year ago, you have to - no exaggeration - compile newer but not new rust, which then you use to compile even newer rust, which you can then use to compile Firefox.

Sure, everyone downloads binaries, but that's not the point.

It's not sustainable to imagine finding a specific version of rust from a specific part of a specific year if you want to compile a certain version of a package like Firefox. It reminds me too much of how every IT person used to have an old laptop around to run a specific version of Java, along with some older Internet Explorer, because Java breaks too many things, and our "write once, run anywhere" promise was more like, "if you want to configure your fibre channel switch, you'll never try to use a JRE newer than X".

[that one in the corner]

Re: Fifty years?

> gcc 10 can compile gcc 11, gcc 12, gcc 13.

Look at those version numbers and the maturity of the specific complier; now compare those to the maturity of Rust; now compare GCC (or other toolchains) when they were at the same level of maturity.

> It's quite normal to have a toolchain in use from several years ago that's still relevant and useful now

I never throw a toolchain away; my build system includes a copy of VC6 (the extant compiler when the build setup was started) and all of the compilers (mainly GCCs now) that have been used, right up to date. It really pisses me off when a compiler only comes as an installer that insists it is the only copy on the machine and even has to always be on PATH. Do not get me started on bleeping Arduino V2 that does not support a "portable" install. Anyway, back to your points.

> rust from a year ago can't compile Firefox... It's not sustainable to imagine finding a specific version of rust from a specific part of a specific year...

True. And for that, you need to point your anger at Firefox et al, who are knowingly using a toolchain that is still in the state of flux that every language starts with - and are doing so in production releases[[1], not as a parallel project preparing for the Rust developers to develop their toolchain.

The problem that exists today is people using for production releases a toolchain that is not yet ready for production use. Those same people would have been equally reckless around any other shiny, new and nowhere near standardised language. From that p.o.v. it is still not Rust's fault, qua Rust, yet another programming language; qua hype surrounding Rust and and the apparent urge to be visibly cutting edge, no matter the pitfalls, that is certainly at fault.[2]

But you started by talking about using Rust in 50 years time - a time frame that will either see Rust long settled into the maturity of GCC, with all the backwards compatibility flags, or will have seen Rust failed and excoriated decades earlier, as the issues you point out make even the Firefox team rebel against the Rust developers.[3]

I remind you of my opening line:

>> Much as I wish for a Rust that is less of a moving target,

That will come, or Rust will never make it to 50 years. Well, only as a relic that you can download from the Wayback Machine as a giggle.

[1] Worse, I have no doubt that they are proudly tracking point releases and compounding the problem.

[2] And jumping onto things and shoving them into production just because they are shiny is not restricted to Rust.

[3] Or everyone will have *finally* stopped pissing around with mediocre build systems and firing off builds with dozens of different compiler versions involved becomes no more difficult than typing "make" and leaving the machine to get on with it. Fat chance.[4]

[4] cue "but all the projects using Build System X already have that, to which the response will have to be "Yes, yes, but is everyone using X?". Anyway, that is a red herring (more of a bete noire, but I don't know to type accents on this device).

[Anonymous Coward]

Confusing article

This article is confusing, it gives the impression that the "coreutils" project ("https://pkgs.alpinelinux.org/package/edge/main/x86_64/coreutils") is reimplemented those utils in Rust where the article actually appears to be referring to the independent "uutils coreutils" project ("https://github.com/uutils/coreutils") which is implementing Rust written utils *compatible* with some/many of the original coreutils utilities.

In a similar fashion Busybox has provided (partly) compatible versions (though written in C) of some coreutils and util-linux and other utilities for quite some time.

[Anonymous Coward]

Re: Confusing article

Huh?

The article seemed very clear: it even explicitly says that the code was a new project, from scratch, and that he even choose to use a new licence.

Nor did it imply anywhere that this is the only new copy of (some of) the same utilities; it even says that coreutils is a good project if you want to learn by reimplementing, because there is a rich set of tests and documentation built up over time.

[JoeCool]

i appreciate the sense of wonder and entusiasm in the write up

but it has the weird tang of blueberry koolaid, and the feel of charlie in the chocolate factory.

[geoff61]

chmod without octal

"Ever used octal? You will with chmod."

I am a frequent user of chmod and I can't remember the last time I used it with octal. It's almost always quicker and/or easier to use its symbolic capabilities. For example, a command I use a lot is "chmod a-w file" to make a file read-only. To do the same using octal would mean performing these steps:

1. Use "ls -l file" to see the current permissions

2. Mentally work out what the new permissions will be without any w's

3. Mentally convert the new permissions to octal

4. Use "chmod octal file" to set the permissions

5. (optional, but a good idea) Use "ls -l file" to check the permissions came out right

Even if you want to set the permissions to something fixed, there's no need to use octal. Want read+write for the owner and just read for group and other? You can use "chmod u=rw,go=r file" - slightly more typing than "chmod 644 file" but no mental gymnasitcs needed.

[Anonymous Coward]

Re: chmod without octal

> To do the same using octal would mean performing these steps...

Or just remembering a few classics for those repeated tasks - and making use of the symbolic options (or even, gasp, using the built-in help) for those cases that only come up once in a while.

Also, it is a very good idea to use the long-winded options when writing up procedures, so they are not just "magic steps" (also giving the shorter equivalent in a sidebar is okay and a friendly gesture).

Bottom line: humourous quip in El Reg article points out way of working that some like, some times - and maybe the readers would like to give it a try? You might like it (or not, your choice).

[Michael Wojcik]

Re: chmod without octal

Indeed. I've been able to do the main bits (rwx for user/group/other) in octal in my head since sometime in the '80s, and I'm sure plenty of other people here can as well.

[An_Old_Dog]

Re: chmod without octal

I started out with Unix a long time ago and can correctly do octal permissions from memory, but can't do the alphabetically-coded ones without first looking at the man page.

Just as I've memorised [SRWECMFA] - Supervisory, Read, Write, Erase, Create, Modify, File scan, Access control - Novell file permissions, but have to look up the Microsoft version of them every time.

Different strokes for different folks.

[Roland6]

Re: chmod without octal

>” You can use "chmod u=rw,go=r file" - slightly more typing than "chmod 644 file" but no mental gymnasitcs needed.”

But that isn’t in the spirit of Unix... :)

Dim memory, suggests “chmod octal file” was the only option until the mid 1980s.

Also if I remember correctly, if you do a script involving permissions lookup and amendment, you’ll be needing octal.

[Michael Wojcik]

While we're picking nits...

Proprietary code goes unpublished: if its host company dies, it probably dies with it the moment the servers are wiped.

Probably? Perhaps. On the other hand, I just delivered an installer to a customer for a proprietary package originally written in the '80s and not updated for the past twenty years or so; that product has gone through five owners so far. Proprietary code can be plenty durable too.

On the other hand, as others have pointed out, a significant amount of open-source code has vanished entirely (if it was pre-Internet Archive, and not archived by someone else or of sufficient interest to carry along) or now goes ignored. How many rump projects are on Sourceforge and similar has-been sites?

Y2K was made many times more difficult because of old COBOL and the like where most of that ecosystem was on the edge of extinction.

COBOL was doing Just Fine in 1999, and still is today. It may not be popular with the kids, but believe me, customers are still buying it.

The pool of C programmers will shrink over time, and at some point the language itself will become an antique.

The persistence of Fortran, COBOL, and LISP suggests this point will be far in the future. Legacy programming languages take a long time to die.

I like Rust — yes, it's more difficult than C, and that's an advantage — and I like seeing it used more. Rewriting coreutils is a good and useful exercise. But extrapolating these things to the end of C is rather a stretch. Technologies persist. People still weave baskets from reeds and hunt with bows and arrows and make buildings from mud (I live in an area where the last are common). I've knapped stone points and carved tools from antler and jewelry from bone. Just a week ago I rode a horse. There may still be C code running when civilization collapses.¹

¹Currently scheduled for 2032, I believe.

[StrangerHereMyself]

Productive

Although I don't want to deny anyone his or her fun, it would've been more productive to write a microkernel in Rust to replace the Linux kernel. Like the article says the coreutils have been bug and security free for decades.

IMHO the most important aspect is that source code is open and free to use and modify. The language itself is merely an afterthought.

[hh121]

A century you say

Wishful thinking is probably being kind. Delusional might be a bit more appropriate. As convincing as the argument that all open source code has a million eyeballs on it so it must be safe. As a grey beard, it seems like the IT grads I come across are getting further and further away from the guts of systems engineering into whatever today's abstract niche for job security might be. Can't see the attraction of the legacy stuff for the newbies. I'd be more inclined to believe there will be more of this (https://www.theregister.com/2024/07/25/ibm_q2_2024/) leveraging AI that actually works (if it ever does) to translate old platforms into (slightly more) modern ones, or maintain them, but that's probably wishful/delusional thinking too.

[Herby]

Then we look at written/spoken lanugages

We started long ago with Latin, and went from there. Maybe modern languages aren't "type safe", but we use them all the time. No one these days will say that English is obsolete, but it could happen, you never know. Then what would we do with keywords "case" "else" "if" "then" (to name a few). The mind boggles.