Is this becoming a thing now (or maybe it was always a thing), where a language, like Rust, has become popular enough that instead of everyone talking about learning it, they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist?
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?
I'm a C programmer by day and I disagree with them, C is only simple if you're trying to do simple tasks with it.
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)
I'm a programmer since the early 90's, but I have seen this problem only ever with Rust so far (where people are eager to learn something new, pick Rust, and then quickly get jaded - case in point, that's also me - I learned enough Rust to write a home computer emulator but in the process realised that it is not the right language for me, even though it should be from its feature set).
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)
While I agree, I also have to say that Rust does a lot more than just solve some specific C and C++ issues. It doesnt solve all of them (e.g. logic errors, so if thats 90% of your issues you wont benefit too much), it repeats some design issues of C++ (massive complexity from the start, many ways to do the same thing), and implements a C-like unsafe{} language anyways.
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.
Only when a certain language community tries to promote itself as a “better” C and thinking all C code should be converted and then some people actually tried and do not agree with it.
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.
>they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist?
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.
> they now want to talk about how “simple” and “beautiful” C is for no other reason than signaling how different you are from the zeitgeist?
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
As someone who should like the proposition of C after having read a few books on it I decided to avoid the language if I can. Read: I wanted to like the language, but the deeper I went into it the more I realized that the absolute knowledge of everything needed to wield it is not something that is worth aquiring.
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.
If there's a "hipster" notion here it's not that of choosing C as rebellion against Rust, but that choosing C constitutes a rebellion against Rust and only Rust, as if it's the only systems programming language worth it's salt.
E.g., explain to me like I'm 10 why you think Rust is better than, say, D.
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.
I've been learning Rust lately. Working on a little game. First few thousand lines of code in I was having some doubt. After being a little frustrated with borrows and lifetimes and with my strong tendency to prematurely optimize all the things I was soooo tempted to just switch to C and have full unfettered access to my sweet sweet pointers.
I'm glad I haven't switched though. Performance (which I'm measuring a ton of) is great. The situations where I wanted to bow out and take the 'easier' path were mostly bad design choices on my part and I think partly just laziness.
Rust forces me to think a little bit more, and I've really enjoyed learning about how/why the various language features were designed. Now I'm one of those damned Rust evangelists that have been annoying me for years =)
My reaction to that has always been that it forces us to think about the things we would have had to think anyways if we wanted to create reasonably reliable and secure software. So in the end if saves work, even if it doesn't appear like that at first.
Don’t expect to see immediate benefit from Rust by writing a small Pong application. Rust gives you confidence at scale: the ability to depend on many 3rd party blocks without compromising stability or performance, the ability to grow and maintain the code, collaborate on it, etc. Nothing of this is easily seen on a small self-contained program you can write in C.
I still cannot figure out how to easily write small applications with Rust on low resource computers, like the one I'm typing this from. (Limited storage, CPU, memory.) It seems even the smallest programs require a massive toolchain. The default reliance on network connection for compilation is offputing. It's vastly easier for me to write small programs, offline, with C.
The rationale for using Rust over C that I see published the most is "memory safety". But I can write small C programs for text-processing using flex that do not manually manipulate memory. What benefit would there be to write them in Rust.
I used to love C for its simplicity. There was just no surprises, and the limited feature set enforced a certain programming style that also happens to run very well on modern CPUs.
But the C standard library is just awful. It's so inconsistent and full of quirks you just have to know. Like how some string functions allow you to specify a size, while others don't. And how strtok keeps track of an internal state and behaves differently on subsequent calls.
I wish there was a language that as simple and limited as C, but with modern (and portable) functions for things like strings, networking, graphics and so on.
This is very painfully true, but one 'killer feature' of C is that it is useful without ever using stdlib functions (except basics like memset, memcpy, ... which can be considered compiler builtins anyway).
In more recent languages (even C++) there is no such clear distinction between the language and stdlib any more, which IMHO is a real problem (e.g. most of C++'s problems are actually stdlib problems, not language problems).
It is as much the case that modern cpus have been designed to facilitate c semantics. C was designed for the cpu initially, but a lot of generations have happened since then, and there have been attempts to try other things, and by now the cpu is designed for c to run well on it.
This is how I feel about C++. It's enjoyable to use!
I'm happy to use Python or JavaScript or something else when appropriate, but coming back to C++ is like sitting on your porch, enjoying a cool breeze and the relaxing after a hard day of juggling magic.
I do have an occasional cozy feeling about the time where I was writing VBA for a french bank lol.
I thankful that time is gone, but ! VBA is simple, and may be enjoyable to use!
> There’s just so much “magic” happening in each that it’s difficult to figure out what’s going on. When I’m writing code in these languages, I realize my brain is effectively writing psuedo-C code and then transpiling to whatever language I’m working with.
I feel the same way about these other languages, but for kind of the opposite reason! I write some code in the new language and then transpile it to C in my head just to see what I expect the CPU to be doing. I'm going through SICP right now and I find myself fighting the urge to imagine `cdr` as dereferencing the `next` pointer of a linked list. I spend a lot of time worrying about this stuff when writing other languages, probably to the detriment of my productivity.
Other than assembly language, all languages embody abstractions.
I find understanding certain abstractions hard going because they don't mesh well with my view of the problem domain and my design for solution's implementation.
Actually, x86 assembly also embodies plenty of abstractions. Not sure on ARM or RISC-V, but x86 assembly instructions are not executed the way you'd think by any modern processor.
Essentially the processor reads a while bunch of instructions at once, splits each in the raw microinstructions, arranges them in a graph of dependencies, and then solves an optimization problem to find the best way to schedule nodes from that graph onto its internal execution pipelines. In real-world execution, you can't even tell what assembly instruction(s ) are the ones being executed at a partocular time - disparate parts of various instructions. Some instructions, like "mov ax, 0", don't even execute: they just serve to mark which the tens of real registers is now free to use for another symbolic register like bx.
This is silly. Assembly is an abstraction too. Do you think the CPU actually runs the code you give it? Of course not. There's microcode, register aliasing, speculative execution, etc.
Even assembly itself has symbols and labels, which are themselves abstractions.
You think C is "low level", but it was once considered "high level", and the compiler does many things you don't want, and the standard's ambiguously-worded, and implementers have their own interpretations about the ambiguity, and also bugs in their compilers, and you eventually arrive at:
"If you really want those instructions to happen in this function, without fear of magic, write them in assembly."
> After looking up compatibility for SDL, I noticed it is able to run on iOS 6 and greater, meaning it supports iOS devices all the way back to iPhone 3GS.
Whoah, I was convinced there is no way to write and run apps on these older iPhones - I wonder how difficult the whole process is.
I don't understand using SDL, it's not that hard to write something in Objective-C that runs on earlier versions of iOS as well. You can even cross-compile from Linux, or even run clang directly on iOS if you jailbreak. My own experience is with iOS 4 - 6.
For some time I think about using Rust, but in a cut down manner. Ignore Cargo and most of its stdlib. Not to use traits. Allow myself to use unsafe once in a while. Basically a subset of Rust that would be just safer-C. I wonder if that would be effective for me. Maybe even compile times would be acceptable. I guess, I must just try.
I am one of those that tried Rust, but guess back to C for my own projects. It's usually that I like to write smaller utilities and many quirks of C are not as painful. I like to write things that do not use dynamically allocated memory for example. Also plethora of available alternative C compilers for example something using QBE gives me a nice warm feeling. Yes, it is not all technical for me.
I’ve been enjoying writing libraries in C and being able to use them both from native applications and in web apps via WASM. I personally avoid emscripten and just implement the minimal C/JS glue and utilities myself.
More power to you. C is beautiful. Properly written C is more of an Art than Science. People who say C doesn’t work for large projects often forget that their cars run on C.
Using a memory unsafe language in a situation where it's not strictly necessary is in my opinion not justifiable at all. It's the leading cause for security issues by some measures[1], incredibly hard to reason about and hard to debug. Honestly unless you have a really, really, good reason not to, use a managed language. If that isn't good enough and you want to be fancy use Rust and only if you've exhausted everything else start writing C.
The opposite it also true though: Using a memory safe language where it's not strictly necessary is not justifiable (e.g. Rust is essential for implementing a sandbox - for instance a WASM VM, but not for code running inside that sandbox - because the whole point of a sandbox is that it can run untrusted, unsafe code safely).
The author appears to be quite green behind the ears, which is fine! They’re certainly doing themselves a disservice by being so sure of themselves. There’s a lot here that feels right in the pocket of Dunning-Kruger ignorance.
Being able to analyse the benefits of new tech at a distance (which is what the author is doing with their sterile toy projects) is not something that you can “fake until you make it”. It requires a lot of deep experience with different technologies, enough that you can pick up the common patterns of costs and benefits, which for the most part never change. This is exactly what OP is doing. Their big list of languages they’ve worked with is doing the opposite of what the author intends. All it says to me is that their bar is way too low, and that they do not understand the level of technological understanding required for a language’s inclusion in that list to mean absolutely anything in the context of this blog post.
In all I’m not really sure what the point of this post is. By the author’s own admission they haven’t worked with much C. If someone doesn’t understand the value in a language that addresses the memory safety footguns of C, I assume that they’re at best inexperienced, or at worst part of the quite sizeable contingent of C developers that are in complete denial about the language / standard library’s shortcomings, especially with regard to memory safety, because it’d require them to admit that they themselves are imperfect developers.
> The first language I properly learned was C in first year of my engineering degree. [...] My experience in the class solidified my belief that programming was what I wanted to do and forged a bond with the C language that I didn’t realize until now.
I am highly skeptical that the author understands the full ramifications of undefined behavior, dangling pointers, platform-dependent integer sizes, and the myriad sharp edges of the C programming language.
I don't disagree that, for example, Rust has a heavy syntax. But those exist for a reason. Those are the result of hard-earned lessons from phenomena like double-free (see ownership) and duck-typed templates in C++ (see traits).
hnarn|2 years ago
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?
ChrisRR|2 years ago
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)
flohofwoe|2 years ago
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)
lionkor|2 years ago
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.
up2isomorphism|2 years ago
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.
coldtea|2 years ago
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.
spoiler|2 years ago
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
scoutt|2 years ago
Maybe we are entering an era where C is cool again!
atoav|2 years ago
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.
tpoacher|2 years ago
E.g., explain to me like I'm 10 why you think Rust is better than, say, D.
pulse7|2 years ago
throwntoday|2 years ago
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.
raverbashing|2 years ago
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.
rootw0rm|2 years ago
I'm glad I haven't switched though. Performance (which I'm measuring a ton of) is great. The situations where I wanted to bow out and take the 'easier' path were mostly bad design choices on my part and I think partly just laziness.
Rust forces me to think a little bit more, and I've really enjoyed learning about how/why the various language features were designed. Now I'm one of those damned Rust evangelists that have been annoying me for years =)
weinzierl|2 years ago
My reaction to that has always been that it forces us to think about the things we would have had to think anyways if we wanted to create reasonably reliable and secure software. So in the end if saves work, even if it doesn't appear like that at first.
kvark|2 years ago
1vuio0pswjnm7|2 years ago
The rationale for using Rust over C that I see published the most is "memory safety". But I can write small C programs for text-processing using flex that do not manually manipulate memory. What benefit would there be to write them in Rust.
ihatepython|2 years ago
This is easily solved by writing a large Pong application in Rust.
Fell|2 years ago
But the C standard library is just awful. It's so inconsistent and full of quirks you just have to know. Like how some string functions allow you to specify a size, while others don't. And how strtok keeps track of an internal state and behaves differently on subsequent calls.
I wish there was a language that as simple and limited as C, but with modern (and portable) functions for things like strings, networking, graphics and so on.
flohofwoe|2 years ago
This is very painfully true, but one 'killer feature' of C is that it is useful without ever using stdlib functions (except basics like memset, memcpy, ... which can be considered compiler builtins anyway).
In more recent languages (even C++) there is no such clear distinction between the language and stdlib any more, which IMHO is a real problem (e.g. most of C++'s problems are actually stdlib problems, not language problems).
Brian_K_White|2 years ago
unixgoddess|2 years ago
coreyp_1|2 years ago
I'm happy to use Python or JavaScript or something else when appropriate, but coming back to C++ is like sitting on your porch, enjoying a cool breeze and the relaxing after a hard day of juggling magic.
dgan|2 years ago
sakras|2 years ago
I feel the same way about these other languages, but for kind of the opposite reason! I write some code in the new language and then transpile it to C in my head just to see what I expect the CPU to be doing. I'm going through SICP right now and I find myself fighting the urge to imagine `cdr` as dereferencing the `next` pointer of a linked list. I spend a lot of time worrying about this stuff when writing other languages, probably to the detriment of my productivity.
GianFabien|2 years ago
I find understanding certain abstractions hard going because they don't mesh well with my view of the problem domain and my design for solution's implementation.
tsimionescu|2 years ago
Essentially the processor reads a while bunch of instructions at once, splits each in the raw microinstructions, arranges them in a graph of dependencies, and then solves an optimization problem to find the best way to schedule nodes from that graph onto its internal execution pipelines. In real-world execution, you can't even tell what assembly instruction(s ) are the ones being executed at a partocular time - disparate parts of various instructions. Some instructions, like "mov ax, 0", don't even execute: they just serve to mark which the tens of real registers is now free to use for another symbolic register like bx.
throwawaymaths|2 years ago
Even assembly itself has symbols and labels, which are themselves abstractions.
shrimp_emoji|2 years ago
You think C is "low level", but it was once considered "high level", and the compiler does many things you don't want, and the standard's ambiguously-worded, and implementers have their own interpretations about the ambiguity, and also bugs in their compilers, and you eventually arrive at:
"If you really want those instructions to happen in this function, without fear of magic, write them in assembly."
hdjjhhvvhga|2 years ago
Whoah, I was convinced there is no way to write and run apps on these older iPhones - I wonder how difficult the whole process is.
ihatepython|2 years ago
detrites|2 years ago
Can't find current info on it online.
hawski|2 years ago
I am one of those that tried Rust, but guess back to C for my own projects. It's usually that I like to write smaller utilities and many quirks of C are not as painful. I like to write things that do not use dynamically allocated memory for example. Also plethora of available alternative C compilers for example something using QBE gives me a nice warm feeling. Yes, it is not all technical for me.
david2ndaccount|2 years ago
sjmulder|2 years ago
0xfedbee|2 years ago
Barrin92|2 years ago
[1]https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
flohofwoe|2 years ago
hussainbilal|2 years ago
Maybe combine them to make a Spring-like framework, but for C?
Long standing non-changing specs and standards should be married, and with children.
KyeRussell|2 years ago
Being able to analyse the benefits of new tech at a distance (which is what the author is doing with their sterile toy projects) is not something that you can “fake until you make it”. It requires a lot of deep experience with different technologies, enough that you can pick up the common patterns of costs and benefits, which for the most part never change. This is exactly what OP is doing. Their big list of languages they’ve worked with is doing the opposite of what the author intends. All it says to me is that their bar is way too low, and that they do not understand the level of technological understanding required for a language’s inclusion in that list to mean absolutely anything in the context of this blog post.
In all I’m not really sure what the point of this post is. By the author’s own admission they haven’t worked with much C. If someone doesn’t understand the value in a language that addresses the memory safety footguns of C, I assume that they’re at best inexperienced, or at worst part of the quite sizeable contingent of C developers that are in complete denial about the language / standard library’s shortcomings, especially with regard to memory safety, because it’d require them to admit that they themselves are imperfect developers.
jbstack|2 years ago
I didn't find the OP to be sure of themselves. See e.g.:
"Admittedly, this would slowly go away as I gained more experience with the language."
"This is likely because I haven’t spent enormous amounts of time in C/C++"
"I will probably come out on the other side with a lot of the same feelings about C as other languages."
"Maybe I will find the complicated syntax and rules of Rust are worth it."
frodowtf|2 years ago
nayuki|2 years ago
I am highly skeptical that the author understands the full ramifications of undefined behavior, dangling pointers, platform-dependent integer sizes, and the myriad sharp edges of the C programming language.
I don't disagree that, for example, Rust has a heavy syntax. But those exist for a reason. Those are the result of hard-earned lessons from phenomena like double-free (see ownership) and duck-typed templates in C++ (see traits).