"But almost all programs have paths that crash, and perhaps the density of crashes will be tolerable."<p>This is a very odd statement. Mature C programs written by professional coders (Redis is a good example) basically <i>never</i> crash in the experience of users. Crashing, in such programs, is a rare occurrence mostly obtained by attackers on purpose, looking for code paths that generate a memory error that - if the program is used as it should - are never reached.<p>This does not mean that C code never segfaults: it happens, especially when developed without care and the right amount of testing. But the code that is the most security sensitive, like C Unix servers, is high quality and crashes are <i>mostly</i> a security problem and a lot less a stability problem.
Notice that it says "almost all programs" and not "almost all _C_ programs".<p>I think if you understand the meaning of "crash" to include any kind of unhandled state that causes the program to terminate execution then it includes things like unwrapping a None value in Rust or any kind of uncaught exception in Python.<p>That interpretation makes sense to me in terms of the point he's making: Fil-C replaces memory unsafety with program termination, which is strictly worse than e.g. (safe) Rust which replaces memory unsafety with a compile error. But it's also true that most programs (irrespective of language, and including Rust) have some codepaths in which programs can terminate where the assumed variants aren't upheld, so in practice that's often an acceptable behaviour, as long as the defect rate is low enough.<p>Of course there is also a class of programs for which that behaviour is not acceptable, and in those cases Fil-C (along with most other languages, including Rust absent significant additional tooling) isn't appropriate.
I don't think it's odd statement. It's not about segfaults, but use-after-free (and similar) bugs, which don't crash in C, but do crash in Fil-C. With Fil-C, if there is such a bug, it will crash, but if the density of such bugs is low enough, it is tolerable: it will just crash the program, but will not cause an expensive and urgent CVE ticket. The bug itself may still need to be fixed.<p>The paragraph refers to detecting such bugs during compilation versus crashing at runtime. The "almost all programs have paths that crash" means all programs have a few bugs that can cause crashes, and that's true. Professional coders do not attempt to write 100% bug-free code, as that wouldn't be efficient use of the time. Now the question is, should professional coders convert the (existing) C code to eg. Rust (where likely the compiler detects the bug), or should he use Fil-C, and so safe the time to convert the code?
I heard this argument about Rust vs. C that Rust might be memory safe, but the reason why memory safety issues ares so prominent in C programs, is that basically every other kind of problem has been fixed throughout its lifetime, so these are the only kind of issues that remain. Both in terms of security and stability.<p>This is very much not the case for programs that are much newer, even if they are written in Rust they still need years of maturation before they reach the quality of older C programs, as Rust programs suffer from non-memory safety issues just as much. That's why just rewriting things in Rust isn't a panacea.<p>The perfect example of this the Rust coreutils drama that has been going on.
I think what you've written is pretty much what the "almost all programs have paths that crash" was intended to convey.<p>I think "perhaps the density of crashes will be tolerable" means something like "we can reasonably hope that the crashes from Fil-C's memory checks will only be of the same sort, that aren't reached when the program is used as it should be".
I think the focus should be on tools with high surface area that enforce security bounadaries. Especially those where performance is not so important. Like sudo, openssh, polkit, PAM modules. It would be make a lot more sense than these half-baked rust rewrites that just take away features. (I'm biased I personally had a backup script broken by uutils) I think rewrites in rust need 100% bit for bit feature parity before replacing the battletested existing tools in c userland. I say this as someone who writes rust security tools for linux.
I think the point is that Fil-C makes programs crash which didn't crash before because use-after-free didn't trigger a segfault. If anything, I'd cite Redis as an example that you can build a safe C program if you go above and beyond in engineering effort... most software doesn't, sadly.
sel4 is the example of building a safe C program if you go above and beyond in effort.<p>It's provably safer than rust, e.g.
Redis uses a whole lot of fiddly data structures that turn out to involve massive amounts of unsafe code even in Rust. You'd need to use something like Frama-C to really prove it safe beyond reasonable doubt. (Or the Rust equivalents that are currently in the works, and being used in an Amazon-funded effort to meticulously prove soundness of the unsafe code in libstd.) Compiling it using Fil-C is a nice academic exercise but not really helpful, since the whole point of those custom data structures is peak performance.
It is a question of probability and effort. My personal estimation rule for my type of projects is it takes 3 times longer from my prototype to something I‘m comfortable having others use it and another factor to get to an early resemblance of a product. A recent interview I read an AI expert said each 9 in terms of error probability is the same effort.<p>Most software written does not serve a serious nation level user base but caters to so a relatively small set of users. The effort spent eradicating errors needs to be justified by the effort of workarounds, remediation work and customer impact. Will not be fixed can a rationale decision.
How many "mature C programs" try to recover in a usable way when malloc() returns NULL? That's a crash - a well-behaved one (no UB involved) hence not one that would be sought by most attackers other than a mere denial of service - but still a crash.
> when malloc() returns NULL? That's a crash - a well-behaved one (no UB involved)<p>Wrong, dereferencing a NULL pointer is UB.
On 64-bit systems (esp Linux ones) malloc almost never returns NULL but keeps overallocating (aka overcommiting). You don't get out of memory errors / kills until you access it.
This is super kind and awesome, I'm seriously flattered!
Did you know each other at Apple?<p>Long long ago, in 2009, Graydon was my official on-boarding mentor when I joined the Mozilla Javascript team. Rust already existed then but, as he notes, was quite different then. For one thing, it was GC'd, like Fil-C. Which I like -- I write a lot of my C/C++ code using Boehm GC, have my own libraries designed knowing GC is there, etc.
Great work for the community.<p>This has obviously been 'rust'ling some feathers, as it challenges some of the arguments laid past; but once the dust settles, it is a major net benefit to the community.<p>I hope you get financed and can support other platforms than linux again.
> This has obviously been 'rust'ling some feathers,<p>I'm a Rust user and a fan. But memory safe C is actually an exciting prospect. I was hoping that the rise of Rust would encourage others to prioritize memory safety and come up with approaches that are much more ergonomic to the developers.<p>> as it challenges some of the arguments laid past<p>Genuinely curious. What are the assumptions you have in mind that Fil-C challenges? (This isn't a rhetorical question. I'm just trying to understand memory safety concepts better.)<p>> but once the dust settles, it is a major net benefit to the community.<p>Agreed, this is big! If Fil-C can fulfill its promise to make old C code memory safe, it will be a massive benefit to the world. God knows how many high-consequnce bugs and vulnerabilities hide in those.
Same here, I don't have any use for Rust, and am perfectly fine with automatic resource management languages (regardless of the approach).<p>However, Rust has been quite successful making more developers think about less known type systems, besides affine types, there is also linear types, effects, dependent types, prof systems.<p>And we as industry aren't going to throw away the millions and millions of stuff that was written in C, C++ and less extent Objective-C, thus efforts like Fil-C are quite welcomed.
> <i>I was hoping that the rise of Rust would encourage others to prioritize memory safety and come up with approaches that are much more ergonomic to the developers.</i><p>That's the end-goal right? I don't write Rust code myself, but I'm glad its existence means there's safer code out there now, and like you I have been looking forward to seeing shifts in safety expectations. I'm not surprised that it's happening so slowly though.
One thing I've been wondering recently about Fil-C - why <i>now</i>? And I don't mean that in a dismissive way at all, I'm genuinely curious about the history. Was there some relatively recent fundamental breakthrough or other change that prevented a Fil-C-like approach from being viable before? Was it a matter of finding the right approach/implementation (i.e., a "software" problem), or is there something about modern hardware which makes the approach impractical otherwise? Something else?
I wrote a bounds checking patch to GCC (mentioned in a link from the article) back in 1995. It did full bounds checking of C & C++ while being compatible with existing libraries and ABIs, making it a bit more practical than Fil-C to deploy in the real world. You only had to recompile your application, if you trusted the libraries (although the bounds checking obviously didn't extend into the libraries unless you recompiled them). It didn't do the GC thing, but instead detected use after free at the point of use.<p><a href="https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html" rel="nofollow">https://www.doc.ic.ac.uk/~phjk/BoundsChecking.html</a>
I’ve been thinking about this problem since 2004.<p>Here’s a rough timeline:<p>- 2004-2018: I had ideas of how to do it but I thought the whole premise (memory safe C) was idiotic.<p>- 2018-2023: I no longer thought the premise was idiotic but I couldn’t find a way to do it that would result in fanatical compatibility.<p>- 2023-2024: early Fil-C versions that were much less compatible and much less performant<p>- end of 2024: InvisiCaps breakthrough that gives current fanatical compatibility and “ok” performance.<p>It’s a hard problem. Lots of folks have tried to find a way to do it. I’ve tried many approaches before finding the current one.
Beyond the Git history, is there any write-up of the different capability designs you've gone with?<p>I'm interested in implementing a safe low-level language with less static information around than C has (e.g. no static pointer-int distinction), but I'd rather keep around the ability to restrict capabilities to only refer to subobjects than have the same compatibility guarantees Invisicaps provide, so I was hoping to look into Monocaps (or maybe another design, if there's one that might fit better).
That's a really interesting timeline! Sounds like it's been stewing for a lot longer than I expected. Was there anything in particular around 2018 that changed your opinion on the idiotic-ness of the premise?<p>If a hypothetical time machine allowed you to send the InvisiCaps idea back to your 2004-era self, do you think the approach would have been feasible back then as well?
> Was there some relatively recent fundamental breakthrough or other change that prevented a Fil-C-like approach from being viable before?<p>The provenance model for C is very recent (and still a TS, not part of the standard). Prior to that, there was a vague notion that the C abstract machine has quasi-segmented memory (you aren't really allowed to do arithmetic on a pointer to an "object" to reach a different "object") but this was not clearly stated in usable terms.
One divide when it comes to using Fil-C is C as an application (git) vs C as a library from another language (libgit2).<p>Suppose we assume that many C applications aren’t performance sensitive and can easily take a 2-4x performance hit without noticing. Browsers and OS internals being obvious exceptions. The ideal candidates are like the ones djb writes, and he’s already a convert to Fil-C. sudo, sshd, curl - all seem like promising candidates.<p>But as far as I can tell, Fil-C doesn’t work for C libraries that can be called from elsewhere. Even if it could be made to work, the reason other languages like Python or Node use C libraries is for speed. If they were ok with it being 2-4x slower, they would just write ordinary Python or Javascript.<p>C (and C++) are fundamentally important because of their use in performance sensitive contexts like operating systems, browsers and libraries. If we’re restricting Fil-C to pure C/C++ applications that <i>aren’t</i> performance sensitive, that might still be very important and useful, but it’s a small slice of the large C/C++ pie.<p>Also, it’s a great tool for an existing C application, certainly. A performance hit in exchange for security is a reasonable trade off while making a battle hardened application work. But for a <i>new</i> application, would someone choose Fil-C over other performant GC languages like Go or Java or C#? I’d be keen to hear why.<p>Still, I want to stress - this is a great project and it’ll generate a lot of value.
Why can't it work? You need to assume that the C library is only ever passed well-behaved pointers and callbacks in order to avoid invoking UB that it can't know about - but other than that it's just a matter of marshaling from the usual C ABI to the Fil-C ABI, which should be doable.
I’m assuming the calling program is a GC language like Python or Node (the most popular run times by far), but the same holds with other popular languages like Ruby. Why would a GC language call out to slow code, that runs its own separate GC. Now you have two GCs running, neither of which knows about the other. I’m not declaring it’s impossible, I’m asking why someone would want to do this.<p>An example: GitHub’s entire business revolves around calling libgit2 (C) from Ruby. Are they more likely to slow down libgit2 and make it substantially more complex by running 2 GCs side by side, or are they going to risk accept any potential unsafety in regular C? It’s 100% the latter, I’ll bet on that.
> ...Now you have two GCs running, neither of which knows about the other. ...<p>For a strictly time-limited interaction (like what's involved in a FFI call) it's not that bad. Everything that GC2 might directly access is temporarily promoted to a root for GC1, and vice versa.
The former could still be cheaper than stop using libgit altogether.
No one is asking them to stop using libgit2 though. They’re going to continue using it. If they find a serious bug, they’ll fix it and continue using it.<p>The cost of all the additional hardware is just not worth it. If it was a choice between higher hardware costs, higher request latency, greater operational complexity of a new technology and rewriting libgit2 in a different language without all those tradeoffs, GitHub definitely chooses the latter.<p>But it’s never going to reach that point because they’ll continue using libgit2 compiled by clang forever.
I suppose /some/ performance loss is inevitable. But this could be quite a game changer. As more folks play with it, performing benchmarks, etc -- it should reveal which C idioms incur the most/least performance hits under Fil-C. So with some targetted patching of C code, we may end up with a rather modest price for the memory safety
And I'm not done optimizing. The perf will get better. Rust and Yolo-C will always be faster, but right now we can't know what the difference will be.<p>Top optimization opportunities:<p>- InvisiCaps 2.0. While implementing the current capability model, when I was about 3/4 of the way done with the rewrite, I realized that if I had done it differently I would have avoided two branch+compares on every pointer load. That's huge! I just haven't had the appetite for doing yet another rewrite recently. But I'll do it eventually.<p>- ABI. Right now, Fil-C uses a binary interface that relies on lowering to what ELF is capable of. This introduces a bunch of overhead on every global variable access and every function call. All of this goes away if Fil-C gets its own object file format. That's a lot of work, but it will happen in Fil-C gets more adoption.<p>- Better abstract interpreter. Fil-C already has an abstract interpreter in the compiler, but it's not nearly as smart as it could be. For example, it doesn't have octagon domain yet. Giving it octagon domain will dramatically improve the performance of loops.<p>- More intrinsics. Right now, a lot of libc functions that are totally memory safe but are implemented in assembly are implemented in plain Fil-C instead right now, just because of how the libc ports happened to work out. Like, say you call some <math.h> function that takes doubles and returns doubles - it's going to be slower in Fil-C today because you'll end up in the generic C code version compiled with Fil-C. No good reason for this! It's just grunt work to fix!<p>- The calling convention itself is trash right now - it involves passing things through a thread-local buffer. It's less trashy than the calling convention I started out with (that allocated everything in the heap lmao), but still. There's nothing fundamentally preventing a Fil-C register-based calling convention, but it would take a decent amount of work to implement.<p>There are probably other perf optimization opportunities that I'm either forgetting right now or that haven't been found yet. It's still early days!
This is such an interesting project.<p>I've always been firmly in the 'let it crash' camp for bugs, the sooner and the closer to the offending piece of code you can generate a crash the better. Maybe it would be possible to embed Fil-C in a test-suite combined with a fuzzing like tool that varies input to try really hard to get a program to trigger an abend. As long as it is possible to fuzz your way to a crash in Fil-C that would be a sign that there is more work to do.<p>That way 'passes Fil-C' would be a bit like running code under valgrind and move the penalty to the development phase rather than the runtime. Is this feasible or am I woolgathering, and is Fil-C only ever going to work by using it to compile the production code?
> Rust and Yolo-C will always be faster<p>graydon points in that direction, but since you're here: how feasible is a hypothetical Fil-Unsafe-Rust? would you need to compile the whole program in Fil-Rust to get the benefits of Fil-Unsafe-Rust?
It's reasonably easy if you can treat the Safe Rust and Fil-Unsafe-Rust code as accessing different address spaces (in the C programming sense of "a broad subset of memory that a pointer is limited to", not the general OS/hardware sense), since that's essentially what the bespoke Fil-C ABI amounts to in the first place. Which of course is not really a good fit for every use of Unsafe Rust, but might suffice for some of them.
Love your Yolo-C remark. :)
Can you elaborate on what makes ELF (potentially with custom sections/extension and maybe custom ld.so plugin) insufficient?<p>A lot of remarkably unusual stuff has been shoved into the format without breaking the tooling, so wondering what the restrictions are.
The savings of two conditional branches sounds interesting; what would the change be?
- Don’t put flags in the high bits of the aux pointer. Instead if an object has flags, it’ll have a fatter header. Most objects don’t have flags.<p>- Give up on lock freedom of atomic pointers. This is a fun one because theoretically, it’s worse. But it comes with a net perf improvement because there’s no need to check the low bit of lowers.
So you'd have to implement binfmt_misc for the new binary format? Will you need to write your own ld.so?
If you are not writing anything performance sensitive, you shouldn't be using C in the first place. Even if Fil-C greatly reduces its overhead, I can't see it ever being a good idea for actual release builds.<p>As a Linux user of two decades, memory safety has never been a major issues that I would be willing to trade performance for. It doesn't magically make my application work it just panics instead of crashes, same end result for me. It just makes it so the issue can not be exploited by an attacker. Which is good but like Linux has been already safe enough to be the main choice to run on servers so meh. The whole memory safety cult is weird.<p>I guess Fil-C could have a place in the testing pipeline. Run some integration tests on builds made with it and see if stuff panics.<p>That said, Fil-C is a super cool projects. I don't mean to throw any shades at it.
Getting a "not available in your state" page, does anyone have an archive? I've only recently tried out fil-c and hope to use it in some work projects.
Yes, safety got more important, and it's great to support old C code in a safe way. The performance drop and specially the GC of Fil-C do limit the usage however. I read there are some ideas for Fil-C without GC; I would love to hear more about that!<p>But all existing programming languages seem to have some disadvange: C is fast but unsafe. Fil-C is C compatible but requires GC, more memory, and is slower. Rust is fast, uses little memory, but us verbose and hard to use (borrow checker). Python, Java, C# etc are easy to use, concise, but, like Fil-C, require tracing GC and so more memory, and are slow.<p>I think the 'perfect' language would be as concise as Python, statically typed, not require tracing GC like Swift (use reference counting), support some kind of borrow checker like Rust (for the most performance critical sections). And leverage the C ecosystem, by transpiling to C. And so would run on almost all existing hardware, and could even be used in the kernel.
> Python, Java, C# [...] are slow<p>These might all be slower than well written C or rust, but they're not nearly the same magnitude of slow. Java is often within a magnitude of C/C++ in practice, and threading is less of a pain. Python can easily be 100x slower, and until very recently, threading wasn't even an option for more CPU due to the GIL so you needed extra complexity to deal with that<p>There's also Golang, which is in the same ballpark as java and c
You are right, languages with tracing GC are fast. Often, they are faster than C or Rust, if you measure peak performance of a micro-benchmark that does a lot of memory management. But that is only true if you just measure the speed of the main thread :-) Tracing garbage collection does most of the work in separate threads, and so is often not visible in benchmarks. Memory usage is also not easily visible, but languages with tracing GC need about twice the amount of memory than eg. C or Rust. (When using an area allocator in C, you can get faster, at the cost of memory usage.)<p>Yes, Python is specially slow, but I think it's probably more because it's dynamically typed, and not not compiled. I found PyPy is quite fast.
I've built high load services in Java. GC can be an issue if it gets bad enough to have to pause, but it's in no way a big performance drain regularly.<p>pypy is fast compared to plain python, but it's not remotely in the same ballpark as C, Java, Golang
Of these languages, C# may actually be the fastest.<p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
In most cases the later entries in a language for the benchmark game are increasingly hyper-optimized and non-idiomatic for that language, which is exactly where C# will say "Here's some dangerous features, be careful" and the other languages are likely to suggest you use a bare metal language instead.<p>Presumably the benchmark game doesn't allow "I wrote this code in C" as a Python submission, but it would allow unsafe C# tricks ?
Nim fits most of those descriptors, and it’s become my favorite language to use. Like any language, it’s still a compromise, but it sits in a really nice spot in terms of compromises, at least IMO. Its biggest downsides are all related to its relative “obscurity” (compared to the other mentioned languages) and resulting small ecosystem.
The advantage of Fil-C is that it's C, not some other language. For the problem domain it's most suited to, you'd do C/C++, some other ultra-modern memory-safe C/C++ system, or Rust.
I agree. Nim is memory safe, concise, and fast. In my view, Nim lacks a very clear memory management strategy: it supports ARC, ORC, manual (unsafe) allocation, move semantics. Maybe supporting viewer options would be better? Usually, adding things that are lacking is easier than removing features, specially if the community is small and if you don't want to alienate too many people.
> And leverage the C ecosystem, by transpiling to C<p>I heavily doubt that this would work on arbitrary C compilers reliably as the interpretation of the standard gets really wonky and certain constructs that should work might not even compile. Typically such things target GCC because it has such a large backend of supported architectures. But LLVM supports a large overlapping number too - thats why it’s supported to build the Linux kernel under clang and why Rust can support so many microcontrollers. For Rust, that’s why there’s the rust codegen gcc effort which uses GCC as the backend instead of LLVM to flush out the supported architectures further. But generally transpiration is used as a stopgap for anything in this space, not an ultimate target for lots of reasons, not least of which that there’s optimizations that aren’t legal in C that are in another language that transpilation would inhibit.<p>> Rust is fast, uses little memory, but us verbose and hard to use (borrow checker).<p>It’s weird to me that my experience is that it was as hard to pick up the borrow checker as the first time I came upon list comprehension. In essence it’s something new I’d never seen before but once I got it it went into the background noise and is trivial to do most of the time, especially since the compiler infers most lifetimes anyway. Resistance to learning is different than being difficult to learn.
Well "transpiling to C" does include GCC and clang, right? Sure, trying to support _all_ C compilers is nearly impossible, and not what I mean. Quite many languages support transpiling to C (even Go and Lua), but in my view that alone is not sufficient for a C replacement in places like the Linux kernel: for this to work, tracing GC can not be used. And this is what prevents Fil-C and many other languages to be used in that area.<p>Rust borrow checker: the problem I see is not so much that it's hard to learn, but requires constant effort. In Rust, you are basically forced to use it, even if the code is not performance critical. Sure, Rust also supports reference counting GC, but that is more _verbose_ to use... It should be _simpler_ to use in my view, similar to Python. The main disadvantage of Rust, in my view, is that it's verbose. (Also, there is a tendency to add too many features, similar to C++, but that's a secondary concern).
> Sure, Rust also supports reference counting GC, but that is more _verbose_ to use... It should be _simpler_ to use in my view, similar to Python.<p>If that's what you're looking for, you can use Swift. The latest release has memory safety by default, just like Rust.
Someone, maybe Tolnay?, recently posted a short Go snippet that segfaults because the virtual function table pointer and data pointer aren't copied atomically or mutexed. The same thing works in swift, because neither is thread safe. Swift is also slower than go unless you pass unchecked making it even less safe than go. C#/f# are safer from that particular problem and more performant than either go or swift, but have suffered from the same deserialization attacks that java does. Right now if you want true memory and thread safety, you need to limit a GC language to zero concurrency, use a borrow checker, i.e. rust, or be purely functional which in production would mean haskell. None of those are effortless, and which is easiest depends on you and your problem. Rust is easiest for me, but I keep thinking if I justvwrite enough haskell it will all click. I'm worried if my brain starts working that way about the impacts on things other than writing Haskell.
Yes. I do like Swift as a language. The main disadvantages of Swift, in my view, are: (A) The lack of an (optional) "ownership" model for memory management. So you _have_ to use reference counting everywhere. That limits the performance. This is measurable: I converted some micro-benchmarks to various languages, and Swift does suffer for the memory managment intensive tasks [1]. (B) Swift is too Apple-centric currently. Sure, this might be become a non-issue over time.<p>[1] <a href="https://github.com/thomasmueller/bau-lang/blob/main/doc/performance.md" rel="nofollow">https://github.com/thomasmueller/bau-lang/blob/main/doc/perf...</a>
Re: borrow checker<p>Isn't it just enforcing something you should be doing in every language anyway, i.e. thinking about ownership of data.
The borrow checker involves <i>documenting</i> the ownership of data throughout the program. That's what people are calling "overly verbose" and saying it "makes comprehensive large-scale refactoring impractical" as an argument against Rust. (And no it doesn't, it's just keeping you honest about what the refactor truly involves.)
> Quite many languages support transpiling to C (even Go and Lua)<p>Source? I’m not familiar with official efforts here. I see one in the community for Lua but nothing for Go. It’s rare for languages to use this as anything other than a stopgap or a neat community poc. But my point was precisely this - if you’re only targeting GCC/LLVM, you can just use their backend directly rather than transpiling to C which only buys you some development velocity at the beginning (as in easier to generate that from your frontend vs the intermediate representation) at the cost of a worse binary output (since you have to encode the language semantics on top of the C virtual machine which isn’t necessarily free). Specifically this is why transpile to C makes no sense for Rust - it’s already got all the infrastructure to call the compiler internals directly without having to go through the C frontend.<p>> Rust borrow checker: the problem I see is not so much that it's hard to learn, but requires constant effort. In Rust, you are basically forced to use it, even if the code is not performance critical<p>Your only forced to use it when you’re storing references within a struct. In like 99% of all other cases the compiler will correctly infer the lifetimes for you. Not sure when the last time was you tried to write rust code.<p>> Sure, Rust also supports reference counting GC, but that is more _verbose_ to use... It should be _simpler_ to use in my view, similar to Python.<p>Any language targeting the performance envelope rust does needs GC to be opt in. And I’m not sure how much extra verbosity there is to wrap the type with RC/Arc unless you’re referring to the need to throw in a RefCell/Mutex to support in place mutation as well, but that goes back to there not being an alternative easy way to simultaneously have safety and no runtime overhead.<p>> The main disadvantage of Rust, in my view, is that it's verbose.<p>Sure, but compared to what? It’s actually a lot more concise than C/C++ if you consider how much boilerplate dancing there is with header files and compilation units. And if you start factoring in that few people actually seem to actually know what the rule of 0 is and how to write exception safe code, there’s drastically less verbosity and the verbosity is impossible to use incorrectly. Compared to Python sure, but then go use something like otterlang [1] which gives you close to Rust performance with a syntax closer to Python. But again, it’s a different point on the Pareto frontier - there’s no one language that could rule them all because they’re orthogonal design criteria that conflict with each other. And no one has figured out how to have a cohesive GC that transparently and progressively lets you go between no GC, ref GC and tracing GC despite foundational research a few years back showing that ref GC and tracing GC are part of the same spectrum and high performing implementations in both the to converge on the same set of techniques.<p>[1] <a href="https://github.com/jonathanmagambo/otterlang" rel="nofollow">https://github.com/jonathanmagambo/otterlang</a>
I agree transpile to C will not result in the fastest code (and of course not the fastest toolchain), but having the ability to convert to C does help in some cases. Besides the ability to support some more obscure targets, I found it's useful for building a language, for unit tests [1]. One of the targets, in my case, is the XCC C compiler, which can run in WASM and convert to WASM, and so I built the playground for my language using that.<p>> transpiling to C (even Go and Lua)<p>Go: I'm sorry, I thought TinyGo internally converts to C, but it turns out that's not true (any more?). That leaves <a href="https://github.com/opd-ai/go2c" rel="nofollow">https://github.com/opd-ai/go2c</a> which uses TinyGo and then converts the LLVM IR to C. So, I'm mistaken, sorry.<p>Lua: One is <a href="https://github.com/davidm/lua2c" rel="nofollow">https://github.com/davidm/lua2c</a> but I thought eLua also converts to C.<p>> Your only forced to use it when you’re storing references within a struct.<p>Well, that's quite often, in my view.<p>> Not sure when the last time was you tried to write rust code.<p>I'm not a regular user, that's true [2]. But I do have some knowledge in quite many languages now [3] and so I think I have a reasonable understanding of the advantages and disadvantages of Rust as well.<p>> Any language targeting the performance envelope rust does needs GC to be opt in.<p>Yes, I fully agree. I just think that Rust has the wrong default: it uses single ownership / borrowing by _default_, and RC/Arc is more like an exception. I think most programs could use RC/Arc by default, and only use ownership / borrowing where performance is critical.<p>> The main disadvantage of Rust, in my view, is that it's verbose.
>> Sure, but compared to what?<p>Compared to most languages, actually [4]. Rust is similar to Java and Zig in this regard. Sure, we can argue the use case of Rust is different than eg. Python.<p>[1] <a href="https://github.com/thomasmueller/bau-lang" rel="nofollow">https://github.com/thomasmueller/bau-lang</a>
[2] <a href="https://github.com/thomasmueller/lz4_simple" rel="nofollow">https://github.com/thomasmueller/lz4_simple</a>
[3] <a href="https://github.com/thomasmueller/bau-lang/tree/main/src/test/resources/org/bau/benchmarks" rel="nofollow">https://github.com/thomasmueller/bau-lang/tree/main/src/test...</a>
[4] <a href="https://github.com/thomasmueller/bau-lang/blob/main/doc/conciseSyntax.md" rel="nofollow">https://github.com/thomasmueller/bau-lang/blob/main/doc/conc...</a>
Slow to whom, though?<p>Yes, they might lose the meaningless benchmarks game that gets thrown around, what matters is are they fast enough for the problem that is being solved.<p>If everyone actually cared about performance above anything else, we wouldn't have an Electron crap crisis.
I think transpiling to C is probably the least interesting way to tap into C. FFI is a lot valuable (and doable).
There are surprisingly many languages that support transpiling to C: Python (via Cython), Go (via TinyGo), Lua (via eLua), Nim, Zig, Vlang. The main advantage (in my view) is to support embedded systems, which might not match your use case.
Eiffel, that is how it always worked, a VM based workflow for development (Melt VM), compilation via C or C++ for release builds.
403's until you go to <a href="https://graydon2.dreamwidth.org/" rel="nofollow">https://graydon2.dreamwidth.org/</a> first
I am very excited about this. Thanks to HN I see such things. To bad normal media is not any longer interested in anything not AI. On Topic: I am quite sceptical about all this rusting only because we can. Going rust makes the amount of programmers willing to look at the code quite small. A way to add this static testing to c will on the other hand open up the whole c community to a needed thing: memory
Garbage collection is GOFAI (the LISP folks came up with it) and of course GOFAI is AI.
As article points out, this does not solve all the things Rust does (apart for memory/performance, things like point 3.). So new code would be preferable in something like Rust (and some other PLs). However lot of existing code is in C and most of it will stay in C. So Fil-C seems to be really useful here.
I can see the value this brings vs regular C, but I’m less clear on what this brings on top of -fbounds-safety
-fbounds-safety is awesome!<p>Here’s what Fil-C gives you that -fbounds-safety doesn’t:<p>- Fil-C gives you comprehensive memory safety while -fbounds-safety just covers bounds. For example, Fil-C panics on use after free and has well defined semantics on ptr-int type confusion.<p>- -fbounds-safety requires you to modify your code. Fil-C makes unmodified C/C++ code memory safe.<p>FWIW, I worked on -fbounds-safety and I still think it’s a good idea. :-)
It's always seemed obvious to me that it would be better to make C safer than it would be to rewrite the billions of lines of C that run all our digital infrastructure. Of course that will get pushback from people who care more about rewriting it in a specific language, but pragmatically it's the obvious solution. Nice to see stuff like Fil-C proving it's possible, and if the performance gap can get within 10% (which seems very possible) it would be a no-brainer.
It depends how much the C software is "done" vs being updated and extended. Some legacy projects need a rewrite/rearchitecting anyway (even well-written battle-tested code may stop meeting requirements simply due to the world changing around it).<p>It also doesn't have to be a complete all-at-once rewrite. Plain C can easily co-exist with other languages, and you can gradually replace it by only writing new code in another language.
Memory safety isn't the <i>only</i> benefit of rewriting C code in Rust. IMO it's maybe not even the biggest.<p>For example you also get a far stronger type system (leading to fewer logic bugs) and modern tooling.
Seems like soapboxing for Rust via backhanded compliments about this amazing tool. If anything, this tool makes rewriting in Rust that much less attractive. If C and C++ get tools like this that deliver 90% of the benefits of Rust without a rewrite or learning a new and equally complex language, then we can avoid needlessly fracturing the software world. I really think we were there before Fil-C, but this is potentially a game-changer.
I don’t think Fil-C supplants Rust; Rust still has a place for things like kernel development where Fil-C would not be accepted since it wouldn’t work there. But also Rust today has significantly better performance and memory usage so makes more sense for greenfield projects that might otherwise consider C/C++. Not to mention that Rust as a language is drastically easier and faster to develop in due to a modern package management system, a good fast cohesive std library, true cross platform support, static catching of all the issues that would otherwise cause Fil-C to crash instead in addition to having better performance without effort.<p>Fil-C is an important tool to secure traditional software but it doesn’t yet compete with Rust in the places it’s competing with C and C++ in greenfield projects (and it may never - that’s ok - it’s still valuable to have a way to secure existing code without rewriting it).<p>And I disagree with the characterization of Graydon’s blog. It’s literally praising Fil-C and saying it’s a valuable piece of tech in the landscape of language dev and worth paying attention to as a serious way to secure a huge amount of existing code. The only position Graydon takes is that safety is a critically important quality of software and Fil-C is potentially an important part of the story of moving the industry forward.
<i>> Seems like soapboxing for Rust via backhanded compliments about this amazing tool.</i><p>I'm not sure how you read it that way? To me it reads like "yes, this is a good and notable thing even if it's not perfect".<p>(The creator of Fil-C is also in this thread and doesn't appear to be reading it that way...)
Don't get me wrong, it sounds positive. A direct attack on Fil-C would have seemed mean-spirited so there is a lot of misdirection. Maybe the author doesn't even see what he's doing because he's so deep in it. But to me the message is clear. No matter what tools are developed for C and C++ to mitigate memory issues, Rust people will never concede that enough of these issues have been solved. They demand a complete rewrite of everything, or at least gradual replacement of all C and C++ code with Rust. Even if Rust is worse in other ways, does not deliver true safety, has technical shortcomings and worse licensing, etc.<p>This post is very polite compared to what I've seen from some Rust fanatics. But it still strikes me as talking down to the C and C++ community, as if these languages are beyond redemption because they don't work the same as Rust.
Graydon's post was about as full-throated an endorsement of Fil-C as you can get, including noting where it's innovations could be used to improve Rust safety. The fact that you see undertones of some sort of deepset Rust agenda to unseat C and C++ is, I think, more a reflection on just how deep down the rabbit hole some Rust critics have gone, seeing so-called Rust zealots hiding in every shadow of the internet.
From my skim, I didn't see anything mean spirited.<p>So far as I've seen, Graydon is not a zealot and he doesn't play political games. It was a shame to lose his guiding hand
> deliver 90% of the benefits of Rust without a rewrite<p>Rust with 1/4 of the speed doesn't feel like 90% of the benefits of Rust. I'm sure the author will make Fil-C faster in time, but Rust is always going to be much faster.
I wasn't suggesting that you should run everything with Fil-C all the time. If you run it sometimes, you're likely to catch most problems. The ideal tool would be CHERI or something. I think Rust makes a big mistake with its maximal error checking every time you compile, among its other flaws. Rust compile times are high compared to similar C++ code. The compiler has a high amount of necessary complexity that comes into play every time you run the code with a few lines of changes. Of course, C++ has higher compile times than Go and C, and probably some other languages, but they are fairly different languages with different error modes.<p>Let me put it another way. We could say that documentation, code formatting, and even profiling, all have a place in development. So would running a model checker or something. But we don't generally make compilers implement these features and make that a mandatory part of the build. I think the complex memory borrowing scheme of Rust unnecessarily forces the compiler to check a lot of extra stuff specific to a certain class of problem. You don't get a choice about how paranoid you need to be about errors. You just have to eat that long compile time, every time.
Maybe always faster, but perhaps not always <i>much</i> faster.
And people who just don't like like the Rust "style" and would rather write new software in a familiar language with all the features like classic OOP they they are used to.
You can use classic OOP in Rust (even implementation inheritance, via the generic typestate pattern!) It's just not a good idea.
There are many languages in this space to choose from.