7 ms·
Note that it is a garbage collector designed and implemented by one of the most experienced GC experts on earth. He previously designed and implemented WebKit's
by mbrock 11mo ago
Note that it is a garbage collector designed and implemented by one of the most experienced GC experts on earth. He previously designed and implemented WebKit's state of the art concurrent GC, for example. So—yes, but don't dismiss it too quickly.
- simonask 11mo agoIf that's all you need, the state of the art is very available already through the JVM and the .NET CLR, as well as a handful others depending on your use case. Most of those also come with decent languages, and great facilities to leverage the GC to its maximum. But GCs aren't magic and you will never get rid of all the overhead. Even if the CPU time is not noticeable in your use case, the memory usage fundamentally needs to be at least 2-4x the actual working set of your program for GCs to be efficient. That's fine for a lot of use cases, especially when RAM isn't scarce. Most people who use C or C++ or Rust have already made this calculation and deemed the cost to be something they don't want to take on. That's not to say Fil-C isn't impressive, but it fills a very particular niche. In short, if you're bothering with a GC anyway, why wouldn't you also choose a better language than C or C++?
- mbrock 11mo agoI don't understand the need to hammer in the point that Fil-C is only valuable for this tiny, teeny, irrelevant microscopic niche, while not even talking about what the niche is? To be clear, the niche is rebuilding your entire GNU/Linux userland with full memory safety and completely acceptable performance, tomorrow, without rewriting anything, right? Is this such a silly little idiosyncratic hobby?
- conradev 11mo agoI am a member of this niche – thank you for the flake!! https://discourse.nixos.org/t/radically-improving-nix-nixos-security-with-fil-c/71476 https://discourse.nixos.org/t/radically-improving-nix-nixos-...
- simonask 11mo agoSo I don’t want to come off as dismissive of the effort - it’s certainly impressive! The reason I’m not super excited is based on the widely publicized findings from Google and Microsoft (IIRC) about memory safety issues in their code: The vast majority is in new code. As such, the returns on running the entire userspace with Fil-C may be quite diminished from the get-go. Those who need to guard against UB bugs in seriously battle-hardened C software in production are definitely a small niche. But that doesn’t mean it isn’t also very useful as a tool during development.
- mbrock 11mo agoHmm, so if they're writing new memory unsafe code in C/C++, presumably to remain within their already established and entrenched C/C++ ecosystems, why isn't Fil-C interesting as a way to thwart memory safety issues in that new code?
- simonask 11mo agoBecause every problem detected by Fil-C is already a serious problem in the existing code. As a mitigation strategy, that becomes less interesting as the quality of that code increases, but you still pay the full cost regardless of whether there are actually any bugs. That can certainly be valuable to you, but as a developer, the more interesting proposition is about how not to ship bugs in the first place.
- vacuity 11mo agoAs others have said, programs that have already been written are plainly not in the business of "not...[shipping] bugs in the first place". New code is new code; old code is old code.
- jitl 11mo agoIt seems like there are constant updates for 20 year old packages on my Ubuntu systems. Ubuntu 20.04 Focal Fossa (first released April 2020) glibc had an update on 2025-05-28. Current stable updated glibc 2025-09-22. To say nothing about the rest of the packages in that operating system.
- vorador 11mo agoThere's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust. Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.
- testdelacc1 11mo agoThere’s no Rust fans here, only GC skeptics. GC skeptics existed long before anyone dreamed of Rust and will survive Rust as well. It’s a pretty reasonable objection too (though I personally don’t agree). C has always been chosen when performance is paramount. For people who prioritise performance it must feel a bit weird to leave performance on the table in this way. And Jesus Christ, give it a rest with this “Rust fans must be thinking” stuff. It sounds deranged.
- vorador 11mo agoNo, back in the day C was used for everything. Vim was not written in C because it needed to wring every last bit of performance out of text editing. Rewriting everything in rust "for memory-safety" is a false tradeoff given the millions of lines of C code out there and the fact that rewrites always introduce new bugs.
- testdelacc1 11mo agoPlease, I’m begging you, stop talking about Rust. You’re shoehorning Rust into a discussion where it hasn’t been mentioned, just to hate on some imaginary people you think are pushing Rust here. No one is talking about that. You sound deranged and obsessed. The vast majority of the conversation here is about GC and the performance implications of that. Please stick to the rest of the thread.
- vorador 11mo ago[flagged]
- HL33tibCe7 11mo agoThe value prop here is for existing projects in C or C++, as is made abundantly clear in the linked article
- GTP 11mo agoI would say that Rust would be a better choice rarher than patching memory safety on top of C. But I think the reason for this is that most, if not all, cryptographic reference implementations are in C. So they want to use existing reference implementations without having to port them to Rust. IMO cryptographers should start using Rust for their reference implementations, but I also get that they'd rather spend their time working on their next paper rather than learning a new language.
- _flux 11mo agoI'm not a practioner of cryptography, but I would be wary about timing attacks that might become possible if such a dynamic runtime is introduced. At least relevant pieces of code would need to be re-evaluated in the Fil-C environment. But maybe you could use C as the "glue language" and then the build better performing libraries in Rust for C to use. Like in Python!
- johnisgood 11mo ago> IMO cryptographers should start using Rust for their reference implementations IMO they should not, because if I look at a typical Rust code, I have no clue what is going on even with a basic understanding of Rust. C, however, is as simple as it gets and much closer to pseudocode.
- Ar-Curunir 11mo ago
- i80and 11mo agoThe user of the code may plausibly want to make a different tradeoff than the author, without wanting to rewrite the project from scratch.
- tkz1312 11mo agoI do not think this is niche in the slightest. I would very happily take a 2-4x slowdown for almost all of the web facing C software I run if I get guaranteed memory safety. I will be using at the very least fil-c openssh (and likely much more) on every machine I run.
- simonask 11mo agoSure, that makes sense. The point I’m making is just that from an engineering perspective, that also implies that there is no longer any reason for that software you’re running to be written in C at all.
- mbrock 11mo agoFrom an engineering perspective, the software is already written in C, and you're weighing the tradeoffs between rewriting it and recompiling it.
- sfpotter 11mo agoSure there is. Making tough choices between alternatives based on where to allocate a limited amount of manpower is an engineering choice. Choosing to use Fil-C to recompile existing (established, stabilized, functional...) software rather than rewrite it is an engineering choice.
- deleted 11mo ago[deleted]
- somat 11mo agoApologies ahead of time as this is pure FUD, That is I don't actually know what I am talking about but had an interesting thought. Remember the Debian weak keys kerfuffle, That was caused because the Debian package maintainer saw a warning about using uninitialized memory, fixed it, and then it turned out that uninitialized memory was a critical seed for the openssl random number generator. Anyhow my stupid FUD thought. is there a weak-key equivalent bug that shows up now that your C compiler is memory safe?
- kragen 11mo agoI think Fil-C is for people who are using software that has already been written, not for people who are trying to pick what language to write new software in. A substantial amount of software has, after all, already been written.
- pizlonator 11mo agoIt's super fun to write C and C++ code in Fil-C because it's like this otherworldly crossover between Java and C/C++: - Unlike Java, you get fantastic startup times. - Unlike Java, you get access to actual syscall APIs. - Unlike Java, you can leverage the ecosystem of C/C++ libraries without having to write JNI wrappers (though you do have to be able to compile those libraries with Fil-C). - Like Java, you can just `new` or `malloc` without `delete`ing or `free`ing. It's so fun!
- kragen 11mo agoI like C, have a probably unhealthy relationship with C++ where I am amazed by what it can do and then get unrealistic expectations it keeps failing to fulfill, and don't really like Java. You know Julia Ecklar's song where she says that programming in assembler is like construction work with a toothpick for a tool? I feel like C, C++, or Java are like having a teaspoon instead. Maybe Java is a tablespoon. I'd rather use something like OCaml or a sane version of Python without the Mean Girls community infighting. I just haven't found it. On the other hand, the supposedly more powerful languages don't have a great record of shipping highly usable production software. There's no Lisp or Ruby or Lua alternative to Firefox, Linux, or LLVM.
- skissane 11mo ago> Like Java, you can just `new` or `malloc` without `delete`ing or `free`ing. Is your intention that people use the Fil-C garbage collector instead of free()? Or is it just a backstop in case of memory leak bugs? Can the GC be configured to warn or panic if something is GCed without free()? Then you could detect memory leak bugs by recompiling with Fil-C - with less overhead than valgrind, although I’m guessing still more than ASan - but more choices is always a good thing.
- EPWN3D 11mo agoEven if you can't use something like Fil-C in your release/production builds, being able to e.g. compile unit tests with it to catch memory safety bugs is a huge win. My team use gcc for its mips codegen, but I'm working on adopting the clang bounds-safety annotations for test builds for exactly this reason.
- OmarAssadi 11mo agoYeah, I haven't yet taken a serious look into it from that perspective yet, but similar came to mind; while, outside of bootstrapping the JDK from GCJ, Boehm GC hasn't been super relevant to me for "release" builds of anything, it's been useful in leak detection mode on occasion. I figure even if you cannot use, or do not want to use, something like Fil-C in production, there's solid potential for it to augment whatever existing suite of sanitizers and other tools that one may already build against.
- usefulcat 11mo agoThe point is that it can compile most existing C and C++ code as-is, and do it while providing complete memory safety. That's the claim, anyway. Doesn't sound all that niche to me.
- rowanG077 11mo agoI expect Fil-C is not really aimed at green field projects. But rather at making existing projects safe.
- miki123211 11mo agoIf you write your software in a language that needs GC, everybody using your software needs GC, but they're guaranteed to get memory safety. If you write your software in an unsafe, non-GC language, nobody needs GC, but nobody gets memory safety either. This is why many software developers chose the latter option. If there were some use cases in which GC wasn't acceptable for their software, nobody would get GC, even the people who could afford it, and would prefer the increased memory safety. Fil-C lets the user make this tradeoff. If you can accept the GC, you compile with Fil-C, otherwise you use a traditional C compiler.
- quotemstr 11mo agoIt's amazing how much technical discourse revolves around impressions. "Oh, it has a GC! GC bad!" "No, this GC by smart guy, so good!" "No, GC always bad!" People aren't engaging with the technical substance. GC based systems and can be plenty good and fast. How do people think JavaScript works? And Go? It's like people just absorbed from the discursive background radiation the idea GC is slow without understanding why that might be or whether it's even true. Of course it's not.
- pas 11mo agoHi, I noticed you made a typo in "JS bad, Go bad", it's not too late to edit your comment! /s
- mbrock 11mo agoYou can wrack some people's brains by stating that for some problems, a GC is a great way to alleviate the performance problems caused by manual memory management.
- jeltz 11mo agoFor those problems arena allocators tend to perform even better.
- mbrock 11mo agoYeah, but if you actually need to retain a live subgraph of the allocated heap, the arena can't help you. So you make an arena allocator that only frees its slab after moving out the reachable set to a new compacted arena. Congratulations, you've implemented a Cheney-style compacting GC!
- quotemstr 11mo agoNot for all allocation patterns. It's hard to beat bump pointer allocation and escape analysis in general.
- kragen 11mo ago> How do people think JavaScript works? Very slowly. Java, OCaml, or LuaJIT would be better examples here!