C gives you enough rope to shoot yourself in the foot. And rightfully so. It came out in a time when everyone was coding assembly. It's meant not to hold you back from doing voodoo with low-level stuff, therefore it won't hold your hand.

Not very practical in the world of today when we've been spoiled by 'better' languages and you need to quickly ship stuff that mostly works without worrying about the little things, but at the time it was revolutionary.

As a C programmer shouldn't you have a library abstracting all this by now? Either your own or one of the dozens available, including pascal-style strings?

  struct strbuf { size_t cap, len; char *str; };
  void sb_setf(struct allocator *a, struct strbuf *sb, const char *fmt, ...);
  void sb_appendf(struct allocator *a, struct strbuf *sb, const char *fmt, ...);
  // have other convenience functions for formatting fixed point values like "prefix AAA.BBB suffix" ("voltage: 7.23 V")
  // special helpers for dates, times, etc.

Obviously, this isn't necessarily an improvement, but in theory you could do this:

  size_t getlength( int m, char (*p) [m] ) { return sizeof *p; }

  char mystring[] = "Hello";
  getlength( sizeof mystring, &mystring )

I've felt that way too, and it's been enough to push me away even as I've tried to build things in Rust in earnest. Along the same lines, I've found it hard to say exactly why I like C and super dislike C++. I guess I have to say it's simplicity--like I won't argue C is by itself simple (integer promotion by itself is not simple) but it's definitely simpler than C++, and the simplicity and power of its core conceit (everything is a number) is just enrapturing. I think it's just an ethos thing: Rust doesn't strive to be simple and I find that makes it impossible for it to delight me.

I also think that's broadly why newer languages have failed to capture the je ne sais quoi of C: you really can't get away with "everything is a number" these days.

This is in a nutshell why I haven't switched to Rust. All I actually want is a small language like C, Go or Zig, but with compile time memory safety guarantees. Even if it means that a lot of 'dangerous' flexibility is removed or in an unsafe{} block (essentially a Rust--).

IMHO one problem with Rust is that it is moving too quickly into too many different directions, and as a result becoming a 'kitchen-sink language' in the tradition of C++.

Most of Rust's features interact in ways that aren't obvious. For example to get the basic memory safety guarantees that the borrow checker provides, you also need:

- the "no mutable aliasing" rule

- destructive move semantics and the Copy trait

- generic containers like Mutex and (probably?) generic enums like Option and Result

- thread safety traits like Send and Sync

- closures, and closure traits like FnOnce

Of course yes, you can have "safe C" without async, and Rust 1.0 shipped without async. But I think it's notable that The Book doesn't teach async. Most of the things The Book teaches are actually necessary for memory safety to work.

Not gonna lie, I don't see too much value in async, but that said, I can see where they (the Rust devs) are coming from. It was an oft requested feature, and it was in the pipeline for ages, leading to Rust dev burnout.

That said Rust team is working on making it fully usable, albeit the space of efficient, zero-cost abstraction closures that work with lifetimes is a set of one language - Rust.

Very true, but C is the standard language on *nixes, so it's often the one that sucks less. It also strikes a good balance between mental burden and expressiveness for writing simple programs that aren't so trivial that they're just a shell script or one-liner. Rust is just too ugly and verbose to make it what I reach for to quickly hack out a throwaway utility with.

Rust blazes a whole new path, with the slightly different objective of safety. It's simple and lean, almost like C. It bakes in lessons learned over the years like inheritance being overly complicated, OOP generally being overly complicated, and how dangerous systems programming can be by having modules instead of classes, composition instead of inheritance, and memory safety as a default. It also broke the false dichotomy of "fast but dangerously leaky" or "slow but safely garbage collected" by introducing borrow checking and move semantics, allowing speed and safety with no garbage collection.

D feels like a continuation down an evolutionary dead end, like teleputer cartridges in Infinite Jest.

Rust feels like an innovative fresh start, like transferring digital DRM-free files.

(If you think that makes D sound charming, I agree. But realistically I would stick with Rust. :p)

The traditional solution is to have different languages for different code layers (e.g. a compiled language for the low level parts, and an interpreted scripting language for the high level parts), but this comes with its own set of problems.

I've written more in C than in any other language (and I've written in dozens of languages professionally over the past 25 years). But the one thing that gets hammered home with every line of C I write is this: You're playing with a loaded gun.

The more code there is, the more likely it is that you have subtle heisenbugs that break in mysterious ways. My current job requires C (for a number of good reasons), and I really notice the jump in crazy, hard-to-track bugs despite my DECADES of experience as a careful, expert C programmer.

C is "simple" because all of the complexity gets pushed to the compiler behaviour and runtime environment. You don't even discover how many assumptions you've been making until you have years of experience under your belt.

Rust’s compiler is slightly slower than many other languages (as it simply does more), but it’s not a significant degree where you would need some monster machine..

No matter what the cpu does internally to arrive at producing the requested output from the supplied instructions, it DOES produce exactly the reqested and expected output from the given instructions.

What it does not do is for example maybe a + operator doesn't mean the same thing after some unknowable prior step changed the definition of +, or flatly not provide a means to manipulate some data in a way that a language author thought was crazy and no one could ever have a valid reason to do $thing like idk execute a string or something. Sure there are now optional settings and features you could consciously use, for example to enforce that data/exec seperation, but it doesn't just do it by it's own magic according to someone else's rules instead of your own code.

Of course assembly is an abstraction, but it is the lowest level programming language that ordinary mortals can still write code in, which was the point the GP was making.

Exactly nobody writes applications in microcode. Register aliasing and speculative execution have under normal circumstances no effect other than some performance which if the CPU just did as it was told by the assembly code (or actually, the machine code, the binary representation of the possibly optimized assembly) would still work exactly as advertised. You can also switch those off if they're features of the assembler, and if the CPU does them then you're going to have to live with it.

If you really wanted to make the point that Assembly is an abstraction then macros would have probably been a better thing to mention.

C's position in the "low- vs high-level" hierarchy arguable hasn't changed much since it was created. There were already higher level languages in the 60's (e.g. languages which abstracted the underlying hardware much more than C, but those weren't useful for writing an operating system in).

[1] https://github.com/nothings/stb/blob/master/stb_sprintf.h