I've been a mobile OS developer for a decade now. Basically nobody uses Rust in the real world of firmware/kernel engineering. There are a few public examples of doing Rust in linux and Google, but the vast majority of work is still done in c or c-flavored c++.
Maybe it'll catch on some day, but it's definitely NOT catching on in the real world of making actual products.
You know it’s kinda funny, I read this comment and then tabbed over to twitter and then read this: https://blogs.blackberry.com/en/2023/02/this-is-the-kind-of-...
Anyway you’re not wrong that Rust is still a tiny portion of this kind of thing, but it is growing, and quickly. Only time will tell.
(I work at a company writing firmware (and virtually everything else) in Rust, but as a startup I don’t expect that to carry as much weight as big established companies, of course.)
Especially on that area of Posrgresql mutants: similar ideas came to a lot of great minds: yugabyte, neondb, cockroach DB, timescaledb, even Amazon (Aurora) an MS here.
They are trying to do different things but common: - they're all tweaking storage in very strange directions - compatibility with core postgres - importance on top (timescale is still an extension to PG) - they all trying to achive a goal of cloud-native DB
And one thing is common: Rust! (cocroachdb are still on golang but they are exception)
And if look what's going inside core postgres you will discover that almost all APIs of PG are duplicated in Rust so in future we'll see quite rusty PG
What do you mean by this?
Looking on trend I expect that in near future it will be even more: - extensions - I expect rust to become first choice - core postgresql - I expect that rust to appear first in pg tools and then in postgres itself
C is more than just another language, it's a quasi protocol that other languages communicate among each other with. Sorry to say, but neither Rust and Zig are likely to ever reach that level of popularity, nor are other languages going to create FFIs for them to that extent.
Another way to look at this. People run around saying Object Pascal/Pascal/Delphi is a "dead" language (despite how its still widely use), yet it stays around #15 on the TIOBE index, and has done so for years. Rust has barely reached #20 on that index and various others. Zig is nowhere to be seen on various indexes and has yet to reach 1.0, though its going on 8 years into its development. These languages have yet to catch up to and surpass Object Pascal/Pascal, much less have any shot at C, debatably in the next 10 years or ever.
not a snowman's chance that "Object Pascal/Pascal/Delphi" is, by ANY measure, in top 15 programming languages by usage or importance in 2023...
There are numerous dialects, IDEs, compilers, and interpreters of Object Pascal/Pascal all over the place (including for embedded and numerous platforms). Delphi (including Turbo Pascal nostalgia), Oxygene, Free Pascal/Lazarus/CodeTyphon, PascalABC, Pascal Script, DWScript, etc...
There are still tons of YouTube videos, books, and websites that are Delphi/Object Pascal/Pascal related. Millions upon millions of lines of code, that people still maintain, or are being produced by small businesses, independents, hobbyists, etc...
The sum total of it, plus the years that Pascal/Object Pascal has been around, means a much greater penetration and usage than many people realize, and much more than the recently trendy or fad languages people might be thinking of.
As much as people might have recently started talking about Rust or Zig on "hip" or "techie" sites, the languages are simply not that known or used to such an extent outside certain circles. Rust and Zig are not being taught like Pascal/Object Pascal was and still is in schools. They haven't been as widely written about or have as many books out about them. They aren't used as much, trusted, or relied upon. A lot more people than one might think, are on the fence, undecided, or only seldomly experimenting with them or something else. Even more, for a language to reach wide spread usage, takes more time and a lot more years than many are aware of or will admit it takes.
A lot of people have in the past had very good arguments for why their language (C++, D Java, OCaml, Objective-C) should replace C but after decades they still haven't. The C-is-dead argument predates Rust by a lot, and Rust is already 10 years old.
C may at some point be replaced, but I'm not holding my breath especially given that I think Cs success is so poorly understood, especially by people who come from other languages.
If yes, you are using software written in Rust.
Fastly? Same. Python? there is a good chance you are using cryptography, which is partially in Rust.
Firefox? Rust is in there.
And i could keep doing, at this point it is slowly creeping everywhere :)
Constantly fighting with your compiler is not how I would imagine a good time.
I've grown to enjoy the Rust programming far more. Having a language, and associated tooling, that's woken up to the 21st century is far more enjoyable. (Really, why is it acceptable that a major language in 2023 still defaults to providing absolutely no diagnostic information on a fault?)
MISRA's rules aren't that distinct from a C coding style you've probably used if you're an experienced C programmer. Any competent C programmer can easily read and understand code that obeys the rules - it's just C, but maybe somebody with no prior experience of MISRA might trip on some of the rules because they're unnatural. For example if you like recursive code, MISRA hates that, so don't do that (call stacks are finite). If you're used to doing shenanigans with pointers (e.g. XOR linked list), MISRA hates that too, C's pointers are just magic, don't try to fiddle with them.
I'd guess that 90+% of code I wrote with no intention for it to be MISRA would, in fact, pass MISRA rules or would pass with some minor tweaks. Some of MISRA's dozens of rules are forbidding stuff no sane C programmer writes unless it's for a contest or something, so you just won't hit those. Some require practices which were recommended in like the ANSI document, that's over 30 years ago, hopefully you are doing that already.
I always hated Wirth's obsession with bloated keywords. I like conciseness (though J might be jumping the shark).
The latter point is just a reflection of how awkward it is to the break the rules in Pascal, which was necessary for many real-world applications.
And yes, I'm also a Rust convertee (sorry haters); I can do everything I did in C in Rust and for most parts it's more readable and frankly less work. I think my biggest regret is that while I know I could write a C compiler, I don't think I could write a Rust compiler [in my lifetime].
I also prefer SPARK2014 instead of Rust if I am not going to use C. I've started learning Rust a few times. SPARK2014 is easier to get going for me, and it has been used to produce high-integrity software and real-world applications for over a decade, and more if you include Ada from which it sprang[2].
SPARK2014 covers me for the things Rust is striving for with a longer legacy of doing so for real world systems. It's also a simpler syntax (Ada, Pascal).
At the time this article was written, you would probably be correct. But for about the past 5 or so years, there's been quite a few people in this space who have entertained the use of Rust instead. This includes people who write firmware, people who write drivers, even some of the people who work on the large operating system kernels themselves--you'll find examples of people who have indicated a desire to at least explore using Rust instead of C. And there's more languages in this space that have come out after Rust (Zig perhaps the most notable of those). While this view is far from universal, it's definitely the case that there's a large number of systems programmers who are interested in no longer writing in C.
> C is on paper not a safe language, but almost all of the most trusted safety critical software is written in it, so from a Darwinistic point of view it has produced more trusted software.
My understanding of things like MISRA C is that it's almost a completely different language--to turn C into something you can use for safety-critical stuff, you need to start ripping out or at least heavily curtail basically all of C's differentiating features.