For those, like me, that didn’t know what Fil-C is:
> Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (InvisiCaps). Every possibly-unsafe C and C++ operation is checked. Fil-C has no unsafe statement and only limited FFI to unsafe code.
The posted article has a detailed explanation of djb successfully compiling a bunch of C and C++ codebases.
commandersaki 6 hours ago [-]
I guess to get on board with this, it is my understanding you have to accept the premise of a Garbage Collector in the runtime?
mbrock 5 hours 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 4 hours ago [-]
If 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 4 hours ago [-]
I 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?
simonask 2 hours ago [-]
So 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 2 hours ago [-]
Hmm, 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?
jitl 1 hours ago [-]
It 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.
jitl 36 minutes ago [-]
Oh, look at the time, a few more CVEs in C code, posted 3 hours ago to Hacker News: "X.Org Security Advisory: multiple security issues X.Org X server and Xwayland"
To torture the analogy: perhaps the "returns" are diminishing, but their absolute value is still a few million bucks, I'm happy to take those returns.
vorador 47 minutes ago [-]
There'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 12 minutes ago [-]
There’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.
I 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.
tkz1312 3 hours ago [-]
I 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 2 hours ago [-]
Sure, 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 2 hours ago [-]
From an engineering perspective, the software is already written in C, and you're weighing the tradeoffs between rewriting it and recompiling it.
sfpotter 2 hours ago [-]
Sure 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.
usefulcat 51 minutes ago [-]
The 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.
EPWN3D 2 hours ago [-]
Even 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.
i80and 4 hours ago [-]
The user of the code may plausibly want to make a different tradeoff than the author, without wanting to rewrite the project from scratch.
HL33tibCe7 4 hours ago [-]
The value prop here is for existing projects in C or C++, as is made abundantly clear in the linked article
GTP 4 hours ago [-]
I 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.
johnisgood 39 minutes 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.
_flux 3 hours ago [-]
I'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!
mbrock 2 hours ago [-]
Good call! Fil-C does in fact have a way to let you build and run OpenSSL with its constant time crypto. I don't know how this works exactly but I guess it's relatively easy to guarantee it's safe.
kragen 19 minutes ago [-]
How easy is it to link Rust code with C compiled with Fil-C's ABI?
quotemstr 2 hours ago [-]
It'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.
mbrock 2 hours ago [-]
You 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 1 hours ago [-]
For those problems arena allocators tend to perform even better.
mbrock 55 minutes ago [-]
Yeah, 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 48 minutes ago [-]
Not for all allocation patterns. It's hard to beat bump pointer allocation and escape analysis in general.
pas 2 hours ago [-]
Hi, I noticed you made a typo in "JS bad, Go bad", it's not too late to edit your comment! /s
kragen 6 hours ago [-]
So far we haven't found a viable alternative; CHERI has holes in its temporal integrity guarantees.
Slothrop99 10 hours ago [-]
Great to see some 3letter guy into this. This might be one of those rando things which gets posted on HN (and which doesn't involve me in the slightest), but a decade later is taking over the world. Rust and Go were like that.
Previously there was that Rust in APT discussion. A lot of this middle-aged linux infrastructure stuff is considered feature-complete and "done". Not many young people are coming in, so you either attract them with "heyy rewrite in rust" or maybe the best thing is to bottle it up and run in a VM.
mesrik 9 hours ago [-]
>Great to see some 3letter guy into this
AFAIK, djb isn't for many "some 3letter guy" for over about thirty years but perhaps it's just age related issue with those less been around.
Just to be clear, I mean to venerate Bernstein for earning his 3letters, not to trivialize him.
3 hours ago [-]
jabwd 3 hours ago [-]
Despite the cool shit the guy has done, keep in mind that "venerate" is not the word to use here. djb is very much not a shorthand used in any positive messaging pretty much ever by any cryptographer. He did it to himself, sadly.
pas 2 hours ago [-]
Sorry, can you explain what he did to himself?
ggm-at-algebras 8 hours ago [-]
Not to trivialise but being a 3 letter guy means being old. So, it's at best a celebration of achieving longevity and at worst a celebration of creaky joints and a short temper.
vkazanov 8 hours ago [-]
Most of us will have a problematic joint or two by a certain age. Almost none of us will be recognised by any name by that time.
ggm-at-algebras 7 hours ago [-]
Mate, we're not talking about the future, but about 3 letter guys now. I'm one, I've carried it with me for 40+ years as have the ten or twenty peers of mine I know by their tla. I got it at pobox.com when the door opened, the guy at the desk next door got a one letter name. I set up campus email for the entire uni in 1989 and gave myself the tla with my superuser rights before that. I'd done the same at ucl-cs in 85, and before that in Leeds and York.
My point here is we're not famous we're just old enough to have a tla from the time before HR demanded everyone get given.surname.
Every Unix system used to ship with a dmr account. It doesn't mean we all knew Dennis Ritchie, it means the account was in the release tape.
There are 17,000 odd of us. Ekr, Kre and Djb are famous but the other 17,573 of us exist.
Valodim 7 hours ago [-]
I'm not sure what your point is here. OP was clearly using "three letter guy" in the sense "so famous people know them by their initials". This is hardly unread of, e.g. https://wiki.c2.com/?ThreeLetterPerson
mesrik 5 hours ago [-]
It was the "Great to see _some_ 3letter guy into this" underlined some that.
It felt bit like s/some/random/g perhaps would apply when reading it. Intentional or not by writer. It made me long and write my comment. There are many 3letter user accounts, which some are more famous than others. To my generation not because they were early users, but great things what they have done. I'm early user too and done things then still quite widely being used with many distributions, but wouldn't compare my achievements to those who became famous and known widely by their account, short or long.
Anyhow I thought that "djb" ring bell anyone having been around for while. Not just those who have been around early 90 or so when he was held renegade opinions he expressed programming style (qmail, dj dns, etc.), dragged to court of ITAR issues etc.
But because of his latter work with cryptography and running cr.yp.to site for quite long time.
I was just wondering, did not intend to start argument fight.
debugnik 6 hours ago [-]
Is this because they're that famous though or simply because there weren't as many people in the scene back then? We just don't do the initials thing anymore.
6 hours ago [-]
8 hours ago [-]
pixelpoet 6 hours ago [-]
It's wild how much he looks like ryg, another 3 letter genius
8 hours ago [-]
kragen 6 hours ago [-]
To summarize, he's sufficiently impressed with it that he's embarking on an attempt to rebuild an entire Debian system with it, and he's written some software (a GC shim library and build scripts) that are likely to be of interest to others who are attempting the same thing.
1vuio0pswjnm7 50 minutes ago [-]
For those who might miss it, the notes cite a new 64-bit version of cdb that supports exabyte databases
Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve
le-mark 5 hours ago [-]
> I had originally configured the server phoenix with only 12GB swap. I then had to restart ./build_all_fast_glibc.sh a few times because the Fil-C compilation ran out of memory. Switching to 36GB swap made everything work with no restarts; monitoring showed that almost 19GB swap (plus 12GB RAM) was used at one point. A larger server, 128 cores with 512GB RAM, took 8 minutes for Fil-C plus 6 minutes for musl, with no restarts needed.
Yikes that’s a lot of memory! Filc is doing a lot of static analysis apparently.
mbrock 3 hours ago [-]
I think that's the build of LLVM+Clang itself.
nitinreddy88 6 hours ago [-]
Building tools is one thing, building a system like Postgres or Databases is going to be another thing.
Anyone really tried building PG or MySQL or such a complex system which heavily relies on IO operations and multi threading capabilities
mbrock 5 hours ago [-]
Look at how fanatic the compatibility actually is. Building Postgres or MySQL is conceivable but probably will require some changes. (SQLite compiles and runs with zero changes right now.)
kragen 3 hours ago [-]
Thanks for checking! I was wondering.
mbrock 2 hours ago [-]
If you run Nix (whether on NixOS or elsewhere) you can do `cachix use filc` and `nix run github:mbrock/filnix#sqlite` and it should drop you into a Fil-C SQLite after downloading the runtime dependencies from my binary cache (no warranty)!
kragen 2 hours ago [-]
Thanks!
scandox 8 hours ago [-]
Interesting to see some bash curl being used by a renowned cryptologist...
It is definitely not fine. The argument seems to be that since you need to trust somebody, curl | bash is fine because you just trust whoever controls the webserver. I think this is missing the point.
oddmiral 6 hours ago [-]
s/webserver/DNS/
arthur2e5 4 hours ago [-]
HTTPS is there, so you go down to that level only if you want to distrust any element of the public key infrastructure. Which, to be fair, there are plenty of reasons if you are paranoid -- they do tell you who's doing what in a shady way as they revoke, so there's a huge list of transgressions.
whyever 6 hours ago [-]
It's missing which point?
uecker 5 hours ago [-]
That you should be very careful about what you install. Cut&pasting some line from a website is the exact opposite of it. This is mostly about psychology and not technology. But there are also other issues with this, e.g. many independent failure points at different levels, no transparency, no audit chain, etc.
The counter model we tried to teach people in the past is that people select a linux distribution, independently verify fingerprints of the installation media, and then only install packages from the curated a list of packages. A lot of effort went into making this safe and close the remaining issues.
IshKebab 4 hours ago [-]
None of that has anything to do with curl|bash.
Be careful who you trust when installing software is a fine thing to teach. But that doesn't mean the only people you can trust are Linux distro packagers.
uecker 4 hours ago [-]
I think it has a lot to do with "curl|bash". Cut&paste a curl|bash command-line disables all inherent mechanisms and stumbling blocks that would ensure properly ensuring trust. It was basically invented to make it easy to install software by circumventing all protection a Linux distribution would traditionally provide. It also eliminates all possibility for independent verification about what was installed or done on the machine.
IshKebab 4 hours ago [-]
Downloading and installing a `.deb` or `.rpm` is going to be no more secure. They can run arbitrary scripts too.
uecker 4 hours ago [-]
Downloading a deb via a package manager is more secure. Downloading a deb, comparing the hash (or at least noting down the hash) would also already be more secure.
But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).
3 hours ago [-]
IshKebab 3 hours ago [-]
> Downloading a deb via a package manager is more secure.
Not what I meant. Getting software into 5 different distros and waiting years for it to be available to users is not really viable for most software authors.
oguz-ismail 7 hours ago [-]
[flagged]
quotemstr 2 hours ago [-]
I can't wait for all the delicious four-way flamewars. Choose your fighter!
1) Rewrite X in Rust
2) Recompile X using Fil-C
3) Recompile X for WASM
4) Safety is for babies
There are a lot of half baked Rust rewrites whose existence was justified on safety grounds and whose rationale is threatened now that HN has heard of Fil-C
dev_l1x_be 2 hours ago [-]
We have a saying that jam is made of fruit that gave up the fight becoming a brandy.
ddalex 2 hours ago [-]
I'm on camp 2.
jeffrallen 8 hours ago [-]
Wish we were talking about making Fil-C required for apt, not Rust...
phicoh 7 hours ago [-]
Those seems to be independent issues. Fil-C is about the best way to compile/run C code.
Rust would be about what language to use for new code.
Now that I have been programming in Rust for a couple of years, I don't want to go back to C (except for some hobby projects).
thomasmg 7 hours ago [-]
I agree. The main advantage of Fil-C is compatibility with C, in a secure way. The disadvantages are speed, and garbage collection. (Even thought, I read that garbage collection might not be needed in some cases; I would be very interested in knowing more details).
For new code, I would not use Fil-C. For kernel and low-level tools, other languages seem better. Right now, Rust is the only popular language in this space that doesn't have these disadvantages. But in my view, Rust also has issues, specially the borrow checker, and code verbosity. Maybe in the future there will be a language that resolves these issues as well (as a hobby, I'm trying to build such a language). But right now, Rust seems to be the best choice for the kernel (for code that needs to be fast and secure).
kees99 5 hours ago [-]
> disadvantages are speed, and garbage collection.
And size. About 10x increase both on disk and in memory
There is no C or C++ memory safe compiler with acceptable performance for kernels, rendering, games, etc. For that you need Rust.
The future includes Fil-C for legacy code that isn’t performance sensitive and Rust for new code that is.
sibellavia 3 hours ago [-]
How slow? In some contexts, the trade-off might be acceptable. From what I've seen in pizlonator's tweets, in some cases the difference in speed didn't seem drastic to me.
kevincox 2 hours ago [-]
Yeah, I would happily run a bunch of my network services in this. I have loads of services that are public-facing doing a lot of complex parsing and rule evaluation and are mostly idle. For example my whole mailserver stack could probably benefit from this. My few messages an hour can run 2x slower. Maybe I would leave dovecot native since the attack surface before authentication is much lower and the performance difference would be more noticeable (mostly for things like searches).
kragen 1 hours ago [-]
You may be aware that one of the things Bernstein is famous for is revolutionizing mailserver security.
mbrock 5 hours ago [-]
What does that have to do with apt?
dontlaugh 5 hours ago [-]
Enough of it is performance sensitive that Fil-C is not an option.
Fil-C is useful for the long tail of C/C++ that no one will bother to rewrite and is still usable if slow.
procaryote 4 hours ago [-]
How is apt performance sensitive?
kragen 3 hours ago [-]
Apt has been painfully slow since I started using Debian last millennium, but I suspect it's not because it uses a lot of CPU, or it would be snappy by now.
dontlaugh 2 hours ago [-]
It parses formats and does TLS, I’m assuming it’d be quite bad. I don’t think you can mix and match.
electroly 2 minutes ago [-]
Apt is pretty I/O-bound. Monitor its CPU usage while doing an install sometime and see for yourself. This is perfect for Fil-C.
jitl 1 hours ago [-]
stuff that talks to "the internet" and runs as "root" seems like a good thing to build with filc.
lucyjojo 5 hours ago [-]
doesnt it only work on x86_64?
oddmiral 6 hours ago [-]
I wish, we will have something like Fil-C as an option for unsafe Rust.
arthur2e5 4 hours ago [-]
Fil-C works because you recompile the whole C userspace. Unsafe Rust doesn't do that... and for many practical purposes you probably want to touch the non-safe-version of the C userspace.
Still, it's all LLVM, so perhaps unsafe Rust for Fil-space can be a thing, a useful one for catching (what would be) UBs even [Fil-C defines everything, so no UBs, but I'm assuming you want to eventually run it outside of Fil-space].
Now I actually wonder if Fil-C has an escape hatch somewhere for syscalls that it does not understand etc. Well it doesn't do inline assembly, so I shouldn't expect much... I wonder how far one needs to extend the asm clobber syntax for it to remotely come close to working.
simonask 4 hours ago [-]
Unsafe Rust actually has a great runtime analyzer: Miri. It's very easy to just run `cargo +nightly miri test` in your project to get some confidence in the more questionable choices along the way.
Rendered at 17:05:03 GMT+0000 (Coordinated Universal Time) with Vercel.
> Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minimal changes. All memory safety errors are caught as Fil-C panics. Fil-C achieves this using a combination of concurrent garbage collection and invisible capabilities (InvisiCaps). Every possibly-unsafe C and C++ operation is checked. Fil-C has no unsafe statement and only limited FFI to unsafe code.
https://fil-c.org/
The posted article has a detailed explanation of djb successfully compiling a bunch of C and C++ codebases.
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++?
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.
https://news.ycombinator.com/item?id=45790015
https://lists.x.org/archives/xorg-announce/2025-October/0036...
To torture the analogy: perhaps the "returns" are diminishing, but their absolute value is still a few million bucks, I'm happy to take those returns.
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.
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.
That's the claim, anyway. Doesn't sound all that niche to me.
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.
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.
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!
"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.
Previously there was that Rust in APT discussion. A lot of this middle-aged linux infrastructure stuff is considered feature-complete and "done". Not many young people are coming in, so you either attract them with "heyy rewrite in rust" or maybe the best thing is to bottle it up and run in a VM.
AFAIK, djb isn't for many "some 3letter guy" for over about thirty years but perhaps it's just age related issue with those less been around.
https://en.wikipedia.org/wiki/Daniel_J._Bernstein
My point here is we're not famous we're just old enough to have a tla from the time before HR demanded everyone get given.surname.
Every Unix system used to ship with a dmr account. It doesn't mean we all knew Dennis Ritchie, it means the account was in the release tape.
There are 17,000 odd of us. Ekr, Kre and Djb are famous but the other 17,573 of us exist.
It felt bit like s/some/random/g perhaps would apply when reading it. Intentional or not by writer. It made me long and write my comment. There are many 3letter user accounts, which some are more famous than others. To my generation not because they were early users, but great things what they have done. I'm early user too and done things then still quite widely being used with many distributions, but wouldn't compare my achievements to those who became famous and known widely by their account, short or long.
Anyhow I thought that "djb" ring bell anyone having been around for while. Not just those who have been around early 90 or so when he was held renegade opinions he expressed programming style (qmail, dj dns, etc.), dragged to court of ITAR issues etc.
But because of his latter work with cryptography and running cr.yp.to site for quite long time.
https://cr.yp.to/
I was just wondering, did not intend to start argument fight.
https://cdb.cr.yp.to
Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve
Yikes that’s a lot of memory! Filc is doing a lot of static analysis apparently.
Anyone really tried building PG or MySQL or such a complex system which heavily relies on IO operations and multi threading capabilities
https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d...
Be careful who you trust when installing software is a fine thing to teach. But that doesn't mean the only people you can trust are Linux distro packagers.
But yes, that the run arbitrary scripts is also a known issue, but this is not the main point as most code you download will be run at some point (and ideally this needs sandboxing of applications to fix).
Not what I meant. Getting software into 5 different distros and waiting years for it to be available to users is not really viable for most software authors.
1) Rewrite X in Rust
2) Recompile X using Fil-C
3) Recompile X for WASM
4) Safety is for babies
There are a lot of half baked Rust rewrites whose existence was justified on safety grounds and whose rationale is threatened now that HN has heard of Fil-C
Rust would be about what language to use for new code.
Now that I have been programming in Rust for a couple of years, I don't want to go back to C (except for some hobby projects).
For new code, I would not use Fil-C. For kernel and low-level tools, other languages seem better. Right now, Rust is the only popular language in this space that doesn't have these disadvantages. But in my view, Rust also has issues, specially the borrow checker, and code verbosity. Maybe in the future there will be a language that resolves these issues as well (as a hobby, I'm trying to build such a language). But right now, Rust seems to be the best choice for the kernel (for code that needs to be fast and secure).
And size. About 10x increase both on disk and in memory
There is no C or C++ memory safe compiler with acceptable performance for kernels, rendering, games, etc. For that you need Rust.
The future includes Fil-C for legacy code that isn’t performance sensitive and Rust for new code that is.
Fil-C is useful for the long tail of C/C++ that no one will bother to rewrite and is still usable if slow.
Still, it's all LLVM, so perhaps unsafe Rust for Fil-space can be a thing, a useful one for catching (what would be) UBs even [Fil-C defines everything, so no UBs, but I'm assuming you want to eventually run it outside of Fil-space].
Now I actually wonder if Fil-C has an escape hatch somewhere for syscalls that it does not understand etc. Well it doesn't do inline assembly, so I shouldn't expect much... I wonder how far one needs to extend the asm clobber syntax for it to remotely come close to working.