Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP.
If they are getting good results with C and without OOP, and people like the product, then those from outside the project shouldn't really have any say on it. It's their project.
> strangely and disproportionately pushed on Hacker News
There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages.
> then those from outside the project shouldn't really have any say on it. It's their project.
People outside the project are allowed to say whatever the hell they want, the project doesn't have to listen.
I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pushing of say Kotlin or Scala or Go or, etc from their fans.
I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like web services, but its big runtime and its GC rule it out for a lot of (especially very low level or latency-critical) uses -- you don't see Go ported to microcontrollers for instance. I can't speak for Scala, because i don't have experience writing software in it.
To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.
There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.
I‘m in the process of migrating Kotlin code back to Java in our product. My experiment with Kotlin is over and I‘m sticking 100% with Java. I like writing Kotlin, but I dislike reading Kotlin code.
First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade".
The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Kotlin's native backend and GraalVM.
The widening gap is not at all moving Kotlin further away from Java developers, but is just increasing the reasons to migrate. It is crucially not making interoperability with existing, legacy Java harder, just giving you more toys. Stuff like suspend functions vs. virtual threads only affects decision making in new application code, and you can for all intents and purposes use either depending on whether you're writing new Kotlin libs for a legacy Java app or a Kotlin app using legacy Java libs.
The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.
Plus, considering that Android apps were responsible for a very significant portion of actively developed Java (I would assume quite a loand has with Android having gone full Kotlin, a quite significant portion of Java developers will either already have migrated or soon be migrating to follow suit. This will over time affect a quite significant portion of the available skill pool for hiring, which will add additional pressure on enterprise.
There will always be Java, but I'd expect a significant portion of actively developed applications (as opposed to maintenance-mode only applications) to slowly migrate to either Kotlin or something else entirely.
I think you're widely mistaken if you don't think Java is a platform. The VM and language are intertwined. The VM explicitly knows about things like records, language constructs, and idioms from Java. Java sets the direction of the VM, not Kotlin.
JVM does not know about Java, it knows about an IR that Java, Kotlin, Scala, Closure, Groovy, etc. all target. Java as a language also doesn't know about JVM, as it commonly targets things that are not the JVM, whether that is Dalvik, Graal or something else entirely.
That the JVM and IR has features to help the Java compiler generate better output is obvious but not really relevant. Modern CPUs also have instructions to help C compiles generate better code, but that doesn't make them C platforms. It's just that implementation details.
So no, Java is not a platform. It is a language that sometimes runs on the JVM together with many other large and quite influential languages.
You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?
> The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable (...)
Yes, in the sense that Java exists and Kotlin by design piggybacks on the JVM.
> The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.
This analysis is very superficial and fails to identify any of the real world arguments to switch from C. For example, Microsoft outright strangled C by wasting many years refusing to support any standard beyond C89, in spite of being directly involved in it's drafts. This was a major contribution to address any of the pain points and DX shortcomings. Compare the evolution of C and C++ during that time period, and we see C++ going through the same path in the C++0x days to then recover spectacularly once C++11 got unstuck.
> You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?
Java runs on several things that are not the JVM. Android does not use JVM to run Java, and even Oracle is pushing something that is not the JVM.
At the same time, JVM runs many things that are not Java.
If you are somehow implying along the lines of JVM only got initially authored because Java, then that is nothing but a historical fact of little relevance from the early days of the language. If not even Oracle considers Java and JVM one thing - and by virtue of Graal they don't - then it simply isn't as such.
> This analysis is very superficial and fails to identify any of the real world arguments to switch from C
You misread - what you quoted was not an analysis of why the migrations happen. It was a parallel, underlining that migrations do happen in spite of obvious feature differences (and sometimes, because of such differences).
Yeah, Kotlin is stuck in an uncomfortable position, like F# is in the .NET world. It has pioneered several important features, but now the big brother has implemented them slightly differently and people demand interop from you.
At least Kotlin can theoretically retreat to Android.
I did a decent amount of AoC this year in F#. I felt it was more verbose than I would have expected. There were a lot of things that helped brevity; I really liked type definitions, unless I was using OO features where it was extremely verbose to define members. I also really didn't like having to to Seq.map or List.filter for everything instead of just calling methods off of the seq or list.
From my POV having worked at a giant 50,000 person tech org—primarily Java—Kotlin was the kick in the pants that ushered in a lot of changes in the post-Java 11 world. We were on the verge of migrating wholesale to Kotlin after our CTO wrote an internal whitepaper in favor of the direction.
> As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this)
does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language.
After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there was an absolute proven need to switch languages, I'd mandate only a single language for our (back end) stack. The cost of supporting different languages is just too high.
I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.
> I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods.
This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to get anyone at a proficient level.
This claim is so outlandish that I'm inclined to dismiss it entirely as completely made-up. There is no project manager in the world who would even entertain this thought.
Your world seems small -- I never said anything about dumping codebases. If i have a library implemented in Rust, which gets called by a program written in C++ through FFI, and contacts a service which is implemented in python, I don't need to dump or waste any old work. A carpenter that only uses a hammer isn't a very good carpenter; different tools have different strengths and weaknesses.
Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.
Kotlin's Niche was to replace LEGACY Java with something that builds for older versions of Java but also gives you features and ergonomics not available for those features. There's a ton of super legacy Java out there.
Carbon is what could someday be a real successor to C++ in my eyes. It actually focuses on being compatible with C++ code similar to how Kotlin can work with Java directly, except it will make a lot more sense once it is stable and usable, I just hope its not a 'forever-project' like Fuchsia.
>To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
This doesn't explain why so many rust activists are going to projects they have no involvement in and demanding they be rewritten in rust.
What's happening is that there are progressive minded people who have progressive minded tactics, where they have a cause and everywhere they go they push their cause regardless of whether the places they are going have anything to do with their cause.
Is it really activism though, i.e. a concerted effort to put pressure on project leaders and make actual "demands"? Or is it just the occasional young Rust enthusiast asking questions or making the case for Rust?
> I think this is because of the gap in its target market
Surely that gap has been filled for at least a decade, even if only by Rust itself?
Moreover, I am not sure that serves as an explanation as it shows up in the strangest places. As you mention Go: Visit any discussion about Go and you'll find some arbitrary comment about Rust, even though, as you point out, they don't even exist in the same niche; being different tools for different jobs.
> Go was originally pitched as a C or C++ replacement
It was originally imagined that it would replace C++ for network servers at Google. The servers part was made abundantly clear. In fact, the team behind it expressed quite a lot of surprise that it eventually found a home doing other things as well.
> you don't see Go ported to microcontrollers for instance.
> Surely that gap has been filled for at least a decade, even if only by Rust itself?
I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one.
> the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin
What, exactly, does distance mean here?
The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not because of C++, but because something like Python (of which Google was the employer of van Rossum at the time!) was too slow. Go was created to offer something more like Python but with performance more like C++. It was a "C++ replacement" only in the sense that C++ is what Google was using where it was considered the "wrong tool for the job". Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast.
Putting things into perspective, the distance between C++ and Go is approximately the same as the distance between C++ and Python. Which is a pretty big distance, I'd say. C, C++, and Rust are much closer. They are all trying to do essentially the same thing, with Rust only standing out from the other two thanks to its at-the-time unique memory model. So it is apparent that we still don't understand "gap" to mean the same thing.
How I interpret his comment about the distance:
The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go (in the similar use-cases) or from Java to Kotlin.
Another argument offered for Rust is that it's high-level enough that you can also use it for the web (see how many web frameworks it has). So I think that Rust's proponents see it as this universal language that could be good for everything.
> The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go
Ten years ago the memory model was a compelling benefit, sure, but nowadays we have Fil-C, that C++ static analyzer posted here yesterday, etc. There is some remaining marginal benefit that C and C++ still haven't quite caught up with yet, but is that significantly smaller and continually shrinking gap sufficient to explain things as they stand today?
You are right that the aforementioned assumption did not play out in the end. It turns out that C++ developers did, in fact, choose C++ because of C++ and would have never selected Python even if Python was the fastest language out there. Although, funnily enough, a "faster Python" ended up being appealing to Python developers so Go does ultimately have the same story, except around Python (and Ruby) instead of C++.
> Another argument offered for Rust is that it's high-level enough that you can also use it for the web
It was able to do that ten years ago just as well. That doesn't really explain things either.
> I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues.
The "long history of safety issues" is actually a combination of being extremely successful (the world runs on C and C++) and production software always featuring bugs.
The moment Rust started to gain some traction, we immediately started seeing CVEs originating from Rust code.
Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
Sqlite's test suite is closed source, so no one other than the Sqlite authors can attempt that. That said, you may be interested in this attempt by Turso to rewrite Sqlite in Rust (https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...). They're not using AI, but they are using some novel ways to test their code.
I'm mostly a Java dev, but baby-stepping Rust has been a lot of fun and reminds me, in a very good way, of the feeling I had in the late 90's when I was first learning Java.
Well that's because C, and C++, are uniquely awful and Rust can actually take them on.
Kotlin doesn't have a strong case for replacing java because java is, well, just fine. At least it's safe. Sure it's, like, slightly inconvenient sometimes.
And other languages like Go which originally claimed to take on C and C++ just don't. Go is garbage collected, it's not a real competition.
But Rust is different. It's actually safe, and it's actually a real competitor. There's basically zero reason to choose C other than "I know it" or "one of my library author's knows it". Which are both very good reason, but incidently have nothing to do with the language itself.
Go has already more or less won its target market. Rust proponents are still working to convince C and C++ holdouts, who are understandably skeptical given the past several decades of promised replacements that never materialized.
I think that's true - but I guess Rust and Zig are unique in that list on being new memory-managed languages (i.e. without garbage collectors).
Low level memory-managed languages have been C and C++ mostly for a really long time, so I think Rust and Zig probably seem "more new" than the likes of Kotlin, Go, Elixir, Gleam, etc.
Can I start then with Scala - it's my favorite language and easily has the best of both OO and functional worlds with insanely useful libraries to express code ergonomically. EVERYBODY SHOULD USE IT!
"having a say on something", in OP's context, means authority and influence over decisions... People can say whatever they want, yes, but not everyone can "have a say on something".
> People outside the project are allowed to say whatever the hell they want
What these people do is a disservice to the general open source community, by spreading misinformation and general FUD about critical software that uses C and C++.
I definitely wouldn't say internet, I think it's popular on HN and a few other online forums. There are a lot of X/twitter circles which make are critical of rust, as well as other sites.
In my mind at least there's a decent risk Rust is going to end up like the next Haskell, its benefits other than safety are not that clear and many of those features can and have been replicated in other languages.
Many of its biggest benefits of rust come directly from other languages - including Haskell. Like, rust’s Option is identical to Haskell’s Maybe type. Traits are similar to type classes in Haskell, or interfaces in Go.
In my mind, the thing that makes rust and zig nice are that they put modern language features in a systems language. Non-nullable pointers and match expressions in a language that runs as fast as C? Yes please.
I love rust, but I personally doubt rust will ever be anywhere near as popular as Python, go, JavaScript and C#. It’s just so complex and difficult to learn. But its niche is pretty clear to me: I see it as a tool for writing beautiful, correct, memory safe, performant systems code. I used to love C. But between zig, rust and Odin, I can’t see myself ever using it again. C is just so much less productive and less pleasant to use than more modern languages.
> There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages.
This is a disingenuous opinion. The level of militance involved in this propaganda push goes way beyond mere interest. Just look at people who actually enjoy Java, C++, Python, etc. These are the most popular languages that mankind ever developed,and countless people built very successful careers around them. Yet, you don't see even a fraction of the fanboys you see constantly pushing these experimental languages.
It is also worth to note that the Rust design, in its theory, and the recent bug in the Linux kernel Rust code (the message passing abstraction used by Android), makes clear that:
1. With Rust, you may lower the exposure, but the same classes of bug still remain. And of course, all the other non memory related bugs.
2. With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
3. With Rust, to decrease the "unsafe" sections amount, you need often to build abstractions that may be a bit unnatural.
4. Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment. Like in the Linux Kernel bug, where such comment was hallucinated by a human that sometimes (not sure in this specific case, it's just an example) may be less used to do the "race spotting" process that C learns you to do.
5. With Rust, in case of a bug, the fix could no longer be the one-liner usually you see in C fixes, and can make the exposure time window larger. Sometimes fixing things in Rust means refactoring in non trivial ways.
6. With C, if there was the same amount of effort in creating wrappers to make kernel programming safer at the cost of other things, the surface of attack could also be lowered in a significant way (see for instance Redis use of sds.c: how many direct strings / pointers manipulation we avoid? The same for other stuff of course). Basically things like sds.c let you put a big part of the unsafe business in a self contained library.
So, is Rust an interesting language for certain features it has? Yes. Is Rust a silver bullet? No. So should Rust be "pushed" to others, hell no, and I suggest you to reply in the most firm way to people stressing you out to adopt Rust at all the costs.
The recent bug in the Linux kernel Rust code, based on my understanding, was in unsafe code, and related to interop with C. So I wouldn't really classify it as a Rust bug. In fact, under normal circumstances (no interop), people rarely use unsafe in Rust, and the use is very isolated.
I think the idea of developers developing a "bugs antenna" is good in theory, though in practice the kernel, Redis, and many other projects suffer from these classes of bugs consistently. Additionally, that's why people use linters and code formatters even though developers can develop a sensitivity to coding conventions (in fact, these tools used to be unpopular in C-land). Trusting humans develop sensibility is just not enough.
Specifically, about the concurrency: Redis is (mostly) single-threaded, and I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong).
Can people write safer C (e.g. by using sds.c and the likes)? For sure! Though we've been writing C for 50+ years at this point, at some point "people can just do X" is no longer a valid argument. As while we could, in fact we don't.
I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there. Treating bugs in unsafe code as not being bugs in rust code is kind of silly, also.
Exactly. You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.
For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. The fact that the percentage is higher in the latter case doesn't change the fact that 95% of your codebase is just as safe as the Python project would be.
A big amount of C code does not do anything unsafe as well, it calls other stuff, do loops, logic business, and so forth. It is also wrong to believe 100% of the C code is basically unsafe.
If so, then it should be trivial for someone to introduce something like Rust's `unsafe` keyword in C such that the unsafe operations can be explicitly annotated and encapsulated.
Of course, it's not actually this trivial because what you're saying is incorrect. C is not equipped to enforce memory safety; even mundane C code is thoroughly suffused with operations that threaten to spiral off the rails into undefined behavior.
It is not so hard to introduce a "safe" keyword in C. I have a patched GCC that does it. The subset of the language which can be used safety is a bit too small to be full replacement on its own, but also not that small.
C lacks safe primitives or non-error-prone ways to build abstractions to refer to business objects. There are no safe string references, let along ways to safely manipulate strings. Want to iterate over or index into a result set? You can try to remember to put bounds checks into every API function.
But even with explicit bounds checks, C has an ace up its sleeve.
int cost_of_nth_item(int n) {
if (n < 0 || n >= num_items)
return -1; // error handling
…
}
Safe, right? Not so fast, because if the caller has a code path that forgets to initialize the argument, it’s UB.
You're swapping definitions of unsafe. Earlier you were referring to the `unsafe` keyword. Now you're using `unsafe` to refer to a property of code. This makes it easy to say things like "It is also wrong to believe 100% of the C code is basically unsafe" but you're just swapping definitions partway through the conversation.
What I see is that antirez claims that absence of "safe" (as syntax) in C lang doesn't automatically mean that all of C code is unsafe (as property). There's no swapping of definitions as I see it.
I think there's a very clear switch of usage happening. Maybe it's hard to see so I'll try to point out exactly where it happens and how you can spot it.
First from antirez:
> You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.
Use of the term `unsafe` here referring to the keyword / "blocks" of code. Note that this statement would be nonsensical if talking about `unsafe` as a property of code, certainly it would be inconsistent with the later unsafe since later it's claimed that C code is not inherently "unsafe" (therefor Rust would not be inherently "unsafe").
Kibwen staying on that definition here:
> For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code.
Here is the switch:
> A big amount of C code does not do anything unsafe as well
Complete shift to "unsafe" as being a property of code, no longer talking about the keyword or about blocks of code. You can spot it by just rewriting the sentences to use Rust instead of C.
You can say:
"A big amount of 'unsafe' Rust code does not do anything unsafe as well"
"It is also wrong to believe 100% of the unsafe Rust code is basically unsafe."
I think that makes this conflation of terms clear, because we're now talking about the properties of the code within an "unsafe" block or globally in C. Note how clear it is in these sentences that the term `unsafe` is being swapped, we can see this by referring to "rust in unsafe blocks" explicitly.
This is just a change of definitions partway through the conversation.
p.s. @Dang can you remove my rate limit? It's been years, I'm a good boy now :)
High performance is not an on/off target. Safe rust really lets you express a lot of software patterns in a "zero-cost" way. Sure, there are a few patterns where you may need to touch unsafe, but safe rust itself is not slow by any means.
For your last sentence, I believe topics are conflated here.
Of course if one writes unsafe Rust and it leads to a CVE then that's on them. Who's denying that?
On the other hand, having to interact with the part of the landscape that's written in C mandates the use of the `unsafe` keyword and not everyone is ideally equipped to be careful.
I view the existence of `unsafe` as pragmatism; Rust never would have taken off without it. And if 5% of all Rust code is potentially unsafe, well, that's still much better than C where you can trivially introduce undefined behavior with many built-in constructs.
Obviously we can't fix everything in one fell swoop.
>>Of course if one writes unsafe Rust and it leads to a CVE then that's on them. >>Who's denying that?
>>The recent bug in the Linux kernel Rust code, based on my understanding, was >>in unsafe code, and related to interop with C. So I wouldn't really classify >>it as a Rust bug.
The bug in question is in rust glue code that interfaces with a C library. It's not in the rust-C interface or on the C side. If you write python glue code that interfaces with numpy and there's a bug in your glue, it's a python bug not a numpy bug.
I already agreed that technically it is indeed a bug in the Rust code. I would just contest that such a bug is representative is all. People in this thread seem way too eager to extrapolate which is not intellectually curious or fair.
Why is glue code not normal code in Rust? I don't think anyone else would say that for any other language out there. Does it physically pain you to admit it's a bug in Rust code? I write bugs in all kind of languages and never feel the need for adjectives like "technical", "normal", "everyday" or words like "outlier" to make me feel not let down by the language of choice.
I have worked with Rust for ~3.5 years. I had to use the `unsafe` keyword, twice. In that context it's definitely not everyday code. Hence it's difficult to use that to gauge the language and the ecosystem.
Of course it's a bug in Rust code. It's just not a bug that you would have to protect against often in most workplaces. I probably would have allowed that bug easily because it's not something I stumble upon more than once a year, if even that.
To that effect, I don't believe it's fair to gauge the ecosystem by such statistical outliers. I make no excuses for the people who allowed the bug. This thread is a very good demonstration as to why: everything Rust-related is super closely scrutinized and immediately blown out of proportion.
As for the rest of your emotionally-loaded language -- get civil, please.
I don't care if there can be a bug in Rust code. It doesn't diminish the language for me. I don't appreciate mental gymnastics when evidence is readily available and your comments come out as compulsive defense of something nobody was really is attacking. I'm sorry for the jest in the comments.
I did latch onto semantics for a little time, that much is true, but you are making it look much worse than it is. And yes I get a PTSD and an eye-roll-syndrome from the constant close scrutiny of Rust even though I don't actively work with it for a while now. It gets tiring to read and many interpretations are dramatically negative for no reason than some imagined "Rust zealots always defending it" which I have not seen in a long time here on HN.
But you and me seem to be much closer in opinion and a stance than I thought. Thanks for clarifying that.
In Rust you can avoid "unsafe" when you use Rust like it was Go or Python.
If you write low level code, that is where C is in theory replaceable only by Rust (and not by Go), then you find yourself in need of writing many unsafe sections. And to lower the amount of unsafe sections, you have to build unnatural abstractions, often, in order to group such unsafe sections into common patterns. Is is a tradeoff, not a silver bullet.
Not necessarily at all. Go peruse the `regex` crate source code, including its dependencies.
The biggest `unsafe` sections are probably for SIMD accelerated search. There's no "unnatural abstractions" there. Just a memmem-like interface.
There's some `unsafe` for eliding bounds checks in the main DFA search loops. No unnatural abstractions there either.
There's also some `unsafe` for some synchronization primitives for managing mutable scratch space to use during a search. A C library (e.g., PCRE2) makes the caller handle this. The `regex` crate does it for you. But not for unnatural reasons. To make using regexes simpler. There are lower level APIs that provide the control of C if you need it.
That's pretty much it. All told, this is a teeny tiny fraction of the code in the `regex` crate (and all of its dependencies).
I think this framing is a bit backwards. Many C programs (and many parts of C programs) would benefit from being more like Go or Python as evident by your very own sds.c.
Now, if what you're saying is that with super highly optimized sections of a codebase, or extremely specific circumstances (some kernel drivers) you'd need a bit of unsafe rust: then sure. Though all of a sudden you flipped the script, and the unsafe becomes the exception, not the rule; and you can keep those pieces of code contained. Similarly to how C programmers use inline assembly in some scenarios.
Funny enough, this is similar to something that Rust did the opposite of C, and is much better for it: immutable by default (let mut vs. const in C) and non-nullable by default (and even being able to define something as non-null).
Flipping the script so that GOOD is default and BAD is rare was a huge win.
I definitely don't think Rust is a silver bullet, though I'd definitely say it's at least a silver alloy bullet. At least when it comes to the above topics.
In my experience (several years of writing high performance rust code), there’s only really 2 instances where you need unsafe blocks:
- C interop
- Low level machine code (eg inline assembly)
Most programs don’t need to do either of those things. I think you could directly port redis to entirely safe rust, and it would be just as fast. (Though there will need be unsafe code somewhere to wrap epoll).
And even when you need a bit of unsafe, it’s usually a tiny minority of any given program.
I used to think you needed unsafe for custom container types, but now I write custom container types in purely safe rust on top of Vec. The code is simpler, and easier to debug. And I’m shocked to find performance has mostly improved as a result.
> was in unsafe code, and related to interop with C
1) "interop with C" is part of the fundamental requirements specification for any code running in the Linux kernel. If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job.
2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code. This is a fundamental limitation, and again is an issue when the fundamental requirement for the task is to interface to data structures implemented as doubly-linked lists.
No matter how good a language is, if it doesn't have support for floating point types, it's not a good language for implementing math libraries. For most applications, the inability to safely express doubly-linked lists and difficulty in interfacing with C aren't fundamental problems - just don't use doubly-linked lists or interface with C code. (well, you still have to call system libraries, but these are slow-moving APIs that can be wrapped by Rust experts) For this particular example, however, C interop and doubly-linked lists are fundamental parts of the problem to be solved by the code.
If Rust is no less safe than C in such a regard, then what benefit is Rust providing that C could not? I am genuinely curious because OS development is not my forte. I assume the justification to implement Rust must be contingent on more than Rust just being 'newer = better', right?
The issue is unrelated to expressing linked lists, it's related to race conditions in the kernel, which is one of the hardest areas to get right.
This could have happened with no linked lists whatsoever. Kernel locks are notoriously difficult, even for Linus and other extremely experienced kernel devs.
I love rust, but C does make it a lot easier to make certain kinds of container types. Eg, intrusive lists are trivial in C but very awkward in rust. Even if you use unsafe, rust’s noalias requirement can make a lot of code much harder to implement correctly. I’ve concluded for myself (after a writing a lot of code and a lot of soul searching) that the best way to implement certain data structures is quite different in rust from how you would do the same thing in C. I don’t think this is a bad thing - they’re different languages. Of course the best way to solve a problem in languages X and Y are different.
And safe abstractions mean this stuff usually only matters if you’re implementing new, complex collection types. Like an ECS, b-tree, or Fenwick tree. Most code can just use the standard collection types. (Vec, HashMap, etc). And then you don’t have to think about any of this.
>> I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong).
You wrote that question in a browser mostly written in C++ language, running on an OS most likely written in C language.
OS can be actually pretty simple to make. Sometimes it's a part of a CS curriculum to make one. If it were so much easier to do it in other languages (e.g. in Rust), don't you think we would already be using them?
Writing a real one? Who's gonna write all the drivers and the myriad other things?
And the claim was not that it's "so much easier", but that it is so much easier to write it in a secure way. Which claim is true. But it's still a complex and hard program.
(And don't even get started on browsers, it's no accident that even Microsoft dropped maintaining their own browser).
The toy one can still be as highly concurrent as the the real one. The amount of drivers written for it doesn't matter.
The point is if it were much easier, then they would overtake existing ones easily, just by adding features and iterating so much faster and that is clearly not the case.
>>difficulty of building safe, fast and highly-concurrent C
This was the original claim. The answer is, there is a tonne of C code out there that is safe, fast and concurrent. Isn't it logical? We have been using C for the last 50 years to build stuff with it and there is a lot of it. There doesn't seem to be a big jump in productivity with the newer generation of low level languages, even though they have many improvements over C.
This is anecdotal, I used to do a lot of low level C and C++ development. And C++ is a much bigger language then C. And honestly I don't think I was ever more productive with it. Maybe the code looked more organized and extendable, but it took the same or larger amount of time to write it. On the other hand when I develop with Javascript or C#, I'm easily 10 times more productive then I would be with either C or C++. This is a bit of apples and oranges comparison, but what I'm trying to say is that new low level languages don't bring huge gains in productivity.
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
I suppose it's possible. I wonder if I'll become a better driver if I take off my seatbelt. Or even better, if I take my son out of my car seat and just let him roam free in the back seat. I'm sure my wife will buy this.
Human behaviour can be a confounding thing. There was some debate a while ago [1] about whether bike helmet use may actually lead more head injuries due to factors like drivers passing closer to helmeted riders vs. unhelmeted ones or riders riding more recklessly, among a tonne of other factors. I still prefer to wear a helmet, but its an interesting example of how difficult it can be to engineer human behaviour.
Another good example of this is how civil engineers adding safety factors into design of roads - lane widths, straighter curves, and so on - leading drivers to speed more and decreasing road safety overall.
FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.
But in this specific case, if the respawn feature is not available or dying isn't a desirable event, FAFO might not be the best way to learn how to drive.
I also think we have the data in for memory safety in C. Even the best people, with the best processes in the world seem to keep writing memory safety bugs. The “just be more vigilant” plan doesn’t seem to work.
> FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.
Yes, just sucks for the person who you hit with your car, or the person whose laptop gets owned because of your code.
"FAFO" is not a great method of learning when the cost is externalized.
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
I think there are effects in both directions here. In C you get burned, and the pain is memorable. In Rust you get forced into safe patterns immediately. I could believe that someone who has done only Rust might be missing that "healthy paranoia". But for teaching in general, it's hard to beat frequent and immediate feedback. Anecdotally it's common for experienced C programmers to learn about some of the rules only late in their careers, maybe because they didn't happen to get burned by a particular rule earlier.
> Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment.
This is an interesting contrast to the previous case. If you write a lot of unsafe Rust, you will eventually get burned. If you're lucky, it'll be a Miri failure. I think this makes folks who work with unsafe Rust extremely paranoid. It's also easier to sustain an that level of paranoia with Rust, because you hopefully only have to consider small bits of unsafe code in isolation, and not thousands of lines of application logic manipulating raw pointers or whatever.
The amount of paranoia I need for unsafe Rust is orders of magnitudes higher than C. Keeping track of the many things that can implicity drop values and/or free memory, and figuring out if im handling raw pointers and reference conversions in a way that doesn't accidentally alias is painful. The C rules are fewer and simpler, and are also well known, and are aleviated and documented by guidelines like MISRA. Unsafe Rust has more rules, which seem underspecified and underdocumented, and also unstable. Known unknowns are preferable over unknown unknowns.
A quick unscientific count on cve.org counts ~86 race condition CVEs in the Linux kernel last year, so you might be overstating how well bug antennas work.
If the kernel was completely written in Rust, we could have a lot of unsafe places, and many Rust CVEs. It is hard to tell, and the comparison in theory should be made after the kernel is developed only by people lacking the C experience that made the current developers so able to reason about race conditions (also when they write Rust).
That's quite the double standard. You extrapolate from one single Rust bug, but insist that "it's hard to tell" and you need completely unrealistic levels of empirical evidence to draw conclusions from the reported C bugs...
Yeah I mean I could also say "there are no CVEs written in PERL in the kernel ergo PERL is safer to write than Rust". Given there's close to zero .pl files in the kernel, I think we can all agree my assertion holds
That claim relies on an absurd "in the kernel" qualifier, making it difficult to agree with. Furthermore, your hypothesis is that "we all" agree with claims that rely on absurd conditions as a matter of course.
(2) and (3) just don't seem to be the case empirically. One bug that was directly in a grep'able `unsafe` block is hardly evidence of these, whereas Google's study on Rust has demonstrated (far more rigorously imo) the opposite. I think anyone paying attention would have guessed that the first Rust CVE would be a race - it is notoriously hard to get locking/ race semantics correct in the kernel, not even the C programmers get it right, it's an extremely common bug class and I believe Linus has basically said something along the lines of "no one understands it" (paraphrasing).
(4) Again, this doesn't seem to be borne out empirically.
(5) I've seen plenty of patches to C code that are way more than a single line for the Linux kernel, but sure, maybe we grant that a bug fix in Rust requires more LOC changed? It'd be nice to see evidence. Is the concern here that this will delay patching? That seems unlikely.
It's not uncommon at all for patches to the C code in the kernel for "make this generally safe" are 1000s of lines of code, seeding things like a "length" value through code, and take years to complete. I don't think it's fair to compare these sorts of "make the abstraction safe" vs "add a single line check" fixes.
(6) Also not borne out. Literally billions spent on this.
> So, is Rust an interesting language for certain features it has? Yes. Is Rust a silver bullet? No.
Agreed. I'm tempted to say that virtually no one contests the latter lol
> So should Rust be "pushed" to others, hell no, and I suggest you to reply in the most firm way to people stressing you out to adopt Rust at all the costs.
I guess? You can write whatever you want however you want, but users who are convinced that Rust code will provide a better product will ask for it, and you can provide your reasoning (as SQLite does here, very well imo) as firm as you'd please I think.
> made the current developers so able to reason about race conditions (also when they write Rust).
Aha. What? Where'd you get this from? Definitely not from Linus, who has repeatedly stated that lock issues are extremely hard to detect ahead of time.
> we’ve tweaked all the in-kernel locking over decades [..] and even people who know what they are doing tend to get it wrong several times
Google have published a couple high-level Rust blog posts with many graphs and claims, but no raw data or proofs, so they haven’t demonstrated anything.
By now their claims keep popping up in Rust discussion threads without any critical evaluation, so this whole communication is better understood as a marketing effort and not a technical analysis.
> Google have published a couple high-level Rust blog posts with many graphs and claims, but no raw data or proofs, so they haven’t demonstrated anything.
Don't expect proofs from empirical data. What we have is evidence. Google has published far better evidence, in my view, than "we have this one CVE, here are a bunch of extrapolations".
> By now their claims keep popping up in Rust discussion threads without any critical evaluation,
Irrelevant to me unless you're claiming that I haven't critically evaluated the information for some reason.
Is there still pressure to use OOP? On Hacker News, at least, the trend seems to be moving in the opposite direction. There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns.
That’s not to say OOP advocacy has disappeared from HN. It still exists, but it no longer feels dominant or ascendant. If anything, it feels like a legacy viewpoint maintained by a sizable but aging contingent rather than a direction the community is moving toward.
Part of OOP’s staying power comes from what I’d call a cathartic trap. Procedural programming is intuitive and straightforward. OOP, by contrast, offers a new conceptual lens: objects, inheritance, polymorphism, and eventually design patterns. When someone internalizes this framework, there’s often a strong moment of “clicking” where complex software suddenly feels explainable and structured. That feeling of insight can be intoxicating. Design patterns, in particular, amplify this effect by making complexity feel principled and universally applicable.
But this catharsis is easy to confuse with effectiveness. The emotional satisfaction of understanding a system is orthogonal to whether that system actually produces better outcomes. I’ve seen a similar dynamic in religion, where the Bible’s dense symbolism and internal coherence produce a powerful sense of revelation once everything seems to “fit” together. The feeling is real, but it doesn’t validate the underlying model.
In practice, OOP often increases complexity and reduces modularity. This isn’t always obvious from inside the paradigm. It tends to become clear only after working seriously in other paradigms, where composition, data-oriented design, or functional approaches make the tradeoffs impossible to ignore.
In my circles, there is one part of OOP seen as positive: encapsulation. Everything else, specially inheritance and partly polymorphism are seen extremely negatively. The hype is over. BUT: I still hear more often as I would like, some manager stating “of course we will use C++, because is THE OOP language, and everybody knows OOP and UML are the only right way of doing software” this is an actual verbatim statement I had to listen 4 years ago.
I mostly agree with your assessment of how OOP is viewed today. In many technical circles, inheritance is seen as actively harmful, and polymorphism is at best tolerated and often misunderstood. The hype is largely gone. I’ve also heard the same managerial rhetoric you mention, where OOP and UML are treated as unquestionable defaults rather than design choices, so that part unfortunately still resonates.
Where I disagree is on encapsulation being the “good” part of OOP.
Encapsulation, as a general idea, is positive. Controlling boundaries, hiding representation, and enforcing invariants are all valuable. But encapsulation as realized through objects is where the deeper problem lies. Objects themselves are not modular, and the act of encapsulating a concept into an object breaks modularity at the moment the boundary is drawn.
When you encapsulate something in OOP, you permanently bind state and the methods that mutate that state into a single unit. That decision fixes the system’s decomposition early and hardens it. Behavior can no longer move independently of data. Any method that mutates state is forever tied to that object, its invariants, and its lifecycle. Reuse and recomposition now operate at the object level rather than the behavior level, which is a much coarser and more rigid unit of change.
This is the core issue. Encapsulation in OOP doesn’t just hide implementation details; it collapses multiple axes of change into one. Data representation, behavior, and control flow are fused together. As requirements evolve, those axes almost never evolve in lockstep, but the object boundary forces them to.
What makes this especially insidious is that the failure mode is slow and subtle. OOP systems don’t usually fail immediately. They degrade over time. As new requirements arrive, developers feel increasing resistance when trying to adapt the existing design. Changes start cutting across object boundaries. Workarounds appear. Indirection layers accumulate. Eventually the system is labeled as having “too much tech debt” or being the result of “poor early design decisions.”
But this framing misses the point. The design mistakes were not merely human error; they were largely inevitable given the abstraction. The original object model could not have anticipated future requirements, and because it was not modular enough to allow the design itself to evolve, every change compounded rigidity. The problem wasn’t that the design was wrong. It’s that it was forced to be fixed.
Polymorphism doesn’t fundamentally resolve this, and often reinforces it. While polymorphism itself is not inherently object-oriented, in OOP it is typically expressed through stateful objects and virtual dispatch. That keeps behavior anchored to object identity and mutation rather than allowing it to be recomposed freely as requirements shift.
The deeper requirement is that a system must be modular enough not just to extend behavior, but to change its own design as understanding improves. Object-based encapsulation works directly against this. It locks in assumptions early and makes architectural change progressively more expensive. By the time the limitations are obvious, the system is already entangled.
So while I agree that inheritance deserves much of the criticism, I think encapsulation via objects is the more fundamental problem. It’s not that encapsulation is bad in principle. It’s that object-based encapsulation produces systems that appear well-structured early on, but inevitably accumulate rigidity and hidden coupling over time. What people often call “tech debt” in OOP systems is frequently just the unavoidable artifact of an abstraction that was never modular enough to begin with. OOP was the tech debt.
The way forward is actually simple. Avoid mutation as much as possible. Use static methods (aka functions) as much as possible. Segregate IO and mutation into its own module separate from all other logic. Those rules are less of a cathartic paradigm shift then OOP and it takes another leap to see why doing these actually resolves most of the issues with OOP.
> Where I disagree is on encapsulation being the “good” part of OOP.
Encapsulation, as a general idea, is positive. Controlling boundaries, hiding representation, and enforcing invariants are all valuable. But encapsulation as realized through objects is where the deeper problem lies. Objects themselves are not modular, and the act of encapsulating a concept into an object breaks modularity at the moment the boundary is drawn.
I’m personally with you here. Just in my circle they see it positively. But I agree with you: as long as it helps modularity, great, but also have many downsides that you describe very well.
Your last paragraph also perfectly aligned with my views. I think you are coming from a functional PoV, which luckily seems to have some more traction in the last decade or two. Sadly, before you say it, often are underline the parts of functional programming that are not the most useful you address here… but maybe, some day…
> There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns.
I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (types) and/or objects (instances) and bunch of methods specific to the class/object. In Rust, you extend that concept to almost all types including structs and enums.
> OOP, by contrast, offers a new conceptual lens: objects, inheritance, polymorphism, and eventually design patterns.
Rust doesn't have inheritance in the traditional sense, but most OOP languages prefer composition to data inheritance. Meanwhile, polymorphism, dynamic dispatch and design patterns all exist in Rust.
> I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (types) and/or objects (instances) and bunch of methods specific to the class/object. In Rust, you extend that concept to almost all types including structs and enums.
That’s not oop. Traits and generics are orthogonal to oop. It’s because oop is likely where you learned these concepts so you think the inception of these things is derived from oop.
What’s unique to oop is inheritance and encapsulation.
Design patterns isn’t unique to OOP either but there’s a strong cultural association with it. The term often involves strictly using encapsulated objects as the fundamental building block for each “pattern”.
The origin of the term “design patterns” was in fact established in context of OOP through the famous book and is often used exclusively to refer to OOP but the definition of the term itself is more broad.
It should not be strange that a tool which is better in every way and makes your code less buggy by default has its praises sung by most of the people who use it. It would be odd to go around saying 'electric drills are strangely and disproportionately pushed at Home Depot over the good old hand auger', and even if I don't work at your contracting company I'd be slightly unnerved about you working on my house.
The issue is that Rust proponents automatically assume that if you write enough C code, there will be memory related bugs.
In reality, this is not the case. Bad code is the result of bad developers. Id rather have someone writing C code that understands how memory bugs happen rather than a Rust developer thinking that the compiler is going to take care of everything for them.
I’ve heard this analogy used to justify firing developers for not using GenAI: a cabinet maker who doesn’t use power tools shouldn’t be working as a cabinet maker.
If only programming languages (or GenAI) were tools like hammers and augers and drills.
Even then the cabinets you see that come out of shops that only use hand tools are some of the most sturdy, beautiful, and long lasting pieces that become the antiques. They use fewer cuts, less glue, avoid using nails and screws where a proper joint will do, etc.
Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so. Antiques suck as often as they don't, and moreover you are only seeing the ones that survived without a base rate to compare it to; they succeeded in spite of power tools, but power tools would have made the same object better.
Comparing it to AI makes no sense. Invoking it is supposed to bring to mind the fact that it's worse in well-known ways, but then the statement 'better in every way' no longer applies. Using Rust passively improves the engineering quality compared to using anything else, unlike AI which sacrifices engineering quality for iteration speed.
> Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so.
No disrespect intended, but your criticism of the analogy reveals that you are speaking from assumptions, but not knowledge, about furniture construction.
In fact, less glue, and fewer fasteners (i.e. design that leverages the strength of the materials), is exactly how quality furniture is made more sturdy.
There was an interesting video on YT where an engineer from a fastener company joined a carpenter to compare their products with traditional joints.
The traditional joints held up very well and even beat the engineered connectors in some cases. Additionally one must be careful with screws and fasteners: if they’re not used according to spec, they may be significantly weaker than expected. The presented screws had to be driven in diagonally from multiple positions to reach the specified strength; driving them straight in, as the average DIYer would, would have resulted in a weak joint.
Glue is typically used in traditional joinery, so less glue would actually have a negative effect.
> Glue is typically used in traditional joinery, so less glue would actually have a negative effect.
And a lot of traditional joinery is about keeping the carcase sufficiently together even after the hide glue completely breaks down so that it can be repaired.
Modern glues allow you to use a lot less complicated joinery.
The topic seems to be native programming languages -- I don't think any of the languages concerned are "better in every way" for every possible coding problem. Many will rightfully choose Fortran over Rust for their application -- knowing full well their choice is far away from "better in every way".
When writing code meant to last, you need a language that’s portable across compilers and through time. C has demonstrated both. Fortran 77 and 90 were portable across compilers, but are now at risk from breaking changes, and later versions are not very portable across compilers.
If the alternative has drawbacks (they always do) or is not as well known by the team, it's perfecly fine to keep using the tool you know if it is working for you.
People who incessantly try to evangelise their tool/belief/preferences to others are often seen as unpleasant to say the least and they often achieve the opposite effect of what they seek.
Given the author's misunderstanding of what Rust provides, the most charitable interpretation is that they haven't updated the parts discussing Rust since 2017. If they had, it would reflect more poorly on them.
The most charitable interpretation of this is that the Reddit mods should stick to Reddit. If they had, this wouldn't have reflected so poorly on them.
Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages.
The US government recently called on everyone to stop using them and move to memory-safe languages.
Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those.
Edit: Typos and to make the point that I'm not necessarily defending C, just acknowledging it's place. I haven't written a significant amount of C in over 2 decades, probably, aside from microcontroller C.
C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong.
C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its uses but it will fuck you up if you do not use industrial-grade PPE.
Stop using C if you can. Stop arguing other people should use it. There have always been alternatives and the opportunity cost of ecosystems continuing to invest in C has massive externalized costs for the entire industry and society as a whole.
> When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.
And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language.
If it was as bad as you make out, we'd have many many many occurrences of this starting in the 80s. We don't.
But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows.
For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equally viable choices. And if we are talking about something that needs to be outright safety-critical, Ada and SPARK should definitely be in the debate.
However, all of that doesn't override the right of projects to decide on what language they believe is best for them or what strategies concerning safety that they wish to pursue.
Pushed != interested in/talked about. People really like to mash together a bunch of random individuals into a single actor/agenda.
Golang is not playing in the same niche as C/C++/Rust/Zig, but we have had countless memory safe languages that are indeed a good fit for many uses where C was previously used.
> In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an Reversec Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors.
> The US government recently called on everyone to stop using them and move to memory-safe languages.
The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al.
Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop.
Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that.
Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.
True, but it required congressional approval to change the name then, and it would now as well.
This congress is not likely to approve it. And the next congress, even less so.
That said, "ever" is probably too strong. There's a window wherein the chaos which is currently being actively created by the US will develop to an extent that compels the US (or is sold to US voters as a necessary step) to adopt a foreign policy where it would be the more appropriate title. And if the adults can't manage that with charismatic leadership in the next election cycle or two, we could be right back here again, with quasi-legitimate geopolitical justification for the sort of big-stick wagging we see today.
I honestly think this is the goal, and I'm not sure the American people are up to the challenge of preventing it.
> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process.
DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.
Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.
> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.
Clearly C “can meet” and “has met” DO-178. So, I posit that more languages than C “can meet” this standard.
Proving it is the very hard, very expensive part.
Oh, and whatever version of the rust compiler that gets certified will be locked down as the only certified toolchain. No more compiler updates every 6 weeks. Unless you go though the whole process again.
I mostly agree, but the OOP is most definitely not in vogue on HN for the past decade at least, arguably far longer than that (think Rust pre-1.0, Go 1.0 times).
There's some muddiness in the terminology here -- OOP is really a design style, and "OOP languages" are generally imperative languages that have sematics that encourage OOP design. It is very possible, even encouraged, to represent state as "Objects" in many functional languages; it's just not really enforced by the language itself.
A good example of this are the object systems in Scheme and Common Lisp (which are less strictly Functional (note the capital F in that word) then something like Haskell).
I asked mainly because of the terminology. I read the primer of how to code OOP in plain C about a decade ago, so I knew that the paradigm definitely can be applied to “non OOP languages”, but I wasn’t sure whether the term “functional programming” allows this or not for some obscure academic reasons. How I coded when I encountered Haskell the first time, I would say it’s definitely possible, but I think, there are some features in Haskell which can be used to break pure functional programming, and if those are not considered FP, then who knows. But I used Haskell the last time a few years ago, so my memory is definitely not clear.
Gilad Bracha talks about how they're not mutually exclusive concepts, and I mostly agree (OOP can have tailcall recursion and first order functions for example). But, the philosophy seems very different: functional programming is "standing above" the data, where you have visibility at all times, and do transformations on the data. OOP is much more about encapsulation, where you "send a message" to an object, and it does its own thing. So you could totally write OOP code where you provide some core data structures that you run operations on, but in practice encapsulation encourages hiding internal data.
Though on further thought, may be this isn't FP vs OOP, because C has a similar approach of "standing above", and C is the hallmark imperative language.
Scala has been that for decades. They are not opposing paradigms. (In fact, mutability has a few edge cases that doesn't play nicely with OOP to begin with)
I mean Scala kind of does both (and then some). I'm not sure I would call it an OOP language, but you can sure write the same gross Java enterprise bloatware in Scala too if you want.
> Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig)
You won't find easily Zig programmers that want you to use Zig at all costs, or that believe it's a moral imperative that you do. It's just antithetical to the whole concept of Zig.
The worst that can happen is that Zig programmers want C projects to have a build.zig so they can cross-compile the project trivially, since that's usually not a thing C/C++ build scripts tend to offer. And even then, we have https://github.com/allyourcodebase/ so that Zig users can get their build.zig scripts without annoying project maintainers.
Not always, but sometimes, new things are just better.
One example is null-- a billion dollar mistake as Tony Hoare called it. A Maybe type with exhaustive pattern matching is so dramatically better, it can be worth switching just for that feature alone.
Funny how managers get blamed for both wanting new things and for not wanting new things. In the Java 6 days every dev wanted to upgrade to 7 and later 8… but the meme was that their manager wouldn’t ever let them.
Every serious project should be able to justify its choice of tools. "Because I feel like it" is fine for hobby projects or open-source passion projects, but production-worthy software should have reasoning behind its choices. That reasoning can be something like "it's most effective for us because we know it better" but it should be a deliberate, measured choice.
SQLite is an example of an extremely high quality software project. That encompasses not only the quality of the software itself, but the project management around it. That includes explaining various design choices, and this document explaining the choice of language is just one of many such explanations.
Yeah, results are what matters. SQLite's process seems to produce solid bug-free results.
My only complaint would be that there's many SQL features I want to use which aren't supported. Surely some part of that is deliberately restricted scope, but some might also be dev velocity issues.
DuckDB (C++) can be used like an SQLite with more SQL features, but it's also a lot buggier. Segfaults from your database are not what you want.
So still hoping for some alternative to come along (or maybe I'll need to write it myself)
The ones that come to mind immediately are more ALTER statements (especially adding non-virtual columns), DATE, TIME, and TIMESTAMP types and their associated functions, and ARRAY types. Although I don't wish to disparage SQLite, they do support a lot of features. Just that I constantly run into the ones they don't, with my use cases.
And beyond standard SQL, stuff like hashmap/bloom filter/vector indices, nearest neighbor search, etc...
OOP was always debatable, but with the rise of AI agents I'd go so far as to say it's objectively bad now. AI is much better at reasoning about pure function grammars than imperative classes with inheritance; abstractions that aren't airtight are bug factories.
I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old that is already so well tested and accessible on all sorts of obscure platforms, it makes little sense to rewrite, and the likely result would be more bugs, not less, at least in the short term.
Limbo and Turso's other tools seem interesting, but the listed limitation of “no multi process database access” is pretty huge.
If you don’t need that, then great—Turso/Limbo might be for you! But there are a ton of use cases out there that rely on SQLite for simultaneous multiprocess access. And I’m not even talking about things that use it from forking servers or for coordination (though those are surprisingly common as well)—instead, lots of processes that use SQLite 99.9% of the time from one process still need it to be multiprocess-authoritative for e.g. data exports, “can I open two copies of an app far enough to get a ‘one is already running’ error?”-type use cases, extensions/plugins, maintenance scripts, etc. not having to worry about cross-process lock files thanks to SQLite is a significant benefit for those.
This seems like the way. Why would Rustaceans bother to "argue their case" before an unwilling board if they can just do the rewrite themselves? Maybe it will succeed, maybe not, but you don't need SQLLite's blessing to test the proposition.
My hunch is that those aren't very serious Rustaceans. Even the original language developers developed Rust to interoperate with C as much as possible, and they often used to discourage the rewrite evangelism. If you are a serious Rustacean, you'd probably be worried about the safety tradeoffs in rewriting in Rust. As your parent commenter points out, a mature C codebase is already tested so well that rewriting it in Rust is likely to introduce more bugs - non-memory-safety bugs that are nevertheless serious enough. That's why I and many other Rustaceans don't recommend it. In fact, some Rustaceans even advise others to not rewrite Fortran 90 code (in order to preserve the performance advantage) and instead recommend integrating it with Rust using FFI.
Oh, SQLite (as a database) is easy compared to a client-server database, or an "embedded" database that runs in a separate process.
The issue is more of the object-relational impedance mismatch that happens when using any SQL database: ORMs can be slow / bloated, and hand-written SQL is time consuming.
I shipped a product on SQLite, and SQLite certainly lived up to its promise. What would have been more helpful was if it could index structured objects instead of rows, and serialize / deserialize the whole object. People are doing this now by putting JSON into SQLite. (Our competitors did it when I looked into their SQLite database.)
I could see it being useful for pure Rust projects once its completed. I mean in Java / Kotlin land, I prefer to use H2 in some cases over SQLite since its native to the platform and H2 is kind of nice altogether. I could see myself only using this in Rust in place of SQLite if its easy to integrate and use on the fly.
The equivalent "platform native" database for Clojure is Datalevin [0], which has a Datomic-like Datalog query language with SQLite-style semantics. Recommended.
The final comments in this text seem sobering and indicate an openness to change. I worked recently on a project to migrate RediSearch to Rust, and this was partially motivated by a decent number of recent CVEs. If SQLite doesn't have this problem, then there needs to be some other strong argument for moving to Rust.
I also think it's important to have really solid understandings (which can take a few decades I imagine) to understand the bounds of what Rust is good at. For example, I personally think it's unclear how good Rust can be for GUI applications.
It's nice that they don't dismiss out-of-hand the idea of using a language other than C (the conclusion is far less dogmatic than the editorialized title here suggests (the actual title of the page being "Why Is SQLite Coded In C?")). But let's be clear that the stability and "boringness" that C currently enjoys took literal decades to realize (pre-ANSI C was a wild-west shitshow that makes pre-ECMA Javascript look tame by comparison), and giving the same leeway to other languages probably doesn't suggest using e.g. Rust until at least 2040 or so.
None of Rust's language features allocate; not arrays, not closures, not iterators. Everything is stack-allocated by default. Rust code doesn't malloc unless you use a library that calls malloc; in other words, exactly like C. Rust fully supports turning off the parts of the standard library that perform allocation, and this is precisely what embedded code and the Linux kernel does. So Rust already gives you full control.
Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking for allocation errors, as well as several nightly functions coming down the pipe in the same vein (e.g. Vec::try_with_capacity, Vec::push_within_capacity).
Talking as a long time C++ programmer. I really don't get this mind set.
First off allocation failure (typically indicated by bad_alloc exception in C++ code, or nullptr in C style code) does not mean that the system (or even the process) as a whole is out of memory.
It just means that this particular allocator could not satisfy the allocation request. The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations.
Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure?
A normal structure for a program is to catch these exceptions at a higher level in the stack close to some logical entry point, such as thread entry point, UI action handler etc. where they can be understood and possibly shown to the user or logged or whatever. It shouldn't really matter if the failure is about failing to allocate socket or failing to allocate memory.
You could make the case that if the system is out of memory the exception propagation itself is going to fail. Maybe..but IMHO on the code path that is taken when stack is unwound due to exception you should only release resources not allocate more anyway.
In rust you could use multiple allocators at the same time. Allocation failure handled by allocator, converting panic to some useful behavior. This logic is observable in WASM, as there are OOMs all the time, which handled transparently to application code
So I assume there is no real blockers as people in this tread assume, this is just not a conventional behavior, ad hoc, so we need to wait and well defined stable OOM handlers will appear
>does not mean that the system is out of memory.
>"The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations."
Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean.
>Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure.
Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development.
"Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean."
As I just explained an allocator can have its own limits.
A process can have multiple allocators. There's no direct logical step that says that because some allocator some failed some allocation, the process itself cannot allocate more ever.
"Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development."
The parent comment is talking about over commitment and OOM as if these are situations that are completely out of the programs control. They aren't.
No. A single process can have several allocators, switch between them, or use temporary low limits to enforce some kind of safety. None of that has any relation to your system running out of memory.
You won't see any of that in a desktop or a server. In fact, I haven't seen people even discuss that in decades. But it exists, and there are real reasons to use it.
I am not well-versed in this area but have a doubt - when the OS sends a SIGKILL to a process because it has run of memory for it how can the program catch that before it is killed and deal with it "gracefully"? Does C provide any mechanism to deal with such scenario?
In your C++ (or C) program you have one (or more) allocators. These are just pieces of code that juggle blocks of memory into smaller chunks for the program to use. Typically the allocators get their memory from the OS in pages using some OS system call such as sbrk or mmap.
For the sake of argument, let's say I write an allocator that has a limit of 2MiB, while my system has 64Gib or RAM. The allocator can then fail some request when it's internal 2MiB has been exhausted. In C world it'd return a nullptr. In C++ world it would normally throw bad_alloc.
If this happens does this mean the process is out of memory? Or the system is out of memory? No, it doesn't.
That being said where things get murky is because there are allocators that in the absence of limits will just map more and more pages from the OS. The OS can "overcommit" which is to say it gives out more pages than can actually fit into the available physical memory (after taking into account what the OS itself uses etc). And when the overall system memory demand grows too high it will just kill some arbitrary process. On Linux this is the infamous OOM killer that uses the "niceness" score to determine what to kill.
And yes, for the OOM killer there's very little you can do.
But an allocation failure (nullptr or bad_alloc) does not mean OOM condition is happening in the system.
None of that matters: what is your application going to do if it tries to allocate 3mb of data from your 2mb allocator?
This is the far more meaningful part of the original comment:
> and furthermore most code is not in a position to do anything other than crash in an OOM scenario
Given that (unlike a language such as Zig) Rust doesn’t use a variety of different allocator types within a given system, choosing to reliably panic with a reasonable message and stack/trace is a very reasonable mindset to have.
Since we're talking about SQLite, by far the most memory it allocates is for the page cache.
If some allocation fails, the error bubbles up until a safe place, where some pages can be dropped from the cache, and the operation that failed can be tried again.
All this requires is that bubbling up this specific error condition doesn't allocate. Which SQLite purportedly tests.
I'll note that this is not entirely dissimilar to a system where an allocation that can't be immediately satisfied triggers a full garbage collection cycle before an OOM is raised (and where some data might be held through soft/weak pointers and dropped under pressure), just implemented in library code.
Sure, and this is completely sensible to do in a library.
But that’s not the point: what can most applications do when SQLite tells them that it encountered a memory error and couldn’t complete the transaction?
Abort and report an error to the user. In a CLI this would be a panic/abort, and in a service that would usually be implemented as a panic handler (which also catches other errors) that attempts to return an error response.
In this context, who cares if it’s an OOM error or another fatal exception? The outcome is the same.
Of course that’s not universal, but it covers 99% of use cases.
The topic is whether Rust should be used to re-implement SQLite.
If SQLite fails to allocate memory for a string or blob, it bubbles up the error, frees some data, and maybe tries again.
Your app may be "hopeless" if the error bubbles up all the way to it, that's your choice, but SQLite may have already handled the error internally, retried, and given your answer without you noticing.
Or it may at least have rolled back your transaction cleanly, instead of immediately crashing at the point of the failed allocation. And although crashing should not corrupt your database, a clean rollback is much faster to recover from, even if your app then decides to crash.
Your app, e.g. an HTTP server, might decide to drop the request, maybe close that SQLite connection, and stay alive to handle other ongoing and new requests.
SQLite wants to be programmed in a language were a failed allocation doesn't crash, and unlike most other code, SQLite is actually tested for how it behaves when malloc fails.
In C++ it will throw an exception which you can catch, and then gracefully report that the operation exceeded limits and/or perform some fallback.
Historically, a lot of C code fails to handle memory allocation failure properly because checking malloc etc for null result is too much work — C code tends to calm that a lot.
Bjarne Stroustrup added exceptions to C++ in part so that you could write programs that easily recover when memory allocation fails - that was the original motivation for exceptions.
In this one way, rust is a step backwards towards C. I hope that rust comes up with a better story around this, because in some applications it does matter.
> most code is not in a position to do anything other than crash in an OOM scenario.
That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way.
You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.
Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
> I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.
It may not be as simple as "that's our policy". I worked at one place (embedded C++ code, 2018) that simply reset the device every 24h because they never managed to track down all the leaks.
Finding memory leaks in C++ is a non-trivial and time-consuming task. It gets easier if your project doesn't use exceptions, but it's still very difficult.
In my experience that is usually the result of years and years of accumulation of shit code. The results is thousands of leaks. That makes detection of incremental leaks much more difficult. If you start with clean code and use ASAN or Valgrind then leak detection is not difficult.
Use Valgrind? Or are we talking projects that have become far too big for their own good, cause leaks aren't hard at all to find with the right tools and a bit of profiling... now crossing thread boundaries and weird dynamic programming tricks maybe, but thats a very different case and not really refecting on C++ itself, would likely trip up a GC lang as well.
Was not available for that specific device, but even with Valgrind and similar tools, you are still going to run into weird destructor issues with inheritance.
There are many possible combinations of virtual, non-virtual, base-class, derived-class, constructors and destructors; some of them will indeed cause a memory leak, and are allowed to by the standard.
> Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
What are you talking about? Every allocation must be checked at the point of allocation, which is "the default"
If you write non-idiomatically, then sure, in other languages you can jump through a couple of hoops and check every allocation, but that's not the default.
The default in C is to return an error when allocation fails.
The default in C++, Rust, etc is to throw an exception. The idiomatic way in C++, etc is to not handle that exception.
> Every allocation must be checked at the point of allocation, which is "the default"
C doesn't force you to check the allocation at all. The default behavior is to simply invoke undefined behavior the first time you use the returned allocation if it failed.
PS. The current default in rust to print something and then abort the program, not panic (i.e. not throw an exception). Though the standard library reserves the right to change that to a panic in the future.
> > C doesn't force you to check the allocation at all.
> No one ever claimed it did;
You specifically said
> Every allocation must be checked at the point of allocation
...
> the default is to check the returned value from memory allocations.
Default has a meaning, and it's what happens if you don't explicitly choose to do something else.
In libc - this is to invoke undefined behavior if the user uses the allocation.
In glib - the library that underpins half the linux desktop - this is to crash. This is an approach I've seen elsewhere as well to the point where I'm comfortable calling it "default" in the sense that people change their default behavior to it.
Nowhere that I've ever seen, in C, is it to make the user handle the error. I assume there are projects with santizers that do do that, I haven't worked on them, and they certainly don't make up the majority.
> : a selection made usually automatically or without active consideration
See that "without active consideration" there? The default usage of malloc includes, whether you want to acknowledge it or not, checking the returned value.
C doesn't have anything done automatically, so I am wondering why you would choose to think that by "default" one would mean that something automatically gets done.
I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Of course things do happen automatically all the time in C, like bumping the stack pointer (another case of unhandled OOM) and decrementing it after the fact. And pushing return addresses - and returning at the end of functions. And so on.
"Ubiquitous" is a different word than default, checking the return code of malloc isn't even that. As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. And it doesn't reliably check the return code. For example: https://github.com/PipeWire/pipewire/blob/6ed964546586e809f7...
And again, this isn't cherry picked, this is just "the last popular open source C code base I've looked at". This is the common case in C. Either you wrap malloc to crash, or you just accept undefined behavior if malloc fails. It is the rare project that doesn't do one of those two.
> I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code.
Right. But this is what you initially responded to:
> You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C.
How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures?
> As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc.
Correct. That does not mean that the default way of writing allocation in C is anything other than what I said.
Do programmers make mistakes? Sure. But that's not what asked - what was asked is how do you handle memory errors gracefully, and I pointed out that, in idiomatic C, handling memory errors gracefully is the default way of handling memory errors.
> How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures?
I think you might want to reread the line you quoted directly above this,
That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C".
This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction of projects allocator wrappers). Not "handling OOM gracefully" - i.e. handling OOM errors.
I have programmed in C plenty. Your assertion that unchecked allocations are few and far between is simply entirely incorrect. That they are treated as bugs when reported is incorrect in most C software.
For good reason. Most C software is not designed to run in a situation where malloc might fail.
I, unlike you, have provided evidence of this by pointing to major pieces of the linux desktop that do not do so.
because of OS-level overcommit, which is nearly always a good thing
It doesn't matter about the language you are writing in, because your OS can tell you that the allocation succeeded, but when you come to use it, only then do you find out that the memory isn't there.
Of course it matters, because you (the system admin) can tell your OS not to do that. Which is only helpful if your app knows how to handle the case. Most don't, so overcommit, in general, makes sense.
> You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory...
Sure, but ... what does that have to do with this thread? Using `mmap` is not the same as using `malloc` and friends.
If you turn off overcommit, malloc will return NULL on failure to allocate. If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
> If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
You misunderstand, you specifically request mmap to ignore overcommit, and it doesn't, not does.
What it has to do with this thread is it makes turning off overcommit on linux an exceptionally unpalatable option because it makes a lot of correct software incorrect in an unfixable manner.
Zig puts OOM handling much more front and center than C. In C, you can handle OOM but it's easy to ignore NULL checks on mallocs &co because they almost never happen.
In Zig you must handle it. Even if handling means "don't care, panic", you have to spell that out.
> That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way.
No, this is wishful thinking. While plenty of programs out the are in the business of maintaining caches that could be optimistically evicted in order to proceed in low-memory situations, the vast majority of programs are not caching anything. If they're out of memory, they just can't proceed.
I used to think this way many years ago, then I saw my own code in production hit OOM errors and manage to recover, and even log what was happening so I could read about it later.
After those experiences I agree with the sibling comment that calls your position "bullshit". I think people come to your conclusion when they haven't experienced a system that can handle it, so they're biased to think it's impossible to do. Since being able to handle it is not the default in so many languages and one very prominent OS, fewer people understand it is possible.
I think this is bullshit. If you are running out of memory, you can, for example, choose to stop accepting more work ("backpressure"). I am always advocating for Rust, but this is one thing I really disagree on. I think Zig gets this right.
Now you need to ensure that your entire error path does not allocate or you have to deal with allocation errors in the error path as well.
Trying to apply backpressure from memory allocation failures which can appear anywhere completely disconnected from their source rather than capping the current in memory set seems like an incredibly hard path to make work reliably.
In Zig's case, the entire stdlib never allocates on failure, and most libraries follow the same pattern. The philosophy of Zig is allocation/creation can fail, but freeing/destroying must never fail. It's caused me to be really thoughtful with how I design my data structures, and often made me use better ways of representing metadata.
Maybe screwed was too strong of a term. In the scenario above, they wanted to log on resource cleanup, but that makes resource cleanup potentially fallible. The Zig philosophy is that cleanup must never fail, so having cleanup be fallible goes against that.
I was suggesting (though in retrospect not clearly) that logging should use a ring buffer instead of allocation, in order to make logging on cleanup a guaranteed best effort operation. You're right that you can recover from OOM, but logging OOM with an allocator is pretty self-defeating.
If you allocate a relatively big chunk of memory for each unit of work, and at some point your allocation fails, you can just drop that unit of work. What is not practical?
I think in that case overcommit will happily say the allocation worked. Unless you also zero the entire chunk of memory and then get OOM killed on the write.
I suppose you can try to reliable target "seriously wild allocation fails" without leaving too much memory on the table.
0: Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slightly more memory in this mode. This is the
default.
There's experimental/nightly support for things like: `push_within_capacity()` which is a more manual way (user-space code would have to handle the return code and then increase the capacity manually if required) of trying to handle that situation.
Vec::push_within_capacity is a nice API to confront the reality of running out of memory. "Clever" ideas that don't actually work are obviously ineffective once we see this API. We need to do something with this T, we can't just say "Somebody else should ensure I have room to store it" because it's too late now. Here's your T back, there was no more space.
Yeah, it's not ideal that the standard library currently has blind spots around allocation and I hope those get resolved eventually, but if you're rolling everything from scratch in C anyway then it's not much of a stretch to likewise roll your own Rust primitives in places where the included batteries don't work for you.
Depends on your definition of graceful but the C standard doesn't preclude handling it and there's POSIX interfaces such as sigaltstack / sigsetjmp etc that fit and indeed some code like language runtimes use this to react to stack exhaustion (having first set up guard pages etc).
> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language.
But I don't see Rust ever going in such a direction. It seems fundamentally opposed to Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree.
The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not ever have to update your 2015 edition code for anything.
No you’re misunderstanding the ecosystem. Rust 2024 code can call 2021 code without issue (and vice versa I think although could be wrong on the vice versa). So you can progressively update code of individual components as you want or not at all and still continue using it just fine in new code using later editions. Thats the very definition of back compat, something you really really shouldn’t do with C++ (every file should be compiled with the same language version target although practically that may be less of an issue depending on the specific stdlib implementation and if they break ABI)
There’s also automated migration tools to convert 2021 code to 2024. It might fail on some translations but generally it’s pretty automatic.
So huge difference both in the migration mechanism and the bc story.
Right. A good mental model would be to imagine every crate of Rust source has an associated Edition and there's a sort of "pre-processing" step where we translate that into the latest version of Rust seamlessly, preserving its exact meaning.
So e.g. 2018 Edition said r# at the start of an identifier now marks a "raw" identifier. Keywords promise never to start this way, so r#foo is the same as foo but r#foo even works if some lunatic makes foo a keyword whereas just foo would become a keyword if that happened. As a result if you write
let async = 5;
... in Rust 1.0 that translator treats it exactly as though you'd written
let r#async = 5;
... in a modern Rust edition because these days the keyword async exists.
The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue.
Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't break your dependents either -unless they don't have a new enough version of the compiler to support said newer edition.
what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file?
If I have Rust code from 2021, can I add a feature from 2024 and run it with --edition=2021 or 2024? Wouldn't adding a 2024 feature then possibly break the 2021 code?
I think the fact that rust is compiled has a big impact in terms of bc for dependencies. py2 must use py2 dependencies, but rust24 could use rust21 binaries as long as there were no API bc breaks, the code itself is already compiled away.
> what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file?
The difference is that it's not the entire compiler. Rust's editions are only allowed to change the frontend. At the middle part of the compiler, it's all the same thing, and the differences are completely gone. This is the core of how the interop works, and it also means that you can't just change anything in an edition, only smaller things. But completely changing the language every few years wouldn't be good either, so it's fine in practice.
> Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree.
But the Rust team found a great way to avoid breaking
backward compatibility: old code gets automatically compiled by the old version of the compiler, whereas more recent code is treated with the latest version of the compiler.
That is much better IMHO than carrying that old baggage along in the language that e.g. the C++ folks struggle with, where every half-decade a pile of additive changes get piled on the previous version of the language, and nobody can clean up the old mess.
> old code gets automatically compiled by the old version of the compile
That's not what happens. You always use the same version of the compiler. It's just that the newer compiler version also knows several older dialects (known as editions) of the language.
Right, it's not considered weird for a C++ compiler to offer C++ 98, C++ 11, C++ 14, C++ 17, C++ 20, C++ 23 and C++ 26 (seven versions) and support its own extra dialects.
It is also usual for the C++ compilers to support all seven standard library versions too. Rust doesn't have this problem, the editions can define their own stdlib "prelude" (the reason why you can just say Vec or println! in Rust rather than their full names, a prelude is a set of use statements offered by default) but they all share the same standard library.
core::mem::uninitialized() is a bad idea and we've known that for many years, but that doesn't mean you can't use it in brand new 2024 Edition Rust code, it just means doing so is still a bad idea. In contrast C++ removes things entirely from its standard library sometimes because they're now frowned on.
This may have its own landmines. Worst case, old code getting compiled in the old way could mean that the exact same line means different things depending on which file it's in. (I don't know whether it is possible with how Rust does this.)
There are several edge cases where that's exactly what happened.
But in all the cases I can think of, when you look at that Rust today, what it meant in say 2018 Edition seems silly, "Oh, that's a daft thing for that to mean, I'm glad it doesn't mean that now"
We can't magically step into a time machine and fix how it worked at the time, any more than we could go back and cancel those minstrel shows which now seem awful. We can only fix it now and Rust's editions enable this, without the cost of making old code not work in old projects.
for dog in array_of_dogs.into_iter() {
/* In Rust 1.0 we get an immutable reference to each dog from the array */
/* But today (since 2021 Edition) we get the actual dogs, not references - thus consuming the array */
}
One of the changes I'm looking forward to from a future Edition is what happens when I write native ranges like 1..=10 (the integers 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10). Today this means core::ops::RangeInclusive but that type isn't Copy, because it is Iterator. Instead hopefully one day it'll become core::range::RangeInclusive which is Copy, and so can't be Iterator but instead IntoIterator.
So in that future Rust edition (when/if it happens) I can treat 1..=10 the same way as a pair of numbers (1,10) or an array of two numbers [1, 10] which are both Copy, that is, by just copying the bit pattern you are guaranteed to get an object which means the same thing, making life easier for programmers and the compiler. Today, because it isn't Copy, I must do extra busy work, which is slightly annoying and discourages use of this otherwise great type.
Sure, Rust can compile old code. But you can't upgrade that old Rust code to new Rust code very easily.
The fact that C was effectively "born old" means you can take a C89 program and compile it as C23 and it should simply work, with extremely minimal changes, if any.
That's a killer feature when you're thinking in decades. Which SQLite is.
You would need to be incredibly careful with compiling old C89 code on a modern compiler. It's not the language changes that would get you, it's a change in how compilers treat undefined behavior.
There has always been undefined behavior in C, but back in the day, compilers were nowhere near as aggressive in taking advantage of it to make your code faster. Most C programmers tended to treat C as portable assembly and not a language with rules that needed to be respected for it to not blow up your code.
I remember this being endlessly groused over by grognard, traditionalist C programmera, and more than a few of them switched to C++ as a result. After all, if the language was going to be a stickler about correctness, they might as well use a language with the features that meant they didn't have to reach into that bag of tricks.
> There has always been undefined behavior in C, but back in the day, compilers were nowhere near as aggressive in taking advantage of it to make your code faster.
That much is true. If you put the derefence of a pointer and the null check in the wrong order both those statements would have code emitted for them.
Now, it is almost certain that one of those statements would not be emitted.
OTOH, compiling with -O0 still leaves most code to be emitted and fewer dead-code elimination places.
I truly believe that the cult of c performance optimization has done more harm than good. It is truly evil to try and infer, or even worse, silently override programmer intent. Many if not most of the optimizations done by llvm and gcc should be warnings, not optimizations (dead code elimination outside of LTO being a perfect example).
How much wasted work has been created by compiler authors deciding that they know better than the original software authors and silently break working code, but only in release mode? Even worse, -O0 performance is so bad that developers feel obligated to compile with -O2 or more. I will bet dollars to donuts that the vast majority of the material wins of -O2 in most real world use cases is primarily due to better register allocation and good selective inlining, not all the crazy transformations and eliminations that subtly break your code and rely on UB. Yeah, I'm sure they have some microbenchmarks that justify those code breaking "optimizations" but in practice I'll bet those optimizations rarely account for more than 5% of the total runtime of the code. But everyone pays the cost of horrifically slow build times as well as nearly unbounded developer time loss debugging the code the compiler broke.
Of course, part of the problem is developers hating being told they're wrong and complaining about nanny compilers. In this sense, compiler authors have historically been somewhat similar to sycophantic llms. Rather than tell the programmer that their code is wrong, they will do everything they can to coddle the programmer while behind the scenes executing their own agenda and likely getting things wrong all because they were afraid to honestly tell the programmer there was a problem with their instructions.
My company maintains a medium set of Rust programs deployed on embedded Linux systems. Most of the time the migration is automatically done for you by Cargo itself with the command `cargo fix --edition`.
I don't know where you got this impression but our switches from 2018 to 2021 and now 2024 editions went very smootly. Rust hasn't broken backwards compatibility in any bigger way since 1.0.
When clang was first coming about, the number one cause of Debian packages failing to build with clang was that (at the time) clang defaulted to C99 whereas gcc defaulted to C89.
No not true. cargo fix —edition automatically does most translation to the new edition (most people never see it fail, I’ve seen it fail only on some obscure constructs that it couldn’t do automatically because the meaning of some trait stuff changed subtly but took 2 minutes or less to fix). cargo clippy —-fix will automatically apply linter fixes or warning fixes when it can.
Claiming that editions are an example of rust failing back compat shows a complete ignorance of the ecosystem or what coding in the language is actually like. People in this thread think you can’t mix n match editions or that migrating is some huge unavoidable obstacle. Indeed I have less fear upgrading editions than I do bumping the version of the c or c++ language or even using a newer compiler that exploits accidental UB that had been lurking.
Calling C "strange" for being conservative and not wanting to break things is rather odd. It's one of the "great" things in that sense. "Stable" could be another description.
Depends on what it’s unwilling to break. “The compiler generates code that segfaults when you multiply 13 * 37, but someone found a way way to trap it and used that as a faster way to make syscalls on Prime minicomputer, so we had to add -ffix-four-eight-won, which the original implementor misspelled in 1993 so we can’t fix that, either, for backward compatibility.”
Some of its actual weirdnesses seem no less odd than that to people who aren’t C experts, I assure you.
The great thing about C is that is was not designed by a committee at all. It was designed by a person with strong opinions. This means it is really great for what it does well(what the author was interested in).
To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee.
If you look at the structure of C++ in Backus Naur form it is absolutely nuts. The compile times have gone through the roof and people leave to create new languages like jai, Zig or whatever.
Common Lisp was designed by committee. It is as chaotic as C++.
Rust is also gigantic. I am very careful not to use in critical systems because it is so big unless we could restrict it with the compiler or something.
> To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee.
This comparison confuses me because C is... also controlled by a committee? The evolution of the C standard is under the control of ISO WG14 [0], much like how the C++ standard is under the control of ISO WG21 [1]. This was true for even the first versions of each language that was standardized.
For what it’s worth rust was also designed by a person with strong opinions. It’s devolved to an organization but that’s inevitable in terms of long term sustainability.
You can always use no-std if you so choose where the language is about the size of C (but still has better utility) although if you’re complaining about the size of the language, c++ is drastically worse in my opinion. Rust starting to work its way into the Linux kernel should be a signal that the language is better suited for paring down than c++
Oh look. Something works. Lets not break it? How crazy is that?
I sometimes wonder if what happens is like this:
1. Have problem. Need higher level computer language.
2. Think about problem.
3. Solve problem - 'C'
4. Think about problems with 'C'
5. Attempt to fix problems with 'C' - get C++
6. Think about problems with C & C++
7. Get: Go, F#, Rust, Java, JavaScript, Python, PHP, ...other
etc.
I tend to do this. The problem is obvious, that I do not repeat step #2.
So then I move to the next step.
8. Thinking about how to fix C, C++, Go, F#, Rust, Java, JavaScript, Python, PHP, ...other is too hard.
9. Stop thinking.
Although Mozilla's reason to pay for Rust R&D was because of problems with C++ it's probably not most helpful to think of Rust (let alone F#) as an attempt to specifically fix those problems.
C is a Worse is Better language (https://en.wikipedia.org/wiki/Worse_is_better). The bet is that if it's simpler to implement then the fact that what you're implementing isn't great will be dwarfed by that ease of implementation. And it worked for decades which is definitely a success.
You can make a similar argument for Go, but not really for Rust. The other side of the Worse is Better coin is that maybe you could make the Right Thing™ instead.
Because implementing C is so easy and implementing the Right Thing™ is very difficult, the only way this would compete is if almost nobody needs to implement the Right Thing™ themselves. In 1970 that's crazy, each Computer is fairly custom. But by 1995 it feels a lot less "out there", the Intel x86 ISA is everywhere, Tim's crap hypermedia experiment is really taking off. And when Rust 1.0 shipped in 2015 most people were able to use it without doing any implementation work, and the Right Thing™ is just better so why not?
Now, for an existing successful project the calculation is very different, though note that Fish is an example of this working in terms of full throated RIIR. But in terms of whether you should use C for new work it comes out pretty strongly against C in my opinion as a fairly expert C programmer who hasn't written any C for years because Rust is better.
> But no other language claims to be faster than C for general-purpose programming, because none are.
The "faster than C for general-purpose programming" is a pretty woolly claim so I'm not entirely surprised nobody claims that, but equally I think to be sure that "because none are" would need some serious caveats to make it true.
In particular you're going to have to say you think it doesn't matter how much developer time is needed. A project where C programmers spend five hours to make it run in 4 seconds is in this caveat "20% faster" than a project where Alt Lang programmers spend five minutes to make it run in 5 seconds - because only those seconds count. This is not how the real world works so it's a pretty nasty caveat.
Of course it's true in the case of sqlite. It's one of the most used pieces of software ever, and user cpu time spent is going to dwarf any developer time.
Your example should instead be:
- 5 hours of developer time to run in 4 seconds * n
- 5 minutes of developer time to run in 5 seconds * n
As long as n <= 17,700, then the developer time is "not worthwhile." This assumes that you value user time as much as developer time.
In the case of sqlite, the user time may as well be infinite for determining that side of the equation. It's just that widely used.
Also battery life. 20% less time, 20% more battery.
But OP is correct, companies don't care as long as it doesn't translate into higher sales (or lower sales because the competitor does better). That's why you see that sort of optimization mainly in FOSS projects, which are not PDD (profits-driven development).
>>A project where C programmers spend five hours to make it run in 4 seconds is in this caveat "20% faster" than a project where Alt Lang programmers spend five minutes to make it run in 5 seconds - because only those seconds count. This is not how the real world works so it's a pretty nasty caveat.
For any project with non-trivial amount of users the C programmer did better.
I mean I know companies like to save money and move the costs (time, electricity, hardware costs) to customers but if you care about users any non-trivial speed improvement is worth a lot in aggregate, surely more than your time implementing it.
Databases are a problem space which can absorb all available effort. So if you spend five hours making thing U as fast as it could be that's five fewer hours you can dedicate to thing V or thing W, not to mention X, Y, Z and so on.
> The C language is old and boring. It is a well-known and well-understood language.
This is such an under appreciated feature.
I'm tired of languages that just keep adding and adding to a language.
Work on the standard library or ecosystem, but stop changing the language otherwise you'll never end up anywhere because there is always going to be something that would benefit from some love.
Hell, I'd say the same is true for many libraries.
> It is a well-known and well-understood language.
This isn't entirely true. There are a bunch of UBs that you have to be very careful about. C has the right idea about simplicity. But deterministic behavior is also important because someone will find a way to make use of UBs in their code.
What I like about C is that when they do add features they are just useful non-controversial features with maybe one exception of VLAs (that one was controversial).
Designated initializers, compound literals, binary literals and the way to printf numbers in binary, constexpr, alignas, #embed, stdbit.h, memset_explicit, restrict to name the ones I really like.
C is the first language where I actually felt like I was programming. After using C and assembly for a few projects, every other language started to feel extremely slow. Even now, when programming with TS, my mind always goes to legacy features that offer better performance at the nanosecond level.
I agree that C is best. I think Rust is actually a language with some severe downsides, despite having including some very good ideas and C having some real issues. But it will take a couple of years before one can discuss this rationally without being flamed at.
If you want to spread this idea, it would probably help your cause if you pointed to what you think Rust does particularly poorly. Steep learning curve, npm-esque packaging?
The article gave many good reasons where Rust is lacking. The points you raise are also clearly issues. My main additional issues are the high complexity, the syntax, the lack of stability, compilation times (and monomorphization), and lack of alternate implementations. Ignoring the language itself, the aggressive and partially misleading negative and positive marketing.
What do you mean by useful dynamic linking? Dynamic linking with C ABI is supported natively in Rust and is very widely used (just checked GitHub), especially for FFI like in Python modules (PyO3). If you mean an ABI that supports all the Rust features (without extern C), then it's a problem faced by every language that has more features than C - C++, Haskell, Go, Zig, etc included. To solve that problem, somebody will have to design a new stable standard common ABI that natively supports all the features from these languages, or at least makes it possible to express these features in some way.
C++ has reasonable dynamic linking (there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11), obviously excluding a lot of metaprogramming features, but a lot of C++ dynamic libraries exist that are widely used. Supposedly Swift does a better job, though I'm not familiar. Yes, Rust can dynamically link with a C ABI (as can any language) but it loses a lot of the expressiveness (I imagine, I'm not a rust developer) to have to use the C ABI.
Dynamic languages of course support dynamic linking.
Because the size information for an instance of foo is only known at compile-time, so the clients aren't allocating enough space on the stack for it (ditto the heap if you're using `new foo();`)
The way around this is awkward and involves the pimpl pattern and moving all your constructors out-of-line... but you also need to freeze all virtual methods (even just adding a new one breaks ABI), and avoid using any template-heavy std:: types (not even std::string), since those are often fragile.
Most people just give up and offer an extern "C" API, because that has the added benefit that it's compatible across compilers.
"true" C++ shared libraries are crazy difficult to maintain. It's the reason microsoft invented COM.
It is problem of all languages whose extensions to C are badly designed. That it works with the C FFI just shows that C part properly supports it while Rust does not. And yes, C++ has similar problems as Rust.
Yes, sorry, apparently not quick enough. I actually do not think it is horrible. It is a nice language, but I still do not like it and see many downsides. What I hate though is how aggressively it is marketed. See my other response for details.
That is fair. Rust is my most used language, and I agree Rust has many downsides and pain points. But for my work, the positives outweigh the downsides of other languages I've used (including Python, Java, C++, and C).
But it ultimately depends on your situation. People elsewhere on this post are listing weaknesses of Rust that I consider to be strengths and vice versa.
Nobody is marketing it. It doesn't have a marketing budget. What you're seeing are lots of people that really like it because it's really good. Not flawless obviously but a significant improvement on C and C++.
I see a lot of activity of very specific parts of the industry promoting it. But also enthusiasts doing aggressive marketing are doing aggressive marketing - even if they do not have a budget. Whether it is an improvement is debatable. From my perspective, it is an improvement in some aspects and a significant step back in others. What is unacceptable though is the significant hate and pressure towards people who have other priorities and preferences, which is created by the "we must stamp out memory safety issues at all cost and Rust is the solution" narrative.
> it is an improvement in some aspects and a significant step back in others
Of course. Very few improvements are better in every way. There's always something you can find to like about the old solution. Horses are friendlier than cars. Records allow bigger artwork than CDs. Unlike DVDs (at first anyway) you can write to VHS. Unlike Typescript, Javascript doesn't need a compile step. FORTRAN77 fits nicely on punch cards.
That doesn't mean there's really any serious debate about them being improvements.
I will freely admit that Rust has only average compile time (though it's better than C++ at this point), high complexity, and async Rust is full of footguns. But I could come up with a much longer list of complaints for C.
> we must stamp out memory safety issues at all cost and Rust is the solution
Yeah I think memory safety is actually probably not the most important thing about Rust. Having a modern strong type system is arguably more significant. Memory safety is important too of course - even if you don't care about security memory safety issues are often plain hard to debug bugs.
I've started using SQLite years ago for its use of a single file to store data. Along the way, I found more reasons to like it. Today, I discovered a new reason when I read this article.
I also noticed many software companies have been switching to SQLite for storing data. Audacity has switched from using hundreds of tiny audio files in multiple folders for a single recording to a single file using SQLite. I suspect it is the reliability that comes from sticking to C
> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages.
This is no longer true. Rust, Zig and likely others satisfy this requirements.
> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe languages.
This is a major annoyance in the rust stdlib. Too many interfaces can panic (and not just in case of an OOM), and some of them don’t even document this.
> This is no longer true. Rust, Zig and likely others satisfy this requirements.
Rust and Zig satisfy this by being C ABI-compatible when explicitly requested. I'm pretty sure that that solution is not actually what the author meant. When you don't explicitly use `extern "C"` in Rust or `export` in Zig, the ABI is completely undefined and undocumented. I would go as far as arguing that the ABI problem, with Rust at least, is even worse than the ABI problem C++ has. Especially since Distros are (if memory serves) starting to ship Rust crates...
The only reasonable way to solve that problem is to design a standard ABI that supports expression of all features in modern compiled languages like Rust, Go, Zig, Haskell, Ada, etc. It doesn't make any sense to design stable ABIs for each language separately, because then you'll end up with a system directory full of dynamic libraries of several distinct ABIs.
> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language.
Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface. I've done it multiple time throughout my career (that ended up being called from Python, Swift, Objective-C/C++, Swift, Java, and Kotlin).
And as a side note, you don't have to do object-oriented programming in C++ if you don't want to.
> It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface
Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?
I've only seen it done for C++ that is more C than C++, or for libraries that were designed to "bail out" to a C interface.
> Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?
If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes.
My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.
But that if you design something from the ground up, then it's rather easy (with a certain set of constraints). My bad for not conveying that better.
Then the statement "Stuff can't interoperate with c++" is true. Nothing from c++ ever gets exposed. You have to explicitly write a C interface yourself, or avoid using c++ features (write C in c++) so everything looks like C in the first place and all you need is #ifdef __cplusplus extern "C" #endif. But then you're not writing c++ either.
> Then the statement "Stuff can't interoperate with c++" is true
Where is that statement? The statement I reacted to (and with some caveats) was the following: "Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++."
Which in my opinion is not true for the reason I mentioned.
> Nothing from c++ ever gets exposed
Depends what's your definition for "getting exposed". If you mean "no C++ feature from the language gets exposed" then it's mostly true (you can still wrap certain things like allocators, though painful, but there's certain C++ features that have no real equivalent in some target languages indeed). But you can definitely expose the functionality of C++ code through a C interface.
That's definitely true. Can't have generics / compile time evaluation across languages. Need to design your code around that restriction ahead of time. SQLite being dynamically typed luckily doesn't have any problems with that.
I've actually run into a similar problem with a C library before, because it heavily used macros as part of its API. Glad most developers don't do that.
You do lose the ability to use some features, that's true. Mostly RAII around the interface. You can still leverage it internally in the implementation, and if using context objects it would be even easier. The main pain point is if you want to let client of the library use their own allocators. It's still doable, but quite a pain.
Classes can be wrapped with a bit of effort. You do need to write the constructors and the destructors manually and invoke a pair of new/delete on the C side, but it's just as you would handle a type allocated by a C library itself. You'd use it the same way. You just have the liberty to have the implementation use (mostly) C++.
I thought you were talking about the use of malloc in both languages - you never mentioned new in your first post. and i think we have different views on what is "idiomatic" in the languages.
> I thought you were talking about the use of malloc in both languages - you never mentioned new in your first post. and i think we have different views on what is "idiomatic" in the languages.
That's fair, but malloc is certainly non-idiomatic, isn't it?
So you have to ensure that in such situation, you can execute code that does not require more memory: ensure that the rest only free stuff, or preallocate structures for that purpose
3. Embedded Programming: Ada has been designed for embedded programming and the language includes constructs for directly manipulating hardware, for example, and direct interaction with assembly language. - https://learn.adacore.com/courses/intro-to-embedded-sys-prog...
5. Ada has features supporting memory safety to avoid many memory issues in the first place ( https://www.adacore.com/blog/memory-safety-in-ada-and-spark-... ) and using its exception handling and programming techniques (like pre-allocating "guard" memory) can allow Ada programs to tackle fringe OOM errors.
I'd like to see Steve Yegge unleash his Gas Town with a convoy or whatever it's called to rewrite the sqlite in Rust obviously preserving 100% test coverage. Results are a guaranteed bombshell regardless of whether it succeeds or fails.
What’s Steve Yegge got to do with Rust? And who’s gonna sponsor some 10,000 hours to “rewrite the sqlite in Rust obviously preserving 100% test coverage”? Will he do it just for the memes, or did you think Rust is so cool there is no effort involved?
What's not serious? He's got a tool which he claims should be able to handle projects of this scale, the existing test coverage is what makes it not immediately impossible and about the memes, have you read his gas town post? Of course it's for the memes, but more importantly it'll validate his vision of the future in the eyes of quite literally everyone if successful.
1. This isn't a 2025 article, it's much older but it received some updates in 2025.
2. Ada is about as old as C so should have been considered as a possible safe language. It's safer than Rust in my opinion. GNAT was released in 1995 while SQLite is from 2000, so it was a possibility. C++ was also around: still unsafe, though less so than C.
Many non-programmers think that programming languages get outdated, just like operating systems or computer hardware, or even some software (old algorithms replaced by better algorithms), and each programmer should "follow trends", since using the same programming language for 10+ years sounds wrong.
But programming languages are like Math. It is like saying "multiplying is outdated" or "the square root is outdated".
if you don't think programming languages can get outdated then why is assembly, fortran, lisp, smalltalk, pascal, basic practically disappeared? programming languages are not like math, it's like the moon
The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code.
Overall, it makes sense. C is a systems language, and a DB is a system abstraction. You shouldn't need to build a deep hierarchy of abstractions on top of C, just stick with the lego blocks you have.
If the project had started in 2016, maybe they would have gone for c++, which is a different beast from what it was pre-2011.
Similarly, you might write SQLite in Rust if you started today.
The author of ZMQ had an article about regretting not using C over C++.
Picking Rust for a "modern" version of SQLite could easily go down a similar route in the end.
Regret is possible with any language, but I'd be surprised if someone regretted choosing Rust for the reasons in the article you linked:
* Error handling via exceptions. Rust uses `Result` instead. (It has panics, but they are meant to be strictly for serious logic errors for which calling `abort` would be fine. There's a `Cargo.toml` option to do exactly that on panic that rather than unwinding.) (btw, C++ has two camps here for better or worse; many programs are written in a dialect that doesn't use exceptions.)
* Constructors have to be infallible. Not a thing in Rust; you just make a method that returns `Result<Self, Error>`. (Even in C++ there are workarounds.)
* Destructors have to be infallible. This is about as true in Rust as in C++: `Drop::drop` doesn't return a `Result` and can't unwind-via-panic if you have unwinding disabled or are already panicking. But I reject the characterization of it as a problem compared to C anyway. The C version has to call a function to destroy the thing. Doing the same in Rust (or C++) is not really any different; having the other calls assert that it's not destroyed is perfectly fine. I've done this via a `self.inner.as_mut().expect("not terminated")`. They say the C only has two states: "Not initialised object/memory where all the bets are off and the structure can contain random data. And there is initialised state, where the object is fully functional". The existence of the "all bets are off" state is not as compelling as they make it out to be, even if throwing up your hands is less code.
"In a more complete build, SQLite also uses library routines like malloc() and free() and operating system interfaces for opening, reading, writing, and closing files."
Whoa. TIL there's a minimal
build of SQLite that doesn't even need malloc() and free() !
Presumably for embedded devices. I'd love to see examples of that being used in the wild.
> So, for example, Android applications written in Java are able to invoke SQLite (through an adaptor). Maybe it would have been more convenient for Android if SQLite had been coded in Java as that would make the interface simpler. However, on iPhone applications are coded in Objective-C or Swift, neither of which have the ability to call libraries written in Java. Thus, SQLite would be unusable on iPhones had it been written in Java.
This feels like they're responding to people asking for SQLite to be rewritten in Java. Who are these people?!
As an outsider when I read about Rust it seems like it is positioning itself as the language to rewrite things that already work.
It's just the simplistic first feeling of a language, in the same way I feel like Go is the language for Kubernetes/cloud/net servers, Ruby is for Rails, JS is the browser/bootcamp language, Python is Data Science and AI...
Sure, you get that safety but you are also throwing the stability that an old (and maintained) codebase has just for the sake of being patched to handle the presssure from the real world.
Maybe it's time Rust positions itself as something more than "the language of rewrites".
who is this that you are claiming is "positioning" itself??? the Rust maintainers? No. Programmers are choosing to write something in Rust and it just so happens they are interested in rewriting something that already exists because they can. You write as if Rust is an entity that chose to position itself.
What is your argument here? Rust should just go do something else? You wouldn't dare say that about Python.
Also, how dare you put these languages in a corner. I've use ruby for many things other than Rails. JS is much more than a browser language now, and python is much more than data science and AI. Go is much more than Kubernetes/cloud/net servers.
Well they don’t have to wait for Rust in the way they said - they’ve already been forked by Turso which has been moving along for a while now. I wouldn’t mind hearing from them how that’s been going.
> Recoding SQLite in Go is unlikely since Go hates assert()
I've heard it said you shouldn't use asserts in production code, but handle errors and exceptions instead? That said, can't you just 'if !condition() {panic...}' to simulate the behavior? Or are they talking about something specific about Golang?
> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy.
Doesn't the language compiler write the code that checks if the array access is in-bounds? Why would you need to test the compiler's code?
...saying that for a statement `if( a>b && c!=25 ){ d++; }`, they use 100% machine-code branch coverage as a way of determining that they've evaluated this in `a<=b`, `a>b && c==25`, and `a>b && c!=25`. (C/C++) branch coverage tools I've used are less strict, only requiring that takes both if and else paths.
One could imagine a better high-level branch coverage tool that achieves this intent without dropping to the machine code level, but I'm not sure it exists today in Rust (or any other language for that matter).
There might also be an element of "we don't even trust the compiler to be correct and/or ourselves to not have undefined behavior" here, although they also test explicitly for undefined behavior as mentioned later on the page.
I think they're saying it's not covered: not only because `call` isn't ever reached but also because they identify `jae` as a branch and see it's always not taken. (If there were no lines in your `; later...` section and the branch were always taken, they'd still identify the `jae` as not covered.)
It might be reasonable to redefine their metric as "100% branch coverage except for panics"...if you can reliably determine that `jae .Lpanic_label` is a panic jump. It's obvious to us reading your example of course but I don't know that the compiler guarantees panics always "look like that", and only panics look like that.
Makes a lot of sense for SQLite to be written in C.
It's a heavily optimized and debugged database implementation: Just look at btree.c with all its gotos :)
The only language that would make sense for a partial/progressive migration is zig, in huge part due to its compatibility with C. It's not mentioned in the article though.
Zig hasn't even had it's first release yet. And projects written in it still break in new releases. Given their stance on boringness and maturity it would make no sense for Sqlite to consider zig yet.
SQLite is never gonna be rewritten by its creators in another language. That is highly doubtful considering the age of SQLite and the roadmap for support I think until 2060 or mid 2050s based on what I’ve read.
> SQLite is never gonna be rewritten by its creators in another language.
Almost certainly correct. It is however being rewritten in Rust by other people https://github.com/tursodatabase/turso. This is probably best thought of as a seperate, compatible project rather than a true rewrite.
I'm biased but when I see Discord as the only way of communication, it doesn't make for a serious project. I wish more projects would rely on IRC/Matrix + forums.
For better or worse, plenty of serious projects are using Discord for communication. It's not great, but IRC and Matrix have their own problems (IMO Zulip is the best of the bunch, but doesn't seem to be particularly widely adopted).
The amount of completely obscure and exotic platforms that have C compiler, and the amount of tooling and analysis tools C has — I'd be surprised anything comparable exists.
The problem with articles like this is that they read a little like justifying a decision that has already been made. I've a feeling that if it was written in C++/Rust/Go/whatever, it would also be possible to justify that decision with similar reasoning.
I think you're not wrong, but it's not necessarily a problem? I might argue that's actually part of the main point the article is making. The software is already written in C, well understood and optimized in that language, and quite stable, so they'd need very compelling reasons for a rewrite.
I think the "lingua franca" argument for C and the points at the end about what they'd need from Rust to switch do go beyond merely justifying a decision that's already been made, though.
Given SQLite's amazing battery of test code, it seems like it would be valuable, illuminating, and not too difficult to write a test implementation in Rust. Can you get the Rust implementation to pass the test suite? Either answer to that question would be interesting.
I considered it outdated back in 1993, when all major GUI based systems (Apple, IBM, Microsoft) were going with C++ for userspace applications.
Then came the rise of FOSS adoption, with the GNU manifest asserting to use only C as compiled language.
"Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C."
For big, fixed environments like Qt — sure. For embedded? Please no. Basic is good. Feel free to reimplement C++, your C library still will not have: most of STL as a dependency; unwind tables in all code (including C!); ctor/dtor arrays; insane kilobyte-sized symbols.
I'm confused. What is a matter of skill? You linked 6 hour livestream where person is working on translating AVR assembly to 6502. What was your point, that translating assembly or executables to another architecture takes a lot of skill? Yes, it does!
Because I could not, by scrubbing that video, find anything where immense skill is used to deal with the enormous overhead that standard C++ forces on every program that uses it.
It is a matter of skill, understanding C++ and how to make it useful for embedded systems, and being able to understand standard library isn't a requirement for each executable.
By the way, the famous Arduino and ESP32 hasve no problem dealing with C++.
As we also didn't, back in MS-DOS, with 640 KB, Turbo Vision and Borland Collection Library (BIDS).
> standard library isn't a requirement for each executable.
So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries.
It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions and most of standard library. If you need to implement your own STL subset to satisfy the library, then modify the library to work with your STL, the resulting API is not much of an API, is it?
Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding.
It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.
C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library!
You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!
These are great, thanks!
That GBA "butano" compiles with -fno-rtti -fno-exceptions, so it is not a C++ engine/library according to C++ standard! It is, however, an impressive piece of work.
The ESP32 SDK (I lol'd at your "even", those Xtensa/RISCV chips can even run linux kernel!) is extremely impressive - they support enabling/disabling rtti and exceptions (obviously disabled by default, but the fact they implemented support for that is amazing). So "real C++" is possible on ESP32, which is good to know.
For comparision, here are the minimum SQLite dependencies from the submitted article: memcmp() memcpy() memmove() memset() strcmp() strlen() strncmp()
Of course you could run javascript and erlang on MCU too, but is that API better than C? Your claim of "skill issue" sounds like RedBull challenge. Please let us unskilled people simply call library functions.
C is like a classic car. It's cool and you might have fun with it, but if something goes wrong out there, there's a significant chance you'll end up in a very bad shape.
What! Classic cars are preferred. I'd trust an old muscle car more than a shiny new one ANY DAY OF THE WEEK. Ah gosh. New cars are trash. Never in my life had a good experience with a new car besides the smell.
I've had many new cars and the car I drive today is a classic, I love it. Takes me everywhere, replace the parts and still goes. No rust. Can't say the same for a new car. I had a brand new truck a few years ago and I sold it. I had way too many problems. Doors being not aligned, electrical problems. Just shit all around. I had a Ford Focus ST as well for a for awhile too and I hated it. I couldn't even go in a car wash without it leaking through the roof, new car as well. Crazy!!!
i haven't seen any rust projects yet that maximize embeddability, portability, space and transparency. maybe an argument could be made for the linux kernel stuff, but nothing like a sqlite that gets compiled and included in a million things on a million platforms ranging from high level interpreter wrappers on general purpose computers to teeny microcontrollers where the operating system is a library or some jump targets in rom.
that said, just because c is best for sqlite today, doesn't mean c is best for you or what you're trying to do.
Yup. But, they're all good in their own way. They're just a means to an end. If the end result is good, reliable, maintainable: whatever you use is good.
I love C and Assembly and I'm impressed by the things people can build in those languages and often (not always) I can understand the code written in it. It's also true that code written in it is available to every other language. For that I'm very happy, as I'm mostly working in higher level languages that can call things like sqlite.
Just imagine if all of Chromium was written in C and used simpler tools like GNU Make and Git for it's projects.
When the Rust version has the same take-up as the C version I know and trust, I might use it. Until then I'll wait. What's available now is good. I'm in no hurry to use an alternative. I like the idea of a reliable black-box, and I don't overly care how the black-box does its magic.
I'm a little surprised they're at all open to a rewrite in Rust:
> All that said, it is possible that SQLite might one day be recoded in Rust.
...followed by a list of reasons why they won't do it now. I think the first one ("Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.") is no longer valid (particularly for software that doesn't need async and has few dependencies), but the other ones probably still are.
I write Rust code and prefer to minimize non-Rust dependencies, but SQLite is the non-Rust dependency I mind the least for two reasons:
* It's so fast and easy to compile: just use the `rusqlite` crate with feature `bundled`. It builds the SQLite "amalgamation" (its entire code basically concatenated into a single .c file). No need to have bazel or cmake or whatever installed, no weird library dependency chains, etc.
* It's so well-tested that the unsafety of the language doesn't bother me that much. 100% machine branch coverage is amazing.
C is fast and maybe has predictable performance, but, for example, strcmp(), strlen(), strncmp() are not as fast (and also secure) as C++ std::string analogs, unless you don't help a bit by storing the string lengths.
> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy.
I don't think they thought about this too much. In the C code are they testing the "branch" into Undefined Behaviour?
The performance/memory security tradeoffs that C made made sense when computers were 100000 times slower and not connected to the internet but now when nearly all software is connected to the Internet it is a disaster.
I've often said (at least half jokingly) - C for systems programming, Javascript for everything else!
This artical makes the case for C as a low level language, I then offer Javascript as a functional-ish language for manipulating domain model data structures on the top.
>As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.
(Memory) safe languages are allowed to guarantee memory safety at any stage, including at runtime using GC and bound checks. That makes every GC language memory safe to a reasonable extend. The novelty in Rust is that it does the same at compile time, mostly automatically.
You can have data races in "safe" Go. If you race a trivial object [such as an integer] it's just radioactive and so long as you didn't need it to have any particular value (e.g. you were just going to write it to a log anyway, or you just discard it) you're fine. However if you race a non-trivial object then that's immediately Undefined Behaviour.
Of course Go programmers will say "Just don't do that" but that's exactly what C programmers told us about bounds misses, use after free and so on...
Plain and simple C is, by far, one of the current _LESS WORSE_ performant alternatives which can be used, actually, from low level to large applications.
C syntax is already waaaaay to rich and complex (and ISO is a bit too much pushing feature creep over 5/10 years cycles).
That's the first time I've heard the C syntax being called "too rich". It's the epitome of succinctness IMHO (too a fault, even, or maybe I'm just old). Are you confusing it with C++? If so, you have a point.
As a Lisper I would consider C having too much syntax. 3 different kinds of brackets, a mix of prefix, suffix, and infix operators, both dot and hyphen + greater than symbol infixes for member access on structures depending on whether you're accessing members of a struct directly or from a struct pointer, semicolons at the end of every statement, the different ways of declaring imports,...
C's syntax is pretty lacking by modern standards, requiring gross things like The Lexer Hack to resolve ambiguities that other languages just don't suffer from: https://en.wikipedia.org/wiki/Lexer_hack . To say nothing of the madness that is C's type declaration syntax, necessitating tools like https://cdecl.org/ and "the spiral rule" for reading type declarations (which doesn't actually produce the correct result anyway).
So "modern standard" is to make it easier for compiler writers instead of programmer to read the code? Thanks god C designers had their priorities elsewhere.
>>"the spiral rule"
Not a problem in 99.99% of cases where it's just:
type name = something;
I am talking about C syntax, not absurdely grotesque ultra-complex syntax like the ones from c++, java and similar (is that true that rust syntax is not that much less worse than c++ one now?).
We need a new C, fixed, leaner and less complex: primitives are all sized (u64, u8, f64, etc), only one loop primitive (loop{}), no switch, no enum, no typedef, no typeof and other c11 _generic/etc, no integer promotion, no implicit casts (except for void* and literal numbers?), real hard compiler constants, current "const" must go away (I don't even talk about "restrict" and similar), no anonymous code block, explicit differentiation between reinterpret,runtime,etc casts?, synchronous numeric computation handling, anonymous struct/union for complex memory layouts, and everything else I am currently forgetting about.
(the expression evaluation of the C pre-processor would require serious modifications too)
We need clean and clear cut definitions, in regards of ABIs, of argument passing by value of aggregates like structs/arrays, you know, mostly for those pesky complex numbers and div_t.
We need keywords and official very-likely-to-be-inline-or-hardware-accelerated-functions, something in between the standard library and the compiler keywords, for modern hardware architecture programming like memory barriers, atomics, byte swapping, some bitwise operations (like popcnt), memcpy, memcmp, memmove, etc.
In the end, I would prefer to have a standard machine ISA (RISC-V) and code everything directly in assembly, or with very high level languages (like [ecma|java]script, lua, etc) with a interpreter coded in that standard machine ISA assembly (all that with a reasonable SDK, ofc)
New C is old B? https://en.wikipedia.org/wiki/B_(programming_language)
I implemented some examples using B language. I like its typeless and simplicity. It would be nice if there was a modern and mature implementation of this language, it's a true portable assembler.
I love C, when I wrote my first programs in it as a teenager, I loved the simplicity, I love procedural code. Large languages like C++ and or Rust are just too much for ME. Too much package. I like writing code in a simple way, if I can do that with a small amount of tools, I will. You can learn C and be efficient in it within a couple weeks. C systems are just built better, faster, more stable, portable, and more! This is my 2 cents.
The article mentions 100% code coverage with tests as one of requirements from their users, and having "safe languages" emit defensive asserts and checks when compiling correct code means 100% branch coverage is impossible. How do you propose to address it with rust?
Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP.
If they are getting good results with C and without OOP, and people like the product, then those from outside the project shouldn't really have any say on it. It's their project.
> strangely and disproportionately pushed on Hacker News
There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages.
> then those from outside the project shouldn't really have any say on it. It's their project.
People outside the project are allowed to say whatever the hell they want, the project doesn't have to listen.
I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pushing of say Kotlin or Scala or Go or, etc from their fans.
I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like web services, but its big runtime and its GC rule it out for a lot of (especially very low level or latency-critical) uses -- you don't see Go ported to microcontrollers for instance. I can't speak for Scala, because i don't have experience writing software in it.
To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.
There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.
I‘m in the process of migrating Kotlin code back to Java in our product. My experiment with Kotlin is over and I‘m sticking 100% with Java. I like writing Kotlin, but I dislike reading Kotlin code.
Strange how people never say this with swift and objc
Probably because almost everyone avoids those languages at all costs
I don't agree.
First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade".
The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Kotlin's native backend and GraalVM.
The widening gap is not at all moving Kotlin further away from Java developers, but is just increasing the reasons to migrate. It is crucially not making interoperability with existing, legacy Java harder, just giving you more toys. Stuff like suspend functions vs. virtual threads only affects decision making in new application code, and you can for all intents and purposes use either depending on whether you're writing new Kotlin libs for a legacy Java app or a Kotlin app using legacy Java libs.
The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.
Plus, considering that Android apps were responsible for a very significant portion of actively developed Java (I would assume quite a loand has with Android having gone full Kotlin, a quite significant portion of Java developers will either already have migrated or soon be migrating to follow suit. This will over time affect a quite significant portion of the available skill pool for hiring, which will add additional pressure on enterprise.
There will always be Java, but I'd expect a significant portion of actively developed applications (as opposed to maintenance-mode only applications) to slowly migrate to either Kotlin or something else entirely.
I think you're widely mistaken if you don't think Java is a platform. The VM and language are intertwined. The VM explicitly knows about things like records, language constructs, and idioms from Java. Java sets the direction of the VM, not Kotlin.
JVM does not know about Java, it knows about an IR that Java, Kotlin, Scala, Closure, Groovy, etc. all target. Java as a language also doesn't know about JVM, as it commonly targets things that are not the JVM, whether that is Dalvik, Graal or something else entirely.
That the JVM and IR has features to help the Java compiler generate better output is obvious but not really relevant. Modern CPUs also have instructions to help C compiles generate better code, but that doesn't make them C platforms. It's just that implementation details.
So no, Java is not a platform. It is a language that sometimes runs on the JVM together with many other large and quite influential languages.
> First of all, Java isn't a platform.
You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?
> The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable (...)
Yes, in the sense that Java exists and Kotlin by design piggybacks on the JVM.
> The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.
This analysis is very superficial and fails to identify any of the real world arguments to switch from C. For example, Microsoft outright strangled C by wasting many years refusing to support any standard beyond C89, in spite of being directly involved in it's drafts. This was a major contribution to address any of the pain points and DX shortcomings. Compare the evolution of C and C++ during that time period, and we see C++ going through the same path in the C++0x days to then recover spectacularly once C++11 got unstuck.
> You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?
Java runs on several things that are not the JVM. Android does not use JVM to run Java, and even Oracle is pushing something that is not the JVM.
At the same time, JVM runs many things that are not Java.
If you are somehow implying along the lines of JVM only got initially authored because Java, then that is nothing but a historical fact of little relevance from the early days of the language. If not even Oracle considers Java and JVM one thing - and by virtue of Graal they don't - then it simply isn't as such.
> This analysis is very superficial and fails to identify any of the real world arguments to switch from C
You misread - what you quoted was not an analysis of why the migrations happen. It was a parallel, underlining that migrations do happen in spite of obvious feature differences (and sometimes, because of such differences).
Yeah, Kotlin is stuck in an uncomfortable position, like F# is in the .NET world. It has pioneered several important features, but now the big brother has implemented them slightly differently and people demand interop from you.
At least Kotlin can theoretically retreat to Android.
I did a decent amount of AoC this year in F#. I felt it was more verbose than I would have expected. There were a lot of things that helped brevity; I really liked type definitions, unless I was using OO features where it was extremely verbose to define members. I also really didn't like having to to Seq.map or List.filter for everything instead of just calling methods off of the seq or list.
From my POV having worked at a giant 50,000 person tech org—primarily Java—Kotlin was the kick in the pants that ushered in a lot of changes in the post-Java 11 world. We were on the verge of migrating wholesale to Kotlin after our CTO wrote an internal whitepaper in favor of the direction.
Out of interest
> As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this)
does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language.
After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there was an absolute proven need to switch languages, I'd mandate only a single language for our (back end) stack. The cost of supporting different languages is just too high.
I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.
> I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods.
This claim does not pass the smell test. Tech sprawl is a widely recognized problem, and dumping codebases each 2-3 years is outright unthinkable and pure madness. It doesn't even come across as resume-driven development because 3 years is not nearly enough to get anyone at a proficient level.
This claim is so outlandish that I'm inclined to dismiss it entirely as completely made-up. There is no project manager in the world who would even entertain this thought.
Your world seems small -- I never said anything about dumping codebases. If i have a library implemented in Rust, which gets called by a program written in C++ through FFI, and contacts a service which is implemented in python, I don't need to dump or waste any old work. A carpenter that only uses a hammer isn't a very good carpenter; different tools have different strengths and weaknesses.
No commit for 7 years but https://tinygo.org/docs/reference/microcontrollers/ is up to date.
Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.
Kotlin won't replace Java. They do not have the same niche.
Kotlin's Niche was to replace LEGACY Java with something that builds for older versions of Java but also gives you features and ergonomics not available for those features. There's a ton of super legacy Java out there.
> Kotlin won't replace Java. They do not have the same niche.
Claiming Java has a niche is very funny. I guess the niche is programmable computers? Well done.
Carbon is what could someday be a real successor to C++ in my eyes. It actually focuses on being compatible with C++ code similar to how Kotlin can work with Java directly, except it will make a lot more sense once it is stable and usable, I just hope its not a 'forever-project' like Fuchsia.
Actually, GO is ported to microcontrollers with Tinygo. Even u-root works on microcontrollers nowadays.
For the more bulky processors, there's also tamago.
>To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.
This doesn't explain why so many rust activists are going to projects they have no involvement in and demanding they be rewritten in rust.
What's happening is that there are progressive minded people who have progressive minded tactics, where they have a cause and everywhere they go they push their cause regardless of whether the places they are going have anything to do with their cause.
Is it really activism though, i.e. a concerted effort to put pressure on project leaders and make actual "demands"? Or is it just the occasional young Rust enthusiast asking questions or making the case for Rust?
You haven't been getting the checks? Bring that up at our next secret cabal meeting.
Probably something in-between: a self-organizing cult with too much support from industry.
> I think this is because of the gap in its target market
Surely that gap has been filled for at least a decade, even if only by Rust itself?
Moreover, I am not sure that serves as an explanation as it shows up in the strangest places. As you mention Go: Visit any discussion about Go and you'll find some arbitrary comment about Rust, even though, as you point out, they don't even exist in the same niche; being different tools for different jobs.
> Go was originally pitched as a C or C++ replacement
It was originally imagined that it would replace C++ for network servers at Google. The servers part was made abundantly clear. In fact, the team behind it expressed quite a lot of surprise that it eventually found a home doing other things as well.
> you don't see Go ported to microcontrollers for instance.
You don't? https://tinygo.org
> Surely that gap has been filled for at least a decade, even if only by Rust itself?
I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one.
> You don't? https://tinygo.org
I wasn't aware of this, thank you.
> the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin
What, exactly, does distance mean here?
The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not because of C++, but because something like Python (of which Google was the employer of van Rossum at the time!) was too slow. Go was created to offer something more like Python but with performance more like C++. It was a "C++ replacement" only in the sense that C++ is what Google was using where it was considered the "wrong tool for the job". Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast.
Putting things into perspective, the distance between C++ and Go is approximately the same as the distance between C++ and Python. Which is a pretty big distance, I'd say. C, C++, and Rust are much closer. They are all trying to do essentially the same thing, with Rust only standing out from the other two thanks to its at-the-time unique memory model. So it is apparent that we still don't understand "gap" to mean the same thing.
How I interpret his comment about the distance: The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go (in the similar use-cases) or from Java to Kotlin.
Another argument offered for Rust is that it's high-level enough that you can also use it for the web (see how many web frameworks it has). So I think that Rust's proponents see it as this universal language that could be good for everything.
> The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go
Ten years ago the memory model was a compelling benefit, sure, but nowadays we have Fil-C, that C++ static analyzer posted here yesterday, etc. There is some remaining marginal benefit that C and C++ still haven't quite caught up with yet, but is that significantly smaller and continually shrinking gap sufficient to explain things as they stand today?
You are right that the aforementioned assumption did not play out in the end. It turns out that C++ developers did, in fact, choose C++ because of C++ and would have never selected Python even if Python was the fastest language out there. Although, funnily enough, a "faster Python" ended up being appealing to Python developers so Go does ultimately have the same story, except around Python (and Ruby) instead of C++.
> Another argument offered for Rust is that it's high-level enough that you can also use it for the web
It was able to do that ten years ago just as well. That doesn't really explain things either.
> Keep in mind that Go was created before we knew how to make actually dynamically-typed languages fast.
Would you mind elaborating on this? The strongtalk heritage of VMs has been around for a while now, and certainly before go was started.
> I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues.
The "long history of safety issues" is actually a combination of being extremely successful (the world runs on C and C++) and production software always featuring bugs.
The moment Rust started to gain some traction, we immediately started seeing CVEs originating from Rust code.
Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
Sqlite's test suite is closed source, so no one other than the Sqlite authors can attempt that. That said, you may be interested in this attempt by Turso to rewrite Sqlite in Rust (https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...). They're not using AI, but they are using some novel ways to test their code.
I'm not a Rust evangelist, but I'm glad that Rust evangelists exist.
I decided to try it for a medium-sized (~10k LoC) performance sensitive component recently and it has been an absolute joy to use.
I'm mostly a Java dev, but baby-stepping Rust has been a lot of fun and reminds me, in a very good way, of the feeling I had in the late 90's when I was first learning Java.
Well that's because C, and C++, are uniquely awful and Rust can actually take them on.
Kotlin doesn't have a strong case for replacing java because java is, well, just fine. At least it's safe. Sure it's, like, slightly inconvenient sometimes.
And other languages like Go which originally claimed to take on C and C++ just don't. Go is garbage collected, it's not a real competition.
But Rust is different. It's actually safe, and it's actually a real competitor. There's basically zero reason to choose C other than "I know it" or "one of my library author's knows it". Which are both very good reason, but incidently have nothing to do with the language itself.
Go has already more or less won its target market. Rust proponents are still working to convince C and C++ holdouts, who are understandably skeptical given the past several decades of promised replacements that never materialized.
Rust is absolutely novel in being the first, production-grade memory-safe low-level language.
I think that's true - but I guess Rust and Zig are unique in that list on being new memory-managed languages (i.e. without garbage collectors).
Low level memory-managed languages have been C and C++ mostly for a really long time, so I think Rust and Zig probably seem "more new" than the likes of Kotlin, Go, Elixir, Gleam, etc.
> I think it's more than just the normal amount for advocacy of a new language.
More than C++? More than Java? More than Python?
Yeah, Julia was all the rage for a while, and that kind of disappeared.
Some languages, like elixir, stick around with a low-volume, but consistently positive mention on HN. Which makes me want to use it more.
Can I start then with Scala - it's my favorite language and easily has the best of both OO and functional worlds with insanely useful libraries to express code ergonomically. EVERYBODY SHOULD USE IT!
Nah it’s too complex, has shipped too many breaking changes, and the community sucks.
I worked on a Scala project about 15 years ago and it definitely felt overly complex. Similar to early C++, everyone used their own dialect.
Always gotta get my yum yucked.
Just been screwed too many times I guess. I do like it more than Kotlin though. The language is powerful.
Yeah, I agree with this observation. Not sure why Rust is different here though.
I understand "shouldn't really have any say on it" as shouldn't expect to infuence the project. Not that they are not allowed to say anything.
Otherwise they would have written something along the lines of "shouldn't say anything about it".
I am pretty certain Rust is pushed more than other languages. Whether warranted or not is another topic, but I think the OP has a point here.
> People outside the project are allowed to say whatever the hell they want, the project doesn't have to listen.
Within reason - don't be a dick and all that. :)
"having a say on something", in OP's context, means authority and influence over decisions... People can say whatever they want, yes, but not everyone can "have a say on something".
> People outside the project are allowed to say whatever the hell they want,
And? GP didn't say that they shouldn't.
> People outside the project are allowed to say whatever the hell they want
What these people do is a disservice to the general open source community, by spreading misinformation and general FUD about critical software that uses C and C++.
Rust is pushed on the internet
I definitely wouldn't say internet, I think it's popular on HN and a few other online forums. There are a lot of X/twitter circles which make are critical of rust, as well as other sites.
In my mind at least there's a decent risk Rust is going to end up like the next Haskell, its benefits other than safety are not that clear and many of those features can and have been replicated in other languages.
Many of its biggest benefits of rust come directly from other languages - including Haskell. Like, rust’s Option is identical to Haskell’s Maybe type. Traits are similar to type classes in Haskell, or interfaces in Go.
In my mind, the thing that makes rust and zig nice are that they put modern language features in a systems language. Non-nullable pointers and match expressions in a language that runs as fast as C? Yes please.
I love rust, but I personally doubt rust will ever be anywhere near as popular as Python, go, JavaScript and C#. It’s just so complex and difficult to learn. But its niche is pretty clear to me: I see it as a tool for writing beautiful, correct, memory safe, performant systems code. I used to love C. But between zig, rust and Odin, I can’t see myself ever using it again. C is just so much less productive and less pleasant to use than more modern languages.
And here I was just reading in another thread that HN was so much less toxic than other places...
Where do you see people having toxic debates?
> There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages.
This is a disingenuous opinion. The level of militance involved in this propaganda push goes way beyond mere interest. Just look at people who actually enjoy Java, C++, Python, etc. These are the most popular languages that mankind ever developed,and countless people built very successful careers around them. Yet, you don't see even a fraction of the fanboys you see constantly pushing these experimental languages.
It is also worth to note that the Rust design, in its theory, and the recent bug in the Linux kernel Rust code (the message passing abstraction used by Android), makes clear that:
1. With Rust, you may lower the exposure, but the same classes of bug still remain. And of course, all the other non memory related bugs.
2. With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
3. With Rust, to decrease the "unsafe" sections amount, you need often to build abstractions that may be a bit unnatural.
4. Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment. Like in the Linux Kernel bug, where such comment was hallucinated by a human that sometimes (not sure in this specific case, it's just an example) may be less used to do the "race spotting" process that C learns you to do.
5. With Rust, in case of a bug, the fix could no longer be the one-liner usually you see in C fixes, and can make the exposure time window larger. Sometimes fixing things in Rust means refactoring in non trivial ways.
6. With C, if there was the same amount of effort in creating wrappers to make kernel programming safer at the cost of other things, the surface of attack could also be lowered in a significant way (see for instance Redis use of sds.c: how many direct strings / pointers manipulation we avoid? The same for other stuff of course). Basically things like sds.c let you put a big part of the unsafe business in a self contained library.
So, is Rust an interesting language for certain features it has? Yes. Is Rust a silver bullet? No. So should Rust be "pushed" to others, hell no, and I suggest you to reply in the most firm way to people stressing you out to adopt Rust at all the costs.
The recent bug in the Linux kernel Rust code, based on my understanding, was in unsafe code, and related to interop with C. So I wouldn't really classify it as a Rust bug. In fact, under normal circumstances (no interop), people rarely use unsafe in Rust, and the use is very isolated.
I think the idea of developers developing a "bugs antenna" is good in theory, though in practice the kernel, Redis, and many other projects suffer from these classes of bugs consistently. Additionally, that's why people use linters and code formatters even though developers can develop a sensitivity to coding conventions (in fact, these tools used to be unpopular in C-land). Trusting humans develop sensibility is just not enough.
Specifically, about the concurrency: Redis is (mostly) single-threaded, and I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong).
Can people write safer C (e.g. by using sds.c and the likes)? For sure! Though we've been writing C for 50+ years at this point, at some point "people can just do X" is no longer a valid argument. As while we could, in fact we don't.
I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there. Treating bugs in unsafe code as not being bugs in rust code is kind of silly, also.
Exactly. You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.
For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. The fact that the percentage is higher in the latter case doesn't change the fact that 95% of your codebase is just as safe as the Python project would be.
A big amount of C code does not do anything unsafe as well, it calls other stuff, do loops, logic business, and so forth. It is also wrong to believe 100% of the C code is basically unsafe.
If so, then it should be trivial for someone to introduce something like Rust's `unsafe` keyword in C such that the unsafe operations can be explicitly annotated and encapsulated.
Of course, it's not actually this trivial because what you're saying is incorrect. C is not equipped to enforce memory safety; even mundane C code is thoroughly suffused with operations that threaten to spiral off the rails into undefined behavior.
It is not so hard to introduce a "safe" keyword in C. I have a patched GCC that does it. The subset of the language which can be used safety is a bit too small to be full replacement on its own, but also not that small.
C lacks safe primitives or non-error-prone ways to build abstractions to refer to business objects. There are no safe string references, let along ways to safely manipulate strings. Want to iterate over or index into a result set? You can try to remember to put bounds checks into every API function.
But even with explicit bounds checks, C has an ace up its sleeve.
Safe, right? Not so fast, because if the caller has a code path that forgets to initialize the argument, it’s UB.Almost all of C code does unsafe things. Deferencing a pointer is unsafe, using the address of a variable is unsafe, adding signed integers is unsafe.
Who is saying that 100% of C code is unsafe? It's potentially unsafe, as in: the mainstream compilers are unable to prove the code is memory-safe.
Rust achieves a sizable but not complete victory on that front.
I can't find the extreme claims that you seem to argue against.
You're swapping definitions of unsafe. Earlier you were referring to the `unsafe` keyword. Now you're using `unsafe` to refer to a property of code. This makes it easy to say things like "It is also wrong to believe 100% of the C code is basically unsafe" but you're just swapping definitions partway through the conversation.
What I see is that antirez claims that absence of "safe" (as syntax) in C lang doesn't automatically mean that all of C code is unsafe (as property). There's no swapping of definitions as I see it.
I think there's a very clear switch of usage happening. Maybe it's hard to see so I'll try to point out exactly where it happens and how you can spot it.
First from antirez:
> You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.
Use of the term `unsafe` here referring to the keyword / "blocks" of code. Note that this statement would be nonsensical if talking about `unsafe` as a property of code, certainly it would be inconsistent with the later unsafe since later it's claimed that C code is not inherently "unsafe" (therefor Rust would not be inherently "unsafe").
Kibwen staying on that definition here:
> For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code.
Here is the switch:
> A big amount of C code does not do anything unsafe as well
Complete shift to "unsafe" as being a property of code, no longer talking about the keyword or about blocks of code. You can spot it by just rewriting the sentences to use Rust instead of C.
You can say:
"A big amount of 'unsafe' Rust code does not do anything unsafe as well" "It is also wrong to believe 100% of the unsafe Rust code is basically unsafe."
I think that makes this conflation of terms clear, because we're now talking about the properties of the code within an "unsafe" block or globally in C. Note how clear it is in these sentences that the term `unsafe` is being swapped, we can see this by referring to "rust in unsafe blocks" explicitly.
This is just a change of definitions partway through the conversation.
p.s. @Dang can you remove my rate limit? It's been years, I'm a good boy now :)
Except that's a dishonest interpretation especially for someone of antirez's experience.
High performance is not an on/off target. Safe rust really lets you express a lot of software patterns in a "zero-cost" way. Sure, there are a few patterns where you may need to touch unsafe, but safe rust itself is not slow by any means.
For your last sentence, I believe topics are conflated here.
Of course if one writes unsafe Rust and it leads to a CVE then that's on them. Who's denying that?
On the other hand, having to interact with the part of the landscape that's written in C mandates the use of the `unsafe` keyword and not everyone is ideally equipped to be careful.
I view the existence of `unsafe` as pragmatism; Rust never would have taken off without it. And if 5% of all Rust code is potentially unsafe, well, that's still much better than C where you can trivially introduce undefined behavior with many built-in constructs.
Obviously we can't fix everything in one fell swoop.
>>Of course if one writes unsafe Rust and it leads to a CVE then that's on them. >>Who's denying that?
>>The recent bug in the Linux kernel Rust code, based on my understanding, was >>in unsafe code, and related to interop with C. So I wouldn't really classify >>it as a Rust bug.
Sometimes it's good to read the whole thread.
I did and it does not quite compute. That was glue code, related to interoperating with C. Not a "normal" everyday Rust code. It's an outlier.
Helps to read and ingest context.
Though I do agree that in the strictest of technical senses it's indeed a "Rust" bug, as in: bug in code written in Rust.
The bug in question is in rust glue code that interfaces with a C library. It's not in the rust-C interface or on the C side. If you write python glue code that interfaces with numpy and there's a bug in your glue, it's a python bug not a numpy bug.
I already agreed that technically it is indeed a bug in the Rust code. I would just contest that such a bug is representative is all. People in this thread seem way too eager to extrapolate which is not intellectually curious or fair.
Nobody is extrapolating from this bug to the rest of rust. The comment I responded to initially was denying that this was a rust bug.
You and a few others don't -- I did not make that clear, apologies. It's disheartening that a good amount of others do.
Why is glue code not normal code in Rust? I don't think anyone else would say that for any other language out there. Does it physically pain you to admit it's a bug in Rust code? I write bugs in all kind of languages and never feel the need for adjectives like "technical", "normal", "everyday" or words like "outlier" to make me feel not let down by the language of choice.
I have worked with Rust for ~3.5 years. I had to use the `unsafe` keyword, twice. In that context it's definitely not everyday code. Hence it's difficult to use that to gauge the language and the ecosystem.
Of course it's a bug in Rust code. It's just not a bug that you would have to protect against often in most workplaces. I probably would have allowed that bug easily because it's not something I stumble upon more than once a year, if even that.
To that effect, I don't believe it's fair to gauge the ecosystem by such statistical outliers. I make no excuses for the people who allowed the bug. This thread is a very good demonstration as to why: everything Rust-related is super closely scrutinized and immediately blown out of proportion.
As for the rest of your emotionally-loaded language -- get civil, please.
I don't care if there can be a bug in Rust code. It doesn't diminish the language for me. I don't appreciate mental gymnastics when evidence is readily available and your comments come out as compulsive defense of something nobody was really is attacking. I'm sorry for the jest in the comments.
I did latch onto semantics for a little time, that much is true, but you are making it look much worse than it is. And yes I get a PTSD and an eye-roll-syndrome from the constant close scrutiny of Rust even though I don't actively work with it for a while now. It gets tiring to read and many interpretations are dramatically negative for no reason than some imagined "Rust zealots always defending it" which I have not seen in a long time here on HN.
But you and me seem to be much closer in opinion and a stance than I thought. Thanks for clarifying that.
In Rust you can avoid "unsafe" when you use Rust like it was Go or Python. If you write low level code, that is where C is in theory replaceable only by Rust (and not by Go), then you find yourself in need of writing many unsafe sections. And to lower the amount of unsafe sections, you have to build unnatural abstractions, often, in order to group such unsafe sections into common patterns. Is is a tradeoff, not a silver bullet.
Not necessarily at all. Go peruse the `regex` crate source code, including its dependencies.
The biggest `unsafe` sections are probably for SIMD accelerated search. There's no "unnatural abstractions" there. Just a memmem-like interface.
There's some `unsafe` for eliding bounds checks in the main DFA search loops. No unnatural abstractions there either.
There's also some `unsafe` for some synchronization primitives for managing mutable scratch space to use during a search. A C library (e.g., PCRE2) makes the caller handle this. The `regex` crate does it for you. But not for unnatural reasons. To make using regexes simpler. There are lower level APIs that provide the control of C if you need it.
That's pretty much it. All told, this is a teeny tiny fraction of the code in the `regex` crate (and all of its dependencies).
Finally, a demonstration of C-like speed: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa...
> Is is a tradeoff, not a silver bullet.
Uncontroversial.
I think this framing is a bit backwards. Many C programs (and many parts of C programs) would benefit from being more like Go or Python as evident by your very own sds.c.
Now, if what you're saying is that with super highly optimized sections of a codebase, or extremely specific circumstances (some kernel drivers) you'd need a bit of unsafe rust: then sure. Though all of a sudden you flipped the script, and the unsafe becomes the exception, not the rule; and you can keep those pieces of code contained. Similarly to how C programmers use inline assembly in some scenarios.
Funny enough, this is similar to something that Rust did the opposite of C, and is much better for it: immutable by default (let mut vs. const in C) and non-nullable by default (and even being able to define something as non-null). Flipping the script so that GOOD is default and BAD is rare was a huge win.
I definitely don't think Rust is a silver bullet, though I'd definitely say it's at least a silver alloy bullet. At least when it comes to the above topics.
In my experience (several years of writing high performance rust code), there’s only really 2 instances where you need unsafe blocks:
- C interop
- Low level machine code (eg inline assembly)
Most programs don’t need to do either of those things. I think you could directly port redis to entirely safe rust, and it would be just as fast. (Though there will need be unsafe code somewhere to wrap epoll).
And even when you need a bit of unsafe, it’s usually a tiny minority of any given program.
I used to think you needed unsafe for custom container types, but now I write custom container types in purely safe rust on top of Vec. The code is simpler, and easier to debug. And I’m shocked to find performance has mostly improved as a result.
> was in unsafe code, and related to interop with C
1) "interop with C" is part of the fundamental requirements specification for any code running in the Linux kernel. If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job.
2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code. This is a fundamental limitation, and again is an issue when the fundamental requirement for the task is to interface to data structures implemented as doubly-linked lists.
No matter how good a language is, if it doesn't have support for floating point types, it's not a good language for implementing math libraries. For most applications, the inability to safely express doubly-linked lists and difficulty in interfacing with C aren't fundamental problems - just don't use doubly-linked lists or interface with C code. (well, you still have to call system libraries, but these are slow-moving APIs that can be wrapped by Rust experts) For this particular example, however, C interop and doubly-linked lists are fundamental parts of the problem to be solved by the code.
> If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job.
Rust is no less safe at C interop than using C directly.
As long as you keep C pointers as pointers. The mutable aliasing rules can bite you though.
(Not the user you were replying to)
If Rust is no less safe than C in such a regard, then what benefit is Rust providing that C could not? I am genuinely curious because OS development is not my forte. I assume the justification to implement Rust must be contingent on more than Rust just being 'newer = better', right?
It's not less safe in C interop. It is significantly safer at everything else.
The issue is unrelated to expressing linked lists, it's related to race conditions in the kernel, which is one of the hardest areas to get right.
This could have happened with no linked lists whatsoever. Kernel locks are notoriously difficult, even for Linus and other extremely experienced kernel devs.
> This is a fundamental limitation
Not really. Yeah you need to reach into unsafe to make a doubly linked list that passes borrow checker.
Guess what. You need unsafe implementation to print to console. Doesn't mean printing out is unsafe in Rust.
That's the whole point of safe abstraction.
I love rust, but C does make it a lot easier to make certain kinds of container types. Eg, intrusive lists are trivial in C but very awkward in rust. Even if you use unsafe, rust’s noalias requirement can make a lot of code much harder to implement correctly. I’ve concluded for myself (after a writing a lot of code and a lot of soul searching) that the best way to implement certain data structures is quite different in rust from how you would do the same thing in C. I don’t think this is a bad thing - they’re different languages. Of course the best way to solve a problem in languages X and Y are different.
And safe abstractions mean this stuff usually only matters if you’re implementing new, complex collection types. Like an ECS, b-tree, or Fenwick tree. Most code can just use the standard collection types. (Vec, HashMap, etc). And then you don’t have to think about any of this.
>> I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong).
You wrote that question in a browser mostly written in C++ language, running on an OS most likely written in C language.
Just because the pyramids exist, it means they were easy to build?
OS and browser development are seriously hard and took countless expert man hours.
OS can be actually pretty simple to make. Sometimes it's a part of a CS curriculum to make one. If it were so much easier to do it in other languages (e.g. in Rust), don't you think we would already be using them?
https://github.com/flosse/rust-os-comparison
Writing a toy one? Sure.
Writing a real one? Who's gonna write all the drivers and the myriad other things?
And the claim was not that it's "so much easier", but that it is so much easier to write it in a secure way. Which claim is true. But it's still a complex and hard program.
(And don't even get started on browsers, it's no accident that even Microsoft dropped maintaining their own browser).
The toy one can still be as highly concurrent as the the real one. The amount of drivers written for it doesn't matter.
The point is if it were much easier, then they would overtake existing ones easily, just by adding features and iterating so much faster and that is clearly not the case.
>>difficulty of building safe, fast and highly-concurrent C
This was the original claim. The answer is, there is a tonne of C code out there that is safe, fast and concurrent. Isn't it logical? We have been using C for the last 50 years to build stuff with it and there is a lot of it. There doesn't seem to be a big jump in productivity with the newer generation of low level languages, even though they have many improvements over C.
This is anecdotal, I used to do a lot of low level C and C++ development. And C++ is a much bigger language then C. And honestly I don't think I was ever more productive with it. Maybe the code looked more organized and extendable, but it took the same or larger amount of time to write it. On the other hand when I develop with Javascript or C#, I'm easily 10 times more productive then I would be with either C or C++. This is a bit of apples and oranges comparison, but what I'm trying to say is that new low level languages don't bring huge gains in productivity.
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
I suppose it's possible. I wonder if I'll become a better driver if I take off my seatbelt. Or even better, if I take my son out of my car seat and just let him roam free in the back seat. I'm sure my wife will buy this.
In all seriousness, your comment reminds me of this funny video: https://www.youtube.com/watch?v=glmcMeTVIIQ
It's nowhere near a perfect analogy, but there are some striking similarities.
Human behaviour can be a confounding thing. There was some debate a while ago [1] about whether bike helmet use may actually lead more head injuries due to factors like drivers passing closer to helmeted riders vs. unhelmeted ones or riders riding more recklessly, among a tonne of other factors. I still prefer to wear a helmet, but its an interesting example of how difficult it can be to engineer human behaviour.
Another good example of this is how civil engineers adding safety factors into design of roads - lane widths, straighter curves, and so on - leading drivers to speed more and decreasing road safety overall.
1. https://bigthink.com/articles/the-bike-helmet-paradox/
FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.
But in this specific case, if the respawn feature is not available or dying isn't a desirable event, FAFO might not be the best way to learn how to drive.
I also think we have the data in for memory safety in C. Even the best people, with the best processes in the world seem to keep writing memory safety bugs. The “just be more vigilant” plan doesn’t seem to work.
> FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.
Yes, just sucks for the person who you hit with your car, or the person whose laptop gets owned because of your code.
"FAFO" is not a great method of learning when the cost is externalized.
> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
I think there are effects in both directions here. In C you get burned, and the pain is memorable. In Rust you get forced into safe patterns immediately. I could believe that someone who has done only Rust might be missing that "healthy paranoia". But for teaching in general, it's hard to beat frequent and immediate feedback. Anecdotally it's common for experienced C programmers to learn about some of the rules only late in their careers, maybe because they didn't happen to get burned by a particular rule earlier.
> Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment.
This is an interesting contrast to the previous case. If you write a lot of unsafe Rust, you will eventually get burned. If you're lucky, it'll be a Miri failure. I think this makes folks who work with unsafe Rust extremely paranoid. It's also easier to sustain an that level of paranoia with Rust, because you hopefully only have to consider small bits of unsafe code in isolation, and not thousands of lines of application logic manipulating raw pointers or whatever.
The amount of paranoia I need for unsafe Rust is orders of magnitudes higher than C. Keeping track of the many things that can implicity drop values and/or free memory, and figuring out if im handling raw pointers and reference conversions in a way that doesn't accidentally alias is painful. The C rules are fewer and simpler, and are also well known, and are aleviated and documented by guidelines like MISRA. Unsafe Rust has more rules, which seem underspecified and underdocumented, and also unstable. Known unknowns are preferable over unknown unknowns.
A quick unscientific count on cve.org counts ~86 race condition CVEs in the Linux kernel last year, so you might be overstating how well bug antennas work.
If the kernel was completely written in Rust, we could have a lot of unsafe places, and many Rust CVEs. It is hard to tell, and the comparison in theory should be made after the kernel is developed only by people lacking the C experience that made the current developers so able to reason about race conditions (also when they write Rust).
That's quite the double standard. You extrapolate from one single Rust bug, but insist that "it's hard to tell" and you need completely unrealistic levels of empirical evidence to draw conclusions from the reported C bugs...
Reminds me of this classic: "Beware Isolated Demands For Rigor" (https://slatestarcodex.com/2014/08/14/beware-isolated-demand...)
86 race conditions compared to what baseline? This is a bit meaningless without benchmarking against other kernels
It's 1 compared to 86, 86 is the baseline.
But you need to control for lines of code at the very least — otherwise you're comparing apples to oranges
I'm perfectly happy to say that it's not a very good way to make a comparison.
Then it would not be unscientific.
Yeah I mean I could also say "there are no CVEs written in PERL in the kernel ergo PERL is safer to write than Rust". Given there's close to zero .pl files in the kernel, I think we can all agree my assertion holds
That claim relies on an absurd "in the kernel" qualifier, making it difficult to agree with. Furthermore, your hypothesis is that "we all" agree with claims that rely on absurd conditions as a matter of course.
That is no base line. That is a comparison with no statistical value.
Tbh I thought that was clear when I used the phrase "unscientific".
> In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.
If that were truely the case, we wouldn’t need Rust now, would we!
Love it
(2) and (3) just don't seem to be the case empirically. One bug that was directly in a grep'able `unsafe` block is hardly evidence of these, whereas Google's study on Rust has demonstrated (far more rigorously imo) the opposite. I think anyone paying attention would have guessed that the first Rust CVE would be a race - it is notoriously hard to get locking/ race semantics correct in the kernel, not even the C programmers get it right, it's an extremely common bug class and I believe Linus has basically said something along the lines of "no one understands it" (paraphrasing).
(4) Again, this doesn't seem to be borne out empirically.
(5) I've seen plenty of patches to C code that are way more than a single line for the Linux kernel, but sure, maybe we grant that a bug fix in Rust requires more LOC changed? It'd be nice to see evidence. Is the concern here that this will delay patching? That seems unlikely.
It's not uncommon at all for patches to the C code in the kernel for "make this generally safe" are 1000s of lines of code, seeding things like a "length" value through code, and take years to complete. I don't think it's fair to compare these sorts of "make the abstraction safe" vs "add a single line check" fixes.
(6) Also not borne out. Literally billions spent on this.
> So, is Rust an interesting language for certain features it has? Yes. Is Rust a silver bullet? No.
Agreed. I'm tempted to say that virtually no one contests the latter lol
> So should Rust be "pushed" to others, hell no, and I suggest you to reply in the most firm way to people stressing you out to adopt Rust at all the costs.
I guess? You can write whatever you want however you want, but users who are convinced that Rust code will provide a better product will ask for it, and you can provide your reasoning (as SQLite does here, very well imo) as firm as you'd please I think.
edit: And to this other comment (I'm rate limited): https://news.ycombinator.com/item?id=46513428
> made the current developers so able to reason about race conditions (also when they write Rust).
Aha. What? Where'd you get this from? Definitely not from Linus, who has repeatedly stated that lock issues are extremely hard to detect ahead of time.
> we’ve tweaked all the in-kernel locking over decades [..] and even people who know what they are doing tend to get it wrong several times
https://lwn.net/Articles/808498/
Definitely one of MANY quotes and Linus is not alone.
Google have published a couple high-level Rust blog posts with many graphs and claims, but no raw data or proofs, so they haven’t demonstrated anything.
By now their claims keep popping up in Rust discussion threads without any critical evaluation, so this whole communication is better understood as a marketing effort and not a technical analysis.
> Google have published a couple high-level Rust blog posts with many graphs and claims, but no raw data or proofs, so they haven’t demonstrated anything.
Don't expect proofs from empirical data. What we have is evidence. Google has published far better evidence, in my view, than "we have this one CVE, here are a bunch of extrapolations".
> By now their claims keep popping up in Rust discussion threads without any critical evaluation,
Irrelevant to me unless you're claiming that I haven't critically evaluated the information for some reason.
Is there still pressure to use OOP? On Hacker News, at least, the trend seems to be moving in the opposite direction. There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns.
That’s not to say OOP advocacy has disappeared from HN. It still exists, but it no longer feels dominant or ascendant. If anything, it feels like a legacy viewpoint maintained by a sizable but aging contingent rather than a direction the community is moving toward.
Part of OOP’s staying power comes from what I’d call a cathartic trap. Procedural programming is intuitive and straightforward. OOP, by contrast, offers a new conceptual lens: objects, inheritance, polymorphism, and eventually design patterns. When someone internalizes this framework, there’s often a strong moment of “clicking” where complex software suddenly feels explainable and structured. That feeling of insight can be intoxicating. Design patterns, in particular, amplify this effect by making complexity feel principled and universally applicable.
But this catharsis is easy to confuse with effectiveness. The emotional satisfaction of understanding a system is orthogonal to whether that system actually produces better outcomes. I’ve seen a similar dynamic in religion, where the Bible’s dense symbolism and internal coherence produce a powerful sense of revelation once everything seems to “fit” together. The feeling is real, but it doesn’t validate the underlying model.
In practice, OOP often increases complexity and reduces modularity. This isn’t always obvious from inside the paradigm. It tends to become clear only after working seriously in other paradigms, where composition, data-oriented design, or functional approaches make the tradeoffs impossible to ignore.
In my circles, there is one part of OOP seen as positive: encapsulation. Everything else, specially inheritance and partly polymorphism are seen extremely negatively. The hype is over. BUT: I still hear more often as I would like, some manager stating “of course we will use C++, because is THE OOP language, and everybody knows OOP and UML are the only right way of doing software” this is an actual verbatim statement I had to listen 4 years ago.
I mostly agree with your assessment of how OOP is viewed today. In many technical circles, inheritance is seen as actively harmful, and polymorphism is at best tolerated and often misunderstood. The hype is largely gone. I’ve also heard the same managerial rhetoric you mention, where OOP and UML are treated as unquestionable defaults rather than design choices, so that part unfortunately still resonates.
Where I disagree is on encapsulation being the “good” part of OOP.
Encapsulation, as a general idea, is positive. Controlling boundaries, hiding representation, and enforcing invariants are all valuable. But encapsulation as realized through objects is where the deeper problem lies. Objects themselves are not modular, and the act of encapsulating a concept into an object breaks modularity at the moment the boundary is drawn.
When you encapsulate something in OOP, you permanently bind state and the methods that mutate that state into a single unit. That decision fixes the system’s decomposition early and hardens it. Behavior can no longer move independently of data. Any method that mutates state is forever tied to that object, its invariants, and its lifecycle. Reuse and recomposition now operate at the object level rather than the behavior level, which is a much coarser and more rigid unit of change.
This is the core issue. Encapsulation in OOP doesn’t just hide implementation details; it collapses multiple axes of change into one. Data representation, behavior, and control flow are fused together. As requirements evolve, those axes almost never evolve in lockstep, but the object boundary forces them to.
What makes this especially insidious is that the failure mode is slow and subtle. OOP systems don’t usually fail immediately. They degrade over time. As new requirements arrive, developers feel increasing resistance when trying to adapt the existing design. Changes start cutting across object boundaries. Workarounds appear. Indirection layers accumulate. Eventually the system is labeled as having “too much tech debt” or being the result of “poor early design decisions.”
But this framing misses the point. The design mistakes were not merely human error; they were largely inevitable given the abstraction. The original object model could not have anticipated future requirements, and because it was not modular enough to allow the design itself to evolve, every change compounded rigidity. The problem wasn’t that the design was wrong. It’s that it was forced to be fixed.
Polymorphism doesn’t fundamentally resolve this, and often reinforces it. While polymorphism itself is not inherently object-oriented, in OOP it is typically expressed through stateful objects and virtual dispatch. That keeps behavior anchored to object identity and mutation rather than allowing it to be recomposed freely as requirements shift.
The deeper requirement is that a system must be modular enough not just to extend behavior, but to change its own design as understanding improves. Object-based encapsulation works directly against this. It locks in assumptions early and makes architectural change progressively more expensive. By the time the limitations are obvious, the system is already entangled.
So while I agree that inheritance deserves much of the criticism, I think encapsulation via objects is the more fundamental problem. It’s not that encapsulation is bad in principle. It’s that object-based encapsulation produces systems that appear well-structured early on, but inevitably accumulate rigidity and hidden coupling over time. What people often call “tech debt” in OOP systems is frequently just the unavoidable artifact of an abstraction that was never modular enough to begin with. OOP was the tech debt.
The way forward is actually simple. Avoid mutation as much as possible. Use static methods (aka functions) as much as possible. Segregate IO and mutation into its own module separate from all other logic. Those rules are less of a cathartic paradigm shift then OOP and it takes another leap to see why doing these actually resolves most of the issues with OOP.
> Where I disagree is on encapsulation being the “good” part of OOP. Encapsulation, as a general idea, is positive. Controlling boundaries, hiding representation, and enforcing invariants are all valuable. But encapsulation as realized through objects is where the deeper problem lies. Objects themselves are not modular, and the act of encapsulating a concept into an object breaks modularity at the moment the boundary is drawn.
I’m personally with you here. Just in my circle they see it positively. But I agree with you: as long as it helps modularity, great, but also have many downsides that you describe very well.
Your last paragraph also perfectly aligned with my views. I think you are coming from a functional PoV, which luckily seems to have some more traction in the last decade or two. Sadly, before you say it, often are underline the parts of functional programming that are not the most useful you address here… but maybe, some day…
> There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns.
I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (types) and/or objects (instances) and bunch of methods specific to the class/object. In Rust, you extend that concept to almost all types including structs and enums.
> OOP, by contrast, offers a new conceptual lens: objects, inheritance, polymorphism, and eventually design patterns.
Rust doesn't have inheritance in the traditional sense, but most OOP languages prefer composition to data inheritance. Meanwhile, polymorphism, dynamic dispatch and design patterns all exist in Rust.
> I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (types) and/or objects (instances) and bunch of methods specific to the class/object. In Rust, you extend that concept to almost all types including structs and enums.
That’s not oop. Traits and generics are orthogonal to oop. It’s because oop is likely where you learned these concepts so you think the inception of these things is derived from oop.
What’s unique to oop is inheritance and encapsulation.
Design patterns isn’t unique to OOP either but there’s a strong cultural association with it. The term often involves strictly using encapsulated objects as the fundamental building block for each “pattern”.
The origin of the term “design patterns” was in fact established in context of OOP through the famous book and is often used exclusively to refer to OOP but the definition of the term itself is more broad.
It should not be strange that a tool which is better in every way and makes your code less buggy by default has its praises sung by most of the people who use it. It would be odd to go around saying 'electric drills are strangely and disproportionately pushed at Home Depot over the good old hand auger', and even if I don't work at your contracting company I'd be slightly unnerved about you working on my house.
The issue is that Rust proponents automatically assume that if you write enough C code, there will be memory related bugs.
In reality, this is not the case. Bad code is the result of bad developers. Id rather have someone writing C code that understands how memory bugs happen rather than a Rust developer thinking that the compiler is going to take care of everything for them.
I’ve heard this analogy used to justify firing developers for not using GenAI: a cabinet maker who doesn’t use power tools shouldn’t be working as a cabinet maker.
If only programming languages (or GenAI) were tools like hammers and augers and drills.
Even then the cabinets you see that come out of shops that only use hand tools are some of the most sturdy, beautiful, and long lasting pieces that become the antiques. They use fewer cuts, less glue, avoid using nails and screws where a proper joint will do, etc.
Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so. Antiques suck as often as they don't, and moreover you are only seeing the ones that survived without a base rate to compare it to; they succeeded in spite of power tools, but power tools would have made the same object better.
Comparing it to AI makes no sense. Invoking it is supposed to bring to mind the fact that it's worse in well-known ways, but then the statement 'better in every way' no longer applies. Using Rust passively improves the engineering quality compared to using anything else, unlike AI which sacrifices engineering quality for iteration speed.
> Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so.
No disrespect intended, but your criticism of the analogy reveals that you are speaking from assumptions, but not knowledge, about furniture construction.
In fact, less glue, and fewer fasteners (i.e. design that leverages the strength of the materials), is exactly how quality furniture is made more sturdy.
There was an interesting video on YT where an engineer from a fastener company joined a carpenter to compare their products with traditional joints.
The traditional joints held up very well and even beat the engineered connectors in some cases. Additionally one must be careful with screws and fasteners: if they’re not used according to spec, they may be significantly weaker than expected. The presented screws had to be driven in diagonally from multiple positions to reach the specified strength; driving them straight in, as the average DIYer would, would have resulted in a weak joint.
Glue is typically used in traditional joinery, so less glue would actually have a negative effect.
> Glue is typically used in traditional joinery, so less glue would actually have a negative effect.
And a lot of traditional joinery is about keeping the carcase sufficiently together even after the hide glue completely breaks down so that it can be repaired.
Modern glues allow you to use a lot less complicated joinery.
The thing is that more than a few people disagree that it is better in every way.
The topic seems to be native programming languages -- I don't think any of the languages concerned are "better in every way" for every possible coding problem. Many will rightfully choose Fortran over Rust for their application -- knowing full well their choice is far away from "better in every way".
When writing code meant to last, you need a language that’s portable across compilers and through time. C has demonstrated both. Fortran 77 and 90 were portable across compilers, but are now at risk from breaking changes, and later versions are not very portable across compilers.
Bad analogy.
If the alternative has drawbacks (they always do) or is not as well known by the team, it's perfecly fine to keep using the tool you know if it is working for you.
People who incessantly try to evangelise their tool/belief/preferences to others are often seen as unpleasant to say the least and they often achieve the opposite effect of what they seek.
of course there are drawbacks to power tools. you could run out of battery for example and now its useless.
but everyone with a brain knows the costs are worth the benefits.
I was talking in general if that escaped you. Hence "beliefs/preferences" and not only tools.
And when it comes to programming languages, it's not as clear cut. As exemplified by the article.
So the power tools is a poor analogy.
I'm very much into Rust but this article is precisely about the fact that Rust is not "better in every way"...
This article was written nine years ago, when Rust 1.0 was two years old, by an author who spent a small (but nonzero) amount of time evaluating Rust.
This page was last updated on 2025-05-09 15:56:17Z
Given the author's misunderstanding of what Rust provides, the most charitable interpretation is that they haven't updated the parts discussing Rust since 2017. If they had, it would reflect more poorly on them.
The most charitable interpretation of this is that the Reddit mods should stick to Reddit. If they had, this wouldn't have reflected so poorly on them.
Not true, the page is updated every now and again.
Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages.
The US government recently called on everyone to stop using them and move to memory-safe languages.
Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those.
Edit: Typos and to make the point that I'm not necessarily defending C, just acknowledging it's place. I haven't written a significant amount of C in over 2 decades, probably, aside from microcontroller C.
C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong.
C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its uses but it will fuck you up if you do not use industrial-grade PPE.
Stop using C if you can. Stop arguing other people should use it. There have always been alternatives and the opportunity cost of ecosystems continuing to invest in C has massive externalized costs for the entire industry and society as a whole.
> in exactly the same way
C is not known to the state of California to cause cancer.
Not yet
Asbestos causes mesothelioma and gruesome death. C does not. Be serious.
When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.
> When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.
And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language.
If it was as bad as you make out, we'd have many many many occurrences of this starting in the 80s. We don't.
https://en.wikipedia.org/wiki/Therac-25#Root_causes
Stop spreading FUD.
But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows.
For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equally viable choices. And if we are talking about something that needs to be outright safety-critical, Ada and SPARK should definitely be in the debate.
However, all of that doesn't override the right of projects to decide on what language they believe is best for them or what strategies concerning safety that they wish to pursue.
Pushed != interested in/talked about. People really like to mash together a bunch of random individuals into a single actor/agenda.
Golang is not playing in the same niche as C/C++/Rust/Zig, but we have had countless memory safe languages that are indeed a good fit for many uses where C was previously used.
Depends on the point of view, for Reversec, it does.
https://reversec.com/usb-armory
> In addition to native support for standard operating environments, such as Linux distributions, the USB armory is directly supported by TamaGo, an Reversec Foundry developed framework that provides execution of unencumbered Go applications on bare metal ARM® System-on-Chip (SoC) processors.
> Golang, etc... who could be discussed and are equally viable choices.
Golang is not 100% zero cost close to metal abstraction. You could add Java and .NET too, but they are not replacement for C obviously.
Now imagine if every CVE was actually fixed.
How would the three letter agencies then spy on people and deliver their payloads on various target devices?
The governments around the world really need the security holes to exist despite what they say.
> The US government recently called on everyone to stop using them and move to memory-safe languages.
The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al.
Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m a pop.
Those toolchains do not exist for rust. I am only aware of these toolchains existing for C, and old C at that.
Hell, rust doesn't even have a formal spec, which is a bit of a roadblock.
The DOD also made the Waterfall method THE standard software development process.
> The DOD also made the Waterfall method THE standard software development process.
I'm sure they also made a few bad decisions too :-P
You mean, "DOW"
Department of Waterfall?
Department of War.
That is not the official name, and it is highly unlikely that it ever will be in the future.
It's worth pointing out the Department of Defense was named the Department of War for over 150 years, up until 1947.
https://en.wikipedia.org/wiki/United_States_Department_of_Wa...
True, but it required congressional approval to change the name then, and it would now as well.
This congress is not likely to approve it. And the next congress, even less so.
That said, "ever" is probably too strong. There's a window wherein the chaos which is currently being actively created by the US will develop to an extent that compels the US (or is sold to US voters as a necessary step) to adopt a foreign policy where it would be the more appropriate title. And if the adults can't manage that with charismatic leadership in the next election cycle or two, we could be right back here again, with quasi-legitimate geopolitical justification for the sort of big-stick wagging we see today.
I honestly think this is the goal, and I'm not sure the American people are up to the challenge of preventing it.
In the UK, War Office --> Ministry of Defence, in the 60s I think.
No. I don't.
https://blog.pictor.us/rust-is-do-178-certifiable/
> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process.
I think your link agrees with me, actually.
https://ferrocene.dev/
DO-178C isn’t there yet, but I believe I heard that it’s coming. In general, Ferrous Systems works with customer demand, which has been more automotive to start.
I believe is may come, that would be really neat.
Actually having it happen, someone is going to be out 10-30 million bucks. And again for each new compiler version.
Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.
26262 is a lot less expensive than DO-178.
> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.
“Can meet” vs “has met” is the entire difference.
Clearly C “can meet” and “has met” DO-178. So, I posit that more languages than C “can meet” this standard.
Proving it is the very hard, very expensive part.
Oh, and whatever version of the rust compiler that gets certified will be locked down as the only certified toolchain. No more compiler updates every 6 weeks. Unless you go though the whole process again.
Ferrocene has qualified Rust 1.68.2, 1.76.0, 1.79.0, 1.81.0, 1.83.0, 1.86.0, 1.87.0, 1.89.0, with 1.91.0 in the upcoming release.
It's not every six weeks, but it's far faster than once every three years.
I mostly agree, but the OOP is most definitely not in vogue on HN for the past decade at least, arguably far longer than that (think Rust pre-1.0, Go 1.0 times).
Absolutely. Our thought leaders have been pushing functional programming for a long time now.
Is it possible to have an OOP language which is also functional? Or is it impossible without imperative paradigms?
There's some muddiness in the terminology here -- OOP is really a design style, and "OOP languages" are generally imperative languages that have sematics that encourage OOP design. It is very possible, even encouraged, to represent state as "Objects" in many functional languages; it's just not really enforced by the language itself.
A good example of this are the object systems in Scheme and Common Lisp (which are less strictly Functional (note the capital F in that word) then something like Haskell).
I asked mainly because of the terminology. I read the primer of how to code OOP in plain C about a decade ago, so I knew that the paradigm definitely can be applied to “non OOP languages”, but I wasn’t sure whether the term “functional programming” allows this or not for some obscure academic reasons. How I coded when I encountered Haskell the first time, I would say it’s definitely possible, but I think, there are some features in Haskell which can be used to break pure functional programming, and if those are not considered FP, then who knows. But I used Haskell the last time a few years ago, so my memory is definitely not clear.
Gilad Bracha talks about how they're not mutually exclusive concepts, and I mostly agree (OOP can have tailcall recursion and first order functions for example). But, the philosophy seems very different: functional programming is "standing above" the data, where you have visibility at all times, and do transformations on the data. OOP is much more about encapsulation, where you "send a message" to an object, and it does its own thing. So you could totally write OOP code where you provide some core data structures that you run operations on, but in practice encapsulation encourages hiding internal data.
Though on further thought, may be this isn't FP vs OOP, because C has a similar approach of "standing above", and C is the hallmark imperative language.
Scala has been that for decades. They are not opposing paradigms. (In fact, mutability has a few edge cases that doesn't play nicely with OOP to begin with)
I mean Scala kind of does both (and then some). I'm not sure I would call it an OOP language, but you can sure write the same gross Java enterprise bloatware in Scala too if you want.
> Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig)
You won't find easily Zig programmers that want you to use Zig at all costs, or that believe it's a moral imperative that you do. It's just antithetical to the whole concept of Zig.
The worst that can happen is that Zig programmers want C projects to have a build.zig so they can cross-compile the project trivially, since that's usually not a thing C/C++ build scripts tend to offer. And even then, we have https://github.com/allyourcodebase/ so that Zig users can get their build.zig scripts without annoying project maintainers.
Not always, but sometimes, new things are just better.
One example is null-- a billion dollar mistake as Tony Hoare called it. A Maybe type with exhaustive pattern matching is so dramatically better, it can be worth switching just for that feature alone.
This "new" thing could have grandkids now :D
ML is not some new development, it just took this long to get some of its ideas mainstream.
I get asked this all the time regarding TidesDB. Why didn’t you choose Rust? Well.
Yeah this super common. Great comment.
OOP is pretty much has-been.
Value semantics is the hot thing now I'd say.
That is why all major operating systems GUIs don't use it, yep.
We (especially management) are trained to always want shiny new thing. Also it's an easy line of dialogue.
Funny how managers get blamed for both wanting new things and for not wanting new things. In the Java 6 days every dev wanted to upgrade to 7 and later 8… but the meme was that their manager wouldn’t ever let them.
Every serious project should be able to justify its choice of tools. "Because I feel like it" is fine for hobby projects or open-source passion projects, but production-worthy software should have reasoning behind its choices. That reasoning can be something like "it's most effective for us because we know it better" but it should be a deliberate, measured choice.
SQLite is an example of an extremely high quality software project. That encompasses not only the quality of the software itself, but the project management around it. That includes explaining various design choices, and this document explaining the choice of language is just one of many such explanations.
Indeed, indeed.
> Every project and programmer shouldn't feel they have to justify their choice not to use Rust
Maybe writing about it was taken as an opportunity to clarify their own thinking about the topic?
Yeah, results are what matters. SQLite's process seems to produce solid bug-free results.
My only complaint would be that there's many SQL features I want to use which aren't supported. Surely some part of that is deliberately restricted scope, but some might also be dev velocity issues.
DuckDB (C++) can be used like an SQLite with more SQL features, but it's also a lot buggier. Segfaults from your database are not what you want.
So still hoping for some alternative to come along (or maybe I'll need to write it myself)
What isn't supported? After window functions were added, what else is missing?
The ones that come to mind immediately are more ALTER statements (especially adding non-virtual columns), DATE, TIME, and TIMESTAMP types and their associated functions, and ARRAY types. Although I don't wish to disparage SQLite, they do support a lot of features. Just that I constantly run into the ones they don't, with my use cases.
And beyond standard SQL, stuff like hashmap/bloom filter/vector indices, nearest neighbor search, etc...
> a bit less in recent years, to use OOP.
That’s an understatement.
>justify their choice not to use Rust (or Zig)
It's disingenuous to lump them together. It is the former that does the whole toxic, pushy advocacy routine.
OOP was always debatable, but with the rise of AI agents I'd go so far as to say it's objectively bad now. AI is much better at reasoning about pure function grammars than imperative classes with inheritance; abstractions that aren't airtight are bug factories.
I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old that is already so well tested and accessible on all sorts of obscure platforms, it makes little sense to rewrite, and the likely result would be more bugs, not less, at least in the short term.
All that said, some have found reasons to rewrite in Rust, and are currently working on that: https://turso.tech/blog/introducing-limbo-a-complete-rewrite...
Limbo and Turso's other tools seem interesting, but the listed limitation of “no multi process database access” is pretty huge.
If you don’t need that, then great—Turso/Limbo might be for you! But there are a ton of use cases out there that rely on SQLite for simultaneous multiprocess access. And I’m not even talking about things that use it from forking servers or for coordination (though those are surprisingly common as well)—instead, lots of processes that use SQLite 99.9% of the time from one process still need it to be multiprocess-authoritative for e.g. data exports, “can I open two copies of an app far enough to get a ‘one is already running’ error?”-type use cases, extensions/plugins, maintenance scripts, etc. not having to worry about cross-process lock files thanks to SQLite is a significant benefit for those.
This seems like the way. Why would Rustaceans bother to "argue their case" before an unwilling board if they can just do the rewrite themselves? Maybe it will succeed, maybe not, but you don't need SQLLite's blessing to test the proposition.
My hunch is that those aren't very serious Rustaceans. Even the original language developers developed Rust to interoperate with C as much as possible, and they often used to discourage the rewrite evangelism. If you are a serious Rustacean, you'd probably be worried about the safety tradeoffs in rewriting in Rust. As your parent commenter points out, a mature C codebase is already tested so well that rewriting it in Rust is likely to introduce more bugs - non-memory-safety bugs that are nevertheless serious enough. That's why I and many other Rustaceans don't recommend it. In fact, some Rustaceans even advise others to not rewrite Fortran 90 code (in order to preserve the performance advantage) and instead recommend integrating it with Rust using FFI.
Honestly, instead of porting SQLite to Rust, IMO, it makes more sense to make an easier-to-use embedded database (in Rust) first.
Is SQLite hard to use?
Oh, SQLite (as a database) is easy compared to a client-server database, or an "embedded" database that runs in a separate process.
The issue is more of the object-relational impedance mismatch that happens when using any SQL database: ORMs can be slow / bloated, and hand-written SQL is time consuming.
I shipped a product on SQLite, and SQLite certainly lived up to its promise. What would have been more helpful was if it could index structured objects instead of rows, and serialize / deserialize the whole object. People are doing this now by putting JSON into SQLite. (Our competitors did it when I looked into their SQLite database.)
I agree. We will see how Limbo turns out :)
I forgot what Limbo was, Rust rewrite of SQLite, now called Turso.
https://github.com/tursodatabase/turso
I could see it being useful for pure Rust projects once its completed. I mean in Java / Kotlin land, I prefer to use H2 in some cases over SQLite since its native to the platform and H2 is kind of nice altogether. I could see myself only using this in Rust in place of SQLite if its easy to integrate and use on the fly.
The equivalent "platform native" database for Clojure is Datalevin [0], which has a Datomic-like Datalog query language with SQLite-style semantics. Recommended.
[0] https://github.com/juji-io/datalevin
The final comments in this text seem sobering and indicate an openness to change. I worked recently on a project to migrate RediSearch to Rust, and this was partially motivated by a decent number of recent CVEs. If SQLite doesn't have this problem, then there needs to be some other strong argument for moving to Rust.
I also think it's important to have really solid understandings (which can take a few decades I imagine) to understand the bounds of what Rust is good at. For example, I personally think it's unclear how good Rust can be for GUI applications.
It's nice that they don't dismiss out-of-hand the idea of using a language other than C (the conclusion is far less dogmatic than the editorialized title here suggests (the actual title of the page being "Why Is SQLite Coded In C?")). But let's be clear that the stability and "boringness" that C currently enjoys took literal decades to realize (pre-ANSI C was a wild-west shitshow that makes pre-ECMA Javascript look tame by comparison), and giving the same leeway to other languages probably doesn't suggest using e.g. Rust until at least 2040 or so.
Something like Ada/SPARK might be a better choice for something like SQLite as well.
> Rust needs a mechanism to recover gracefully from OOM errors.
Linus also brought this up: https://lkml.org/lkml/2021/4/14/1099
None of Rust's language features allocate; not arrays, not closures, not iterators. Everything is stack-allocated by default. Rust code doesn't malloc unless you use a library that calls malloc; in other words, exactly like C. Rust fully supports turning off the parts of the standard library that perform allocation, and this is precisely what embedded code and the Linux kernel does. So Rust already gives you full control.
well, as an example, Vec::push doesn't have a way to report allocation failure. it will just panic, which is not acceptable in the kernel.
Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking for allocation errors, as well as several nightly functions coming down the pipe in the same vein (e.g. Vec::try_with_capacity, Vec::push_within_capacity).
Talking as a long time C++ programmer. I really don't get this mind set.
First off allocation failure (typically indicated by bad_alloc exception in C++ code, or nullptr in C style code) does not mean that the system (or even the process) as a whole is out of memory.
It just means that this particular allocator could not satisfy the allocation request. The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations.
Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure?
A normal structure for a program is to catch these exceptions at a higher level in the stack close to some logical entry point, such as thread entry point, UI action handler etc. where they can be understood and possibly shown to the user or logged or whatever. It shouldn't really matter if the failure is about failing to allocate socket or failing to allocate memory.
You could make the case that if the system is out of memory the exception propagation itself is going to fail. Maybe..but IMHO on the code path that is taken when stack is unwound due to exception you should only release resources not allocate more anyway.
In rust you could use multiple allocators at the same time. Allocation failure handled by allocator, converting panic to some useful behavior. This logic is observable in WASM, as there are OOMs all the time, which handled transparently to application code
So I assume there is no real blockers as people in this tread assume, this is just not a conventional behavior, ad hoc, so we need to wait and well defined stable OOM handlers will appear
>does not mean that the system is out of memory. >"The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations."
Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean.
>Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure.
Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development.
"Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean."
As I just explained an allocator can have its own limits.
A process can have multiple allocators. There's no direct logical step that says that because some allocator some failed some allocation, the process itself cannot allocate more ever.
"Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development."
The parent comment is talking about over commitment and OOM as if these are situations that are completely out of the programs control. They aren't.
> Are we playing word games here?
No. A single process can have several allocators, switch between them, or use temporary low limits to enforce some kind of safety. None of that has any relation to your system running out of memory.
You won't see any of that in a desktop or a server. In fact, I haven't seen people even discuss that in decades. But it exists, and there are real reasons to use it.
I am not well-versed in this area but have a doubt - when the OS sends a SIGKILL to a process because it has run of memory for it how can the program catch that before it is killed and deal with it "gracefully"? Does C provide any mechanism to deal with such scenario?
There are several levels here.
In your C++ (or C) program you have one (or more) allocators. These are just pieces of code that juggle blocks of memory into smaller chunks for the program to use. Typically the allocators get their memory from the OS in pages using some OS system call such as sbrk or mmap.
For the sake of argument, let's say I write an allocator that has a limit of 2MiB, while my system has 64Gib or RAM. The allocator can then fail some request when it's internal 2MiB has been exhausted. In C world it'd return a nullptr. In C++ world it would normally throw bad_alloc.
If this happens does this mean the process is out of memory? Or the system is out of memory? No, it doesn't.
That being said where things get murky is because there are allocators that in the absence of limits will just map more and more pages from the OS. The OS can "overcommit" which is to say it gives out more pages than can actually fit into the available physical memory (after taking into account what the OS itself uses etc). And when the overall system memory demand grows too high it will just kill some arbitrary process. On Linux this is the infamous OOM killer that uses the "niceness" score to determine what to kill.
And yes, for the OOM killer there's very little you can do.
But an allocation failure (nullptr or bad_alloc) does not mean OOM condition is happening in the system.
None of that matters: what is your application going to do if it tries to allocate 3mb of data from your 2mb allocator?
This is the far more meaningful part of the original comment:
> and furthermore most code is not in a position to do anything other than crash in an OOM scenario
Given that (unlike a language such as Zig) Rust doesn’t use a variety of different allocator types within a given system, choosing to reliably panic with a reasonable message and stack/trace is a very reasonable mindset to have.
Since we're talking about SQLite, by far the most memory it allocates is for the page cache.
If some allocation fails, the error bubbles up until a safe place, where some pages can be dropped from the cache, and the operation that failed can be tried again.
All this requires is that bubbling up this specific error condition doesn't allocate. Which SQLite purportedly tests.
I'll note that this is not entirely dissimilar to a system where an allocation that can't be immediately satisfied triggers a full garbage collection cycle before an OOM is raised (and where some data might be held through soft/weak pointers and dropped under pressure), just implemented in library code.
Sure, and this is completely sensible to do in a library.
But that’s not the point: what can most applications do when SQLite tells them that it encountered a memory error and couldn’t complete the transaction?
Abort and report an error to the user. In a CLI this would be a panic/abort, and in a service that would usually be implemented as a panic handler (which also catches other errors) that attempts to return an error response.
In this context, who cares if it’s an OOM error or another fatal exception? The outcome is the same.
Of course that’s not universal, but it covers 99% of use cases.
The topic is whether Rust should be used to re-implement SQLite.
If SQLite fails to allocate memory for a string or blob, it bubbles up the error, frees some data, and maybe tries again.
Your app may be "hopeless" if the error bubbles up all the way to it, that's your choice, but SQLite may have already handled the error internally, retried, and given your answer without you noticing.
Or it may at least have rolled back your transaction cleanly, instead of immediately crashing at the point of the failed allocation. And although crashing should not corrupt your database, a clean rollback is much faster to recover from, even if your app then decides to crash.
Your app, e.g. an HTTP server, might decide to drop the request, maybe close that SQLite connection, and stay alive to handle other ongoing and new requests.
SQLite wants to be programmed in a language were a failed allocation doesn't crash, and unlike most other code, SQLite is actually tested for how it behaves when malloc fails.
In C++ it will throw an exception which you can catch, and then gracefully report that the operation exceeded limits and/or perform some fallback.
Historically, a lot of C code fails to handle memory allocation failure properly because checking malloc etc for null result is too much work — C code tends to calm that a lot.
Bjarne Stroustrup added exceptions to C++ in part so that you could write programs that easily recover when memory allocation fails - that was the original motivation for exceptions.
In this one way, rust is a step backwards towards C. I hope that rust comes up with a better story around this, because in some applications it does matter.
I may be getting SIGKILL and SIGABORT mixed up, but one of them is not sent to the process, rather it's sent to the OS.
If it were any other way then processes could ignore signals and just make themselves permanent, like Maduro or Putin.
> most code is not in a position to do anything other than crash in an OOM scenario.
That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way.
You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.
Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
It's possible. But very very few projects do.
I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.
> I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.
It may not be as simple as "that's our policy". I worked at one place (embedded C++ code, 2018) that simply reset the device every 24h because they never managed to track down all the leaks.
Finding memory leaks in C++ is a non-trivial and time-consuming task. It gets easier if your project doesn't use exceptions, but it's still very difficult.
In my experience that is usually the result of years and years of accumulation of shit code. The results is thousands of leaks. That makes detection of incremental leaks much more difficult. If you start with clean code and use ASAN or Valgrind then leak detection is not difficult.
Use Valgrind? Or are we talking projects that have become far too big for their own good, cause leaks aren't hard at all to find with the right tools and a bit of profiling... now crossing thread boundaries and weird dynamic programming tricks maybe, but thats a very different case and not really refecting on C++ itself, would likely trip up a GC lang as well.
> Use Valgrind?
Was not available for that specific device, but even with Valgrind and similar tools, you are still going to run into weird destructor issues with inheritance.
There are many possible combinations of virtual, non-virtual, base-class, derived-class, constructors and destructors; some of them will indeed cause a memory leak, and are allowed to by the standard.
> Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
What are you talking about? Every allocation must be checked at the point of allocation, which is "the default"
If you write non-idiomatically, then sure, in other languages you can jump through a couple of hoops and check every allocation, but that's not the default.
The default in C is to return an error when allocation fails.
The default in C++, Rust, etc is to throw an exception. The idiomatic way in C++, etc is to not handle that exception.
> Every allocation must be checked at the point of allocation, which is "the default"
C doesn't force you to check the allocation at all. The default behavior is to simply invoke undefined behavior the first time you use the returned allocation if it failed.
In practice I've found most people write their own wrappers around malloc that at least crash - for example: https://docs.gtk.org/glib/memory.html
PS. The current default in rust to print something and then abort the program, not panic (i.e. not throw an exception). Though the standard library reserves the right to change that to a panic in the future.
> C doesn't force you to check the allocation at all.
No one ever claimed it did; I said, and still do, that the in C, at any rate, the default is to check the returned value from memory allocations.
And, that is true.
The default in other language is not to recover.
> > C doesn't force you to check the allocation at all.
> No one ever claimed it did;
You specifically said
> Every allocation must be checked at the point of allocation
...
> the default is to check the returned value from memory allocations.
Default has a meaning, and it's what happens if you don't explicitly choose to do something else.
In libc - this is to invoke undefined behavior if the user uses the allocation.
In glib - the library that underpins half the linux desktop - this is to crash. This is an approach I've seen elsewhere as well to the point where I'm comfortable calling it "default" in the sense that people change their default behavior to it.
Nowhere that I've ever seen, in C, is it to make the user handle the error. I assume there are projects with santizers that do do that, I haven't worked on them, and they certainly don't make up the majority.
> Default has a meaning, and it's what happens if you don't explicitly choose to do something else.
It also has the meaning of doing the common thing: https://www.merriam-webster.com/dictionary/default
> : a selection made usually automatically or without active consideration
See that "without active consideration" there? The default usage of malloc includes, whether you want to acknowledge it or not, checking the returned value.
C doesn't have anything done automatically, so I am wondering why you would choose to think that by "default" one would mean that something automatically gets done.
I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Of course things do happen automatically all the time in C, like bumping the stack pointer (another case of unhandled OOM) and decrementing it after the fact. And pushing return addresses - and returning at the end of functions. And so on.
"Ubiquitous" is a different word than default, checking the return code of malloc isn't even that. As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc. And it doesn't reliably check the return code. For example: https://github.com/PipeWire/pipewire/blob/6ed964546586e809f7...
And again, this isn't cherry picked, this is just "the last popular open source C code base I've looked at". This is the common case in C. Either you wrap malloc to crash, or you just accept undefined behavior if malloc fails. It is the rare project that doesn't do one of those two.
> I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code.
Right. But this is what you initially responded to:
> You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C.
How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures?
> As an example - I've been having some issues with pipewire recently (unrelated) and happen to know it uses an unwrapped malloc.
Correct. That does not mean that the default way of writing allocation in C is anything other than what I said.
Do programmers make mistakes? Sure. But that's not what asked - what was asked is how do you handle memory errors gracefully, and I pointed out that, in idiomatic C, handling memory errors gracefully is the default way of handling memory errors.
That is not the case for other languages.
> How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures?
I think you might want to reread the line you quoted directly above this,
That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C".
This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction of projects allocator wrappers). Not "handling OOM gracefully" - i.e. handling OOM errors.
> I think you might want to reread the line you quoted directly above this,
I am reading exactly what I said:
> You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C.
How is it possible to read that as anything other than "That Way Of Writing Code Is The Default Way In C"?
Are you saying that checking the result of malloc (and others) is not the default way of allocating memory?
> Are you saying that checking the result of malloc (and others) is not the default way of allocating memory?
In C - yes. I've said that repeatedly now...
>> Are you saying that checking the result of malloc (and others) is not the default way of allocating memory?
> In C - yes. I've said that repeatedly now...
Well, that's just not true. The instances of unchecked allocations are both few and far between, *and* treated as bugs when reported :-/
Maybe you should program in a language for a little bit before forming an opinion on it :-/
I have programmed in C plenty. Your assertion that unchecked allocations are few and far between is simply entirely incorrect. That they are treated as bugs when reported is incorrect in most C software.
For good reason. Most C software is not designed to run in a situation where malloc might fail.
I, unlike you, have provided evidence of this by pointing to major pieces of the linux desktop that do not do so.
From the parent comment:
because of OS-level overcommit, which is nearly always a good thing
It doesn't matter about the language you are writing in, because your OS can tell you that the allocation succeeded, but when you come to use it, only then do you find out that the memory isn't there.
Of course it matters, because you (the system admin) can tell your OS not to do that. Which is only helpful if your app knows how to handle the case. Most don't, so overcommit, in general, makes sense.
You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory...
It's a place where windows legitimately is better than linux.
> You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory...
Sure, but ... what does that have to do with this thread? Using `mmap` is not the same as using `malloc` and friends.
If you turn off overcommit, malloc will return NULL on failure to allocate. If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
> If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
You misunderstand, you specifically request mmap to ignore overcommit, and it doesn't, not does.
What it has to do with this thread is it makes turning off overcommit on linux an exceptionally unpalatable option because it makes a lot of correct software incorrect in an unfixable manner.
Zig puts OOM handling much more front and center than C. In C, you can handle OOM but it's easy to ignore NULL checks on mallocs &co because they almost never happen.
In Zig you must handle it. Even if handling means "don't care, panic", you have to spell that out.
It's also really ergonomic with `errdefer` and `try`.
> That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way.
No, this is wishful thinking. While plenty of programs out the are in the business of maintaining caches that could be optimistically evicted in order to proceed in low-memory situations, the vast majority of programs are not caching anything. If they're out of memory, they just can't proceed.
I used to think this way many years ago, then I saw my own code in production hit OOM errors and manage to recover, and even log what was happening so I could read about it later.
After those experiences I agree with the sibling comment that calls your position "bullshit". I think people come to your conclusion when they haven't experienced a system that can handle it, so they're biased to think it's impossible to do. Since being able to handle it is not the default in so many languages and one very prominent OS, fewer people understand it is possible.
I think this is bullshit. If you are running out of memory, you can, for example, choose to stop accepting more work ("backpressure"). I am always advocating for Rust, but this is one thing I really disagree on. I think Zig gets this right.
Now you need to ensure that your entire error path does not allocate or you have to deal with allocation errors in the error path as well.
Trying to apply backpressure from memory allocation failures which can appear anywhere completely disconnected from their source rather than capping the current in memory set seems like an incredibly hard path to make work reliably.
In Zig's case, the entire stdlib never allocates on failure, and most libraries follow the same pattern. The philosophy of Zig is allocation/creation can fail, but freeing/destroying must never fail. It's caused me to be really thoughtful with how I design my data structures, and often made me use better ways of representing metadata.
How do you log or tell the world about the state of the program without allocating?
Well if you've hit OOM, you're kinda screwed anyways. But, if you allocate a ring buffer at the beginning, you can always do a best attempt write.
Why screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?
Maybe screwed was too strong of a term. In the scenario above, they wanted to log on resource cleanup, but that makes resource cleanup potentially fallible. The Zig philosophy is that cleanup must never fail, so having cleanup be fallible goes against that.
I was suggesting (though in retrospect not clearly) that logging should use a ring buffer instead of allocation, in order to make logging on cleanup a guaranteed best effort operation. You're right that you can recover from OOM, but logging OOM with an allocator is pretty self-defeating.
You need to apply backpressure before you hit memory limits, not after.
If you’re OOM your application is in a pretty unrecoverable state. Theoretically possible, practically not.
If you allocate a relatively big chunk of memory for each unit of work, and at some point your allocation fails, you can just drop that unit of work. What is not practical?
I think in that case overcommit will happily say the allocation worked. Unless you also zero the entire chunk of memory and then get OOM killed on the write.
I suppose you can try to reliable target "seriously wild allocation fails" without leaving too much memory on the table.
https://www.kernel.org/doc/Documentation/vm/overcommit-accou...Running in an environent without overcommit would allow you to handle it gracefully though, although bringing its own zoo of nasty footguns.
See this recent discussion on what can happen when turning off overcommit:
https://news.ycombinator.com/item?id=46300411
> See this recent discussion on what can happen when turning off overcommit:
What are you referring to specifically? Overcommit is only (presumably) useful if you are using Linux as a desktop OS.
Good grief all kinds of ways. Practically all the same countless possible paths as those that require allocating.
You don't have to allocate to print to stdout if that's what you're asking.
And then whatever thing that is collecting and forwarding(if applicable) the logs needs to be entirely allocation free?
It just needs to have whatever memory it needs statically allocated.
> Now you need to ensure that your entire error path does not allocate or you have to deal with allocation errors in the error path as well
And that is usually not too difficult in C (in my experience), where allocation is explicit.
In C++, on the other hand, this quickly gets hairy IMO.
That's why you don't use std in this case. You limit yourself to things defined in core.
That seems like an enormous question. Is anyone working on it?
There's experimental/nightly support for things like: `push_within_capacity()` which is a more manual way (user-space code would have to handle the return code and then increase the capacity manually if required) of trying to handle that situation.
And of course the kernel - which doesn't even use Rust's Vec but has its own entire allocator library because it is the kernel - likewise provides
https://rust.docs.kernel.org/next/kernel/alloc/kvec/struct.V...
Vec::push_within_capacity is a nice API to confront the reality of running out of memory. "Clever" ideas that don't actually work are obviously ineffective once we see this API. We need to do something with this T, we can't just say "Somebody else should ensure I have room to store it" because it's too late now. Here's your T back, there was no more space.
Yeah, it's not ideal that the standard library currently has blind spots around allocation and I hope those get resolved eventually, but if you're rolling everything from scratch in C anyway then it's not much of a stretch to likewise roll your own Rust primitives in places where the included batteries don't work for you.
you understand that stack allocation can OOM too?
Can C gracefully recover from running out of stack space?
Depends on your definition of graceful but the C standard doesn't preclude handling it and there's POSIX interfaces such as sigaltstack / sigsetjmp etc that fit and indeed some code like language runtimes use this to react to stack exhaustion (having first set up guard pages etc).
Or in short: no, C is no better than Rust at gracefully recovering from stack overflow, either in theory or in practice.
Yep, the “split” between core and std is brilliant. It enables so many usecases: one example I ran into recently is compiling Rust (core) to eBPF.
Great to know!
Off topic: This CSS improves the usability of that page:
Should be:
He's not wrong, but needs to clean own house a bit.
> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language.
But I don't see Rust ever going in such a direction. It seems fundamentally opposed to Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree.
The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not ever have to update your 2015 edition code for anything.
Sounds like textbook bc break. I'm curious as to what you think a bc break would look like?
Consider python2 and python3, you don't need to update your python2 code really, you can just use the python2 interpreter.
No you’re misunderstanding the ecosystem. Rust 2024 code can call 2021 code without issue (and vice versa I think although could be wrong on the vice versa). So you can progressively update code of individual components as you want or not at all and still continue using it just fine in new code using later editions. Thats the very definition of back compat, something you really really shouldn’t do with C++ (every file should be compiled with the same language version target although practically that may be less of an issue depending on the specific stdlib implementation and if they break ABI)
There’s also automated migration tools to convert 2021 code to 2024. It might fail on some translations but generally it’s pretty automatic.
So huge difference both in the migration mechanism and the bc story.
As long as the compiler is new enough to handle 2024 code (i.e., you're not using a 2021 version of the compiler itself), 2021 code can use 2024 code.
Right. A good mental model would be to imagine every crate of Rust source has an associated Edition and there's a sort of "pre-processing" step where we translate that into the latest version of Rust seamlessly, preserving its exact meaning.
So e.g. 2018 Edition said r# at the start of an identifier now marks a "raw" identifier. Keywords promise never to start this way, so r#foo is the same as foo but r#foo even works if some lunatic makes foo a keyword whereas just foo would become a keyword if that happened. As a result if you write
... in Rust 1.0 that translator treats it exactly as though you'd written ... in a modern Rust edition because these days the keyword async exists.The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue.
Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't break your dependents either -unless they don't have a new enough version of the compiler to support said newer edition.
Hmm, couple of questions.
what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file?
If I have Rust code from 2021, can I add a feature from 2024 and run it with --edition=2021 or 2024? Wouldn't adding a 2024 feature then possibly break the 2021 code?
I think the fact that rust is compiled has a big impact in terms of bc for dependencies. py2 must use py2 dependencies, but rust24 could use rust21 binaries as long as there were no API bc breaks, the code itself is already compiled away.
> what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file?
The difference is that it's not the entire compiler. Rust's editions are only allowed to change the frontend. At the middle part of the compiler, it's all the same thing, and the differences are completely gone. This is the core of how the interop works, and it also means that you can't just change anything in an edition, only smaller things. But completely changing the language every few years wouldn't be good either, so it's fine in practice.
> Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree.
But the Rust team found a great way to avoid breaking backward compatibility: old code gets automatically compiled by the old version of the compiler, whereas more recent code is treated with the latest version of the compiler.
That is much better IMHO than carrying that old baggage along in the language that e.g. the C++ folks struggle with, where every half-decade a pile of additive changes get piled on the previous version of the language, and nobody can clean up the old mess.
> old code gets automatically compiled by the old version of the compile
That's not what happens. You always use the same version of the compiler. It's just that the newer compiler version also knows several older dialects (known as editions) of the language.
And it remains to be seen how well this approach will work as time passes and the number of versions continues to increase.
That won't be any more of a problem than the support that every existing C or C++ compiler has for targeting different versions of the standard.
Right, it's not considered weird for a C++ compiler to offer C++ 98, C++ 11, C++ 14, C++ 17, C++ 20, C++ 23 and C++ 26 (seven versions) and support its own extra dialects.
It is also usual for the C++ compilers to support all seven standard library versions too. Rust doesn't have this problem, the editions can define their own stdlib "prelude" (the reason why you can just say Vec or println! in Rust rather than their full names, a prelude is a set of use statements offered by default) but they all share the same standard library.
core::mem::uninitialized() is a bad idea and we've known that for many years, but that doesn't mean you can't use it in brand new 2024 Edition Rust code, it just means doing so is still a bad idea. In contrast C++ removes things entirely from its standard library sometimes because they're now frowned on.
Well, there's the 2015, 2018, 2021, and 2024 editions. It's been a decade and it seems to be working pretty well?
This may have its own landmines. Worst case, old code getting compiled in the old way could mean that the exact same line means different things depending on which file it's in. (I don't know whether it is possible with how Rust does this.)
There are several edge cases where that's exactly what happened.
But in all the cases I can think of, when you look at that Rust today, what it meant in say 2018 Edition seems silly, "Oh, that's a daft thing for that to mean, I'm glad it doesn't mean that now"
We can't magically step into a time machine and fix how it worked at the time, any more than we could go back and cancel those minstrel shows which now seem awful. We can only fix it now and Rust's editions enable this, without the cost of making old code not work in old projects.
One of the changes I'm looking forward to from a future Edition is what happens when I write native ranges like 1..=10 (the integers 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10). Today this means core::ops::RangeInclusive but that type isn't Copy, because it is Iterator. Instead hopefully one day it'll become core::range::RangeInclusive which is Copy, and so can't be Iterator but instead IntoIterator.So in that future Rust edition (when/if it happens) I can treat 1..=10 the same way as a pair of numbers (1,10) or an array of two numbers [1, 10] which are both Copy, that is, by just copying the bit pattern you are guaranteed to get an object which means the same thing, making life easier for programmers and the compiler. Today, because it isn't Copy, I must do extra busy work, which is slightly annoying and discourages use of this otherwise great type.
Sure, Rust can compile old code. But you can't upgrade that old Rust code to new Rust code very easily.
The fact that C was effectively "born old" means you can take a C89 program and compile it as C23 and it should simply work, with extremely minimal changes, if any.
That's a killer feature when you're thinking in decades. Which SQLite is.
You would need to be incredibly careful with compiling old C89 code on a modern compiler. It's not the language changes that would get you, it's a change in how compilers treat undefined behavior.
There has always been undefined behavior in C, but back in the day, compilers were nowhere near as aggressive in taking advantage of it to make your code faster. Most C programmers tended to treat C as portable assembly and not a language with rules that needed to be respected for it to not blow up your code.
I remember this being endlessly groused over by grognard, traditionalist C programmera, and more than a few of them switched to C++ as a result. After all, if the language was going to be a stickler about correctness, they might as well use a language with the features that meant they didn't have to reach into that bag of tricks.
> There has always been undefined behavior in C, but back in the day, compilers were nowhere near as aggressive in taking advantage of it to make your code faster.
That much is true. If you put the derefence of a pointer and the null check in the wrong order both those statements would have code emitted for them.
Now, it is almost certain that one of those statements would not be emitted.
OTOH, compiling with -O0 still leaves most code to be emitted and fewer dead-code elimination places.
I truly believe that the cult of c performance optimization has done more harm than good. It is truly evil to try and infer, or even worse, silently override programmer intent. Many if not most of the optimizations done by llvm and gcc should be warnings, not optimizations (dead code elimination outside of LTO being a perfect example).
How much wasted work has been created by compiler authors deciding that they know better than the original software authors and silently break working code, but only in release mode? Even worse, -O0 performance is so bad that developers feel obligated to compile with -O2 or more. I will bet dollars to donuts that the vast majority of the material wins of -O2 in most real world use cases is primarily due to better register allocation and good selective inlining, not all the crazy transformations and eliminations that subtly break your code and rely on UB. Yeah, I'm sure they have some microbenchmarks that justify those code breaking "optimizations" but in practice I'll bet those optimizations rarely account for more than 5% of the total runtime of the code. But everyone pays the cost of horrifically slow build times as well as nearly unbounded developer time loss debugging the code the compiler broke.
Of course, part of the problem is developers hating being told they're wrong and complaining about nanny compilers. In this sense, compiler authors have historically been somewhat similar to sycophantic llms. Rather than tell the programmer that their code is wrong, they will do everything they can to coddle the programmer while behind the scenes executing their own agenda and likely getting things wrong all because they were afraid to honestly tell the programmer there was a problem with their instructions.
My company maintains a medium set of Rust programs deployed on embedded Linux systems. Most of the time the migration is automatically done for you by Cargo itself with the command `cargo fix --edition`.
I don't know where you got this impression but our switches from 2018 to 2021 and now 2024 editions went very smootly. Rust hasn't broken backwards compatibility in any bigger way since 1.0.
When clang was first coming about, the number one cause of Debian packages failing to build with clang was that (at the time) clang defaulted to C99 whereas gcc defaulted to C89.
I'm going to guess that most of those issues were caused by implicit declarations no longer being valid.
Without an explicit declaration, C will consider this function to have the following signature based on the call site: By the way, in C () doesn't mean "no parameters" it means "any parameters, which the compiler will infer from the call site and pass to the function."True that!
No not true. cargo fix —edition automatically does most translation to the new edition (most people never see it fail, I’ve seen it fail only on some obscure constructs that it couldn’t do automatically because the meaning of some trait stuff changed subtly but took 2 minutes or less to fix). cargo clippy —-fix will automatically apply linter fixes or warning fixes when it can.
Claiming that editions are an example of rust failing back compat shows a complete ignorance of the ecosystem or what coding in the language is actually like. People in this thread think you can’t mix n match editions or that migrating is some huge unavoidable obstacle. Indeed I have less fear upgrading editions than I do bumping the version of the c or c++ language or even using a newer compiler that exploits accidental UB that had been lurking.
Calling C "strange" for being conservative and not wanting to break things is rather odd. It's one of the "great" things in that sense. "Stable" could be another description.
Depends on what it’s unwilling to break. “The compiler generates code that segfaults when you multiply 13 * 37, but someone found a way way to trap it and used that as a faster way to make syscalls on Prime minicomputer, so we had to add -ffix-four-eight-won, which the original implementor misspelled in 1993 so we can’t fix that, either, for backward compatibility.”
Some of its actual weirdnesses seem no less odd than that to people who aren’t C experts, I assure you.
The great thing about C is that is was not designed by a committee at all. It was designed by a person with strong opinions. This means it is really great for what it does well(what the author was interested in).
To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee.
If you look at the structure of C++ in Backus Naur form it is absolutely nuts. The compile times have gone through the roof and people leave to create new languages like jai, Zig or whatever.
Common Lisp was designed by committee. It is as chaotic as C++.
Rust is also gigantic. I am very careful not to use in critical systems because it is so big unless we could restrict it with the compiler or something.
> To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee.
This comparison confuses me because C is... also controlled by a committee? The evolution of the C standard is under the control of ISO WG14 [0], much like how the C++ standard is under the control of ISO WG21 [1]. This was true for even the first versions of each language that was standardized.
[0]: https://www.open-std.org/jtc1/sc22/wg14/
[1]: https://www.open-std.org/jtc1/sc22/wg21/
For what it’s worth rust was also designed by a person with strong opinions. It’s devolved to an organization but that’s inevitable in terms of long term sustainability.
You can always use no-std if you so choose where the language is about the size of C (but still has better utility) although if you’re complaining about the size of the language, c++ is drastically worse in my opinion. Rust starting to work its way into the Linux kernel should be a signal that the language is better suited for paring down than c++
Uh oh! I think Rust may settle down eventually. Who knows, maybe one of the devs will chime in.
It's pretty settled now.
Oh look. Something works. Lets not break it? How crazy is that?
I sometimes wonder if what happens is like this:
1. Have problem. Need higher level computer language. 2. Think about problem. 3. Solve problem - 'C' 4. Think about problems with 'C' 5. Attempt to fix problems with 'C' - get C++ 6. Think about problems with C & C++ 7. Get: Go, F#, Rust, Java, JavaScript, Python, PHP, ...other etc.
I tend to do this. The problem is obvious, that I do not repeat step #2. So then I move to the next step.
8. Thinking about how to fix C, C++, Go, F#, Rust, Java, JavaScript, Python, PHP, ...other is too hard. 9. Stop thinking.
Although Mozilla's reason to pay for Rust R&D was because of problems with C++ it's probably not most helpful to think of Rust (let alone F#) as an attempt to specifically fix those problems.
C is a Worse is Better language (https://en.wikipedia.org/wiki/Worse_is_better). The bet is that if it's simpler to implement then the fact that what you're implementing isn't great will be dwarfed by that ease of implementation. And it worked for decades which is definitely a success.
You can make a similar argument for Go, but not really for Rust. The other side of the Worse is Better coin is that maybe you could make the Right Thing™ instead.
Because implementing C is so easy and implementing the Right Thing™ is very difficult, the only way this would compete is if almost nobody needs to implement the Right Thing™ themselves. In 1970 that's crazy, each Computer is fairly custom. But by 1995 it feels a lot less "out there", the Intel x86 ISA is everywhere, Tim's crap hypermedia experiment is really taking off. And when Rust 1.0 shipped in 2015 most people were able to use it without doing any implementation work, and the Right Thing™ is just better so why not?
Now, for an existing successful project the calculation is very different, though note that Fish is an example of this working in terms of full throated RIIR. But in terms of whether you should use C for new work it comes out pretty strongly against C in my opinion as a fairly expert C programmer who hasn't written any C for years because Rust is better.
> But no other language claims to be faster than C for general-purpose programming, because none are.
The "faster than C for general-purpose programming" is a pretty woolly claim so I'm not entirely surprised nobody claims that, but equally I think to be sure that "because none are" would need some serious caveats to make it true.
In particular you're going to have to say you think it doesn't matter how much developer time is needed. A project where C programmers spend five hours to make it run in 4 seconds is in this caveat "20% faster" than a project where Alt Lang programmers spend five minutes to make it run in 5 seconds - because only those seconds count. This is not how the real world works so it's a pretty nasty caveat.
Of course it's true in the case of sqlite. It's one of the most used pieces of software ever, and user cpu time spent is going to dwarf any developer time.
Your example should instead be:
- 5 hours of developer time to run in 4 seconds * n
- 5 minutes of developer time to run in 5 seconds * n
As long as n <= 17,700, then the developer time is "not worthwhile." This assumes that you value user time as much as developer time.
In the case of sqlite, the user time may as well be infinite for determining that side of the equation. It's just that widely used.
Also battery life. 20% less time, 20% more battery.
But OP is correct, companies don't care as long as it doesn't translate into higher sales (or lower sales because the competitor does better). That's why you see that sort of optimization mainly in FOSS projects, which are not PDD (profits-driven development).
>>A project where C programmers spend five hours to make it run in 4 seconds is in this caveat "20% faster" than a project where Alt Lang programmers spend five minutes to make it run in 5 seconds - because only those seconds count. This is not how the real world works so it's a pretty nasty caveat.
For any project with non-trivial amount of users the C programmer did better. I mean I know companies like to save money and move the costs (time, electricity, hardware costs) to customers but if you care about users any non-trivial speed improvement is worth a lot in aggregate, surely more than your time implementing it.
I see a few people have been caught by this.
Databases are a problem space which can absorb all available effort. So if you spend five hours making thing U as fast as it could be that's five fewer hours you can dedicate to thing V or thing W, not to mention X, Y, Z and so on.
> The C language is old and boring. It is a well-known and well-understood language.
This is such an under appreciated feature.
I'm tired of languages that just keep adding and adding to a language.
Work on the standard library or ecosystem, but stop changing the language otherwise you'll never end up anywhere because there is always going to be something that would benefit from some love.
Hell, I'd say the same is true for many libraries.
> It is a well-known and well-understood language.
This isn't entirely true. There are a bunch of UBs that you have to be very careful about. C has the right idea about simplicity. But deterministic behavior is also important because someone will find a way to make use of UBs in their code.
This is one of the things I love about Clojure. It's a simple, elegant, stable language.
What I like about C is that when they do add features they are just useful non-controversial features with maybe one exception of VLAs (that one was controversial).
Designated initializers, compound literals, binary literals and the way to printf numbers in binary, constexpr, alignas, #embed, stdbit.h, memset_explicit, restrict to name the ones I really like.
C is the first language where I actually felt like I was programming. After using C and assembly for a few projects, every other language started to feel extremely slow. Even now, when programming with TS, my mind always goes to legacy features that offer better performance at the nanosecond level.
I agree that C is best. I think Rust is actually a language with some severe downsides, despite having including some very good ideas and C having some real issues. But it will take a couple of years before one can discuss this rationally without being flamed at.
If you want to spread this idea, it would probably help your cause if you pointed to what you think Rust does particularly poorly. Steep learning curve, npm-esque packaging?
The article gave many good reasons where Rust is lacking. The points you raise are also clearly issues. My main additional issues are the high complexity, the syntax, the lack of stability, compilation times (and monomorphization), and lack of alternate implementations. Ignoring the language itself, the aggressive and partially misleading negative and positive marketing.
Lack of (useful) dynamic linking is a huge problem IMO.
What do you mean by useful dynamic linking? Dynamic linking with C ABI is supported natively in Rust and is very widely used (just checked GitHub), especially for FFI like in Python modules (PyO3). If you mean an ABI that supports all the Rust features (without extern C), then it's a problem faced by every language that has more features than C - C++, Haskell, Go, Zig, etc included. To solve that problem, somebody will have to design a new stable standard common ABI that natively supports all the features from these languages, or at least makes it possible to express these features in some way.
C++ has reasonable dynamic linking (there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11), obviously excluding a lot of metaprogramming features, but a lot of C++ dynamic libraries exist that are widely used. Supposedly Swift does a better job, though I'm not familiar. Yes, Rust can dynamically link with a C ABI (as can any language) but it loses a lot of the expressiveness (I imagine, I'm not a rust developer) to have to use the C ABI.
Dynamic languages of course support dynamic linking.
> there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11
ABI breaks are everywhere in C++... consider a class
and an impl in the dynamic library: You build a libfoo.so and clients use it, calling `foo f; f.do_something();`, it calls your library and it's great.But as soon as you ship a new version that adds a new field to foo (still source-code compatible):
With a new function body in your shared object: You're hosed. Clients have to recompile, or they get: Because the size information for an instance of foo is only known at compile-time, so the clients aren't allocating enough space on the stack for it (ditto the heap if you're using `new foo();`)The way around this is awkward and involves the pimpl pattern and moving all your constructors out-of-line... but you also need to freeze all virtual methods (even just adding a new one breaks ABI), and avoid using any template-heavy std:: types (not even std::string), since those are often fragile.
Most people just give up and offer an extern "C" API, because that has the added benefit that it's compatible across compilers.
"true" C++ shared libraries are crazy difficult to maintain. It's the reason microsoft invented COM.
Swift goes through crazy lengths to make this work, and it's impressive: https://faultlore.com/blah/swift-abi/#resilient-type-layout
Rust would have to do something like Swift is doing, and that's probably never going to happen.
Sure, you can break ABI in a library, but the compiler doesn't force you to, is what I mean. Same as breaking ABI in C when you change a struct...
It is problem of all languages whose extensions to C are badly designed. That it works with the C FFI just shows that C part properly supports it while Rust does not. And yes, C++ has similar problems as Rust.
> Rust is actually a horrible language
Can you expand a little?
They never said it's a horrible language.
The original comment was edited after I replied.
Yes, sorry, apparently not quick enough. I actually do not think it is horrible. It is a nice language, but I still do not like it and see many downsides. What I hate though is how aggressively it is marketed. See my other response for details.
That is fair. Rust is my most used language, and I agree Rust has many downsides and pain points. But for my work, the positives outweigh the downsides of other languages I've used (including Python, Java, C++, and C).
But it ultimately depends on your situation. People elsewhere on this post are listing weaknesses of Rust that I consider to be strengths and vice versa.
Nobody is marketing it. It doesn't have a marketing budget. What you're seeing are lots of people that really like it because it's really good. Not flawless obviously but a significant improvement on C and C++.
I see a lot of activity of very specific parts of the industry promoting it. But also enthusiasts doing aggressive marketing are doing aggressive marketing - even if they do not have a budget. Whether it is an improvement is debatable. From my perspective, it is an improvement in some aspects and a significant step back in others. What is unacceptable though is the significant hate and pressure towards people who have other priorities and preferences, which is created by the "we must stamp out memory safety issues at all cost and Rust is the solution" narrative.
> Whether it is an improvement is debatable.
Not really.
> it is an improvement in some aspects and a significant step back in others
Of course. Very few improvements are better in every way. There's always something you can find to like about the old solution. Horses are friendlier than cars. Records allow bigger artwork than CDs. Unlike DVDs (at first anyway) you can write to VHS. Unlike Typescript, Javascript doesn't need a compile step. FORTRAN77 fits nicely on punch cards.
That doesn't mean there's really any serious debate about them being improvements.
I will freely admit that Rust has only average compile time (though it's better than C++ at this point), high complexity, and async Rust is full of footguns. But I could come up with a much longer list of complaints for C.
> we must stamp out memory safety issues at all cost and Rust is the solution
Yeah I think memory safety is actually probably not the most important thing about Rust. Having a modern strong type system is arguably more significant. Memory safety is important too of course - even if you don't care about security memory safety issues are often plain hard to debug bugs.
I've started using SQLite years ago for its use of a single file to store data. Along the way, I found more reasons to like it. Today, I discovered a new reason when I read this article.
I also noticed many software companies have been switching to SQLite for storing data. Audacity has switched from using hundreds of tiny audio files in multiple folders for a single recording to a single file using SQLite. I suspect it is the reliability that comes from sticking to C
> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages.
This is no longer true. Rust, Zig and likely others satisfy this requirements.
> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe languages.
This is a major annoyance in the rust stdlib. Too many interfaces can panic (and not just in case of an OOM), and some of them don’t even document this.
> This is no longer true. Rust, Zig and likely others satisfy this requirements.
Rust and Zig satisfy this by being C ABI-compatible when explicitly requested. I'm pretty sure that that solution is not actually what the author meant. When you don't explicitly use `extern "C"` in Rust or `export` in Zig, the ABI is completely undefined and undocumented. I would go as far as arguing that the ABI problem, with Rust at least, is even worse than the ABI problem C++ has. Especially since Distros are (if memory serves) starting to ship Rust crates...
The only reasonable way to solve that problem is to design a standard ABI that supports expression of all features in modern compiled languages like Rust, Go, Zig, Haskell, Ada, etc. It doesn't make any sense to design stable ABIs for each language separately, because then you'll end up with a system directory full of dynamic libraries of several distinct ABIs.
> Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++. On the other hand, libraries written in C are callable from any programming language.
Not saying they should have picked C++ but that's a bit untrue. It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface. I've done it multiple time throughout my career (that ended up being called from Python, Swift, Objective-C/C++, Swift, Java, and Kotlin).
And as a side note, you don't have to do object-oriented programming in C++ if you don't want to.
Yeah, it's not a very convincing argument imho. You can write C libraries in C++ or Rust or D or Zig, and people do it all the time.
In fact, some popular C++ libraries don't even have a stable C++ API, only a C API. LLVM comes to mind. DuckDB is another example
> It's quite easy given some thought into the API to invoke C++ code in basically any language which can invoke C code, since you can wrap a C++ implementation in a C interface
Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?
I've only seen it done for C++ that is more C than C++, or for libraries that were designed to "bail out" to a C interface.
> Is it easy to write a nice C interface for C++ that makes heavy use of templates, smart pointers, and move semantics?
If the interface itself has or leaks those features, no that's not easy indeed. But if those do not leak, then they can be used internally yes.
My point was not that it's easy to wrap a currently existing C++ library that has modern features in its interface in a C interface, especially post-C++11.
But that if you design something from the ground up, then it's rather easy (with a certain set of constraints). My bad for not conveying that better.
Then the statement "Stuff can't interoperate with c++" is true. Nothing from c++ ever gets exposed. You have to explicitly write a C interface yourself, or avoid using c++ features (write C in c++) so everything looks like C in the first place and all you need is #ifdef __cplusplus extern "C" #endif. But then you're not writing c++ either.
> Then the statement "Stuff can't interoperate with c++" is true
Where is that statement? The statement I reacted to (and with some caveats) was the following: "Libraries written in C++ or Java can generally only be used by applications written in the same language. It is difficult to get an application written in Haskell or Java to invoke a library written in C++."
Which in my opinion is not true for the reason I mentioned.
> Nothing from c++ ever gets exposed
Depends what's your definition for "getting exposed". If you mean "no C++ feature from the language gets exposed" then it's mostly true (you can still wrap certain things like allocators, though painful, but there's certain C++ features that have no real equivalent in some target languages indeed). But you can definitely expose the functionality of C++ code through a C interface.
That's definitely true. Can't have generics / compile time evaluation across languages. Need to design your code around that restriction ahead of time. SQLite being dynamically typed luckily doesn't have any problems with that.
I've actually run into a similar problem with a C library before, because it heavily used macros as part of its API. Glad most developers don't do that.
You lose most of the advantages of C++ if you can't use vector, unique_ptr and the like in your APIs. Classes are also useful for a lot of things.
You do lose the ability to use some features, that's true. Mostly RAII around the interface. You can still leverage it internally in the implementation, and if using context objects it would be even easier. The main pain point is if you want to let client of the library use their own allocators. It's still doable, but quite a pain.
Classes can be wrapped with a bit of effort. You do need to write the constructors and the destructors manually and invoke a pair of new/delete on the C side, but it's just as you would handle a type allocated by a C library itself. You'd use it the same way. You just have the liberty to have the implementation use (mostly) C++.
You can still use them inside your code, just not as arguments or return values from the API.
And it's not like that's a point in favor of C, since C doesn't have vector or unique_ptr either
> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM.
As someone who runs into this problem a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite?
> As someone who runs into this problem [OOM]a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite?
How are you running into it?
If you're writing in C, idiomatic code works (check the return values of functions that allocate!)
If you're in C++, Rust or similar, you have to write pretty non-idiomatically to recover from an allocation failure.
how exactly do you think C and C++ differ here?
> how exactly do you think C and C++ differ here?
`new` throws, `malloc` returns. That's a pretty big difference!
Idiomatic C++ code never puts a `try` around `new`, while idiomatic C code always checks the return from an allocation.
Well: https://en.cppreference.com/w/cpp/memory/new/nothrow.html
I thought you were talking about the use of malloc in both languages - you never mentioned new in your first post. and i think we have different views on what is "idiomatic" in the languages.
> I thought you were talking about the use of malloc in both languages - you never mentioned new in your first post. and i think we have different views on what is "idiomatic" in the languages.
That's fair, but malloc is certainly non-idiomatic, isn't it?
An oom is when malloc failed
So you have to ensure that in such situation, you can execute code that does not require more memory: ensure that the rest only free stuff, or preallocate structures for that purpose
Well, can't argue with it. Ruby and Python are written mostly in C underneath.
Many try to replace C. All failed.
I'd love to see a language that could satisfy both high end needs and low need needs. I would not know how such a language would look though.
> Ruby and Python are written mostly in C underneath. > > Many try to replace C. All failed.
What do you mean by all failed? Rust supports CPython modules using PyO3 [1]. Even the popular polars dataframe library [2] uses it.
[1] https://github.com/PyO3/pyo3
[2] https://github.com/pola-rs/polars
From what they have written, the only other language that meets their requirement seems to be Ada:
1. Stability: Ada is an "old and boring" language (aka stable and reliable - the first standard for the language was issued in 1983 and created for the Defence industry) - https://learn.adacore.com/courses/intro-to-ada/chapters/intr...
2. Compatibility: Interoperability features is built-in, allowing you to create Ada libraries that can be used with other languages - https://piembsystech.com/interfacing-ada-programming-with-c-...
3. Embedded Programming: Ada has been designed for embedded programming and the language includes constructs for directly manipulating hardware, for example, and direct interaction with assembly language. - https://learn.adacore.com/courses/intro-to-embedded-sys-prog...
4. Ada supports processes / suites to comply with Branch coverage in ISO 26262 ( https://github.com/NVIDIA/spark-process ) and Decision coverage in DO-178C ( https://learn.adacore.com/booklets/adacore-technologies-for-... ).
5. Ada has features supporting memory safety to avoid many memory issues in the first place ( https://www.adacore.com/blog/memory-safety-in-ada-and-spark-... ) and using its exception handling and programming techniques (like pre-allocating "guard" memory) can allow Ada programs to tackle fringe OOM errors.
6. Performance: Ada is built for systems programming, is just as fast as C ( https://learn.adacore.com/courses/Ada_For_The_Embedded_C_Dev... ), with the added bonus of "modern" programming features that can generate more "reliable" code
2017 at least[1] but "This page was last updated on 2025-05-09 15:56:17Z."
[1] https://web.archive.org/web/20170701061906/https://sqlite.or...
The only changes in 2025 were a few minor typos fixed. Nothing substantial.
I’m sure it’ll be updated more
I'd like to see Steve Yegge unleash his Gas Town with a convoy or whatever it's called to rewrite the sqlite in Rust obviously preserving 100% test coverage. Results are a guaranteed bombshell regardless of whether it succeeds or fails.
What’s Steve Yegge got to do with Rust? And who’s gonna sponsor some 10,000 hours to “rewrite the sqlite in Rust obviously preserving 100% test coverage”? Will he do it just for the memes, or did you think Rust is so cool there is no effort involved?
Let’s be serious now.
What's not serious? He's got a tool which he claims should be able to handle projects of this scale, the existing test coverage is what makes it not immediately impossible and about the memes, have you read his gas town post? Of course it's for the memes, but more importantly it'll validate his vision of the future in the eyes of quite literally everyone if successful.
The title is "Why Is SQLite Coded In C", not "C Is Best". The content is far more nuanced than this specific section title suggests.
1. This isn't a 2025 article, it's much older but it received some updates in 2025.
2. Ada is about as old as C so should have been considered as a possible safe language. It's safer than Rust in my opinion. GNAT was released in 1995 while SQLite is from 2000, so it was a possibility. C++ was also around: still unsafe, though less so than C.
Many non-programmers think that programming languages get outdated, just like operating systems or computer hardware, or even some software (old algorithms replaced by better algorithms), and each programmer should "follow trends", since using the same programming language for 10+ years sounds wrong.
But programming languages are like Math. It is like saying "multiplying is outdated" or "the square root is outdated".
if you don't think programming languages can get outdated then why is assembly, fortran, lisp, smalltalk, pascal, basic practically disappeared? programming languages are not like math, it's like the moon
Many of those are still under active development (both language and tooling) and code is still being written in them. They have hardly disappeared.
Nonsense, unless you think the entire field of PL research is doing nothing. The industry learns things and gradually improves, on average.
Do you still write FORTRAN and Perl?
The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code.
Overall, it makes sense. C is a systems language, and a DB is a system abstraction. You shouldn't need to build a deep hierarchy of abstractions on top of C, just stick with the lego blocks you have.
If the project had started in 2016, maybe they would have gone for c++, which is a different beast from what it was pre-2011.
Similarly, you might write SQLite in Rust if you started today.
> The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code.
That section was probably written 20 years ago when Java was all the rage.
I think they would have still gone with C. I still do.
The author of ZMQ had an article about regretting not using C over C++. Picking Rust for a "modern" version of SQLite could easily go down a similar route in the end.
https://web.archive.org/web/20250130053844/https://250bpm.co...
Regret is possible with any language, but I'd be surprised if someone regretted choosing Rust for the reasons in the article you linked:
* Error handling via exceptions. Rust uses `Result` instead. (It has panics, but they are meant to be strictly for serious logic errors for which calling `abort` would be fine. There's a `Cargo.toml` option to do exactly that on panic that rather than unwinding.) (btw, C++ has two camps here for better or worse; many programs are written in a dialect that doesn't use exceptions.)
* Constructors have to be infallible. Not a thing in Rust; you just make a method that returns `Result<Self, Error>`. (Even in C++ there are workarounds.)
* Destructors have to be infallible. This is about as true in Rust as in C++: `Drop::drop` doesn't return a `Result` and can't unwind-via-panic if you have unwinding disabled or are already panicking. But I reject the characterization of it as a problem compared to C anyway. The C version has to call a function to destroy the thing. Doing the same in Rust (or C++) is not really any different; having the other calls assert that it's not destroyed is perfectly fine. I've done this via a `self.inner.as_mut().expect("not terminated")`. They say the C only has two states: "Not initialised object/memory where all the bets are off and the structure can contain random data. And there is initialised state, where the object is fully functional". The existence of the "all bets are off" state is not as compelling as they make it out to be, even if throwing up your hands is less code.
* Inheritance. Rust doesn't have it.
Actual title: Why Is SQLite Coded In C
"In a more complete build, SQLite also uses library routines like malloc() and free() and operating system interfaces for opening, reading, writing, and closing files."
Whoa. TIL there's a minimal build of SQLite that doesn't even need malloc() and free() !
Presumably for embedded devices. I'd love to see examples of that being used in the wild.
BTW, the study referred to in 1.2, which claims that SQLite was faster than the file system is not supported by the numbers in the study referenced:
https://github.com/chrisdavies/dbench
> For a my real(ish) world scenario, SQLite-- once warmed up-- is roughly twice as fast as the file system.
is that actually surprising ?
once data leaves the fs and is all (or in part) bought into a processes memory, access is just limited by the memory bandwidth.
ofcourse if you start touching uncached data things slow down, but just for a short while…
> So, for example, Android applications written in Java are able to invoke SQLite (through an adaptor). Maybe it would have been more convenient for Android if SQLite had been coded in Java as that would make the interface simpler. However, on iPhone applications are coded in Objective-C or Swift, neither of which have the ability to call libraries written in Java. Thus, SQLite would be unusable on iPhones had it been written in Java.
This feels like they're responding to people asking for SQLite to be rewritten in Java. Who are these people?!
As an outsider when I read about Rust it seems like it is positioning itself as the language to rewrite things that already work.
It's just the simplistic first feeling of a language, in the same way I feel like Go is the language for Kubernetes/cloud/net servers, Ruby is for Rails, JS is the browser/bootcamp language, Python is Data Science and AI...
Sure, you get that safety but you are also throwing the stability that an old (and maintained) codebase has just for the sake of being patched to handle the presssure from the real world.
Maybe it's time Rust positions itself as something more than "the language of rewrites".
who is this that you are claiming is "positioning" itself??? the Rust maintainers? No. Programmers are choosing to write something in Rust and it just so happens they are interested in rewriting something that already exists because they can. You write as if Rust is an entity that chose to position itself. What is your argument here? Rust should just go do something else? You wouldn't dare say that about Python. Also, how dare you put these languages in a corner. I've use ruby for many things other than Rails. JS is much more than a browser language now, and python is much more than data science and AI. Go is much more than Kubernetes/cloud/net servers.
Well they don’t have to wait for Rust in the way they said - they’ve already been forked by Turso which has been moving along for a while now. I wouldn’t mind hearing from them how that’s been going.
previous discussion a few months ago: https://news.ycombinator.com/item?id=45584464
I believe this article is from a few years ago
Updated quite often I see.
> Recoding SQLite in Go is unlikely since Go hates assert()
I've heard it said you shouldn't use asserts in production code, but handle errors and exceptions instead? That said, can't you just 'if !condition() {panic...}' to simulate the behavior? Or are they talking about something specific about Golang?
> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy.
Doesn't the language compiler write the code that checks if the array access is in-bounds? Why would you need to test the compiler's code?
They talk about this here: https://sqlite.org/testing.html#statement_versus_branch_cove...
...saying that for a statement `if( a>b && c!=25 ){ d++; }`, they use 100% machine-code branch coverage as a way of determining that they've evaluated this in `a<=b`, `a>b && c==25`, and `a>b && c!=25`. (C/C++) branch coverage tools I've used are less strict, only requiring that takes both if and else paths.
One could imagine a better high-level branch coverage tool that achieves this intent without dropping to the machine code level, but I'm not sure it exists today in Rust (or any other language for that matter).
There might also be an element of "we don't even trust the compiler to be correct and/or ourselves to not have undefined behavior" here, although they also test explicitly for undefined behavior as mentioned later on the page.
Hmm, so in a language that does automatic bounds checking, the compiler might translate a line of source code like:
to assembly code like: Are they saying with "correct code" the line of source code won't be covered? Because the assembly instruction to call panic isn't ever reached?I think they're saying it's not covered: not only because `call` isn't ever reached but also because they identify `jae` as a branch and see it's always not taken. (If there were no lines in your `; later...` section and the branch were always taken, they'd still identify the `jae` as not covered.)
It might be reasonable to redefine their metric as "100% branch coverage except for panics"...if you can reliably determine that `jae .Lpanic_label` is a panic jump. It's obvious to us reading your example of course but I don't know that the compiler guarantees panics always "look like that", and only panics look like that.
Makes a lot of sense for SQLite to be written in C. It's a heavily optimized and debugged database implementation: Just look at btree.c with all its gotos :)
The only language that would make sense for a partial/progressive migration is zig, in huge part due to its compatibility with C. It's not mentioned in the article though.
Zig hasn't even had it's first release yet. And projects written in it still break in new releases. Given their stance on boringness and maturity it would make no sense for Sqlite to consider zig yet.
SQLite is never gonna be rewritten by its creators in another language. That is highly doubtful considering the age of SQLite and the roadmap for support I think until 2060 or mid 2050s based on what I’ve read.
> SQLite is never gonna be rewritten by its creators in another language.
Almost certainly correct. It is however being rewritten in Rust by other people https://github.com/tursodatabase/turso. This is probably best thought of as a seperate, compatible project rather than a true rewrite.
I'm biased but when I see Discord as the only way of communication, it doesn't make for a serious project. I wish more projects would rely on IRC/Matrix + forums.
For better or worse, plenty of serious projects are using Discord for communication. It's not great, but IRC and Matrix have their own problems (IMO Zulip is the best of the bunch, but doesn't seem to be particularly widely adopted).
You're right. Just look at their branding. Such poor taste. I'm sure it's a scam.
The amount of completely obscure and exotic platforms that have C compiler, and the amount of tooling and analysis tools C has — I'd be surprised anything comparable exists.
Maybe DRH will see this and update the page !
What would be a reason to bring Zig in?
For example, Rust has additional memory guarantees when compared to C.
Zig has better ergonomics over C but not as complex as Rust.
The problem with articles like this is that they read a little like justifying a decision that has already been made. I've a feeling that if it was written in C++/Rust/Go/whatever, it would also be possible to justify that decision with similar reasoning.
I think you're not wrong, but it's not necessarily a problem? I might argue that's actually part of the main point the article is making. The software is already written in C, well understood and optimized in that language, and quite stable, so they'd need very compelling reasons for a rewrite.
I think the "lingua franca" argument for C and the points at the end about what they'd need from Rust to switch do go beyond merely justifying a decision that's already been made, though.
Given SQLite's amazing battery of test code, it seems like it would be valuable, illuminating, and not too difficult to write a test implementation in Rust. Can you get the Rust implementation to pass the test suite? Either answer to that question would be interesting.
SQLite's test suite is proprietary.
A Rust implementation exists. It's called turso
https://github.com/tursodatabase/turso
There's a whole company around it.
Did they rename from Limbo to Torso?
yes, mentioned in https://turso.tech/blog/upcoming-changes-to-the-turso-platfo...
*C-API is the best.
As a language, it's too basic. Almost every C projects try to mimic what C++ already has.
I considered it outdated back in 1993, when all major GUI based systems (Apple, IBM, Microsoft) were going with C++ for userspace applications.
Then came the rise of FOSS adoption, with the GNU manifest asserting to use only C as compiled language.
"Using a language other than C is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. So please write in C."
The GNU Coding Standard in 1994, http://web.mit.edu/gnu/doc/html/standards_7.html#SEC12
That’s not true, give me an example used in real code out in the wild?
Since I am feeling generous, here are two examples,
https://docs.gtk.org/glib/
https://github.com/antirez/sds
Thank you
Ah, C has stable ABI unlike C++, never would get tired of unresolved std::__1 symbols.
What stable ABI?
First of all, ABI is a property of the OS calling conventions, which happen to overlap with C on UNIX/POSIX, given its symbiotic relationship.
Secondly, https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...
For big, fixed environments like Qt — sure. For embedded? Please no. Basic is good. Feel free to reimplement C++, your C library still will not have: most of STL as a dependency; unwind tables in all code (including C!); ctor/dtor arrays; insane kilobyte-sized symbols.
"C++20 for Commodore 64"
https://www.youtube.com/live/EIKAqcLxtT0?si=J82Us4zBlXLPbZVq
It is a matter of skill.
I'm confused. What is a matter of skill? You linked 6 hour livestream where person is working on translating AVR assembly to 6502. What was your point, that translating assembly or executables to another architecture takes a lot of skill? Yes, it does!
Because I could not, by scrubbing that video, find anything where immense skill is used to deal with the enormous overhead that standard C++ forces on every program that uses it.
Here is a better one then,
"Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17"
https://youtu.be/zBkNBP00wJE?si=uqUwVMMEpp4ZPWun
It is a matter of skill, understanding C++ and how to make it useful for embedded systems, and being able to understand standard library isn't a requirement for each executable.
By the way, the famous Arduino and ESP32 hasve no problem dealing with C++.
As we also didn't, back in MS-DOS, with 640 KB, Turbo Vision and Borland Collection Library (BIDS).
A matter of skill, as mentioned.
> standard library isn't a requirement for each executable.
So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries.
It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions and most of standard library. If you need to implement your own STL subset to satisfy the library, then modify the library to work with your STL, the resulting API is not much of an API, is it?
Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding.
It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.
C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library!
You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!
Some people have the skills to make C++ work on a GBA, https://github.com/GValiente/butano
Arduino, https://docs.arduino.cc/arduino-cloud/guides/arduino-c/
Or even ESP32, https://docs.espressif.com/projects/esp-idf/en/stable/esp32/...
Others do not.
As for C does not such thing, strangly there are enough examples from TI, Microchip, Atmel that prove otherwise.
These are great, thanks! That GBA "butano" compiles with -fno-rtti -fno-exceptions, so it is not a C++ engine/library according to C++ standard! It is, however, an impressive piece of work.
The ESP32 SDK (I lol'd at your "even", those Xtensa/RISCV chips can even run linux kernel!) is extremely impressive - they support enabling/disabling rtti and exceptions (obviously disabled by default, but the fact they implemented support for that is amazing). So "real C++" is possible on ESP32, which is good to know.
For comparision, here are the minimum SQLite dependencies from the submitted article: memcmp() memcpy() memmove() memset() strcmp() strlen() strncmp()
Of course you could run javascript and erlang on MCU too, but is that API better than C? Your claim of "skill issue" sounds like RedBull challenge. Please let us unskilled people simply call library functions.
No it's not. Arch is the best. https://wiki.archlinux.org/title/Arch_is_the_best
C is like a classic car. It's cool and you might have fun with it, but if something goes wrong out there, there's a significant chance you'll end up in a very bad shape.
What! Classic cars are preferred. I'd trust an old muscle car more than a shiny new one ANY DAY OF THE WEEK. Ah gosh. New cars are trash. Never in my life had a good experience with a new car besides the smell.
I've had many new cars and the car I drive today is a classic, I love it. Takes me everywhere, replace the parts and still goes. No rust. Can't say the same for a new car. I had a brand new truck a few years ago and I sold it. I had way too many problems. Doors being not aligned, electrical problems. Just shit all around. I had a Ford Focus ST as well for a for awhile too and I hated it. I couldn't even go in a car wash without it leaking through the roof, new car as well. Crazy!!!
Sounds like it's an accurate analogy after all haha
i haven't seen any rust projects yet that maximize embeddability, portability, space and transparency. maybe an argument could be made for the linux kernel stuff, but nothing like a sqlite that gets compiled and included in a million things on a million platforms ranging from high level interpreter wrappers on general purpose computers to teeny microcontrollers where the operating system is a library or some jump targets in rom.
that said, just because c is best for sqlite today, doesn't mean c is best for you or what you're trying to do.
This submission title has been editorialized, contrary to the HN guidelines. The article title is actually "Why Is SQLite Coded In C".
Also, the article appears to be quite old, so the submission should have a year appended.
See also previous discussions, the last of which was only a few months ago: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
It was updated in 2025.
I just did a diff with the Wayback Machine. Have you? The only changes were a few minor typos fixed.
I would strongly urge you to read and respect the HN guidelines and FAQ. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsfaq.html
What the post says is that you can do software engineering in C and be portable.
C is good
Yup. But, they're all good in their own way. They're just a means to an end. If the end result is good, reliable, maintainable: whatever you use is good.
The actual title is "Why Is SQLite Coded In C"
I love C and Assembly and I'm impressed by the things people can build in those languages and often (not always) I can understand the code written in it. It's also true that code written in it is available to every other language. For that I'm very happy, as I'm mostly working in higher level languages that can call things like sqlite.
Just imagine if all of Chromium was written in C and used simpler tools like GNU Make and Git for it's projects.
I can't imagine how writing C directly could possibly be better than using a language like Dafny and then generating C code.
Edit: Dafny: A verification language capable of enforcing invariants
Down-voting me without providing a counter comment is just pathetic.
DRH writing truth! People love to jump to Rust or C++.
Tittle should be "C is a Standard"
Title should actually be “Why Is SQLite Coded In C”, since that’s the title of the article.
Well, take "C Is Best"
For someone who might not think so they may think "Why?" and click it.
I think this makes a bit more sense.
C3 is bester?
What does “Go hates assert()” mean?
https://go.dev/doc/faq#assertions
https://go.dev/doc/faq#assertions
I long to see an sq-rust project!
Like this? https://github.com/tursodatabase/turso
Disclaimer: Credit goes to whoever mentioned this in this discussion before me.
Ada is best.
No UB, strict types, contracts that can be formally proven, runtime checks, better (than phthreds) concurrency, certifiable.
It's bitch sometimes but you'll thank it after release.
There's already attempted re-implementations of SQLite in Rust, so if it really is a good approach, time should tell.
https://turso.tech/blog/introducing-limbo-a-complete-rewrite...
Really time will tell indeed. It’s too early.
When the Rust version has the same take-up as the C version I know and trust, I might use it. Until then I'll wait. What's available now is good. I'm in no hurry to use an alternative. I like the idea of a reliable black-box, and I don't overly care how the black-box does its magic.
I'm a little surprised they're at all open to a rewrite in Rust:
> All that said, it is possible that SQLite might one day be recoded in Rust.
...followed by a list of reasons why they won't do it now. I think the first one ("Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.") is no longer valid (particularly for software that doesn't need async and has few dependencies), but the other ones probably still are.
I write Rust code and prefer to minimize non-Rust dependencies, but SQLite is the non-Rust dependency I mind the least for two reasons:
* It's so fast and easy to compile: just use the `rusqlite` crate with feature `bundled`. It builds the SQLite "amalgamation" (its entire code basically concatenated into a single .c file). No need to have bazel or cmake or whatever installed, no weird library dependency chains, etc.
* It's so well-tested that the unsafety of the language doesn't bother me that much. 100% machine branch coverage is amazing.
C is fast and maybe has predictable performance, but, for example, strcmp(), strlen(), strncmp() are not as fast (and also secure) as C++ std::string analogs, unless you don't help a bit by storing the string lengths.
> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy.
I don't think they thought about this too much. In the C code are they testing the "branch" into Undefined Behaviour?
The performance/memory security tradeoffs that C made made sense when computers were 100000 times slower and not connected to the internet but now when nearly all software is connected to the Internet it is a disaster.
I've often said (at least half jokingly) - C for systems programming, Javascript for everything else!
This artical makes the case for C as a low level language, I then offer Javascript as a functional-ish language for manipulating domain model data structures on the top.
...at what it does, couldn't agree more.
https://github.com/codr7/hacktical-c
Given they added Section 2 and 3 in response to previous commentary: https://news.ycombinator.com/item?id=16585120
it seems rather stupid to take a sub-heading as the title.
I'm certain you can think why I chose that second heading.
Yeh, clickbait
Absolutely.
This makes sense with the quality and quantity of testing they do.
https://sqlite.org/testing.html
>As of version 3.42.0 (2023-05-16), the SQLite library consists of approximately 155.8 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 590 times as much test code and test scripts - 92053.1 KSLOC.
That's an enormous test suite but considering how large the SQL spec is it makes sense.
no, triples is best!
.. one of the safe languages like.. Go.. o_O
Go is a safe language? It has garbage collection and performs checks for things like buffer overflows and use-after-free
(Memory) safe languages are allowed to guarantee memory safety at any stage, including at runtime using GC and bound checks. That makes every GC language memory safe to a reasonable extend. The novelty in Rust is that it does the same at compile time, mostly automatically.
You can have data races in "safe" Go. If you race a trivial object [such as an integer] it's just radioactive and so long as you didn't need it to have any particular value (e.g. you were just going to write it to a log anyway, or you just discard it) you're fine. However if you race a non-trivial object then that's immediately Undefined Behaviour.
Of course Go programmers will say "Just don't do that" but that's exactly what C programmers told us about bounds misses, use after free and so on...
WRONG!
Plain and simple C is, by far, one of the current _LESS WORSE_ performant alternatives which can be used, actually, from low level to large applications.
C syntax is already waaaaay to rich and complex (and ISO is a bit too much pushing feature creep over 5/10 years cycles).
That's the first time I've heard the C syntax being called "too rich". It's the epitome of succinctness IMHO (too a fault, even, or maybe I'm just old). Are you confusing it with C++? If so, you have a point.
As a Lisper I would consider C having too much syntax. 3 different kinds of brackets, a mix of prefix, suffix, and infix operators, both dot and hyphen + greater than symbol infixes for member access on structures depending on whether you're accessing members of a struct directly or from a struct pointer, semicolons at the end of every statement, the different ways of declaring imports,...
C's syntax is pretty lacking by modern standards, requiring gross things like The Lexer Hack to resolve ambiguities that other languages just don't suffer from: https://en.wikipedia.org/wiki/Lexer_hack . To say nothing of the madness that is C's type declaration syntax, necessitating tools like https://cdecl.org/ and "the spiral rule" for reading type declarations (which doesn't actually produce the correct result anyway).
So "modern standard" is to make it easier for compiler writers instead of programmer to read the code? Thanks god C designers had their priorities elsewhere.
>>"the spiral rule"
Not a problem in 99.99% of cases where it's just: type name = something;
with maybe * and [] somewhere.
Huh. I don’t think I miswrote yes I’m talking about a larger language like c++.
Forgot to switch the account?
Huh, what switch account I have one account.
hahaha
I am talking about C syntax, not absurdely grotesque ultra-complex syntax like the ones from c++, java and similar (is that true that rust syntax is not that much less worse than c++ one now?).
We need a new C, fixed, leaner and less complex: primitives are all sized (u64, u8, f64, etc), only one loop primitive (loop{}), no switch, no enum, no typedef, no typeof and other c11 _generic/etc, no integer promotion, no implicit casts (except for void* and literal numbers?), real hard compiler constants, current "const" must go away (I don't even talk about "restrict" and similar), no anonymous code block, explicit differentiation between reinterpret,runtime,etc casts?, synchronous numeric computation handling, anonymous struct/union for complex memory layouts, and everything else I am currently forgetting about.
(the expression evaluation of the C pre-processor would require serious modifications too)
We need clean and clear cut definitions, in regards of ABIs, of argument passing by value of aggregates like structs/arrays, you know, mostly for those pesky complex numbers and div_t.
We need keywords and official very-likely-to-be-inline-or-hardware-accelerated-functions, something in between the standard library and the compiler keywords, for modern hardware architecture programming like memory barriers, atomics, byte swapping, some bitwise operations (like popcnt), memcpy, memcmp, memmove, etc.
In the end, I would prefer to have a standard machine ISA (RISC-V) and code everything directly in assembly, or with very high level languages (like [ecma|java]script, lua, etc) with a interpreter coded in that standard machine ISA assembly (all that with a reasonable SDK, ofc)
New C is old B? https://en.wikipedia.org/wiki/B_(programming_language) I implemented some examples using B language. I like its typeless and simplicity. It would be nice if there was a modern and mature implementation of this language, it's a true portable assembler.
This "new C" would be severely different than B, and way closer to C... this new C is more a "sane and explicit oriented" subset of C than anything B.
>>primitives are all sized (u64, u8, f64, etc)
stdint.h already gives you that.
>> only one loop primitive (loop{}), no switch, no enum
I don't think you will find many fans of that.
>> atomics
check stdatomic.h
>>some bitwise operations (like popcnt)
Check stdbit.h in C23
Interesting! Let’s start this debate!
I love C, when I wrote my first programs in it as a teenager, I loved the simplicity, I love procedural code. Large languages like C++ and or Rust are just too much for ME. Too much package. I like writing code in a simple way, if I can do that with a small amount of tools, I will. You can learn C and be efficient in it within a couple weeks. C systems are just built better, faster, more stable, portable, and more! This is my 2 cents.
C is considered harmful. They should rewrite it in Rust.
> They should rewrite it in Rust.
Why they? You should do it.
indeed
What
They actually should. As such a rewrite went so well for sudo-rs.
The article mentions 100% code coverage with tests as one of requirements from their users, and having "safe languages" emit defensive asserts and checks when compiling correct code means 100% branch coverage is impossible. How do you propose to address it with rust?
It's either trolling or sarcasm. May be both.
Not trolling. Everyone knows C is not safe.
C is safe if you know how to write it. Jokes aside yes you need to be more careful.
Life as a whole is not safe, and not everyone seems to be aware of this.