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.
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.
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).
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.
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.
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.
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.
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?
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.
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.
you understand that stack allocation can OOM too?
Can C gracefully recover from running out of stack space?
Or in short: no, C is no better than Rust at gracefully recovering from stack overflow, either in theory or in practice.
Great to know!
Off topic: This CSS improves the usability of that page:
ul.threadlist li:hover > a {
color: red;
}
ul.threadlist li.origin > a {
display: block;
background: rgb(205, 216, 216);
font-weight: normal;
padding: 1px 6px;
margin: 1px -6px;
}Should be:
ul.threadlist li.origin a {
display: block;
background: rgb(205, 216, 216);
font-weight: normal;
padding: 1px 6px;
margin: 1px -6px;
}Good point.
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.
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;
let r#async = 5;
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?
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 is not‡ dynamically linked. The whole tree is compiled from source every time. The same compiler compiles all editions of the language together, and it is exactly the same as py3 interpreting a py2 script and allowing a py3 script to call it or vice versa.
Very few features are restricted to the 2024 edition; only those that actively introduce or leverage breaking changes. Most things released since 2024 are available in 2015 edition. If you want to upgrade to 2024 edition, that is a manifest flag; your code may break when you change it, and there's incompatibility lints available on the lower editions to tell you what will break when that happens and how to fix it.
> 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.
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.
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 */
}
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.
int main() {
printf("Sans headers, this is valid C89.");
return 0;
}
int printf();
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.
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.
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.
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.
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.
Both Pin Projection and the handling of async are pretty bad in my opinion and I write a lot of Rust code. The syntax is also slowly getting very funky with horrible additions like the recent `+ use <'a>` snytax. I also agree with the orphan rule but it makes a lot of code very ugly, fast.
> 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.
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++.
> 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.
This is one of the things I love about Clojure. It's a simple, elegant, stable language.
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
> 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.
Eh. I write quite a bit of Rust and this story is not as simple as you tell it.
> 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.
> 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
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
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
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?
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.
"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.
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.
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.
What the post says is that you can do software engineering in C and be portable.
Actual title: Why Is SQLite Coded In C
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.
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.
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.
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.
Maybe DRH will see this and update the page !
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.
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:
> 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…
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.
> 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?!
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.
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.
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.
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.
> 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:
let val = arr[i]
cmp rdx, rsi ; Compare i (rdx) with length (rsi)
jae .Lpanic_label ; Jump if i >= length
; later...
.Lpanic_label:
call core::panicking::panic_bounds_check
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.
> 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 actual title is "Why Is SQLite Coded In C"
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.
> 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?
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...
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.
*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,
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.
> 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?
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
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.
No it's not. Arch is the best. https://wiki.archlinux.org/title/Arch_is_the_best
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.
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
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.
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.
DRH writing truth! People love to jump to Rust or C++.
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.
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?
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.
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.
Absolutely.
...at what it does, couldn't agree more.
no, triples is best!
[dead]
.. 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
[dead]
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.
It is a complex matter. But it narrows down to one thing: the number of real-life alternative compilers, which is in direct relation to this benchmark: can a small team of average devs, or an individual average dev, develop with reasonable effort and time and near 0 technical dependence, a real-life alternative of a compiler. It is a protection of developer/vendor lock-in, in the SDK realm.
Most honnest software developers know the answer: for any computer language with an ultra-complex syntax(c++,etc) or which requires an intrusive and tricky runtime (java,etc), the answer is obvsiously "nope". But we all know, for plain and simple C, the answer is "yes" (have a look at cproc and QBE, or scc, tinycc, etc). The new C I am talking about should reduce the effort related to such compiler developement and "fix" all C implicit stuff hiding too much things, kind of error prone.
There is a huge pitfall though: linux is not coded in plain and simple C, but in GCC C... which is VERY different, a GCC C alternative, is clancg/llvm, those are not to be called reasonable in any capacity.
If linux code would care about having clean assembly source files on top of plain and simple C code, unfortunately it would be slower. BUT, you guess what, for the ability to compile linux with an _REAL ALTERNATIVE_ C compiler (and a small assembler), I will happily accept to have a "slower" kernel.
C is considered harmful. They should rewrite it in Rust.
> They should rewrite it in Rust.
Why they? You should do it.
indeed
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?
What
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.
> 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.
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.
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.
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.
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.
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.
No commit for 7 years but https://tinygo.org/docs/reference/microcontrollers/ is up to date.
> 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.
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?
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.
Actually, GO is ported to microcontrollers with Tinygo. Even u-root works on microcontrollers nowadays.
For the more bulky processors, there's also tamago.
Good point. Many of these other languages claim to be "successors", but are really C++ alternatives, that can have very different programming philosophies, goals, and use cases.
> I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu
I spent five years working at a company (Materialize) whose main product is entirely in Rust. Since then I work at a company (Polar Signals) where sadly I have to use C and Go, but the main backend storage layer is in Rust. And several of our customers use Rust and it would be a show-stopping bug for them if our product stopped working on Rust codebases.
Besides all that, plenty of companies you’ve heard of are now writing large amounts of new code in Rust — most notably Meta and Amazon. Large parts of Firefox are in Rust and have been for years.
Ubuntu coreutils is underselling it a bit.
> Until now, the only real world usage was for coreutils in Ubuntu,
This is simply not true, there are millions of lines of Rust code running in production at the largest tech companies in the world.
> 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.
technically, Kotlin can use VirtualThreads like it can use any other Java Api (when being compiled to JVM bytecode).[1] If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads. So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines). What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions! My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)
[1] https://void2unit.onrender.com/post/virtualthreads-in-kotlin...
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.
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!
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.
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.
> 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, 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".
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.
> 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++.
> 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.
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?
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.
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.
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.
>>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.
There is a reason for this. A lot of libraries were written at a time when the Rust compiler either rejected sound and safe code so you have to reach for unsafe, or `core` didn't yet deliver safe abstractions.
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.
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?
For 1) The necessary safety guarantees downgrade to the level available in C all the time.
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?
> 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
But you need to control for lines of code at the very least — otherwise you're comparing apples to oranges
That is no base line. That is a comparison with no statistical value.
> 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
HN is not for flamebait.
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.
> 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
Department of Waterfall?
No. I don't.
https://blog.pictor.us/rust-is-do-178-certifiable/
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.
> 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.
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.
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.
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?
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.
Smalltalk, the original OOP lang, is "both", at least if you're not one of those people who thinks FP c'est impossible if it's not ML or haskell
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.
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 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?
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.
> a bit less in recent years, to use OOP.
That’s an understatement.
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...
Rust programmers have this "holier than you" attitude that is so toxic. It's essentially wokeism for programming. No wonder it originates from San Francisco, from all places.
The language itself features interesting ideas, many of them borrowed (pun intended) from Haskell, so not that new after all. But the community behavior proved consistently abysmal. A real put off.
>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.