The very common thing I want to use in C is some sort of variable size string object. But no, I have to dynamically allocate a buffer that I know will be at least the right size for any text I ever put into it, or do I create a buffer that's the correct size for that string but re-alloc if I ever change it to a longer string. But then how do I store the buffer size? Do I want to create a struct that constains a point to the buffer and the length, or use sizeof() to calculate the string length? But then I can't use sizeof() if I pass that buffer into a function via a pointer. If I pass that string to a function is it being copied straight away or just storing the pointer so I can't change the string at a later date. I can't enforce copy semantics
And god forbid you ever forget to include space for the NULL
I just want a string I can dump some text in, I don't want to go searching for libraries, I don't want to have to consider allocation and copying and all that crap. If I wrote half of my boilerplate C code in python it would look just as simple and beautiful (if not more)
C gives you enough rope to shoot yourself in the foot. And rightfully so. It's meant not to hold you back from doing voodoo with low-level stuff. It came out in a time when everyone was coding assembly.
This was before my time, but I think it's a common misconception (only true for operating system development). When C was created, there was already Lisp, Cobol, Fortran, Algol, Simula, BASIC... and SmallTalk and Prolog were just around the corner - and most of those are much higher level than C).
Exactly this. This belief that Rust can and even will replace C is at best ignorant and at worst evangelical. In fact I’m convinced most Rust enthusiasts on HN are less involved in programming and more with politics.
While I’m all for mem-safe languages Rust is simply too abstract and undefined to work on any real embedded systems work. At most, it can work on the driver level, but even that code will need to be constantly redone as the language ages without any proper specifications.
...interesting that you mention that, I think that functions and structs are the essential 'core abstraction tools' that get you to at least 80% of any higher level abstractions that were invented since then, and this is exactly the reason why C is still quite popular. Its feature set is just enough to be considered a high level language which enables abstractions, but not more (especially no fads and fashions that came and disappeared again).
It is a urban myth that C was the first one, usually pushed by naturally UNIX folks.
JOVIAL, ESPOL, NEWP, PL/I, PL/S, PL.8, PL/M, Bliss, Mesa, Modula-2, VMS Basic, VMS Pascal,...
If this was intended to illustrate the unexpected consequences of undefined behavior it succeeded remarkably well!
I will utterly kill all humor by explaining it:
They made a funny observation about a thing that happens. The thing that happens is (today) called UB. The funny observation is that that comment kind of exhibited the outward appearance of what the effects of UB could look like.
It began reciting one metaphore, "enough rope to hang yourself" but mid-way unexpectedly switched to a different metaphore "shoot yourself in the foot", producing a combined invalid nonsensical output. As though a program suffered some UB in the routine for looking up and printing metaphores.
The comment author might have done it on purpose. Maybe they intended to make exactly that joke.
The history of the term UB has no more bearing than the history of any of the other words used.
eg. C leaves the case of exceeding the size of an int undefined. In most cases it has a predictable effect on modern, mostly similar architectures but that is by no means guaranteed, and forcing an architecture to calculate overflow a particular way seems like a negative.
That being said, everyone has a pet example of a compiler doing some really odd and deep optimisations - I suspect that’s mostly due to successive layers and optimisers adding up to have unexpected effects, rather than a deliberate effort by compiler writers - but I’m no expert on the matter.
Section 4. Conformance says "A strictly conforming program shall only use those features of the language and library specified in this International Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any implementation limit."
Compilers are not allowed to produce output dependent on UB for strictly conforming ISO C programs, they must optimize those statements out. Treating UB as impossible is required for ISO C. It's NOT required for GNU C, or Clang C, or Microsoft Visual C, but they usually do so anyway (even though they're not compiling strictly conforming ISO C programs).
Expect to hear from @pjmlp on this!
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.
If you’re extremely lucky, things will compile and work.
If you’re just lucky things won’t compile, and you’ll have to write conversion functions (or macros).
If you’re unlucky, there will be subtle differences, likely poorly documented, between the libraries, and code will compile but have subtle bugs.
Of course, other languages have that problem, too, but at the higher level of json parsers or graphics libraries, not at the basic level of strings, lists, or maps.
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?
The long term cost of those decisions as well as the number of really bad bugs (and security issues) that can be traced back to one-off code is likely much larger than the same figure for well used libraries. But it all sort of evens out whenever a bug in such a library is found because then it is so widespread that lots of systems will suffer.
Weird how that works.
Well, not sure about the LISP programmers, but C programmers have a good reason: they work under different environments (from embedded to Windows, legacy UNIX, the latest Ubuntu, ...) and also have different needs, regarding allocation, string management, etc. So one-size-fits-all lib might not cut it for everybody. It can also be as simple as having an inherited codebase which uses something else.
Still, there are popular string libraries, and C programmers do use them when they can.
The only problem is C is simply not expressive enough to have proper abstractions like that.
Everything else, however, cannot.
Their industry uses are highly different as well. C is almost a requirement for embedded systems, and while C++/Rust can be used there, they’re simply too complex and in Rust’s case additionally too young to be adopted. C++, and possibly Rust (if it can get its act together), are more used in high level programming, as that’s what they’re built for.
If C++ could do what C can, then why is the Linux kernel 98.5% C code? Wouldn’t it be better to use a more varied and powerful language?
Or, maybe different languages have different use cases and cannot be directly slotted in to replace one another.
As a result to some extent GCC and Clang are also compilers for some sort of "Linux C" which is strongly reminiscent of the ISO standard language but distinct.
And there's no reason you would choose C++ for a project where you'd otherwise use C on account of the (exaggerated) relationship between the two languages, the reason you'd do it would be that you want C++ features, and Linus doesn't want C++ features. Projects to "just" compile the existing Linux code but with C++ compilers failed AFAIK.
And maybe this: https://dl.acm.org/doi/10.1145/3477113.3487274
(I agree though that the C standard isn't actually relevant in the real world, most C compilers treat it more or less as a 'suggestion', unless enforced with options like '-pedantic')
What does language complexity has to do with anything? It will get compiled down to machine code, and both can be and are used for embedded. They occupy the exact same low-level niche as C, hell, they may be even more level as they can also do things like SIMD.
Linux kernel is C because Linus doesn’t like C++, it’s that easy. And usually no, why would you use multiple languages in a project if you don’t have a good reason?
Sure, it's possible (you can write C in C++, for the most part, and to its credit, C++ has placement new). But many of C++'s niceties require memory allocation, making much of its value-add over C questionable.
The first version used preprocessor macro tricks for generatic code, basically what Go folks re-discovered with //go:generate, we already had it in 1992.
BIDS 2.0 already used templates.
It was exactly because even C++ for MS-DOS provided safer library than C, that I was never that into C. It wasn't better than TP in features and safety, only in portability, and that I could get from C++ anyway.
And/or you need a crate like alloc, heapless, etc.
For the sake of a sprintf "abstraction"...
std::string_view would have been a good thing if it hadn't added another memory corruption foot gun.
A general string type is one of those things where you can either have convenience or performance, but never both.
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 )
It feels a bit like a speed run of C++, at least this took around 2 decades for people to get fed up and turn away ;)
(and interestingly, I also switched back to 'mostly C' for my hobby stuff, and I'm quite happy with it)
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.
I don't think C consistently lives up to this principle:
- In the memory model, even simple integers can hold "poison" values.
- Pointers usually behave like integer addresses, but in the memory model they have "provenance" (edit: spelling), and they also have to follow "strict aliasing" rules.
- Signed integer overflow is UB. We could ignore integer promotion rules most of the time, if not for this restriction.
- Even simple integer assignment isn't simple when an integer is shared between threads. Atomic orderings are hilariously complicated.
I worry that a lot of people who find delight in C just...aren't aware of these rules? Or maybe aren't consistently aware? Or maybe are aware but think that some violations are benign?
Although I am tickled by the idea of pointer providence – that pointers are handed to us from on high, from the C gods.
(and actually: yes, some rules are benign if the major compilers agree on the same non-standard behaviour, so far I have never seen unions used for type punning break in C++ for instance - it's good that C++ now offers a 'proper' alternative though).
It's pretty much an illusion that any non-trivial C or C++ program can be entirely standard compliant, it always depends on the specific compilers it has been tested with - which is still a better situation than Rust, which only has a single implementation (so far).
- whoa cool everything is a number! Make that light blink, wipe that SDRAM chip, whiz bang!
- What the fuck is a torn read (insert any C gotcha in here)?! Everything is garbage!
- I know, I'll encapsulate "The right way to do things" in a library/new language.
- Never mind, I've decided to build websites (insert popular tech job here) for a living, but be super grouchy about it
The corollary to "I think Rust's complexity makes it impossible to delight me" is "I think C's brittleness makes it impossible to delight me." It has notes of innocence lost, nostalgia, a "simpler time", etc. Are those days gone forever, as the Dan say? Dunno.
Maybe we are entering an era where C is cool again!
If Rust was just C but with strong typing, a borrow checker and what would basically be suoer strong static analysis of pairing malloc() and free(), people would likely switch immediately.
But it isnt - its a whole different beast which by far is not perfect and repeats many issues it didnt need to repeat (e.g. terrible async like python).
Its just so good at having a compiler that tells you whats wrong that most of the other things are not that bad, and switching to Rust is likely good for 80%+ of C projects.
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.
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.
1) tokio, which uses unsafe{}, and/or
2) async functions requiring all calling functions to also be async
So, really, you can't avoid it. The ecosystem is built on the idea of NIH, which is fine, if it wasnt for so many rust features you can abuse so heavily (e.g. macros to make your own language that I then have to learn).
There are a lot of issues with the complexity Rust brings.
It sounds to me like they keep learning languages with the same illusions and failing to take any lessons between their language exploration escapades.
All programming languages suck. It's just about finding the one that sucks the least for you (or your project/business).
They made the comparison of RPG characters and mentioned endgame frustrations. In my experience, C is the epitome of endgame frustrations (C++ maybe being worse, depending on codebases you work on); they've just yet to discover that
Overall, C++ can be great choice, but it often times results in not being due to lack of rigorous discipline by everyone involved on the project.
It's a bit philosophical whether that's a problem of the tool or the craftsman, but I think it's usually a bit of both.
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.
I understand most of the historical reasons why certain things in the language are the way they are, but some of those result in really bad ergonomics and counterintuitive behavior.
So simple and beautiful is not how I would describe C even if I would love it to be that way.
These people (with rare exceptions) quite funnily never seem to have shipped some actual product or service based on those "simpler" languages. Or if they have it's shipping their parallel implementations of basic services that every language does better than C like strings, slices, data structures, etc. And no, if your code depends on cpp macro magic, it is not helping your point.
Given that this has been an argument for 3 decades or so, e.g. compared to C++ especially, I don't think so.
Even more so since C is not just some trendy language you pick up quickly, but needs quite a lot of time and effort to be profficcient in, to the point of appreciating its simplicity and portability/stability/etc benefits.
>Rust exists for a reason, and it solves specific problems.
Rust exists because its creators had a reason such a language was needed in mind. Doesn't mean others necessarily share it, or if they do, that they see Rust as the solution to the problem behind that reason.
But if say the foundation that supports it's development were to try asserting draconian control over it, many may reasonably be turned off.
I'll stick to C/C++ personally, rust does seem less flavor of the month but I can't get behind it if it's clear there are nutjobs at the helm.
Just write programs with your favorite language, if it is actually a “better “ one it will win, and you don’t annoy yourself and others by over promoting it. C did not start by building a evangelical strike force but bunch of programmers that actually wrote software that people have to use.
E.g., explain to me like I'm 10 why you think Rust is better than, say, D.
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)
Rust exists for a reason, and it solves specific problems. That’s the “magic”, just like any abstraction in any language. So what’s the argument, that abstractions are bad? Clearly not:
> I also haven’t really experienced the problems Rust claims to be solving
This is like hearing someone say 20 years ago that “I’ve heard a lot of good things about PHP but I don’t see the point of it, because I’ve never had to write a web application that interfaces with a database” — well, no shit?