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?<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:<p>> I also haven’t really experienced the problems Rust claims to be solving<p>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'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.<p>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.<p>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 =)
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 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.<p>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.<p>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 how I feel about C++. It's enjoyable to use!<p>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.
> 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.<p>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.<p>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.
> 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.<p>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.
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.<p>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.<p>[1]<a href="https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/" rel="nofollow">https://www.zdnet.com/article/microsoft-70-percent-of-all-se...</a>
You ever get the feeling that C should be grouped with all the XML and (semantic) web technologies the W3C no longer has active working groups for?<p>Maybe combine them to make a Spring-like framework, but for C?<p>Long standing non-changing specs and standards should be married, and with children.
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.<p>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.<p>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.<p>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.<p>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).