Rust is eating into our systems, and it's a good thing

Rust is eating into our systems. The first Rusted drivers are being welded into Linux, while Microsoft's Azure CTO Mark Russinovich said C/C++ – until now, the systems languages of choice – should be dropped in favor of Rust henceforth.  This is not universally applauded. No change in ecosystem ever is, and language wars have …

[prandeamus]

Pension plan

Even if you don't learn Rust, there's also some scope for C and C++ to become the COBOL of the 2030s. If I live that long, it could well be an addition to my pension.

(If you're thinking of arguing the exact date this might happen, yeah, yeah, yeah, whatever)

[bazza]

Re: Pension plan

Could be. Though if the (probably hypocrophal) wise-old-coders' lore is correct, there's more Cobol been written than anything else so the scope of a C-fuelled pension scheme is less than the one that once existed for Cobol.

We might end up competing for C maintenance jobs!

One of the interesting things might be that, because Rust interops with C so well, maintain old C code might be best done by re-writing the module in Rust.

Another thing that could be interesting, for old code bases, is that Rust seems to be picking up talents in all sorts of areas (web, etc). So if one has a large pile of C that, for example, needs to (finally) get with the Internet, adding that by adding a Rust module could be an effective way of doing that.

[Steve Channell]

Re: Pension plan

Java is already the COBOL of the 21st century, while Java/EE is a slower version of CISC/COBOL in the 21st century. C++ might be the PL/1 of the 21st century.

by far the best thing about Rust is that you don't have to explain why you never switched to unique_ptr<> for type safety ... many of us C++ developers don't have the luxury of rancid buggy code to justify a shiny new toy.

Rust is great, but cpp2/cmake/vcpkg will eclipse it

[bazza]

Re: Pension plan

Ah, PL/1. Never used it, but I did earn some money programming in PLP on a Prime mainframe. Happy days. Seemed to involve a lot of croquet as I recall.

It will be interesting to see how things go. It's been pointed out that Rust is a sibling of Algol66, rather than a descendant. That could have some consequences in the future. IF the academic world starts teaching Rust, rather than any Algol66-derived language (C, C++, Java, C#, etc) then there could eventually be a population of programmers who are entirely used to Rust and all it does for you, and have no awareness of Algol66-style languages and all their characteristics. That could make ancient code bases very difficult to get maintained.

[Mike 125]

we won't go quietly...

"A generation of systems programmers have gone from hip young codeslingers to senior management,"

You say that like it's a good thing. Some of us stayed coding, because done properly, it's just as satisfying and fun as it ever was.

Of course, change must come. No corner of IT, big or small, is single threaded any more. And it's no longer just about execution speed and code size.

So bring it on, young guns. Show us what you've got.

But I'll C you and raise you anyday!

[AndrueC]

Re: we won't go quietly...

I never climbed into management because I preferred to code. Also being in management means spending more time dealing with people and that's just not fun.

I've been through a lot in my time (Basic->BCPL->C++->Delphi->C#. CP/M->MSDOS->OS/2->Windows. By and large things have got easier over time (Basic->BCPL being an exception, lol and there are certainly times when I feel that Visual Studio is not making anything easier) so if I wasn't retiring I'd be investigating Rust.

Being wedded to one particular technology and resistant to change is one of the worst things you can do if you work in IT. It's a balancing act though - leaping with wild abandon onto the next new thing is worse :)

[sgj100]

Re: we won't go quietly...

Nice to see another BCPL user! My first post University job was porting a suite of BCPL code from an IBM mainframe to a Motorola 68000 based S100 system running Cromix, Nowadays, for fun, I use Go which I think has something of BCPL about it

[AndrueC]

Re: we won't go quietly...

It took a while to get my head around the lack of types but the upside was that it taught me more about the low-level side of programming languages whilst at the same time introducing me to hierarchically structured code. And of course a good taster for my later C/C++ work.

[prandeamus]

Re: we won't go quietly...

BCPL ? Me too.

Electronics Dept at Uni of Southampton, wrote an interactive debugger for 6809 and 68K systems for my undergraduate degree. It was crap, by the way, so if anyone bumped into it in later years, sorry. Then worked for Richards Computer Products in the mid-80s.

Lovely little language, if a little eccentric by modern standards.

[Anonymous Coward]

Re: we won't go quietly...

I remember writing in BCPL on a BBC B as a hobbiest. Don't remember too much about it as that was a looong time ago.

[John Hawkins]

Re: we won't go quietly...

"Worse yet, they may become managers who never get to write any code themselves"

Snow Crash, Neal Stephenson 1992

[trevorde]

Meh!

I can write Fortran in any language

[Anonymous Coward]

Re: Meh!..Meh, Meh

I can write any language in asm..

..but dont ask me to write it in x86. I'd rather kill myself. Or watch back to back episodes of Emmerdale Farm for a week. All 168 hours.

Yes, x86 is that gruesome.

[Anonymous Coward]

Re: Meh!..Meh, Meh

Yes, x86 can be gruesome, but PowerPC is absolutely horrific.

[Anonymous Coward]

Re: Meh!..Meh, Meh

And Emmerdale Farm may be bad, but imagine having to listen to the entire run of The Archers.

[Anonymous Coward]

Re: Meh!..Meh, Meh..Emmerdale.

I hesitated a moment between Emmerdale Farm and The Archers. But plumped for Emmerdale Farm as being the most awful. I vaguely remember The Archers being ever so slightly interesting some time in the late 1970's. But that might might have been a hallucination brought on by old age.

[Anonymous Coward]

Re: Meh!..Meh, Meh.. PPC is OK

Wrote quite a bit of various PowerPC starting with the 601. It was OK. A huge step down from the 68K for orthogonality and ease of getting things done. But nothing outstandingly awful.

I'd rate the PowerPC as about average when it came to pain and suffering. You want a painful RISC instruction set, try the SH-2.

[bazza]

Re: Meh!..Meh, Meh.. PPC is OK

Plus, if (hazy) memory serves, one of the philosphies of RISC was that one used a compiler instead of hand writting assembler.

Having said that, I have been the beneficiary of the labours of some extremely talented assembler coders who really, really knew what they were doing with PowerPC assembler, Altivec, and the caches on the CPU. Their employer would occassionally let them out for fresh air...

[Jonathon Green]

Re: Meh!..Meh, Meh

RISC instruction sets as a class literally are not intended for human consumption…

[Tom 7]

Re: Meh!..Meh, Meh

That's why the have an assembler!

[Anonymous Coward]

Re: Meh!..Meh, Meh..RISC compiler only? really?

ARM and MIPS, both very RISC, are both nice asms to work with. PPC is not bad. Sparc left me me with a throbbing headache.

In CISC world 68k is orthogonal heaven. Z80 and 6502 are both workman like. Get things done without much fuss.

x86 makes me want to slit my wrists. x64 is almost tolerable.

Now the Transputers Occam was fun. But never really commercial. And 2900 bit-slice was great for instruction control freaks.

[Arthur the cat]

Re: Meh!..Meh, Meh..RISC compiler only? really?

In CISC world 68k is orthogonal heaven

I'd argue that NatSemi 320xx processors were slightly better, but unfortunately came late to the game so never really got anywhere.

x86 makes me want to slit my wrists. x64 is almost tolerable.

x86 makes me want to slit the "designer"'s throat. Agree on x64.

Now the Transputers Occam was fun. But never really commercial. And 2900 bit-slice was great for instruction control freaks.

Ooh, 2900 bit-slice. Now that was fun!

[Version 1.0]

Re: Meh!..Meh, Meh

I wrote assembly software for a device that I created - it generated an clinical quality EKG two channel simulation back in 1979. I wrote it with a pencil because there was no assembler, it was only running on an SD Systems Z80 Starter Kit so it was writen with a pencil, occasional errors were just erased and replaced, then manually coded into an Eprom via the keyboard , it ran great - the link shows the board it was written on.

[werdsmith]

Re: Meh!..Meh, Meh

Writing assembler on paper with a pen, and then manually transposing the assember into hex codes, and then manually entering the hex codes sequentially on a keypad was a normal activity for me back in the olden days.

[that one in the corner]

Re: Meh!..Meh, Meh

Ditto - but only after soldering all the bits and pieces onto the PCB in the first place; how else was one supposed to get hold of a microprocessor and write code for it?

[eldel]

Re: Meh!..Meh, Meh

Ah memories of a Nascom 1. Fondly remembered even though, if I were to be completely honest, it caused me to learn and invent many more swearwords.

[werdsmith]

Re: Meh!..Meh, Meh

Ditto - but only after soldering all the bits and pieces onto the PCB in the first place; how else was one supposed to get hold of a microprocessor and write code for it?

I also made these things on Vero stripboard back then. With 7 segment LED displaying an 8 bit latch (I think 74LS374) outputs and a hex keypad from RS.

But the college machines which were essentially the same thing were repurposed point of sale machines.

[Anonymous Coward]

Re: Meh!..Meh, Meh..hex?

Well the pen and paper was all we had when I wrote my first assembly language program. Which then had to be hand-assembled into octal. For input on a front panel.

It was absolute heaven when I got to write my first 6502 by hand and then type it into an Apple II and have it displayed on a screen and then stuff happened - on the screen. Although not where I wanted as it turned out the Apple II had non contiguous video memory mapping. That Woz guy and his obsession with saving a few 74LS TTL's wherever he could.

[Anonymous Coward]

Re: Meh!..Meh, Meh..hex?

I never liked Z80 assembler (or x86 for that matter) but loved 6502 assembler - I wrote a complete Windowing System in 6502 assembly language (10K? 12K? of code) for a BBC Micro and burnt it onto a EPROM so the machine booted into it :-)

Those were the days!

[AndrueC]

Re: Meh!..Meh, Meh..hex?

I'm the opposite. I could never get past two things: The lack of registers on the 6502 and syntax that combined source and destination. I'm guessing that with the lack of source options it made sense but I will never accept LDA, 123. It should LD A, 123 :)

[druck]

Re: Meh!..Meh, Meh

26 bit ARM was a thing of beauty with all instructions conditional, free barrel shifts, and the combined PC+PSR allowing costless flag preservation over subroutines. 32 bit ARM lost a bit of the magic when the PC and PSR became separate, but it was still fun. But now with ARMv8, it could really be just any other 64 bit ISA, so I leave it to the compiler.

[Vometia has insomnia. Again.]

Re: Meh!..Meh, Meh

Sophie Wilson seemed to be quite the assembler enthusiast back in the day and certainly made good use of it, so I can see why that would be the case; I think her philosophy for the ARM's design was pretty much a 6502 on steroids. But she moved elsewhere decades ago and I guess the newer models were done by people who were primarily logic and circuit designers rather than enthusiasts.

I never learnt assembler properly. Too skint to afford one in my early teens (shame, the 6809 I had available had a good reputation amongst, erm, assemblerists) and too busy trying to get thrown out of college later on. :|

[Kristian Walsh]

Re: Meh!..Meh, Meh

Yes, 6502 was her original influence, but ARM was always a 6502 programmer’s wish-list for a better ISA.

The first time I saw the “conditional instruction” idea I was amazed at how something so simple could fix such a common performance issue - branches are fairly expensive, but code is filled with short conditional jumps. For example, code like "if (x==0) y=1 else y=2” need five instructions on a typical ISA (load, branch-if-zero +2, load #1, branch-unconditionally +1, load #2), but only three on ARM (load, load-if-zero #1, load-if-not-zero #2). Saves space and memory, Genius.

[Bertieboy]

Re: Meh!

D'accorde! Still the daddy as far as I (an un-reconstructed number cruncher) am concerned but I must admit C is all I use these days. Now where did I put my pension book?

[Anonymous Coward]

Re: Meh! - You had languages?!?

Programming has been going downhill since we gave up on plug boards and patch cables.

[Dan 55]

Something C++ can do that Rust can't

Backward compatibility.

From C/old C++ to Rust would be a big bang change, from C/old C++ to new C++ can be done piecewise.

That's quite a barrier to overcome.

[The Indomitable Gall]

Re: Something C++ can do that Rust can't

If you're properly modularising your code, then you should be able to spin off any existing code to runtime-linked libraries, so that's nowhere near as big an issue as it would have been 25 years ago.

[karlkarl]

Re: Something C++ can do that Rust can't

What? And marshal the data (i.e std::string) between them? No thanks. Spending my time writing bindings is not productive when I can just stick to one homogeneous language.

Unlike good ol' C, the C++ and Rust languages also have weak ABI compat making this a further waste of time.

[sneed]

Re: Something C++ can do that Rust can't

Both C++ and Rust can use the C ABI as an intermediary.

[Anonymous Coward]

Re: Something C++ can do that Rust can't..ha.ha

..properly modularising ...

I'd guess you have not worked on very many very large commercial application code bases then.

Some of the better ones actually have a kinda logically organizer source tree. Sort of. Dont have enormous numbers of globals which cause weird unrelated code interdependencies. Hell, I'm happy if i can edit a single source file and it does not cause a global recompile. You think I'm joking?...

Here's an example. And its one of the cleaner application codebase I've seen. Go grab the Chrome browser source code. All of it. Now try to get it to build. All of it. Read all those build instructions carefully. Several times Now try to get it to build. Now find the code for a nice simple feature to modify. Try to work out how to modify it. Watch what gets rebuilt. Go off and have lunch. Have a coffee. Read a short novel.

And thats one of the saner codebases. You should see whats inside the codebases that never see the public gaze.

[RichardBarrell]

Re: Something C++ can do that Rust can't

Totes can. I've seen someone write up the process before of turning a working C program into a working Rust program one `.o` file at a time.

[karlkarl]

Re: Something C++ can do that Rust can't

And liberal use of unsafe {} to support the char* C-style strings I suppose.

[ssokolow]

Re: Something C++ can do that Rust can't

Rust has `std::ffi::CString` (allocate/free in Rust) and `std::ffi::CStr` (can be wrapped around memory allocated outside Rust) types for null-terminated strings, so you only need `unsafe` for the `from_raw`/`from_ptr` constructors which rely on you to ensure their input is in compliance with the expected invariants. (Stuff like "must be a non-null pointer to a null-terminated string".)

The rest is on you designing an API that ensures they can't be used incorrectly.

[Dan 55]

Re: Something C++ can do that Rust can't

I'm talking about one variable, string, structure, or function at a time. Refactoring when fixing bugs over months or years that doesn't scare the PHBs and their budgets, because it's effectively free.

[ssokolow]

Re: Something C++ can do that Rust can't

There's also Federico Mena Quintero's blog, where he detailed the process of incrementally rewriting librsvg from C to Rust.

https://viruta.org/tag/rust.html

[DrXym]

Re: Something C++ can do that Rust can't

First off, don't move to Rust unless you have a good reason to. If something works, it works.

However if you do need to switch then yes it can be done piece wise. Tools like bindgen & cbindgen generate the C headers or Rust files to call from C to Rust or Rust to C super easy. It's actually pretty straightforward although since C is not safe and Rust is safe, you need to think of your interface and what data you share..

For C++ you would call Rust like a C lib through exposed functions and wrap it with some RAII class. Similar to how you might wrap a C library. Calling C++ from Rust would require you expose a C function (i.e. not mangled) in your C++ as an entry point that caught exceptions etc, which would be similar complexity to trying to call C++ from C - not something people usually do.

[ssokolow]

Re: Something C++ can do that Rust can't

...and, cbindgen's support for C++ constructs aside, there also exist crates like flapigen (https://lib.rs/crates/flapigen) which can do a lot of that for you to ensure that it's a compile-time error if the Rust→C→C++ parts don't line up.

[Decani]

I'm getting rusty

I've still got 5 to 10 years before I retire, but I'm looking into migrating to Rust, to escape the utter BS of modern Java development (endless frameworks rather than writing code, verbosity, vanilla developers). I did plenty of C and C++ back in the day so it wouldn't be a total shock. Null-safety, memory safety, sum types, no reflection, no byte code weaving, etc. All good. Plus maybe the framework w*nks won't destroy the fun of programming in Rust before I retire.

Either that or I've got PTSD/Long Covid after looking at so much shocking java.

[Tessier-Ashpool]

Re: I'm getting rusty

I'd join you, but I already scarpered from the world of work. I was doing primarily C# for many years, which I must admit was an easy and powerful way to program, especially with LINQ extensions. But the headaches of null pointer reference exceptions was a real pain in the neck, and garbage collection / object disposal was always a bit hit and miss as to whether it would work efficiently and cleanly. I got into the habit of using the "using { }" construct religiously to dispose of disposable resources, but code analysis would inevitably moan that I needed to go through additional manual hoop jumping to clean things up. Right. Royal. Pain. In. The. Neck.

[tiggity]

Re: I'm getting rusty

And garbage collection still is a PITA in C#

.. Just today, to deal with some exceptions that would otherwise occur later in the code I had to follow myObj.Dispose(); with myObj = null; (alternatively I could have forced garbage collection, but the code convention we use is set to null after dispose just to make clear its one of those weird C# disposal bugs

[fg_swe]

Not True

The efficiency of C and C++ comes from things such as

+ Stack Allocation of complex data

+ Finely controlled heap allocation/deallocation (as opposed to stop the process GC)

+ Arrays of complex data structures (as opposed to arrays of pointers)

+ Call by reference

+ synchronous destructors

+ RAII

They can be realized in a rather straightforward manner in a memory safe evolution of C and C++.

Proof: http://sappeur.ddnss.de

[Crypto Monad]

Re: Not True

For anyone looking for a "better C/C++", then this is interesting:

https://ziglang.org/

[Anonymous Coward]

Re: Not True

Will you please stop spamming the board with your own property commercial "language". Nobody wants TypeScript for C++. If you must advertise, pay El Reg to advertise.

[chololennon]

Re: I'm getting rusty

"I'm getting rusty"

So do I. I am an experienced C/C++ programmer (more than 30 years using them) who used to love both languages, but about 6 years ago I started to hate C++ with passion. Even with my experience I can't longer say that I am an expert in C++, but with 15 years in Java or Python I can do it, why? because C ++ is so bloated with new features that's impossible to know all of them, and of course, at the same time, we have all the nasty features available (e.g. the fiasco initialization). The language is so complex now that each programmer does what they can with their knowledge, which in turn ends up in horrible code bases when new, old, good and bad features are mixed. Another thing to mention: The same feature present in other languages is always more complex in C++, OMG! (e.g. just look what multithreading, concepts or coroutines are).

I'm sorry for my rant, but that's why I am learning Rust these days (I am still don't know if it is better or not than than C/C++, but I will find it)

[cornetman]

Re: I'm getting rusty

I hear that.

The other thing that is the bane of my life is templates and how truly awful they are in C++. A good concept done really badly, or at least implemented really badly. Every time I have to decode template error messages I want to tear all the skin on my face off.

https://www.youtube.com/watch?v=tnqgYm0CXys

[DexterWard]

Re: I'm getting rusty

C++ template error messages are so obscure that they have introduced a new language feature in C++20 purely to make the template errors comprehensible. ‘Concepts’. I like C++ but it is now so huge and complex that I can’t believe anyone can know all of it. Rust strikes me as more a replacement for C than C++ anyway. Much less expressive power than C++ but it tries to do one thing well, which is not a bad idea at all.

[TheMeerkat]

Re: I'm getting rusty

I have a feeling that Java is truly on the way to become a monster like C++ in terms of number of features added to the language…

[DrXym]

Re: I'm getting rusty

In terms of complexity Rust sits somewhere between C and C++.

It has some new concepts and will kick your ass until you learn how borrowing works, but it alleviates a LOT of bullshit that C++ causes by its design and the overcomplexity caused by classes, inheritance, overloading, rule of 3, rule of 5 etc. etc.

[Michael H.F. Wilkinson]

Re: I'm getting rusty

I am a long-time C/C++ user in my research (and have used Pascal, FORTRAN, and assembler in the past). Rust does have a real appeal. I am considering rewriting some parallel and distributed algorithms for processing HUGE images and volume data (biggest one 162 giga-voxel, 32 bit floating point from the LOw Frequency ARray (LOFAR) radio telescope). Better still, I could get one of my students to do that. Very curious how that will pan out

[Anonymous Coward]

Rust likes to promote itself as a better and safer C, but it isn't really. It's quite a lot different from C, and the only way to make C safer is to remove or curtail the features that make it so useful.

The argument for using Rust, like so many modern arguments, seems to be analogous to "Everybody is clumsy occasionally, so nobody should ever be allowed to use sharp knives, and then nobody will ever accidentally cut themselves. Nanny knows best. Health and Safety. etc." Personally I find that somewhat uninspiring.

C is pretty much the perfect language for low-level drivers and embedded programming. But using C is a different skill to programming in a high-level language, and it requires a different mindset. If you are the kind of programmer that thinks in abstract terms about objects and numbers and strings rather than bytes and pointers and registers then don't try to write C.

[MJB7]

Re: "nobody should ever be allowed to use sharp knives"

But that's not what Rust says. If you need a sharp knife without a safety guard, you can have it - you just have to mark the code region as `unsafe`. That means when I come to review your code, I don't have to worry about dangling pointers, use-after-free, multi-threading errors, etc in 90% of the code, and hopefully the remaining 10% is so simple that it is obviously free of errors.

[fg_swe]

A Bit More Complicated

A lack of memory safety translates into exploitable weaknesses and therefore cyber security risks.

For some(many?) computer applications, this can have very real, deadly consequences.

Also, bankrobbers have programmers these days.

[Anonymous Coward]

Re: A Bit More Complicated

You call it "a lack of memory safety".

Others may call it "the ability to easily reference any byte in the address space".

Whether you view this as desirable or undesirable depends entirely on your application.

[martinusher]

Re: A Bit More Complicated

I depends on the hardware, too.

Programmers have shown repeatedly that they can't cope with segmented address spaces, the like the large puddle of generic memory because it means they don't have to design memory usage. It causes all sorts of issues, though. The problem was recognized many decades ago, the fix is obvious, but.....

[Anonymous Coward]

Re: Whether you view this as desirable or undesirable depends entirely on your application.

Yeah, do you want your application to work or not?

[ssokolow]

Re: A Bit More Complicated

Optimizers frown on that, even in C, and there are experiments ongoing with architectures like CHERI which encode pointer provenance in a hidden second 64 bits of the pointer so, if you step outside of the allocation your pointer descended from, you get a hardware trap.

[StrangerHereMyself]

This is one of the excuses I hear ALL the time: "All those other programmers suck! I can write C code flawlessly!"

We, of course, know they can't. It's too damned hard and even if they could they're not given enough time by senior management, which want it finished NOW because they want their $100 million bonuses.

[Locomotion69]

Yet another kid on the block

My background is with C/C++, and I like it. Not the most easy languages to master though (and I definetly do not claim I do).

Over the years, many other "languages" have been released to challenge the position of C/C++ - and failed, however most of them collected a lot of enthousiasts and find their place in the IT ecosystem.

I expect this to happen to Rust too. I am curious to learn more about it (although I am not employed in "IT" anymore).

But I doubt it will challenge the position of C++, let alone C. C emerged in 1972-1973, and is just as normal to be as, say, breathing.

Rust is not going to take my breath away....

[fg_swe]

ALGOL, PASCAL, MODULA 2, ADA

Algol/Algol mainframes is older than C and Unix. Arguably, this is the technologically more robust and more secure approach.

Unix was given away for "free", so it dominates to this day.

Windows is even worse, yet it dominates applied computer science.

If you really want to improve things, look here for inspiration:

https://en.wikipedia.org/wiki/Friedrich_L._Bauer

https://en.wikipedia.org/wiki/Niklaus_Wirth

https://en.wikipedia.org/wiki/Tony_Hoare

https://en.wikipedia.org/wiki/ALGOL

https://en.wikipedia.org/wiki/ICL_2900_Series

https://en.wikipedia.org/wiki/Modula-2

https://en.wikipedia.org/wiki/SPARK_(programming_language)

The greatness of European thought comes from intellectual honesty, not from sucking up to power.

[Dan 55]

Re: ALGOL, PASCAL, MODULA 2, ADA

Unix was given away for "free", so it dominates to this day.

AT&T Unix was most certainly not free. Neither were Solaris, AIX, or HP U/X. And yet it still came out on top.

[fg_swe]

Re: ALGOL, PASCAL, MODULA 2, ADA

BSD and Linux are given away for free.

[Dan 55]

Re: ALGOL, PASCAL, MODULA 2, ADA

You should probably check the date each thing you cite failed in the market, you'll probably find that it died when competing against paid-for Unix.

[MarcoV]

Re: ALGOL, PASCAL, MODULA 2, ADA

Pascal still lives in Delphi and Free Pascal.

Modula2 is fairly dead (while there is a GNU M2, it isn't the most active). It was used quite a bit in the mid nineties in medical and other.

Wirthian influences are heavily felt in Java (listed in the credits of the VM IIRC), and of course C# is a hybrid of Java with Delphi directly.

[Charlie Clark]

Re: ALGOL, PASCAL, MODULA 2, ADA

Unix wasn't sold as software, largely because the idea of software that could be installed, uninstalled, swapped, etc. didn't exist at the time. You bought a machine and it came with the necessary documentation, including the source code in order to be able to run it.

Unix became a standard, largely because of C, and as a result and some fairly large DARPA projects, the BSD effectively became the first software and it was both free to use and "open source", inasmuch as it was assumed you'd need the source code in order to fix any of the inevitable bugs.

[Tomo1967]

I see only one reason to use Rust.

To get rid of all those expensive C++ers, requiring too much money.

Rust is a way of Idiocracy.

Why I can't do that:

double X = 1.2345;

double sinVal = sin(X);

double cosVal = cos(X);

Ownership is good. Rust implementation is idiotic.

[fg_swe]

Can someone verify the correctness of the claim above ? I doubt it.

[Ilsa Loving]

It's wrong, but I can't be bothered to go into all the reasons why.

His argument basically boils down to "I want to code like _X_, but rust won't let me, therefore it sucks.".

I deplore this kind of attitude from developers. The decisions made /w Rust have nothing to do with the developer, and everything to do with development as a long-term effort.

[zac_harrold]

Yeah They're Wrong

Below is a complete snippet of Rust code that performs exactly what they say is impossible:

fn main() {

let x: f64 = 1.234;

let a = x.sin();

let b = x.cos();

}

What I think they were trying to refer to is the ownership system in Rust, which allows unlimited read-only references to a variable, but only 1 owner. If sin() or cos() modified x directly, then they would be correct in saying Rust wouldn't allow that code.

For anyone interested in learning more, the Rust Docs have a pretty detailed section describing the concept of ownership: https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html

[Dan 55]

Re: Yeah They're Wrong

So "const double x" in other words?

Why am I supposed to be impressed by "let x: f64" instead of "const double x"?

This is a genuine question.

[werdsmith]

Re: Yeah They're Wrong

I don't think anyone is trying to impress you.

[Kristian Walsh]

Re: Yeah They're Wrong

f64 Makes it obvious to new programmers how big a “double” is. I’ve seen code where people forget this, read 32 bits from a stream, cast it to double, store it somewhere, then all hell breaks loose later.

I write a lot of C. With the exception of loop-counters, I always use the <stdint.h> names for integers, not the built-ins.

I've looked into Rust a few times. It seems to be a way of automating some of my own (hard-won) good practices when using C++: use RAII, avoid "new", methods take objects as const references not pointers unless you've a really good reason to do otherwise, try to use return by value of small types wherever you can. Memory leaks and violations weren't ever a class of bug I got in my C++ code.

C is a simple language. That makes it easy to master, but it is very, very low-level, and that puts everything on your shoulders. Some people like to think that makes them a better programmer, but after a long time doing this stuff, I think that honestly it just gives you more chances to plant landmines in your code. One thing I like about Rust is that it still allows you to do the dangerous but fast things if you need to, but the path of least resistance produces safer code than taking the same unthinking approach in C.

[Dan 55]

Re: Yeah They're Wrong

If the programmer is really at a level where they don't know how wide an IEEE double-precision floating point value is, perhaps they might also be confused with what the "f" is in "f64".

Nor am I convinced by the ownership argument which wasn't expanded upon, unless by default all variables are const unless specified otherwise, which could be something to enforce better programming practice... or a pain in the backside.

You mention following good design patterns in C++ saves a lot of debugging time later. From what I can gather it seems Rust's main advantage is it doesn't have older design patterns which people fall back on so removing foot-gun opportunities. There are a tonne of paid-for static code analysis tools which can do similar for C and C++, but like code reviews, business is loathe to spend the money on them.

[ssokolow]

Re: Yeah They're Wrong

The Pascal-ish "let <name>[: <type>] = ..." syntax is to avoid needing The Lexer Hack and comes from Rust's Ocaml ancestry.

(Any time you wonder about a piece of Rust syntax that's different from C++, it probably boils down to "Rust is kinda an ML-family language in a C++ trench coat".)

Same reason typecasting is `*x as Y` rather than `(Y) *x`.

[Aremmes]

Romani ite dōmum

Surely you meant to say *ductor interretī* given the second declension genitive, right?

It bugs me that there seemingly doesn't exist any good Spanish translation for router (*enrutador* doesn't sound right even if the parts look correct), or for a lot of IT terminology for that matter. The English language truly has cemented its hegemony in this field, for better or worse, and it doesn't appear to be losing ground there, ductores interreti notwithstanding.

[fg_swe]

Re: Romani ite dōmum

English is a good compromise between German and Latin, so we can live with it ?

It could be much worse, Finnish or Welsh ;-)

[Bitsminer]

Pronunciation?

Is it rowter, or rooter?

Canadian mind wants to know. I've done both, I must say.

As in "routing the packets here and there, the router is an important element...."

[Irony Deficient]

Is it rowter, or rooter?

It’s dialect-dependent. Both pronunciations exist in North American dialects.

[Anonymous Coward]

Re: Is it rowter, or rooter?

In the Australian dialect, the noun rooter generally has the preposition "filthy" before it.

[ssokolow]

Re: Pronunciation?

As a fellow canuck, I rowt packets and plan my root on the roads.

[Irony Deficient]

Re: Romani ite dōmum

Surely you meant to say *ductor interretī* given the second declension genitive, right?

Presuming that the -ret… part came from the Latin word for “net”, rēte, which is third declension, its singular genitive would be interrētis.

It bugs me that there seemingly doesn’t exist any good Spanish translation for router (*enrutador* doesn’t sound right even if the parts look correct),

There are apparently a number of Spanish translations of “router”, e.g. direccionador, encaminador. “Router”, of course, comes from “route” and goes back to Latin (via) rupta → ruptus, the perfect passive participle of rumpō. The modern Spanish descendant of ruptus is roto, but given the current definitions of roto, it might not be the best choice from which to coin a Spanish translation of “router”.

[Aremmes]

Re: Romani ite dōmum

Presuming that the -ret… part came from the Latin word for “net”, rēte, which is third declension, its singular genitive would be interrētis.

Thanks for the correction.

The modern Spanish descendant of ruptus is roto, but given the current definitions of roto, it might not be the best choice from which to coin a Spanish translation of “router”.

Roto/a (meaning broken) is one descendant, the other is ruta (meaning route), e.g. Ruta Panamericana.

[Irony Deficient]

Re: Romani ite dōmum

Since you’d already written that enrutador didn’t sound right to you, I’d excluded ruta from consideration.

Perhaps basing a Spanish translation of “router” on a meaning of Latin ductor might be another alternative? For example, guiador ?

[Aremmes]

Re: Romani ite dōmum

That would work, or perhaps conductor. There's some precedent behind that logic as well -- IBM call their ESCON/FICON switches directors. Now it's just a simple matter of convincing Spanish-speaking IT geeks to call routers conductores.

[Proton_badger]

It saves time.

I feel I've spent half my time for the last few decades looking at memory related bug reports in C++ code and they're hard to reproduce and fix. No matter how expert we think we are - we're above all human and we can't keep track of it all in a complex codebase.

The amateur thinks he's that good and can manage it, the expert knows he's not.

With Rust the compiler helps us writing good code and keeping track of memory references, while still requiring us to understand how it works (unlike a black box garbage collector). The language also have a lot of other great features that are never talked about.

I was watching Asahi Lina write the M1 GPU Linux driver in Rust. What was amazing was that there were almost no crashes in the driver, even during development. She mostly had to chase down logic errors.

AsahiLina wrote this comment about the experience: "Not just secure, but more reliable! This particular GPU has a limitation that means that if the firmware crashes, the user needs to reboot the whole machine (there is no way to recover), so it's important to get it right. I use Rust's type system to manage the types and lifetimes of GPU-side pointers and data, not just the CPU side ^^

Honestly, this is the first time I've ever written anything serious in Rust, but I'm very happy with the language! I feel like it encourages good design, and then the compiler goes a long way towards making sure your implementation is correct. The firmware crashes I had yesterday were due to silly logic/setting bugs (getting a ring buffer size wrong and forgetting the last command in some command lists), and the only time the kernel side crashed was when I tried to release an imported GEM object as if were one of the driver's own. All the lifetime stuff just works, everything gets allocated and freed when it needs to be, no dangling pointers (neither on the GPU side nor the CPU side), ..."

CloudFlare had similar experiences writing their Pingora proxy and the reliability of the code in production.

[Ilsa Loving]

Good

This can't happen soon enough.

The pendulum has swung way too far towards the "developer convenience" side and away from the "quality" side. Sloppy, poorly thought out software has gotten sloppier and more poorly thought out with each passing year, and there are way too many self-taught developers who think "runs" equates to "done".

Shoehorning extra safety features (or yet another "framework"... *shudder*) onto existing languages can never solve the problem, because it doesn't stop developers from ignoring those features and doing it wrong anyway.

The single biggest advantage of rust is that, by default, it doesn't let you get away with _anything_. No ridiculous untyped variables. No incomplete conditionals. No memory manipulation nonsense. Sensible crate management.

In short: The language has sensible default requirements, and if you want to stray away from that, you need to go out of your way to do that. That's as opposed to basically every other language out there that requires developers to code defensively to protect from the languages failings. And heaven forbid the developer doesn't know how to do that, because you end up with a code base rife with ticking time bombs.

Rust may hurt developer "velocity" in the short term, but the long term means dramatically reduced maintenance cycles, bugs, and headaches in general.

[StrangerHereMyself]

Re: Good

I don't agree. The quality of software has increased markedly over the last two decades. Even larger programs are generally much more stable than the ones in the late '90's, which had memory errors all over the place and you could actually "feel" their instability.

Case in point: Microsoft Access.

[yetanotheraoc]

Gives with one hand, takes away with the other

Sure, Rust mitigates one class of error. As a commentard alluded to in the Russinovich article, crates.io introduces a whole other class of error. We can say it takes some effort in C++ not to run into the first class of error, but it will take just as much effort in Rust not to run into the second class of error. Maybe Rust is worse, because in C++ the books say not to make the first error, but in Rust the books say to make the second error.

[DS999]

Rust is just the latest fad

First it was C++, then it was Java, now we have Rust.

It is just one more language added to the zoo. Rust does not do anything unique other languages do not, but it is being touted by its adherents with the same religious zeal that C++ and Java evangelists were touting them as the solution to all software ills.

[Anonymous Coward]

Re: Rust is just the latest fad

Java was going to be bug free, IIIRC.

...but this time it is right, it will work, and no one will have to get nailed to anything.

[StrangerHereMyself]

Re: Rust is just the latest fad

I assure you Rust is not a fad. In fact I see it picking up steam all the time. It's already big at Microsoft internally and no doubt other large ISV's are also researching it.

Rust's biggest problem is that it doesn't have a nice UI framework like wxWidgets. There are some Qt bindings but those are not native Rust and therefore lose a lot of the benefits of Rust.

[Abominator]

Re: Rust is just the latest fad

It's like the Go evangelists all over again from 10 years ago.

[StrangerHereMyself]

Re: Rust is just the latest fad

Go has never really taken off, except with Google internally.

It seemed like a good idea back then, but has since been superseded by Rust.

[DS999]

Re: Rust is just the latest fad

Don't worry, Rust will be superceded as well. Something new will come along that addresses Rust's faults and that will be the new hotness.

I am guessing you are a bit younger than some of us, and haven't seen this play out again and again for as long as we have.

[Henry Wertz 1]

Hear hear!

Hear hear! Agreed with the article. The parts I see as most important and relevant:

1) Memory safety, thread safety, etc. It's possible to write code that is just as safe in C/C++, if you do everything just right, and this is being used as an argument against Rust. Well, you can follow that argument to it's conclusion and conclude everything should be written in assembly -- why have all that hand-holding C does either? Just saying.

2) Rust is fairly similar to C. I don't have much to add to this. Just saying, it's much closer to C syntactically than it is to Javascript, Python, Java, or C# for instance. You're not going to have to forget everything you learned and start over.

Please don't fear Rust, I think using it in the places it's going now is a positive.

(Disclaimer: My language of choice is Python, and to be honest I prefer Python to both C and Rust; but obviously Python does not belong in kernel code.)

[StrangerHereMyself]

Re: Hear hear!

I don't agree with you on 2). Rust's syntax is dissimilar enough compared to C that it's IMHO less fun to work with. I despise the return value operator (=>) which is tedious to type (and you need to type it all the time).

Also I despise the shorthand notation for lots of stuff (fn = function, pub = public). The thing I love about C# is that it spells out everything clearly without one having to guess the meaning.

[sneed]

Re: Hear hear!

This one confused me a bit, you despise "=>" because it's "tedious" to type, and "you need to type it all the time", but are totally fine with tediously typing out "function" and "public" - all the time?

Chopping these keywords down makes them less tedious and isn't any less clear: Hmans r vry gd at fguring out wht wrds with mssng lettrs mean, and this time you're not even having to read a sentence. Maybe this would have some merit if Rust went gung-ho and chopped "break" down to "brk" (for example), but, it doesn't: https://doc.rust-lang.org/reference/keywords.html

BTW, "=>" doesn't even make it into the top 10 most commonly used syntax in Rust, and nor does "->", which is what I think you actually might be talking about. https://twitter.com/davidtolnay/status/1534955471714406402/photo/1

[StrangerHereMyself]

Re: Hear hear!

I'm a touch typist so typing text is very fast. Symbols and such are, however, a pain.

[sneed]

Re: Hear hear!

My recommendation would be to look into snippets provided by your IDE. I'm sure it already provides snippets that can mitigate your symbol typing concerns, for any language.

[martinusher]

What's with the obsession with NES?

This harping on about 'NES' and '8 bit' says more about the author than the technology of that period. A lot of people were building quite powerful and complex systems that required the code to be type safe, memory safe, thread safe and generally programmer proof, the just weren't the people that this author would be aware of. The entire PC buisiness has been one of masses of people learning why wheels were round, water wet and so on as the shortcomings of the cheap 'n dirty school of computer architecture were addressed piecemeal. Hence years later we learn that languages ideally should be programmer proof becuase only a subset of programmers have the patience to manage that level of detail. Rust appears to be one such language, a 'super-C' that takes a lot of the legwork out of coding. It might well be useful in my world, it largely depends on how well it integrates with other components and whether an efficient code generator for less well known parts becomes available.

The older 'programmer proof' language? Ada, of course. Not what I'd call my favorite by any stretch of the imagination but its a bona-fide attempt to achieve these goals.

[StrangerHereMyself]

Re: What's with the obsession with NES?

The difference was that games or programs in general didn't encompass hundreds of thousands or millions of lines of code. Everything was much simpler and smaller and could therefore be programmed in assembly.

[Anonymous Coward]

Rust versus Linux distros

My concern with Rust is regarding its/the Rust devs situation regarding distros.

Rust has the concept of 3 Tiers of supported/unsupported platforms.

Tier-1 is "guaranteed to work" and, for Linux systems, is basically aarch64 and x86/x86_64 with glibc.

Tier-2 is "guaranteed to build" (and by implication *not* guaranteed to work) and includes Linux platforms using musl instead of glibc (i.e. Alpine Linux, a popular distro for containers), RiscV chips, some MIPS chips.

Many distros support multiple archs that include more than just Tier-1 platforms and it causes issues if Rust-based applications cannot be built or don't then work on some of the distro's platforms.

In addition to this some distros face the problem that each new Rust release needs to be built by only using the directly previous Rust release, so if multiple releases have come out in the intervening time then a sequence of step-by-step builds needs to be performed (A->D is not possible so A is used to build B, then B builds C, then C builds D).

Distro-related issues are not unique to Rust, e.g. it is only recently that Python added support for wheels with musl. Indeed some developers seems to be resistant to distros packaging their software in general and want/expect users to use other means to get it - that's fine if those are generic applications but it's a different story for "key" tools like compilers or crypto libraries.

[ssokolow]

Re: Rust versus Linux distros

Tier 1 is quite literally "we have access to CI farms using this hardware-software combination that every push and PR gets natively built and regression tested on".

Tier 2 is more of a "We also do these on our CI, but we can only cross-compile for them".

They're pretty conservative about what they're willing to promise because they've made "fearless upgrades" one of their slogan goals.

(I believe, if Microsoft weren't donating Azure capacity for their CI, their development process would be seriously bottlenecking on CI capacity.)

[zac_harrold]

Still Learning

I've only recently started learning Rust, coming from a Python, C#, and JavaScript background. I know people are excited to replace C/++ with Rust, but I'm far more excited to see it replace C#. I've spent the better part of half a decade on a C# REST API, and the number of problems that could've been caught at compile time that just aren't is insane. Between garbage collection causing randomised performance, random guard clauses being darted all over the codebase for fear of the null, and a general lack of understanding among less experienced devs around how C# defaults to passing by mutable reference for objects ("Why did my function change that variable? Isn't it copied??"), I wish I could migrate the project to something with clear rules, and a compiler which actually enforces them.

[werdsmith]

Re: Still Learning

Rust is more aligned with C than C++ or C#. It doesn't support inheritance in the way that OO languages can have a type hierarchy. Although it does have traits and can use interfaces, I wouldn't say it is a replacement for Object Oriented languages. And C# is more of a high level language with a C++ like style.

[zac_harrold]

Re: Still Learning

Oh yes I agree they're very different in style, I'm not saying that Rust is C# 2, but rather that (at least in my experience thus far) Rust solves problems in ways that are superior to C#. I've yet to see Rust code that was substantially harder to grok than equivalent C# code in the projects I've worked on, but are verifiably better.

As a personal opinion, I will say I prefer the trait/interface method of composing data into objects, as opposed to everything being an object directly with an inheritance structure. There are any instances where the C# insistence on OO is clearly antithetical to a programmer's intention. The implicit single-file namespace and implicit Program.main() are pretty clear evidence of that IMO.

[teambob]

Recovering C++ Programmer

Rust doesn't have a stable ABI. Looks like they are going to copy at least one of C++'s mistakes.

Of course Go gets around this problem by using static linking only. Without a stable ABI it means there will never be a "maven" for C++ or any other language that doesn't have an ABI

[ssokolow]

Re: Recovering C++ Programmer

Rust has a "release a minimum viable product now, enhance it later" philosophy.

They don't have a stable ABI now, but that doesn't mean they've rejected the idea forever.

Among other reasons they don't have a stable ABI yet, they're still finding ways to improve it. For example, Rust v1.0 didn't ship with automatic structure packing, but Rust now has it if you don't use #[repr(C)]` to request a C ABI layout.

Also, in the mean time, there exist crates like abi_stable (https://lib.rs/crates/abi_stable) which allow the problem to be worked around. (abi_stable does Rust-to-Rust FFI through the C ABI, handling the task of making sure, at compile time, that both sides share the same interpretation of the higher-level constructed being pinned into stable forms by the C ABI in the middle.)

They also care enough that one of the big names in their low-level work made the frustrating discovery that there is no one "the C ABI" even within a single platform when writing a checker to make sure Rust could reliably speak "the C ABI" without having to carry along a C compiler.

https://gankra.github.io/blah/c-isnt-a-language/

(eg. GCC and LLVM don't agree on how to represent __int128 because the AMD64 SysV ABI document is merely human-readable, not an executable conformance suite.)

> I wrote this dang thing to check for mistakes in rustc, I didn’t expect to find inconsistencies between the two major C compilers on one of the most important and well-trodden ABIs!

[StrangerHereMyself]

Systems Programming Language vs. Application Programming Language

I keep reiterating that C (and Rust) are Systems Programming Languages, to be used for developing operating systems, device drivers and time critical applications (such as audio / video encoding and decoding). But somehow we ended up using it an Application Programming Language, most likely because some developers are stubbornly insisting on a programming language which produces the fastest code.

The makers of C have called it "high level assembly language" and that's what it basically is. With all the warts and dimples that go with it, like no pointer validation or bounds checking.

Even mediocre programmers can write a flawless C program of a couple hundred lines of code. But it's nigh impossible to write bug-free C code programs consisting of hundreds of thousands of lines of code. People should recognize that and switch to a language which does enable them to do so. Rust tries to solve it by adding handlebars to prevent you from making errors. Another solution would be to make a safe Application Programming Language.

[ssokolow]

Re: Systems Programming Language vs. Application Programming Language

Because they intuitively recognize that, in addition to being capable of low-level programming, Rust also has a lot of high-level constructs and, more importantly, it cares a lot about being an imperative systems programming language in the original definition of the term, where languages with comparable guarantees tend to be functional languages like Haskell.

To reference a quote used to good effect in https://willcrichton.net/notes/systems-programming/ :

> In Systems Programming Languages (Bergeron et al. 1972), the authors say:

>

>> A system program is an integrated set of subprograms, together forming a whole greater than the sum of its parts, and exceeding some threshold of size and/or complexity. Typical examples are systems for multiprogramming, translating, simulating, managing information, and time sharing. […] The following is a partial set of properties, some of which are found in non-systems, not all of which need be present in a given system.

>>

>> The problem to be solved is of a broad nature consisting of many, and usually quite varied, sub-problems.

>> The system program is likely to be used to support other software and applications programs, but may also be a complete applications package itself.

>> It is designed for continued “production” use rather than a one-shot solution to a single applications problem.

>> It is likely to be continuously evolving in the number and types of features it supports.

>> A system program requires a certain discipline or structure, both within and between modules (i.e. , “communication”) , and is usually designed and implemented by more than one person.

In other words, by the original definition that Rust pays a lot of attention to, Java and Go are also systems programming languages, because systems programming is about producing complex infrastructural components with a long service life that need to be maintained by shifting teams... like the networks of microservices Go excels at.

[Robert Grant]

This might be a good direction, but I've never before thought, "The CTO of Azure has something to say about systems programming! Let's listen!"

[Trixr]

You need to read up on Mr Russinovich's CV. Azure is merely the latest iteration of his career.

I'm a bit surprised he pivoted into Azure, personally, but maybe they needed someone to go kick some butt and get them delivering on security and maintainability.

[DaleksInc]

Syncretism begone!

"But as religion so ably attests, sooner or later the language of the past cannot fully support the needs of the now. People still have fun creating Latin terms for 'internet router' (ductor interretus, since you ask), but Christianity has largely recompiled itself for better compatibility with the present day."

Ironically, attempts to make Christianity "more hip" (as opposed to "okay, have we been reading the Bible wrong due to cultural baggage?") usually make it less applicable to the modern day.

This is because attempts at "modernization" tend to discard traditional doctrine (which, while I know some people will disagree with me on this, does a good job of not conflicting with what we know about the world) in favor of feel-good moralistic mysticism. A good example of this is theistic existentialism (a la Kierkegaard), in which blind, unquestioning faith replaces "traditional" Christianity's rationalism.

Also, as other people have mentioned, you need to touch up on your Latin grammar.

[Michael 66]

Re: Syncretism begone!

I was wondering if anyone who thought Christianity had become hip has visited Texas.

[electronicbits]

"Much depends on culture and ego, rather than technical proficiency."

Oh yes... having worked on IT for 20+ years, I can attest to this.

Many technical decisions come first from ego + politics. Not necessarily being the best technical decision.