TL,DR;
Ubuntu announced that will replace GNU with a new Unix toolset written in Rust. Why not Ada?
Dear.all,
I just “tripped over” this video about the announcement of Ubuntu that in the future it will replace GNU with a new Unix toolset built (us I understand) with Rust.
My first reaction was: why not Ada? Better yet, why not having the whole toolset formally checked with Spark?
I watched the video just five minutes ago, so this is written surfing the tsunami of enthusiasm… and I do not have any detailed plan in head, but… (writing as the thoughts come to my mind, brainstorm-like)
The different tools (ls, cp, rm, …) could be developed by different groups in parallel, since (I would say) they are fairly independent
We could involve CS departments in universities, maybe with some hackaton
It would be useful a layer to interface to the Linux kernel. Maybe one thin layer and a thicker one with a more Ada-ish interface (developers would mostly use the latter)
Of course, we need a coordination center, at least to decide on high-level architecture and dispatching tasks to other groups
Maybe it would be a nice idea to get in touch with Ubuntu and coordinate with them
I have seen a criticism that this Rust project is a poor choice because most of those tools are battle tested with low bug reports and Rust will bring new bugs. So you could argue Spark counters that and maybe get Ubuntu backing but I imagine this is to do with Microsoft’s romantic affair with Rust and so technical arguments might not win out. They do look like all rather simple tools though so they might as you say make good student projects. I guess code quality might be a concern
Considering quirks of the file system with its links, pseudo-folders “.” and “..”, network drives, compressed folders, thumbnails etc. What about notification of changes, dirty caches and so on and so forth?
I think logical algorithmic errors would play here the key role.
Because posix has varargs and rust can do that, whereas Ada cannot, and no the new variable argument overloading doesn’t count. But yes, for the upper layers.
But for the OS I am planning, I will likely be using a rust posix lib.
Because they want to transliterate, not actually rewrite.
(Note that a rewrite would entail leveraging the new language’s strengths.)
They definitely aren’t going to be redesigning; to be blunt, Linux/Unix are stupidly stuck on unformatted-text — the sensible thing to do would be to have the underlying [i.e. OS-level] system be at least three typed-streams: one input-data, one parameters/switches, and one output-data. (The parameters would be structured and typed, and the parse-engine would handle things uniformly for all applications; i.e. there would be no funny commandline formats, it would all be handled by the OS’s parsing library/engine.)
Once you leave unformatted-text behind things become so much simpler data-processing-wise— things like ls/dir are now not about returning strings, but records (like SQL), and then, since you’re operating on a set of records, you can do things like incremental search-refinement and proper manipulation of the underlying objects. (See The UNIX-hater’s Handbook.)
This is actually a big problem: “simple” is embraced over correct, especially if the complexity can be pushed onto the programmer. (See string-handling in C.)
No, they aren’t as simple as they seem, nor even as simple as they should be (even accounting for those oddities you mention), because the Unix/C ideology is to make everything simple, to the point it foists more complexity onto everyone else. Just consider for a moment how the “pipe programs together” mentality forces ad hoc processing for the output of the previous process in the chain, trying to recover discarded type information: is the item in column 3 Positive, or Natural, oh-no-it’s-the-text-“Invalid”-and-I-didn’t-allow-for-that-so-now-we’re-in-corrupted-stackland!
Varargs is retarded, especially when you have a good type-system, and easily devolves into some informal structure/protocol: “the last item is an integer describing X”, “the penultimate item controls new behavior, and if value = Y then X is ignored, except if the last item is 0, in which case the third-to-last item is a pointer to a string, otherwise it’s a pointer to a callback of the form W…” — Having typed-streams (with the ability to collect/group) solves 99% of the usecases.
Ada focuses on embedded and not application development. There’s no clear story about how to handle UTF-8 in a consistent way, especially in a way to prevent copying. When I restarted my blog this is expressly why I didn’t write my static site generator in Ada.
Rust has a very devoted open source community using it for real work. They really like the language and like to use it everywhere. Rust natively supports unicode – predominantly UTF-8 – everywhere via strong built-in support which is super easy to use.
This reminds me of how Powershell works and it’s always been a hassle for me to use. Maybe that’s because I grew up using bash.
C++ compile-time parameter packs are super useful for type-safe ergonomics.
That’s not true. Adas design was a “common language for programming large scale and real-time systems” with “three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency”. Ada 95 arguably eroded some of that common part but with some benefits for application development such as better concurrency support than Rust (judging by Dmitry’s recent criticism on LinkedIn). The utf-8 issue is largely historic and I wouldn’t be surprised if Rust has more issues dealing with utf-16 than Ada does. Rust certainly has a lot of string types.
Use Ada.Strings.UTF_Encoding.UTF_8_String; TBH, this probably should be a private-type w/ unknown discriminant.
This is exactly what Limited types are for.
Package Example is
Type String_Thing(<>) is Limited Private;
Function Init( Data : String ) return String_Thing;
Procedure Init( Object : in out String_Thing; Data : String );
-- String-operations
Private
Type String_Thing (Data : not null access Ada.Strings.UTF_Encoding.UTF_8_String) is
new Ada.Finalization.Limited_Controlled with null record;
overriding
procedure Finalize( Object : in out String_Thing );
End Example;
Package Body Example is
procedure Finalize( Object : in out String_Thing ) is
type UTF_Data is Access Ada.Strings.UTF_Encoding.UTF_8_String;
procedure Free is new Ada.Unchecked_Deallocation(
Object => Ada.Strings.UTF_Encoding.UTF_8_String,
Name => UTF_Data
);
Overlay : UTF_Data(Object.Data'Range)
with Import, Address => Object.Data'Address;
begin
Free( Overlay );
end Finalize;
Function Init( Data : String ) return String_Thing is
use Ada.Strings.UTF_Encoding, Ada.Strings.UTF_Encoding.Strings;
Input : UTF_8_String renames Encode( Output_Scheme => UTF_8, Item => Data );
begin
Return ( Data => New UTF_8_String'(Input) );
end Init;
-- …other operations
End Example;
And there you have a string that is guaranteed to have Encode called, and is in UTF_8.
PowerShell is terrible because the object-streams/-commands have absurdly inconsistent names (only Linux commandline parameter names is worse, IMO), no way to interactively query/insert commands, and really seems that the object/stream architecture is bolted-on.
C and Unix were “grown together” —it is incident to say C was designed to write OSes, it was not; it was designed to write Unix… likewise, Unix was written to do an OS in a non-assembly language— the two are intertwined, intimately so.
It would not be inaccurate to say that C/Unix development grew just as bootstrapping a selfhosting compiler grows. It was also widely known, at the time, that Unix was “simple in implementation”, to the point that ‘doing things the wrong way because it’s simpler’ is not an inaccurate evaluation of the design-strategy: in fact, much of the design-flaws in both can be described thus. (This is particularly noticeable on the things that C “lets through” that are detectable in less ad hoc languages; e.g.: C cannot do case-coverage on switch for an enumeration precisely because an enumeration is an alias for int.)
It’s half-true: while Ada was intended for large, robust systems (as evidenced by task), it was imperative that it be able to interface to non-standard hardware at a precise level — i.e. there was no standard for missile- and torpedo-control hardware… but such systems absolutely had to be as correct and reliable as possible. (I mean, we don’t want the system to crash and detonate because it hit 00:00 on 01, Jan 2000.)
varargs is part of C, C was slapped together to create Unix, posix evolved out of unix AND c, posix has varargs all over the place. They’re intertwined, they’re connected, they go hand in hand. What part of that do you NOT understand??
Things like Rust’s “uutils” (or RedoxOS, or PopOS/Cosmic) only happen in big communities with momentum. The Rust rides the safety wave and these “rewrite it in Rust” projects spring out in all corners. Their dream seems to be to replace the “stack” of C programs with a stack of Rust programs in order not to have to ever deal with C and its toolchain. If you dream this big, then perhaps you can justify the rewriting of old, time-tested software in a safer (or a fashionable) language.
There is no way in the universe anyone would spend their time doing a similar project in Ada.
Involving CS departments to help rewrite POSIX utils in Ada?? That’s so enthusiastic.
Contacting Ubuntu, who reportedly are in the process of replacing GNU coreutils with uutils, to consider Ada? Outright whimsical.
This is a list of POSIX utilities: Utilities
GNU extends them and adds more. A rewrite is a monumental task and one that only makes sense as a fragment of a grander idea.
On top of that all, this is often yesterday’s software designed with yesterday’s constraints and offering yesterday’s ergonomics. The real work should be put in design and implementation of tomorrow’s utilities. There’s one project I’m aware of that is pursuing this direction - Sunsetting Cursed Terminal Emulation | Arcan
That’s evidently true. Please notice your own use of the past tense
I see Ada as a relatively high-level language (at a time it was conceived, much less so today) with a low-level standard library and no third-party ecosystem to make up for that.
This is of course only confirmed by Ada’s use across the industry and its marketing.
and I do not have any detailed plan in head, but… (writing as the thoughts come to my mind, brainstorm-like)
