14 ms·

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be graduall

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

stingraycharles 11mo ago
It’s available on more obscure platforms than Rust, and more people are familiar with it. I wouldn’t say it’s inevitable that everything will be rewritten in Rust, at the very least this will this decades. C has been with us for more than half a century and is the foundation of pretty much everything, it will take a long time to migrate all that. More likely is that they will live next to each other for a very, very long time.
drnick1 11mo ago
Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
- vlovich123 11mo ago
  I can’t think of many real world production systems which don’t have a rust target. Also I’m hopeful the GCC backend for rustc makes some progress and can become an option for the more esoteric ones
  - MobiusHorizons 11mo ago
    It's mostly embedded / microcontroller stuff. Things that you would use something like SDCC or a vendor toolchain for. Things like the 8051, stm8, PIC or oddball things like the 4 cent Padauk micros everyone was raving about a few years ago. 8051 especially still seems to come up from time to time in things like the ch554 usb controller, or some NRF 2.4ghz wireless chips.
    - vlovich123 11mo ago
      Those don’t really support C in any real stretch, talking about general experience with microcontrollers and closed vendor toolchains; it’s a frozen dialect of C from decades ago which isn’t what people think of when they say C (usually people mean at least the 26 year old C99 standard but these often at best support C89 or even come with their own limitations)
      - MobiusHorizons 11mo ago
        It’s still C though, and rust is not an option. What else would you call it? Lots of c libraries for embedded target C89 syntax for exactly these reasons. Also for what it’s worth, SDCC seems to support very modern versions of C (up to C23), so I also don’t think that critique is very valid for the 8051 or stm8. I would argue that c was built with targets like this in mind and it is where many of its quirks that seem so anachronistic today come from (for example int being different sizes on different targets)
  - phire 11mo ago
    There aren't really any "systems programming" platforms anywhere near production that doesn't have a workable rust target. It's "embedded programming" where you often start to run into weird platforms (or sub-platforms) that only have a c compiler, or the rust compiler that does exist is somewhat borderline. We are sometimes talking about devices which don't even have a gcc port (or the port is based on a very old version of gcc). Which is a shame, because IMO, rust actually excels as an embedded programming language. Linux is a bit marginal, as it crosses the boundary and is often used as a kernel for embedded devices (especially ones that need to do networking). The 68k people have been hit quite hard by this, linux on 68k is still a semi-common usecase, and while there is a prototype rust back end, it's still not production ready.
    - vlovich123 11mo ago
      There’s also I believe an effort to target C as the mid level although I don’t know the state / how well it’ll work in an embedded space anyway where performance really matters and these compilers have super old optimizers that haven’t been updated in 3 decades.
  - pjmlp 11mo ago
    Commercial embedded OSes, game consoles, for example.
    - vlovich123 11mo ago
      Seems like game consoles for example has been accomplished by at least one dedicated team even if the vendor nor upstream provide official support: https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_kyren_from_chucklefish_we_make_and/ https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky... I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and there’s probably almost nothing wrong with the stock toolchain in terms of generating working binaries: PlayStation and Switch are FreeBSD (x86 vs ARM respectively) and Xbox is x86 Windows, all of which are supported platforms.
      - pjmlp 11mo ago
        Being supported on a games console means that you can produce binaries that are able to go through the whole approval process, and there is day 1 support for anything that is provided by the console vendor. Otherwise is yak shaving instead of working on the actual game code. Some people like to do that, that is how new languages like Rust get adoption, however they are usually not the majority, hence why mainstream adoption without backing from killer projects or companies support is so hard, and very few make it. Also you will seldom see anyone throw away the confort of Unreal, Unity or even Godot tooling, to use Rust instead, unless they are more focused on proving the point the game can be made in Rust, than the actual game design experience.
      - bob1029 11mo ago
        > Switch Good luck shipping arbitrary binaries to this target. The most productive way for an indie to ship to Nintendo in 2025 is to create the game Unity and build via the special Nintendo version of the toolchain. How long do we think it would take to fully penetrate all of these pipeline stages with rust? Particularly Nintendo, who famously adopts the latest technology trends on day 1. Do we think it's even worthwhile to create, locate, awaken and then fight this dragon? C# with incremental GC seems to be more than sufficient for a vast majority of titles today.
- brokencode 11mo ago
  What other newfangled alternative to C was ever adopted in the Linux kernel? I have no doubt C will be around for a long time, but I think Rust also has a lot of staying power and won’t soon be replaced.
  - ottah 11mo ago
    I wouldn't be surprised to see zig in the kernel at some point
    - littlestymaar 11mo ago
      IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel. Rust is different because it both: - significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities. - And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld. That doesn't mean Zig is a bad language for a particular project, just that it's not worth adding to an already massive project like the Linux kernel. (Especially a project that already have two languages, C and now Rust).
      - sayamqazi 11mo ago
        Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??
        littlestymaar 11mo ago
        Not zero, but Rust-based kernels (see redox, hubris, asterinas, or blog_os) have demonstrated that you only need a small fraction of unsafe code to make a kernel (3-10%) and it's also the least likely places to make a memory-related error in a C-based kernel in the first place (you're more likely to make a memory-related error when working on the implementation of an otherwise challenging algorithm that has nothing to do with memory management itself, than you are when you are explicitly focused on the memory-management part). So while there could definitely be an exploitable memory bug in the unsafe part of the kernel, expect those to be at least two orders of magnitude less frequent than with C (as an anecdotal evidence, the Android team found memory defects to be between 3 and 4 orders of magnitude less in practice over the past few years).
- thayne 11mo ago
  > very slow compilation times That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.
  - Yiin 11mo ago
    typescript transpilation to js is nearly instant, it's not comparable
    - baq 11mo ago
      Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.
    - thayne 11mo ago
      Rust compilation is also almost instant, if you have a relatively small project. It's only when you get very large projects that compilation time becomes a problem. If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]? [1]: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
  - timow1337 11mo ago
    Compared to C, rust compiles much slower. This might not matter on performant systems, but when resources are constrained you definitely notice it. And if the whole world is rewritten in Rust, this will have a non-significant impact on the total build time of a bunch of projects.
    - gf000 11mo ago
      Runtime memory issues probably have a significantly higher total cost. But of course that doesn't negate this cost, but building can always be done on another machine as a way to circumvent the problem.
    - 11mo ago
- jcranmer 11mo ago
  There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran, and BASIC-with-an-asterisk, are the only languages to really have done so), and Perl is the only one I would risk money on departing in my lifetime. I do firmly expect that we're less than a decade out from seeing some reference algorithm be implemented in Rust rather than C, probably a cryptographic algorithm or a media codec. Although you might argue that the egg library for e-graphs already qualifies.
  - qalmakka 11mo ago
    We're already at the point where in order to have a "decent" desktop software experience you _need_ Rust too. For instance, Rust doesn't support some niche architectures because LLVM doesn't support them (those architectures are now exceedingly rare) and this means no Firefox for instance.
  - tormeh 11mo ago
    A system only needs one programming language to be useful, and when there's only one it's basically always C.
    - trinix912 11mo ago
      A C compiler is also relatively easy to implement (compared to a Rust compiler) if you're making your own hobby OS with its own C compiler and libc.
    - deleted 11mo ago
      [deleted]
  - teruakohatu 11mo ago
    > There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash Java, really? I don’t think Java has been essential for a long time. Is Perl still critical?
- blintz 11mo ago
  Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?
  - aw1621107 11mo ago
    rustc can use a few different backends. By my understanding, the LLVM backend is fully supported, the Cranelift backend is either fully supported or nearly so, and there's a GCC backend in the works. In addition, there's a separate project to create an independent Rust frontend as part of GCC. Even then, there are still some systems that will support C but won't support Rust any time soon. Systems with old compilers/compiler forks, systems with unusual data types which violate Rust's assumptions (like 8 bit bytes IIRC)
  - loeg 11mo ago
    There are a number of oddball platforms LLVM doesn't support, yeah.
  - einpoklum 11mo ago
    Many organizations and environments will not switch themselves to LLVM to hamfist compiled Rust code. Nor is the fact of LLVM supporting something in principle means that it's installed on the relevant OS distribution.
    - simonask 11mo ago
      Using LLVM somewhere in the build doesn't require that you compile everything with LLVM. It generates object files, just like GCC, and you can link together object files compiled with each compiler, as long as they don't use compiler-specific runtime libraries (like the C++ standard library, or a polyfill compiler-rt library). `clang-cl` does this with `cl.exe` on Windows.
    - oblio 11mo ago
      If you're developing, you generally have control over the development environment (+/-) and you can install things. Plus that already reduces the audience: set of people with oddball hardware (as someone here put it) intersected with the set of people with locked down development environments. Let alone the fact that conceptually people with locked down environments are precisely those would really want the extra safety offered by Rust. I know that real life is messy but if we don't keep pressing, nothing improves.
- mustache_kimono 11mo ago
  > Every system under the Sun has a C compiler... My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative. This is still the worst possible argument for C. If C persists in places no one uses, then who cares?
  - jazzyjackson 11mo ago
    I think you didn't catch their drift C will continue to be used because it always has been and always will be available everywhere, not only places no one uses :/
    - mustache_kimono 11mo ago
      > C will continue to be used because it always has been and always will be available everywhere Yes, you can use it everywhere. Is that what you consider a success?
      - AceJohnny2 11mo ago
        ... yes?
        mustache_kimono 11mo ago
        >> Yes, you can use it everywhere. Is that what you consider a success? > ... yes? Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers. My hope is that competition from Rust makes using C better/easier/more productive, but I have my doubts as to whether it will move C to make changes.
        qwm 11mo ago
        Sometimes it's nice to know that something will run and compile reliably far into the future. That's a nice thing to have, and wide support for the language and its relatively unchanging nature make it reliable.
- AceJohnny2 11mo ago
  > My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative. if only due to the Lindy Effect https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
  - qwm 11mo ago
    Sure, but the reason tends to be that if you want something to run everywhere, C is your best bet.
- pjmlp 11mo ago
  As mentioned in another thread, POSIX requires the presence of a C compiler, https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
  - eru 11mo ago
    Though to be fair, POSIX is increasingly outdated.
    - pjmlp 11mo ago
      GNU/Linux isn't the only system out there, POSIX last update was in 2024 (when C requirement got upgraded to C17), and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Still, who supports POSIX is expected to have a C compiler available if applying for the OpenGroup stamp.
      - eru 11mo ago
        > GNU/Linux isn't the only system out there, [...] Yes? I'm especially keen on the project to make just 'Linux' without any Gnu components. Jokes aside, yes, other operating systems exist. > [...] and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Well, also on modern hardware in general. POSIX's idea about storage abstractions don't gel well with modern hardware. Well, not just modern hardware: atime has been cast aside since time immemorial. But lots of the other ideas are also dropping by the wayside. In practice, we get something like 'POSIX-y' or 'close-enough-to-POSIX', which doesn't get a stamp from OpenGroup. I think Linux largely falls in that boat. But regardless of that distinction, a C compiler is very much part of the informal 'close-enough-to-POSIX' class. It's a bit of a shame that Unix has retarded operating system research for so long. Fortunately, the proliferation of virtual machines and hypervisors have re-invigorated the field. Just pretend that your hypervisor is your nano-kernel and your VMs are your processes. No need to run a full on Linux kernel in your VM, you can just have enough code running for your webserver or database etc, no general kernel needed. See eg https://mirage.io/ https://mirage.io/
- archargelod 11mo ago
  One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*
  - aw1621107 11mo ago
    The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI. Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.
  - sophacles 11mo ago
    Perhaps we can finally stop defining abis in terms of c structs!
    - qwm 11mo ago
      If only Rust had a spec to do that with
      - sophacles 11mo ago
        I don't think they should be defined in terms of any programming language. They should be defined in terms of the architecture - bits, bytes, words and instructions, along with semantics of use. Like we do with networking protocols and file formats.
      - steveklabnik 11mo ago
        It's being worked on! https://github.com/rust-lang/rfcs/pull/3470 https://github.com/rust-lang/rfcs/pull/3470
jcranmer 11mo ago
C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, and the pointer size type are all the same type, which is not the case for a couple of architectures; it's also the case that things like segmented pointers don't really work in Rust (of course, they barely work in C, but barely is more than nothing).
- raggi 11mo ago
  That first sentence though. Bitfields and ABI alongside each other. Bitfield packing rules get pretty wild. Sure the user facing API in the language is convenient, but the ABI it produces is terrible (particularly in evolution).
  - mjevans 11mo ago
    I would like a revision to bitfields and structs to make them behave the way a programmer things, with the compiler free to suggest changes which optimize the layout. As well as some flag that indicates the compiler should not, it's a finalized structure.
- dataflow 11mo ago
  In what architecture are those types different? Is there a good reason for it there architecturally, or is it just a toolchain idiosyncrasy in terms of how it's exposed (like LP64 vs. LLP64 etc.)?
  - jcranmer 11mo ago
    CHERI has 64-bit object size but 128-bit pointers (because the pointer values also carry pointer provenance metadata in addition to an address). I know some of the pointer types on GPUs (e.g., texture pointers) also have wildly different sizes for the address size versus the pointer size. Far pointers on segmented i386 would be 16-bit object and index size but 32-bit address and pointer size. There was one accelerator architecture we were working that discussed making the entire datapath be 32-bit (taking less space) and having a 32-bit index type with a 64-bit pointer size, but this was eventually rejected as too hard to get working.
scottyah 11mo ago
I think it'll be less like telegram lines- which were replaced fully for a major upgrade in functionality, and more like rail lines- which were standardized and ubiquitous, still hold some benefit but mainly only exist in areas people don't venture nearly as much.
heddelt 11mo ago
[flagged]
mmooss 11mo ago
Before we ask if almost all things old will be rewritten in Rust, we should ask if almost all things new are being written in Rust or other memory-safe languages? Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?
- sho_hn 11mo ago
  I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.
  - mmooss 11mo ago
    People can learn Rust at any age. The reality is that experienced people often are more hesitant to learn new things. I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to make the choice, you are less likely to make yourself change (and more likely to make the junior people change, when there's a trade-off). Power corrupts, even on that small scale. There's also a good argument for being stubborn and jaded: You have 30 years perfecting the skills, tools, efficiencies, etc. of C++. For the new project, even if C++ isn't as good a fit as Rust, are you going to be more efficient using Rust? How about in a year? Two years? ... It might not be worth learning Rust at all; ROI might be higher continuing to invest in additional elite C++ skills. Certainly that has more appeal to someone who knows C++ intimately - continue to refine this beautiful machine, or bang your head against the wall? For someone without that investment, Rust might have higher ROI; that's fine, let them learn it. We still need C++ developers. Morbid but true, to a degree: 'Progress happens one funeral at a time.'
    - sho_hn 11mo ago
      I still think you're off the mark. Again, most existing Rust developers are not "blank slate Rust developers". That they do not rush out to rewrite all of their past projects in C++ may be more about sunk costs, and wanting to solve new problems with from-scratch development.
nibman 11mo ago
[dead]
QuiEgo 11mo ago
Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.
- accelbred 11mo ago
  Lack of stable build-std and panic_immediate_abort features result in a order of magnitude size difference for some rust code I have. Using no_std brings it to ~60kb from ~350kb, but still more than the ~40kb for the C version
  - torginus 11mo ago
    Afaik despite Rust not having exceptions, panic still unwinds the stack and executes 'drop'-s the same way C++ does, which means the code retains much of the machinery necessary to support exceptions.
    - dwattttt 11mo ago
      The panic_immediate_abort feature should prevent this. build-std is the name of the feature that recompiles the Rust standard libraries with your chosen profile, so the combination of these two features should result in no unwinding code bloat.
      - torginus 11mo ago
        Are all crates compatible with this feature?
        dwattttt 11mo ago
        It's possible for a crate to assume there will be unwinding, but given the Rust communities general attitude to exceptions it's not common. By default, all it means is that unwinding the stack doesn't happen, so Drop implementations don't get called. Which _can_ result in bugs, but they're a fairly familiar kind: it's the same kind of fault if a process is aborted (crashes?), and it doesn't get a chance to finalise external resources. EDIT: to clarify, the feature isn't really something crates have to opt in to support
obviouslynotme 11mo ago
A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript. There will be small niches leftover: * Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers. * OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky. * Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best. * High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go. * Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it. * High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.
- tayo42 11mo ago
  Rust isn't that complex unless your pulling in magical macro libraries or dealing with things like pin and that stuff,which you really don't need to. It's like saying python is complex becasue you have metaclasses, but you'll never need to reach for them.
- scq 11mo ago
  Rust is already making substantial inroads in browsers, especially for things like codecs. Chrome also recently replaced FreeType with Skrifa (Rust), and the JS Temporal API in V8 is implemented in Rust.
- aw1621107 11mo ago
  > No memory allocation means no Rust benefits. This isn't really true; otherwise, there would be no reason for no_std to exist. Data race safety is independent of whether you allocate or not, lifetimes can be handy even for fixed-size arenas, you still get bounds checks, you still get other niceties like sum types/an expressive type system, etc. > OS / Kernel - Nearly all of the relevant code is unsafe. I think that characterization is rather exaggerated. IIRC the proportion of unsafe code in Redox OS is somewhere around 10%, and Steve Klabnik said that Oxide's Hubris has a similarly small proportion of unsafe code (~3% as of a year or two ago) [0] > Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Technically speaking, Rust already has. There has been Rust in Firefox for quite a while now, and Chromium has started allowing Rust for third-party components. [0]: https://news.ycombinator.com/item?id=42312699 https://news.ycombinator.com/item?id=42312699 [1]: https://old.reddit.com/r/rust/comments/bhtuah/production_deployment_of_rust_in_hft_system_at/ https://old.reddit.com/r/rust/comments/bhtuah/production_dep...
QuiEgo 11mo ago
Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.
- goku12 11mo ago
  That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned. C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler. People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.
  - Surac 11mo ago
    So you try to say c is for good programmers only and rust let also the idiots Programm? I think that’s the wrong way to argue for rust. Rust catches one kind of common problem but but does not magically make logic errors away.
    - ykonstant 11mo ago
vbezhenar 11mo ago
For my hobby code, I'm not going to start writing Rust anytime soon. My code is safe enough and I like C as it is. I don't write software for martian rovers, and for ordinary tasks, C is more ergonomic than Rust, especially for embedded tasks. For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite number of hoops and incomplete rust ports, I'll just use official SDK and C. If it would be the opposite, I would be using Rust, but I don't think that would happen in the next 10 years. Just like C++ never killed C, despite being perfect replacement for it, I don't believe that Rust would kill C, or C++, because it's even less convenient replacement. It'll dilute the market, for sure.
- anticrymactic 11mo ago
  > Just like C++ never killed C, despite being perfect replacement for it I think c++ didn't replace C because it is a bad language. It did not offer any improvements on the core advantages of C. Rust however does. It's not perfect, but it has a substantially larger chance of "replacing" C, if that ever happens.
  - NetMageSCW 11mo ago
    I don’t agree that C++ is a bad language, though it has been standardized to death into a bad language. But the whole point is for C++ to not be worse than C while offering a lot more, which I think it does well. Of course, my last serious use of C++ was a little after release E…
greesil 11mo ago
Shitloads of already existing libraries. For example I'm not going to start using it for Arduino-y things until all the peripherals I want have drivers written in Rust.
- littlestymaar 11mo ago
  Why? You can interact with C libraries from Rust just fine.
  - LtWorf 11mo ago
    But you now have more complexity and no extra safety.
    - timeon 11mo ago
      You have extra safety in new code.
    - pornel 11mo ago
      If you create wrappers that provide additional type information, you do get extra safety and nicer interfaces to work with.
    - dwattttt 11mo ago
      That's not really the case. Not all C APIs are inherently unsafe by construction, and I've always appreciated when someone has wrapped a C library and produced two crates: - a pure binding crate, which exposes the C lib libraries API, and - a wrapper library that performs some basic improvements Stuff in the second category typically includes adding Drop impls to resources that need to be released, translating "accepts pointer + len" into "accepts slices" (or vice versa on return), and "check return value of C call and turn it into a Result, possibly with a stringified error". All of those are also good examples of local reasoning about unsafety. If a C API returns a buffer + size, it's unsafe to turn it into a reference/slice. But if you check the function succeeded, you unsafely make the slice/reference, and return it from a safe function. If it crashes, you've either not upheld the C calls preconditions (your fault, check how to call the C function), or the C code has a bug (not your fault, the bug is elsewhere).
keyle 11mo ago
C is fun to write. I can write Rust, but I prefer writing C. I prefer compiling C, I prefer debugging C. I prefer C. It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?
- IshKebab 11mo ago
  > I prefer debugging C I prefer not having to debug... I think most people would agree with that.
  - gjajric 11mo ago
    [dead]
    - jkelleyrtp 11mo ago
      https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c... better to crash than leak https keys to the internet
      - gjajric2 11mo ago
        [dead]
  - ykonstant 11mo ago
    I prefer a billion dallars tax free, but here we are:(
    - pornel 11mo ago
      In Rust dev, I haven't needed Valgrind or gdb in years, except some projects integrating C libraries. Probably kernel dev isn't as easy, but for application development Rust really shifts majority of problems from debugging to compile time.
0xbadcafebee 11mo ago
It's a bit like asking if there is any significant advantage to ICE motors over electric motors. They both have advantages and disadvantages. Every person who uses one or the other, will tell you about their own use case, and why nobody could possibly need to use the alternative. There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re-creating it with the "new thing". And the "old thing" has some advantages the "new thing" doesn't have. So some very specific applications will keep using the "old thing". Other applications will use the "new thing" as it is convenient. To answer your second question, nothing is inevitable, except death, taxes, and the obsolescence of machines. Rust is the new kid on the block now, but in 20 years, everybody will be rewriting all the Rust software in something else (if we even have source code in the future; anyone you know read machine code or punch cards?). C'est la vie.
- NetMageSCW 11mo ago
  Machine code: Yes. Punched cards: easy - every punch has the character it represents at the top of the card.
  - deleted 11mo ago
    [deleted]
s_ting765 11mo ago
You mean safer languages like Fil-C.
biorach 11mo ago
There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C
- ViewTrick1002 11mo ago
  Or just build a tested unsafe implementation as a library. For example the Linked List in the standard library. https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#481 https://doc.rust-lang.org/src/alloc/collections/linked_list....
  - mjlawson 11mo ago
    I think that misses the point though. C trusts you to design your own linked list. It also trusts your neighbor, your kid, your LLM, you, your dog, another linked list...
  - biorach 11mo ago
    Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig is probably the best modern choice. The TigerBeetle people chose Zig for these reasons, various resources on the net explain their motivations.
    - ViewTrick1002 11mo ago
      The point with the linked list is that it is perfectly valid to use unsafe to design said ”tailored data structure with internal cross-reference or what not” library and then expose a safe interface. If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way. That is how all standard library collections in Rust works. They’ve just gone to the length of formally verifying parts of the code to ensure performance and safety.
sniggler 11mo ago
[dead]
antioxide 11mo ago
you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc. there u can likely explore well the boundaries where rust does and does not work. people have all kind of opinions. mine is this: if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems rust solves arent bad, just solved in a way thats way more complicated than writing same (safe) C code. a language is not unsafe. you can write perfectly shit code in rust. and you can write perfectly safe code in C. people need to stop calling a language safe and then reimplementing other peoples hard work in a bad way creating whole new vulnerabilities.
- herni 11mo ago
  I disagree. Rust shines when you need perform "unsafe" operations. It forces programmers to be explicit and isolate their use of unsafe memory operations. This makes it significantly more feasible to keep track of invariants. It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is bad.
  - gjajric 11mo ago
    [flagged]
    - K0nserv 11mo ago
      1. This doesn't really matter for the argument. Most of the time you can audit unsafe blocks, in some instances the invariants you are upholding require you to consider more code. The benefit is still that you can design safe interfaces around these smaller bits of audited code. 2. I agree it's harder, I feel like most of the community knows and recognises this. > Maybe Rust proponents should spend more time on making unsafe Rust easier and more ergonomic, instead of effectively *undermining safety and security*. Unless the strategy is to trick as many other people as possible into using Rust, and then hope those people fix the issues for you, a common strategy normally used for some open source projects, not languages. I don't think there is any evidence that Rust is undermining safety and security. In fact all evidence shows it's massively improving these metrics wherever Rust replaces C and C++ code. If you have evidence to the contrary let's see it.
stabbles 11mo ago
A C compiler is easier to bootstrap than a Rust compiler.
qsera 11mo ago
>does C hold any significant advantage over Rust Yes, it's lots of fun. rust is Boring. If I want to implement something and have fun doing it, I ll always do it in C.
StopDisinfo910 11mo ago
Depends of what you do. Rust has a nice compiler-provided static analyzer using annotation to do life time analysis and borrow checking. I believe borrow checking to be a local optima trap when it comes to static analysis and finds it often more annoying to use than I would like but I won't argue it's miles better than nothing. C has better static analysers available. They can use annotations too. Still, all of that is optional when it's part of Rust core language. You know that Rust code has been successfully analysed. Most C code won't give you this. But if it's your code base, you can reach this point in C too. C also has a fully proven and certified compiler. That might be a requirement if you work in some niche safety critical applications. Rust has no equivalent there. The discussion is more interesting when you look at other languages. Ada/Spark is for me ahead of Rust both in term of features and user experience regarding the core language. Rust currently still have what I consider significant flaws: a very slow compiler, no standard, support for a limited number of architectures (it's growing), it's less stable that I consider it should be given its age, and most Rust code tends to use more small libraries than I would personaly like. Rust is very trendy however and I don't mean that in a bad way. That gives it a lot of leverage. I doubt we will ever see Ada in the kernel but here we are with Rust.
otikik 11mo ago
Ubiquity is still a big one. There's many, many places where C exists that Rust has not reached yet.
pjmlp 11mo ago
Yes it does, alongside C++, Rust isn't available everywhere. There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon. POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,... Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded. Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence. Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.
- Philpax 11mo ago
  I agree with you for the most part, but it's worth noting that those standards can expose a C API/ABI while being primarily implemented in and/or used by non-C languages. I think we're a long way away from that, but there's no inherent reason why C would be a going concern for these in the Glorious RIIR Future:tm:.

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

stingraycharles 11mo ago

It’s available on more obscure platforms than Rust, and more people are familiar with it. I wouldn’t say it’s inevitable that everything will be rewritten in Rust, at the very least this will this decades. C has been with us for more than half a century and is the foundation of pretty much everything, it will take a long time to migrate all that. More likely is that they will live next to each other for a very, very long time.

drnick1 11mo ago

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

vlovich123 11mo ago
I can’t think of many real world production systems which don’t have a rust target. Also I’m hopeful the GCC backend for rustc makes some progress and can become an option for the more esoteric ones
- MobiusHorizons 11mo ago
  It's mostly embedded / microcontroller stuff. Things that you would use something like SDCC or a vendor toolchain for. Things like the 8051, stm8, PIC or oddball things like the 4 cent Padauk micros everyone was raving about a few years ago. 8051 especially still seems to come up from time to time in things like the ch554 usb controller, or some NRF 2.4ghz wireless chips.
  - vlovich123 11mo ago
    Those don’t really support C in any real stretch, talking about general experience with microcontrollers and closed vendor toolchains; it’s a frozen dialect of C from decades ago which isn’t what people think of when they say C (usually people mean at least the 26 year old C99 standard but these often at best support C89 or even come with their own limitations)
    - MobiusHorizons 11mo ago
      It’s still C though, and rust is not an option. What else would you call it? Lots of c libraries for embedded target C89 syntax for exactly these reasons. Also for what it’s worth, SDCC seems to support very modern versions of C (up to C23), so I also don’t think that critique is very valid for the 8051 or stm8. I would argue that c was built with targets like this in mind and it is where many of its quirks that seem so anachronistic today come from (for example int being different sizes on different targets)
- phire 11mo ago
  There aren't really any "systems programming" platforms anywhere near production that doesn't have a workable rust target. It's "embedded programming" where you often start to run into weird platforms (or sub-platforms) that only have a c compiler, or the rust compiler that does exist is somewhat borderline. We are sometimes talking about devices which don't even have a gcc port (or the port is based on a very old version of gcc). Which is a shame, because IMO, rust actually excels as an embedded programming language. Linux is a bit marginal, as it crosses the boundary and is often used as a kernel for embedded devices (especially ones that need to do networking). The 68k people have been hit quite hard by this, linux on 68k is still a semi-common usecase, and while there is a prototype rust back end, it's still not production ready.
  - vlovich123 11mo ago
    There’s also I believe an effort to target C as the mid level although I don’t know the state / how well it’ll work in an embedded space anyway where performance really matters and these compilers have super old optimizers that haven’t been updated in 3 decades.
- pjmlp 11mo ago
  Commercial embedded OSes, game consoles, for example.
  - vlovich123 11mo ago
    Seems like game consoles for example has been accomplished by at least one dedicated team even if the vendor nor upstream provide official support: https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_kyren_from_chucklefish_we_make_and/ https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky... I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and there’s probably almost nothing wrong with the stock toolchain in terms of generating working binaries: PlayStation and Switch are FreeBSD (x86 vs ARM respectively) and Xbox is x86 Windows, all of which are supported platforms.
    - pjmlp 11mo ago
      Being supported on a games console means that you can produce binaries that are able to go through the whole approval process, and there is day 1 support for anything that is provided by the console vendor. Otherwise is yak shaving instead of working on the actual game code. Some people like to do that, that is how new languages like Rust get adoption, however they are usually not the majority, hence why mainstream adoption without backing from killer projects or companies support is so hard, and very few make it. Also you will seldom see anyone throw away the confort of Unreal, Unity or even Godot tooling, to use Rust instead, unless they are more focused on proving the point the game can be made in Rust, than the actual game design experience.
    - bob1029 11mo ago
      > Switch Good luck shipping arbitrary binaries to this target. The most productive way for an indie to ship to Nintendo in 2025 is to create the game Unity and build via the special Nintendo version of the toolchain. How long do we think it would take to fully penetrate all of these pipeline stages with rust? Particularly Nintendo, who famously adopts the latest technology trends on day 1. Do we think it's even worthwhile to create, locate, awaken and then fight this dragon? C# with incremental GC seems to be more than sufficient for a vast majority of titles today.
brokencode 11mo ago
What other newfangled alternative to C was ever adopted in the Linux kernel? I have no doubt C will be around for a long time, but I think Rust also has a lot of staying power and won’t soon be replaced.
- ottah 11mo ago
  I wouldn't be surprised to see zig in the kernel at some point
  - littlestymaar 11mo ago
    IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel. Rust is different because it both: - significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities. - And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld. That doesn't mean Zig is a bad language for a particular project, just that it's not worth adding to an already massive project like the Linux kernel. (Especially a project that already have two languages, C and now Rust).
    - sayamqazi 11mo ago
      Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??
      - littlestymaar 11mo ago
        Not zero, but Rust-based kernels (see redox, hubris, asterinas, or blog_os) have demonstrated that you only need a small fraction of unsafe code to make a kernel (3-10%) and it's also the least likely places to make a memory-related error in a C-based kernel in the first place (you're more likely to make a memory-related error when working on the implementation of an otherwise challenging algorithm that has nothing to do with memory management itself, than you are when you are explicitly focused on the memory-management part). So while there could definitely be an exploitable memory bug in the unsafe part of the kernel, expect those to be at least two orders of magnitude less frequent than with C (as an anecdotal evidence, the Android team found memory defects to be between 3 and 4 orders of magnitude less in practice over the past few years).
thayne 11mo ago
> very slow compilation times That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.
- Yiin 11mo ago
  typescript transpilation to js is nearly instant, it's not comparable
  - baq 11mo ago
    Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.
  - thayne 11mo ago
    Rust compilation is also almost instant, if you have a relatively small project. It's only when you get very large projects that compilation time becomes a problem. If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]? [1]: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
- timow1337 11mo ago
  Compared to C, rust compiles much slower. This might not matter on performant systems, but when resources are constrained you definitely notice it. And if the whole world is rewritten in Rust, this will have a non-significant impact on the total build time of a bunch of projects.
  - gf000 11mo ago
    Runtime memory issues probably have a significantly higher total cost. But of course that doesn't negate this cost, but building can always be done on another machine as a way to circumvent the problem.
  - 11mo ago
jcranmer 11mo ago
There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash (with a degree of asterisks on the last two). Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through. Leaving this set of mandatory languages is difficult (I think Fortran, and BASIC-with-an-asterisk, are the only languages to really have done so), and Perl is the only one I would risk money on departing in my lifetime. I do firmly expect that we're less than a decade out from seeing some reference algorithm be implemented in Rust rather than C, probably a cryptographic algorithm or a media codec. Although you might argue that the egg library for e-graphs already qualifies.
- qalmakka 11mo ago
  We're already at the point where in order to have a "decent" desktop software experience you _need_ Rust too. For instance, Rust doesn't support some niche architectures because LLVM doesn't support them (those architectures are now exceedingly rare) and this means no Firefox for instance.
- tormeh 11mo ago
  A system only needs one programming language to be useful, and when there's only one it's basically always C.
  - trinix912 11mo ago
    A C compiler is also relatively easy to implement (compared to a Rust compiler) if you're making your own hobby OS with its own C compiler and libc.
  - deleted 11mo ago
    [deleted]
- teruakohatu 11mo ago
  > There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash Java, really? I don’t think Java has been essential for a long time. Is Perl still critical?
blintz 11mo ago
Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?
- aw1621107 11mo ago
  rustc can use a few different backends. By my understanding, the LLVM backend is fully supported, the Cranelift backend is either fully supported or nearly so, and there's a GCC backend in the works. In addition, there's a separate project to create an independent Rust frontend as part of GCC. Even then, there are still some systems that will support C but won't support Rust any time soon. Systems with old compilers/compiler forks, systems with unusual data types which violate Rust's assumptions (like 8 bit bytes IIRC)
- loeg 11mo ago
  There are a number of oddball platforms LLVM doesn't support, yeah.
- einpoklum 11mo ago
  Many organizations and environments will not switch themselves to LLVM to hamfist compiled Rust code. Nor is the fact of LLVM supporting something in principle means that it's installed on the relevant OS distribution.
  - simonask 11mo ago
    Using LLVM somewhere in the build doesn't require that you compile everything with LLVM. It generates object files, just like GCC, and you can link together object files compiled with each compiler, as long as they don't use compiler-specific runtime libraries (like the C++ standard library, or a polyfill compiler-rt library). `clang-cl` does this with `cl.exe` on Windows.
  - oblio 11mo ago
    If you're developing, you generally have control over the development environment (+/-) and you can install things. Plus that already reduces the audience: set of people with oddball hardware (as someone here put it) intersected with the set of people with locked down development environments. Let alone the fact that conceptually people with locked down environments are precisely those would really want the extra safety offered by Rust. I know that real life is messy but if we don't keep pressing, nothing improves.
mustache_kimono 11mo ago
> Every system under the Sun has a C compiler... My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative. This is still the worst possible argument for C. If C persists in places no one uses, then who cares?
- jazzyjackson 11mo ago
  I think you didn't catch their drift C will continue to be used because it always has been and always will be available everywhere, not only places no one uses :/
  - mustache_kimono 11mo ago
    > C will continue to be used because it always has been and always will be available everywhere Yes, you can use it everywhere. Is that what you consider a success?
    - AceJohnny2 11mo ago
      ... yes?
      - mustache_kimono 11mo ago
        >> Yes, you can use it everywhere. Is that what you consider a success? > ... yes? Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers. My hope is that competition from Rust makes using C better/easier/more productive, but I have my doubts as to whether it will move C to make changes.
        qwm 11mo ago
        Sometimes it's nice to know that something will run and compile reliably far into the future. That's a nice thing to have, and wide support for the language and its relatively unchanging nature make it reliable.
AceJohnny2 11mo ago
> My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative. if only due to the Lindy Effect https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
- qwm 11mo ago
  Sure, but the reason tends to be that if you want something to run everywhere, C is your best bet.
pjmlp 11mo ago
As mentioned in another thread, POSIX requires the presence of a C compiler, https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
- eru 11mo ago
  Though to be fair, POSIX is increasingly outdated.
  - pjmlp 11mo ago
    GNU/Linux isn't the only system out there, POSIX last update was in 2024 (when C requirement got upgraded to C17), and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Still, who supports POSIX is expected to have a C compiler available if applying for the OpenGroup stamp.
    - eru 11mo ago
      > GNU/Linux isn't the only system out there, [...] Yes? I'm especially keen on the project to make just 'Linux' without any Gnu components. Jokes aside, yes, other operating systems exist. > [...] and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Well, also on modern hardware in general. POSIX's idea about storage abstractions don't gel well with modern hardware. Well, not just modern hardware: atime has been cast aside since time immemorial. But lots of the other ideas are also dropping by the wayside. In practice, we get something like 'POSIX-y' or 'close-enough-to-POSIX', which doesn't get a stamp from OpenGroup. I think Linux largely falls in that boat. But regardless of that distinction, a C compiler is very much part of the informal 'close-enough-to-POSIX' class. It's a bit of a shame that Unix has retarded operating system research for so long. Fortunately, the proliferation of virtual machines and hypervisors have re-invigorated the field. Just pretend that your hypervisor is your nano-kernel and your VMs are your processes. No need to run a full on Linux kernel in your VM, you can just have enough code running for your webserver or database etc, no general kernel needed. See eg https://mirage.io/ https://mirage.io/
archargelod 11mo ago
One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*
- aw1621107 11mo ago
  The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI. Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.
- sophacles 11mo ago
  Perhaps we can finally stop defining abis in terms of c structs!
  - qwm 11mo ago
    If only Rust had a spec to do that with
    - sophacles 11mo ago
      I don't think they should be defined in terms of any programming language. They should be defined in terms of the architecture - bits, bytes, words and instructions, along with semantics of use. Like we do with networking protocols and file formats.
    - steveklabnik 11mo ago
      It's being worked on! https://github.com/rust-lang/rfcs/pull/3470 https://github.com/rust-lang/rfcs/pull/3470

jcranmer 11mo ago

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, and the pointer size type are all the same type, which is not the case for a couple of architectures; it's also the case that things like segmented pointers don't really work in Rust (of course, they barely work in C, but barely is more than nothing).

raggi 11mo ago
That first sentence though. Bitfields and ABI alongside each other. Bitfield packing rules get pretty wild. Sure the user facing API in the language is convenient, but the ABI it produces is terrible (particularly in evolution).
- mjevans 11mo ago
  I would like a revision to bitfields and structs to make them behave the way a programmer things, with the compiler free to suggest changes which optimize the layout. As well as some flag that indicates the compiler should not, it's a finalized structure.
dataflow 11mo ago
In what architecture are those types different? Is there a good reason for it there architecturally, or is it just a toolchain idiosyncrasy in terms of how it's exposed (like LP64 vs. LLP64 etc.)?
- jcranmer 11mo ago
  CHERI has 64-bit object size but 128-bit pointers (because the pointer values also carry pointer provenance metadata in addition to an address). I know some of the pointer types on GPUs (e.g., texture pointers) also have wildly different sizes for the address size versus the pointer size. Far pointers on segmented i386 would be 16-bit object and index size but 32-bit address and pointer size. There was one accelerator architecture we were working that discussed making the entire datapath be 32-bit (taking less space) and having a 32-bit index type with a 64-bit pointer size, but this was eventually rejected as too hard to get working.

scottyah 11mo ago

I think it'll be less like telegram lines- which were replaced fully for a major upgrade in functionality, and more like rail lines- which were standardized and ubiquitous, still hold some benefit but mainly only exist in areas people don't venture nearly as much.

heddelt 11mo ago

[flagged]

mmooss 11mo ago

Before we ask if almost all things old will be rewritten in Rust, we should ask if almost all things new are being written in Rust or other memory-safe languages? Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?

sho_hn 11mo ago
I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.
- mmooss 11mo ago
  People can learn Rust at any age. The reality is that experienced people often are more hesitant to learn new things. I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to make the choice, you are less likely to make yourself change (and more likely to make the junior people change, when there's a trade-off). Power corrupts, even on that small scale. There's also a good argument for being stubborn and jaded: You have 30 years perfecting the skills, tools, efficiencies, etc. of C++. For the new project, even if C++ isn't as good a fit as Rust, are you going to be more efficient using Rust? How about in a year? Two years? ... It might not be worth learning Rust at all; ROI might be higher continuing to invest in additional elite C++ skills. Certainly that has more appeal to someone who knows C++ intimately - continue to refine this beautiful machine, or bang your head against the wall? For someone without that investment, Rust might have higher ROI; that's fine, let them learn it. We still need C++ developers. Morbid but true, to a degree: 'Progress happens one funeral at a time.'
  - sho_hn 11mo ago
    I still think you're off the mark. Again, most existing Rust developers are not "blank slate Rust developers". That they do not rush out to rewrite all of their past projects in C++ may be more about sunk costs, and wanting to solve new problems with from-scratch development.

nibman 11mo ago

[dead]

QuiEgo 11mo ago

Rust still compiles into bigger binary sizes than C, by a small amount. Although it’s such a complex thing depending on your code that it really depends case-by-case, and you can get pretty close. On embedded systems with small amounts of ram (think on the order of 64kbytes), a few extra kb still hurts a lot.

accelbred 11mo ago
Lack of stable build-std and panic_immediate_abort features result in a order of magnitude size difference for some rust code I have. Using no_std brings it to ~60kb from ~350kb, but still more than the ~40kb for the C version
- torginus 11mo ago
  Afaik despite Rust not having exceptions, panic still unwinds the stack and executes 'drop'-s the same way C++ does, which means the code retains much of the machinery necessary to support exceptions.
  - dwattttt 11mo ago
    The panic_immediate_abort feature should prevent this. build-std is the name of the feature that recompiles the Rust standard libraries with your chosen profile, so the combination of these two features should result in no unwinding code bloat.
    - torginus 11mo ago
      Are all crates compatible with this feature?
      - dwattttt 11mo ago
        It's possible for a crate to assume there will be unwinding, but given the Rust communities general attitude to exceptions it's not common. By default, all it means is that unwinding the stack doesn't happen, so Drop implementations don't get called. Which _can_ result in bugs, but they're a fairly familiar kind: it's the same kind of fault if a process is aborted (crashes?), and it doesn't get a chance to finalise external resources. EDIT: to clarify, the feature isn't really something crates have to opt in to support

obviouslynotme 11mo ago

A lot of C's popularity is with how standard and simple it is. I doubt Rust will be the safe language of the future, simply because of its complexity. The true future of "safe" software is already here, JavaScript. There will be small niches leftover: * Embedded - This will always be C. No memory allocation means no Rust benefits. Rust is also too complex for smaller systems to write compilers. * OS / Kernel - Nearly all of the relevant code is unsafe. There aren't many real benefits. It will happen anyways due to grant funding requirements. This will take decades, maybe a century. A better alternative would be a verified kernel with formal methods and a Linux compatibility layer, but that is pie in the sky. * Game Engines - Rust screwed up its standard library by not putting custom allocation at the center of it. Until we get a Rust version of the EASTL, adoption will be slow at best. * High Frequency Traders - They would care about the standard library except they are moving on from C++ to VHDL for their time-sensitive stuff. I would bet they move to a garbage-collected language for everything else, either Java or Go. * Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Mozilla lost their ability to make effective change and already killed their Rust project once. Google has probably the largest C++ codebase in the world. Migrating to Rust would be so expensive that the board would squash it. * High-Throughput Services - This is where I see the bulk of Rust adoption. I would be surprised if major rewrites aren't already underway.

tayo42 11mo ago
Rust isn't that complex unless your pulling in magical macro libraries or dealing with things like pin and that stuff,which you really don't need to. It's like saying python is complex becasue you have metaclasses, but you'll never need to reach for them.
scq 11mo ago
Rust is already making substantial inroads in browsers, especially for things like codecs. Chrome also recently replaced FreeType with Skrifa (Rust), and the JS Temporal API in V8 is implemented in Rust.
aw1621107 11mo ago
> No memory allocation means no Rust benefits. This isn't really true; otherwise, there would be no reason for no_std to exist. Data race safety is independent of whether you allocate or not, lifetimes can be handy even for fixed-size arenas, you still get bounds checks, you still get other niceties like sum types/an expressive type system, etc. > OS / Kernel - Nearly all of the relevant code is unsafe. I think that characterization is rather exaggerated. IIRC the proportion of unsafe code in Redox OS is somewhere around 10%, and Steve Klabnik said that Oxide's Hubris has a similarly small proportion of unsafe code (~3% as of a year or two ago) [0] > Browsers - Despite being born in a browser, Rust is unlikely to make any inroads. Technically speaking, Rust already has. There has been Rust in Firefox for quite a while now, and Chromium has started allowing Rust for third-party components. [0]: https://news.ycombinator.com/item?id=42312699 https://news.ycombinator.com/item?id=42312699 [1]: https://old.reddit.com/r/rust/comments/bhtuah/production_deployment_of_rust_in_hft_system_at/ https://old.reddit.com/r/rust/comments/bhtuah/production_dep...

QuiEgo 11mo ago

Apple handled this problem by adding memory safety to C (Firebloom). It seems unlikely they would throw away that investment and move to Rust. I’m sure lots of other companies don’t want to throw away their existing code, and when they write new code there will always be a desire to draw on prior art.

goku12 11mo ago
That's a rather pessimistic take compared to what's actually happening. What you say should apply to the big players like Amazon, Google, Microsoft, etc the most, because they arguably have massive C codebases. Yet, they're also some of the most enthusiastic adopters and promoters of Rust. A lot of other adopters also have legacy C codebases. I'm not trying to hype up Rust or disparage C. I learned C first and then Rust, even before Rust 1.0 was released. And I have an idea why Rust finds acceptance, which is also what some of these companies have officially mentioned. C is a nice little language that's easy to learn and understand. But the price you pay for it is in large applications where you have to handle resources like heap allocations. C doesn't offer any help there when you make such mistakes, though some linters might catch them. The reason for this, I think, is that C was developed in an era when they didn't have so much computing power to do such complicated analysis in the compiler. People have been writing C for ages, but let me tell you - writing correct C is a whole different skill that's hard and takes ages to learn. If you think I'm saying this because I'm a bad programmer, then you would be wrong. I'm not a programmer at all (by qualification), but rather a hardware engineer who is more comfortable with assembly, registers, Bus, DRAM, DMA, etc. I still used to get widespread memory errors, because all it takes is a lapse in attention while coding. That strain is what Rust alleviates.
- Surac 11mo ago
  So you try to say c is for good programmers only and rust let also the idiots Programm? I think that’s the wrong way to argue for rust. Rust catches one kind of common problem but but does not magically make logic errors away.
  - ykonstant 11mo ago

vbezhenar 11mo ago

For my hobby code, I'm not going to start writing Rust anytime soon. My code is safe enough and I like C as it is. I don't write software for martian rovers, and for ordinary tasks, C is more ergonomic than Rust, especially for embedded tasks. For my work code, it all comes down to SDKs and stuff. For example I'm going to write firmware for Nordic ARM chip. Nordic SDK uses C, so I'm not going to jump through infinite number of hoops and incomplete rust ports, I'll just use official SDK and C. If it would be the opposite, I would be using Rust, but I don't think that would happen in the next 10 years. Just like C++ never killed C, despite being perfect replacement for it, I don't believe that Rust would kill C, or C++, because it's even less convenient replacement. It'll dilute the market, for sure.

anticrymactic 11mo ago
> Just like C++ never killed C, despite being perfect replacement for it I think c++ didn't replace C because it is a bad language. It did not offer any improvements on the core advantages of C. Rust however does. It's not perfect, but it has a substantially larger chance of "replacing" C, if that ever happens.
- NetMageSCW 11mo ago
  I don’t agree that C++ is a bad language, though it has been standardized to death into a bad language. But the whole point is for C++ to not be worse than C while offering a lot more, which I think it does well. Of course, my last serious use of C++ was a little after release E…

greesil 11mo ago

Shitloads of already existing libraries. For example I'm not going to start using it for Arduino-y things until all the peripherals I want have drivers written in Rust.

littlestymaar 11mo ago
Why? You can interact with C libraries from Rust just fine.
- LtWorf 11mo ago
  But you now have more complexity and no extra safety.
  - timeon 11mo ago
    You have extra safety in new code.
  - pornel 11mo ago
    If you create wrappers that provide additional type information, you do get extra safety and nicer interfaces to work with.
  - dwattttt 11mo ago
    That's not really the case. Not all C APIs are inherently unsafe by construction, and I've always appreciated when someone has wrapped a C library and produced two crates: - a pure binding crate, which exposes the C lib libraries API, and - a wrapper library that performs some basic improvements Stuff in the second category typically includes adding Drop impls to resources that need to be released, translating "accepts pointer + len" into "accepts slices" (or vice versa on return), and "check return value of C call and turn it into a Result, possibly with a stringified error". All of those are also good examples of local reasoning about unsafety. If a C API returns a buffer + size, it's unsafe to turn it into a reference/slice. But if you check the function succeeded, you unsafely make the slice/reference, and return it from a safe function. If it crashes, you've either not upheld the C calls preconditions (your fault, check how to call the C function), or the C code has a bug (not your fault, the bug is elsewhere).

keyle 11mo ago

C is fun to write. I can write Rust, but I prefer writing C. I prefer compiling C, I prefer debugging C. I prefer C. It's a bit like asking with the new mustang on the market, with airbags and traction control, why would you ever want to drive a classic mustang?

IshKebab 11mo ago
> I prefer debugging C I prefer not having to debug... I think most people would agree with that.
- gjajric 11mo ago
  [dead]
  - jkelleyrtp 11mo ago
    https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ https://blog.cloudflare.com/incident-report-on-memory-leak-c... better to crash than leak https keys to the internet
    - gjajric2 11mo ago
      [dead]
- ykonstant 11mo ago
  I prefer a billion dallars tax free, but here we are:(
  - pornel 11mo ago
    In Rust dev, I haven't needed Valgrind or gdb in years, except some projects integrating C libraries. Probably kernel dev isn't as easy, but for application development Rust really shifts majority of problems from debugging to compile time.

0xbadcafebee 11mo ago

It's a bit like asking if there is any significant advantage to ICE motors over electric motors. They both have advantages and disadvantages. Every person who uses one or the other, will tell you about their own use case, and why nobody could possibly need to use the alternative. There's already applications out there for the "old thing" that need to be maintained, and they're way too old for anyone to bother with re-creating it with the "new thing". And the "old thing" has some advantages the "new thing" doesn't have. So some very specific applications will keep using the "old thing". Other applications will use the "new thing" as it is convenient. To answer your second question, nothing is inevitable, except death, taxes, and the obsolescence of machines. Rust is the new kid on the block now, but in 20 years, everybody will be rewriting all the Rust software in something else (if we even have source code in the future; anyone you know read machine code or punch cards?). C'est la vie.

NetMageSCW 11mo ago
Machine code: Yes. Punched cards: easy - every punch has the character it represents at the top of the card.
- deleted 11mo ago
  [deleted]

s_ting765 11mo ago

You mean safer languages like Fil-C.

biorach 11mo ago

There are certain styles of programming and data structure implementations that end up requiring you to fight Rust at almost every step. Things like intrusive data structures, pointer manipulation and so on. Famously there is an entire book online on how to write a performant linked list in idiomatic Rust - something that is considered straightforward in C. For these cases you could always use Zig instead of C

ViewTrick1002 11mo ago
Or just build a tested unsafe implementation as a library. For example the Linked List in the standard library. https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#481 https://doc.rust-lang.org/src/alloc/collections/linked_list....
- mjlawson 11mo ago
  I think that misses the point though. C trusts you to design your own linked list. It also trusts your neighbor, your kid, your LLM, you, your dog, another linked list...
- biorach 11mo ago
  Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig is probably the best modern choice. The TigerBeetle people chose Zig for these reasons, various resources on the net explain their motivations.
  - ViewTrick1002 11mo ago
    The point with the linked list is that it is perfectly valid to use unsafe to design said ”tailored data structure with internal cross-reference or what not” library and then expose a safe interface. If you’re having trouble designing a safe interface for your collection then that should be a signal that maybe what you are doing will result in UB when looked at the wrong way. That is how all standard library collections in Rust works. They’ve just gone to the length of formally verifying parts of the code to ensure performance and safety.

sniggler 11mo ago

[dead]

antioxide 11mo ago

you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc. there u can likely explore well the boundaries where rust does and does not work. people have all kind of opinions. mine is this: if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems rust solves arent bad, just solved in a way thats way more complicated than writing same (safe) C code. a language is not unsafe. you can write perfectly shit code in rust. and you can write perfectly safe code in C. people need to stop calling a language safe and then reimplementing other peoples hard work in a bad way creating whole new vulnerabilities.

herni 11mo ago
I disagree. Rust shines when you need perform "unsafe" operations. It forces programmers to be explicit and isolate their use of unsafe memory operations. This makes it significantly more feasible to keep track of invariants. It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is bad.
- gjajric 11mo ago
  [flagged]
  - K0nserv 11mo ago
    1. This doesn't really matter for the argument. Most of the time you can audit unsafe blocks, in some instances the invariants you are upholding require you to consider more code. The benefit is still that you can design safe interfaces around these smaller bits of audited code. 2. I agree it's harder, I feel like most of the community knows and recognises this. > Maybe Rust proponents should spend more time on making unsafe Rust easier and more ergonomic, instead of effectively *undermining safety and security*. Unless the strategy is to trick as many other people as possible into using Rust, and then hope those people fix the issues for you, a common strategy normally used for some open source projects, not languages. I don't think there is any evidence that Rust is undermining safety and security. In fact all evidence shows it's massively improving these metrics wherever Rust replaces C and C++ code. If you have evidence to the contrary let's see it.

stabbles 11mo ago

A C compiler is easier to bootstrap than a Rust compiler.

qsera 11mo ago

>does C hold any significant advantage over Rust Yes, it's lots of fun. rust is Boring. If I want to implement something and have fun doing it, I ll always do it in C.

StopDisinfo910 11mo ago

Depends of what you do. Rust has a nice compiler-provided static analyzer using annotation to do life time analysis and borrow checking. I believe borrow checking to be a local optima trap when it comes to static analysis and finds it often more annoying to use than I would like but I won't argue it's miles better than nothing. C has better static analysers available. They can use annotations too. Still, all of that is optional when it's part of Rust core language. You know that Rust code has been successfully analysed. Most C code won't give you this. But if it's your code base, you can reach this point in C too. C also has a fully proven and certified compiler. That might be a requirement if you work in some niche safety critical applications. Rust has no equivalent there. The discussion is more interesting when you look at other languages. Ada/Spark is for me ahead of Rust both in term of features and user experience regarding the core language. Rust currently still have what I consider significant flaws: a very slow compiler, no standard, support for a limited number of architectures (it's growing), it's less stable that I consider it should be given its age, and most Rust code tends to use more small libraries than I would personaly like. Rust is very trendy however and I don't mean that in a bad way. That gives it a lot of leverage. I doubt we will ever see Ada in the kernel but here we are with Rust.

otikik 11mo ago

Ubiquity is still a big one. There's many, many places where C exists that Rust has not reached yet.

pjmlp 11mo ago

Yes it does, alongside C++, Rust isn't available everywhere. There are industry standards based in C, or C++, and I doubt they will be adopting Rust any time soon. POSIX (which does require a C compiler for certification), OpenGL, OpenCL, SYSCL, Aparavi, Vulkan, DirectX, LibGNM(X), NVN, CUDA, LLVM, GCC, Unreal, Godot, Unity,... Then plenty of OSes like the Apple ecosystem, among many other RTOS and commercial endevours for embedded. Also the official Rust compiler isn't fully bootstraped yet, thus it depends on C++ tooling for its very existence. Which is why efforts to make C and C++ safer are also much welcomed, plenty of code out there is never going to be RIR, and there are domains where Rust will be a runner up for several decades.

Philpax 11mo ago
I agree with you for the most part, but it's worth noting that those standards can expose a C API/ABI while being primarily implemented in and/or used by non-C languages. I think we're a long way away from that, but there's no inherent reason why C would be a going concern for these in the Glorious RIIR Future:tm:.