The Great Rewriting in Rust
deprogrammaticaipsum.com
deprogrammaticaipsum.com
The question is not "will some new hotness come along to usurp the old hotness," the question is "will the new hotness make software any better." Unless the answer to this question is a resounding "no" (even "probably not" is acceptable), maybe people should try. Please stop complaining that people want to find ways to pioneer in their fields rather than just retreading old ground.
Also, many of the best Rust ideas have been backported to it.
I wonder if it’ll still be in second place after whatever new hotness replaces Rust in a decade.
However, I can't see Ada thriving without fixing their licensing. But on the other hand I don't know how well the Ada vendors could survive without charging for their compilers/toolchains.
It was developed on the same building as UNIX (so to speak), as C pre-processor with no additional requirements on C's toolchain.
That made it quickly available across all UNIX platforms and respective toolchains.
Then it followed C as younger brother alternative in any C toolchain that mattered.
A few UNIX vendors, e.g. Sun, did offer Ada compilers, but it was naturally an additional software package to buy, and not everything was available, thus additional hurdles to write FFI bindings.
Not bundling a language with a platform is always an issue with system programming languages.
I want to be great at Rust, but I’m nowhere near there. Getting basic things done like defining functions, passing data remain challenging every single step of the way.
For this reason alone, Rust will remain the domain of dedicated and motivated programmers.
It’s never going to be crowded in this community.
Unless of course I’m a slow witted dunce, in which case, maybe Rust ain’t hard.
Rust is targeted pretty much as a C replacement. And the thing is, you have to do the borrow checker's work when you program in C too.
You must know whether it's copy-by-value or a reference. If it's a reference and it needs to be a copy, you must do that manually. You must know how many threads are accessing something by a reference, and you must guarantee that more than one thread is not writing a non-mutex variable at the same time. You must know when your objects are created, where they go (heap? stack?) and you must track those objects over their lifetime, and then you must free them at the end. (Or tell a garbage collector about them, and remember to run the garbage collector periodically.)
Except a C program still compiles when you don't get that right. And then it segfaults. Rust's borrowing model ends up enforcing much of that as language policy, rather than just good programming style. It's a bit like how you have to cast types explicitly in many languages (including Rust, of course). Any implementation can wrap an integer used as a pointer to guarantee you're not pointing into dead memory. But when the compiler knows the type explicitly, it can often generate fast unwrapped code that is safe and will not crash. All of this comes with explicitness which is burdensome to the programmer, unfortunately.
Sometimes you need to state, explicitly, what should be obvious to allow the compiler to show something is correct and fast. In this regard, Rust is, at least, nicer than C, even when you have to fight the borrow checker. (In my opinion.) Which is probably why it's growing so fast. I don't expect it to displace more than the C niche of systems programming, though.
A simple emulator in a C-style might consist of a UI thread and a compute thread. The UI thread sends messages to the compute thread. You can have some timing though not usually safety/crash issues if you do this without locks. So maybe you do or don't lock that. But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. Simple, fast, almost-safe.
How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? It's hard to get that right.
You can use atomic types with custom memory ordering, just like you would in C.
Specially when that high level language was Ada, Modula-2, a Pascal dialect like Turbo/Quick Pascal, or a compiled BASIC, yes really "Why?! WHYYYY?!"
Rust especially, thanks to the efficient hypemachine, will have the problem of people wanting to learn it but not having anywhere to apply it immediately. I actually have a similar problem with French.
Another thing worth mentioning is that while being a great language Rust is still a tool. Designing the architecture, algorithms, logic of the system, refactoring are much more difficult than the language itself in my opinion.
IMHO, programming in Rust is no harder than C++ or C. It just forces one to be explicit about lifetimes and ownership, concepts one should be carefully thinking about in other systems programming languages.
Or put another way, C and C++ make some things easy when perhaps they shouldn't.
I'm trying to understand the uptick in references to these projects. Neither are widely used at all, maybe a supercomputing lab here and there, but it's very much in the early stages.
As for its current state,