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?
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 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 )
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.
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.
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.
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.
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.
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
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.
Maybe we are entering an era where C is cool again!
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.
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)
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.
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'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.
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.
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'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..
This is easily solved by writing a large Pong application in Rust.
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).
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 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.
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.
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.
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.
Even assembly itself has symbols and labels, which are themselves abstractions.
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.
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."
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).
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.
Can't find current info on it online.
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.
[1] https://github.com/nothings/stb/blob/master/stb_sprintf.h
[1]https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
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.
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.
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."
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).