Misra C is not normal likeable C. And while people have written safety critical code in normal likeable C, that isn't at all common. Ada, more recently spark, and various c++ subsets are all far more common. But yes Misra C is very common.

Zig seems likeable, but I haven't tried it yet. And rust is enjoyable now that I'm into it as my daily driver. The complexity is only there if I go looking. Mostly.

Isn't malloc one of prime reasons that makes C "less likeable"?

I would imagine banning the use of malloc would make C easier, not harder to code in.

Ban malloc, use stack only? Using C like Forth is definitely a thing someone could do.

what would you replace it with? stack allocation almost everywhere and acyclic reference counting when you absolutely have to?

I write Rust code without malloc equivalents.

You stack allocate, you statically allocate. Anything growable either doesn’t grow, or preallocates (on the stack or statically) an upper limit and “grows” within that.

Often for dsp type stuff you'd blow out the stack for the size of a time series or image buffer. I typically preallocate when the size is known and reuse. Is yhere a good way to do that statically.

In Rust? Simplest thing is to declare an array as a static. Mutable statics do require unsafe, because it's inherently not threadsafe, but if you wanted to stay away from that directly, just depends on what kinds of tradeoffs you're interested in making.

I didn't realize who I was replying to! But yes in rust. I have messed with mutable statics with a mutex and maybeuinit mostly for exporting stuff as a cdylib that has mutable state, and found I lose some of what I love about rust. So I heap allocate once and do borrows for each stage in my pipeline (SDR stuff). Sometimes a stage copies to cuda device mem, or back, or doesn't and just carries a device pointer through behind an abstraction. Is there a good reason to avoid preallocation on the heap?

I thought we were talking about a situation with no heap! If you have that luxury, heck yeah just call malloc.

That's not always viable. Allowing heap allocation only at init is pretty common in embedded. Read config to get sizes, allocate at startup, never call free().

I don't understand what you mean by "That's not always viable." You can either call malloc, or you can't. If you can only call it at startup, only call it at startup. Every project has different requirements, and Rust will let you satisfy any of them.

I believe first Warcraft game used the same technique in C, IIRC.

Seems to have worked. But it would be a mess to use only stack and static memory for today's large applications.

Absolutely, it’s a pain in the butt. But sometimes it’s what you have to do.

Static buffers, which means they're created at program load time. IIRC, MISRA also allows malloc, but only at startup.

And then you re-use your existing buffers.

To be fair, that is how I code anything I want to be performant regardless of language.

Things have changed a lot since 2012. The Asahi Linux devs have said positive things about writing OS code in Rust. They have built a full M1 GPU driver in Rust which says a lot for the future of system code in safer languages.

I liked C perfectly well, and for over 25 years I wrote software in it, including both Free Software you may have used and in-house software I was directly employed to write for a large corporation. However I began learning Rust back in 2021 and not only do I now not want to write any more C, I want to rewrite my C software in Rust, although obviously 25 years worth of software means that's a whole lot of work and in a few cases I don't own the rights.

> but people who _want_ to actually write, and maintain system software want to do so in C.

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.

I'm going to butt in with a counterpoint, since every time someone mentions "c" on the internet a bunch of Rust people come out of the woodwork and give this impression that Rust is taking over, everything is Rust now, everyone loves Rust, etc.

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.

> I've been a mobile OS developer for a decade now. Basically nobody uses Rust in the real world of firmware/kernel engineering.

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.)

Man oh man. I realized I'd never even seen Rust code once in my life, so I loaded up some random Rust book and skimmed through it. I know HackerNews doesn't like half-informed angry opinions, so I'll just say "I really hope Rust never takes off" and leave it at that.

Not everything can be everyone's cup of tea :)

What about your brief skimming turned you off?

Don’t worry, that’s the same amount of research done as all the other complaints about rust.

Your loss. I tried three times to learn Rust and I had plenty of doubts, but 3rd time I struck to it and it took maybe a year before I would reach for Rust before C (I have 40 years of C muscle memory so that's saying something). Some things _are_ awkward in Rust (eg. occasionally the explicit "a[x as usize]" casts are tiring), but the payoff is awesome.

ADD: what finally worked for me was to not read the book [linearly], but instead jumping between tons of sources, lots of exercises, and generally not stressing about getting everything in all the [ample] detail. And of course doing it and doing it every day. I definitely still have lots of holes (hello async) and I'm not shy about Cloning/Copying liberally unless it really matters for performance.

Look on databases today.

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

> 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?

Even right now rust is quite adopted in PG community.

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

Agree with your points. There is a big difference between hype and actual change. That some hardcore fans want their favorite language to take over, is far different from their language being anywhere near to surpassing or replacing C.

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.

> yet it stays around #15 on the TIOBE index,

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...

Instead of just thinking about maybe only the USA or a favorite site that one might like, look at it from a wider and world perspective. You have entire school systems of various countries that use Delphi/Object Pascal. South Africa, Turkey, Jamaica, Russia, etc... To include Embarcadero is very aggressive in its outreach to schools and pushing its software and licenses, to the tune of many millions of copies (and many years). There are reasons why Embarcadero and Delphi are still very much around.

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.

Lots of people are _entertaining_ Rust as an option, but that's very different from C being defecto. I don't know of a single peace of software I have used written in Rust.

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.

Sure, Rust isn't there yet; C is still undisputably the king of system languages. But it's honestly the first language to crack the chink of C's dominance in low-level programming--C no longer looks unstoppable, in a way that C++ or D never managed to achieve.

Ever used Android? VScode?

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 :)

Linux also contains the building blocks for loading rust modules now as I understand. And some builds like Asahi Linux contain major rust components.

Iirc AWS ship quite some rust in their hypervisor and networking stack too

It's like Chesterton's Fence. If you don't understand why C is used, you aren't going to be able to convince people that they ought to use something else. And you for certain are not going to be able to create a language to replace it.

Still, C is far more enjoyable to write than Rust is.

Constantly fighting with your compiler is not how I would imagine a good time.

I care to disagree. I'd much rather fight with my compiler than play the game of "oops, I segfaulted, let me recompile with -g so I can rerun with gdb so I can figure out where I crashed." Or more minor stuff, like trying to track down which header file actually contains the implementation of, say, struct mcontext_t so I can remember how to set the value of RSP in a signal handler.

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?)

Clearly that's a matter of taste. The popularity of rust shows that some people prefer writing it to writing C or C++, otherwise they'd just write C or C++. And yeah, personally I'd rather spend time fixing compile time errors, directly in the editor as I type, than hunting segfaults with gdb later.

Personally — and I know this isn't a good philosophy for secure software, I'm just commenting purely on the enjoyability aspect — I much prefer the logic game of hunting memory errors over the frustration of one of my tools refusing to do what I'm telling it to do.

Fighting with the compiler just means you have the wrong frame of thinking. Once you learn how to express things in ways that are verifiably safe, there is no fighting because you’ll get it mostly correct the first time.

I agree, but I think you should then look at SPARK2014 [1]. Rust just has better marketing and a bigger company behind it, but SPARK2014 is simpler and has been delivering Rust's bullet list for almost 10 years.

[1] https://www.adacore.com/about-spark

Why on earth did they add 2014 to the name? It’s like putting an expiry date on it before it even takes off.

It is more a version thing, and I always put it in the name to differentiate from Apache's Spark. That and the all-uppercase letters.

> My understanding of things like MISRA C is that it's almost a completely different language

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.

My annecdata: my first language after BASIC was Pascal and I worked professionally for a couple of years using Turbo Pascal, yet I preferred C. I think the reasons were (in order): verbosity and flexibility.

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 love J and APL, but April takes the cake for me[1]. APL in Lisp.

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].

[1] https://github.com/phantomics/april

[2] https://www.adacore.com/about-spark

April is interesting, thanks. Aside: I worked professionally in Scheme for a few years, but Haskell (and ghci) is my favorite language (thus my handle) for experimenting with non-trivial derivations and quick one-off experiments. Rust gives me some of what I love in Haskell (type classes, polymorphic types, sum types, some type inference, rich and ergonomic library, some functional style, ...) without the sad part (space leaks, unpredictable runtime, completely insane defaults from a perf POV)

I find APL and J to be functional enough and terse to a point of beauty once you get it. Look at solutions on rosettacode.org between Haskell and J or APL to get a feel for what I am saying. Rust's syntax is a turn off, but that is a personal bias against my C background once I embraced Haskell, J, APL, Forth, Lisp, etc...

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).

> The "Likeability" of C is very underestimated.

I like C quite a bit for systems programming because it's design is simple, minimalistic, and cohesive - especially given its age. It does not restrict how I design my software. I'm (usually) unsurprised when reviewing the generated assembly. I wish C "successors" would show more restraint. They _usually_ fail on at least one of these points. With that said, I am keeping my eye on Zig, Hare, C3, and a few others.

I very much agree. Rust has some good ideas but the more I've tried it and played with it it lacks that restraint you mentioned. Sooo many concepts, so many sub-languages for different parts. Don't get me wrong, I like the memory safety and that is an honorable goal, but I am not even sure I think ownership / uniqueness types are the best solution for that. There are so many other interesting solutions to memory safety that I think needs to be investigated and tried and I am getting a bit upset that Rust people seem so "our way is the only way"-sounding. But maybe that is just me, as I said I like some parts of the language.

Like you I am looking at Zig and a few others. A recent one I that really caught my eye was Austral (which uses linear types which is the more restrained cousin to Rusts ownership for example).

> trusted safety critical software

Does that exist? Is it only found in expensive, narrow verticals? Because general purpose free or retail software has been blowing up randomly for my entire career. At this point I believe conforming C can be generated, but I doubt a human being can write much at all.