23 ms·

Notes by djb on using Fil-C

365 points by transpute 1y ago

Slothrop99 1y 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 1y 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. https://en.wikipedia.org/wiki/Daniel_J._Bernstein https://en.wikipedia.org/wiki/Daniel_J._Bernstein
  - Slothrop99 1y ago
    Just to be clear, I mean to venerate Bernstein for earning his 3letters, not to trivialize him.
    - ggm-at-algebras 1y 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.
      - deleted 1y ago
        [deleted]
      - vkazanov 1y 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 1y 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 1y 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 https://wiki.c2.com/?ThreeLetterPerson
        debugnik 1y 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.
        overfeed 1y ago
        Yes: the fame is the subtext. It's akin to mononyms; they'd be referring to famous people like Shakira, Madonna, or Beyoncé. A lot of us have first names, but the point isn't that one's family calls them "Dave" without ambiguity. There were many unix instances, and likely multiple djb logins around the world, but there's only one considered to be the djb, and it's dur to fame.
    - deleted 1y ago
      [deleted]
    - jabwd 1y 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 1y ago
        Sorry, can you explain what he did to himself?
        bgwalter 1y ago
        I would like to know as well. All that is public is that a couple of IETF apparatchiks want to ban him for criticizing corporate and NSA influence: https://web.archive.org/web/20250513185456/https://mailarchive.ietf.org/arch/msg/tls/nqouPVfPtU7hm-RF0lSDHCfze54/ https://web.archive.org/web/20250513185456/https://mailarchi... The IETF has now accepted the required new moderation guidelines, which will essentially be a CoC troika that can ban selectively: https://mailarchive.ietf.org/arch/msg/mod-discuss/s4y2j3Dv6DS4qns7AwqRunowIHY/ https://mailarchive.ietf.org/arch/msg/mod-discuss/s4y2j3Dv6D... It is very sad that all open source and Internet institutions are being subverted by bureaucrats.
        pas 1y ago
        ... if he thinks some WG is making a mistake and he's not welcome there (everyone else seems to be okay with what's happening based on the quoted email on the first link), then - CoC or not - he should then leave, and publicly post distance himself from the outcome. (Obviously he was never the one to back down from a just fight, but it's important to find the right hill to die on. And allies! And him not following RFC 2026 [from 1996, hardly the peak of Internet bureaucracy] is not a CoC thing anyway.)
        bgwalter 1y ago
        Why should he leave? The IETF pretends on its sponsor page (https://www.ietf.org/support-us/endowment/ https://www.ietf.org/support-us/endowment/): The IETF is a global standards-setting organization, intentionally created without a membership structure so that anyone with the technical competency can participate in an individual capacity. This lack of membership ensures its position as the primary neutral standards body because participants cannot exert influence as they could in a pay-to-play organization where members, companies, or governments pay fees to set the direction. IETF standards are reached by rough consensus, allowing the ideas with the strongest technical merit to rise to the surface. Further, these standards that advance technology, increase security, and further connect individuals on a global scale are freely available, ensuring small-to-midsize companies and entrepreneurs anywhere in the world are on equal footing with the large technology companies. With a community from around the world, and an increased focus on diversity in all its forms, IETF seeks to ensure that the global Internet has input from the global community, and represents the realities of all who use it. There is only one IETF, and telling dissenters to leave is like telling a dissenting citizen to go to another country. I don't think that people (apart from real spammers) were banned in 1996. The CoC discussion and power grab has reached the IETF around 2020 and it continues. "Posting too many messages" has been deemed a CoC violation by for example the PSF and its henchmen, and functionally the IETF is using the same selective enforcement no matter what the official rationale is. They won't go after the "director" Wouters, even though his message was threatening and rude.
  - pixelpoet 1y ago
    It's wild how much he looks like ryg, another 3 letter genius
- deleted 1y ago
  [deleted]
scandox 1y ago
Interesting to see some bash curl being used by a renowned cryptologist...
- IshKebab 1y ago
  Almost like it's actually fine. https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d6676eb607c9 https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d...
  - oguz-ismail 1y ago
    [flagged]
  - uecker 1y ago
    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 1y ago
      s/webserver/DNS/
      - arthur2e5 1y 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.
        zzo38computer 1y ago
        It is not only that directly; the domain name might be reassigned to someone else, resulting in a valid certificate which is different than the one you wanted. (If you have the hash of the file which you have verified independently then it is more secure (if the hash algorithm is secure enough), although HTTPS is not needed in that case, it can still be used if you wish to avoid spies knowing which file you accessed. You can also use the server's public key if you know what it should be, although this has different issues, such as someone compromising the server (or the key) and modifying the script.) (There is also knowing if the script is what you intended or not anyways (or if there is something unexpected due to the configuration on your computer); if that is your issue, you can read it (and perhaps verifying the character encoding) before executing it, whether or not you trust the server operator and the author of that script.)
jeffrallen 1y ago
Wish we were talking about making Fil-C required for apt, not Rust...
- phicoh 1y 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 1y 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 1y ago
      > disadvantages are speed, and garbage collection. And size. About 10x increase both on disk and in memory $ stat -c '%s %n' {/opt/fil,}/bin/bash 15299472 /opt/fil/bin/bash 1446024 /bin/bash $ ps -eo rss,cmd | grep /bash 34772 /opt/fil/bin/bash 4256 /bin/bash
      - nialse 1y ago
        How does that compare with rust? You don't happen to have an example of a binary underway moving to rust in Ubuntu-land as well? Curious to see as I honestly don't know whether rust is nimble like C or not.
testdelacc1 1y ago
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. https://fil-c.org/ https://fil-c.org/ The posted article has a detailed explanation of djb successfully compiling a bunch of C and C++ codebases.
- commandersaki 1y 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?
  - kragen 1y ago
    So far we haven't found a viable alternative; CHERI has holes in its temporal integrity guarantees.
    - Findecanor 1y ago
      Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool. The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet. I've seen discussions on adding an additional memory tag to CHERI for memory in quarantine, but I dunno what is best. Fil-C relies on the compiler being trusted whereas CHERI does not. If we do, then perhaps we could come up with a hardware-accelerated system that is more lightweight than either.
      - kragen 1y ago
        I didn't know this, but aside from the GC, Fil-C promptly revokes capabilities to freed objects, not relying on a concurrent task to do it eventually; CHERI cannot AFAIK.
nitinreddy88 1y 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 1y 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 1y ago
    Thanks for checking! I was wondering.
    - mbrock 1y 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 1y ago
        Thanks!
  - SQLite 11mo ago
    SQLite runs about 5 times faster compiled with GCC (13.3.0) than it does when compiled with FIL-C. And the resulting compiled binary from GCC is 13 times smaller.
    - mbrock 11mo ago
      Interesting! I guess that's from your standard benchmark setup. Please note that Fil-C makes no secret of having a performance penalty. It's definitely a pre-1.0 toolchain and only recently starting to pick up some momentum. The author is eager to keep improving it, and seems to think that there's still plenty of low hanging and medium hanging fruit to pick. It does (or did, at some point) pass the thorough SQLite test suite, so at least it's probably correct! The famous SQLite test coverage and general proven quality might make SQLite itself less interesting to harden, but in order to run less comprehensively verified software that links with SQLite, we have to build SQLite with Fil-C too.
kragen 1y 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.
le-mark 1y 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 1y ago
  I think that's the build of LLVM+Clang itself.
  - collinfunk 1y ago
    Yes, linking LLVM takes up a lot of memory. The documented guidance is to allow one link job per 15 GB of RAM [1]. [1] https://llvm.org/docs/CMake.html#frequently-used-llvm-related-variables https://llvm.org/docs/CMake.html#frequently-used-llvm-relate...
    - brucehoult 1y ago
      And, fairly uniquely, LLVM has a LLVM_PARALLEL_LINK_JOBS setting that is distinct from the number of parallel jobs for everything else. I think I was using that 15 years ago. I wish GCC had it. I have a quad core machine with 16 GB RAM that OOMs on building recent GCC -- 15 and HEAD for sure, can't remember whether 14 is affected. Enabling even 1 GB of swap makes it work. The culprit is four parallel link jobs needing ~4 GB each. There are only four of them, so a -j8 build (e.g., with HT) is no worse.
    - Narishma 1y ago
      Is that why the Rust toolchain can't be compiled on a 32-bit system?
      - the_mitsuhiko 11mo ago
quotemstr 1y 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
- Klonoar 1y ago
  Fil-C has come up on HN plenty of times before. If it was going to make much of a dent in the discussions, it would have by now.
  - quotemstr 1y ago
    It's strange how ideas seem to explode at random into the discourse despite being known for a long time. It's as if some critical mass stumbles on a thing and it becomes "the current thing" everyone talks about until the next current thing.
  - jitl 1y ago
    odd fallacy. things grow in popularity / awareness over time
- ddalex 1y ago
  I'm on camp 2.
- dev_l1x_be 1y ago
  We have a saying that jam is made of fruit that gave up the fight becoming a brandy.
- Rebelgecko 1y ago
  Obviously someone needs to rewrite Rust in Fil-C
  - pizlonator 1y ago
    Yeah since Fil-C is just an LLVM transform we could make Rust memory safe with it
1vuio0pswjnm7 1y ago
For those who might miss it, the notes cite a new 64-bit version of cdb that supports exabyte databases https://cdb.cr.yp.to https://cdb.cr.yp.to Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve
- loeg 1y ago
  https://news.ycombinator.com/item?id=45663435 https://news.ycombinator.com/item?id=45663435 (discussed 11d ago)
- Panino 1y ago
  > Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve This is not correct. There isn't a cdb subdomain because cdb.cr.yp.to doesn't have NS records, which is where DNSCurve fits in. If you have a DNSCurve resolver, then your queries for cdb.cr.yp.to will use DNSCurve and will be sent to the yp.to nameservers. From there, if you have pqconnect, your http(s) connection to cdb.cr.yp.to will happen over pqconnect. Maybe the confusion is because both DNSCurve and pqconnect encode pubkeys in DNS, but they do different things. Here is DNSCurve: $ dig +short ns yp.to uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to. Here is pqconnect: $ dig +short cdb.cr.yp.to pq1htvv9k4wkfcmpx6rufjlt1qrr4mnv0dzygx5mlrjdfsxczbnzun055g15fg1.yp.to. 131.193.32.108 Like CurveCP, pqconnect puts the pubkey into a CNAME.
- deleted 1y ago
  [deleted]
- 1vuio0pswjnm7 1y ago
  Use of pqconnect at yp.to is probably old news but the cdb.cr.yp.to CNAME does appear to be new as of around 21 Oct The notes on using Fil-C were submitted three days ago https://news.ycombinator.com/item?id=45765718 https://news.ycombinator.com/item?id=45765718
  - 1vuio0pswjnm7 11mo ago
    s/CNAME/alias/
lquidfire 1y ago
Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wonder how / where Epic Games comes in?
- pornel 1y ago
  Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.
  - thesz 1y ago
    From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most interpreters are. The ROOT C/C++ interpreter is 20+ times slower than binary code, for example.
    - silotis 1y ago
      Cryptographic software is probably close to a best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. As long as Fil-C is able to avoid doing anything expensive in the inner loops you get good performance.
      - thesz 1y ago
        > best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. This describes most C programs and many, if not most, C++ programs. Basically, this is how C/C++ code is being written, by avoiding memory management, especially in tight loops.
dang 1y ago
Related: Fil-C: A memory-safe C implementation - https://news.ycombinator.com/item?id=45735877 https://news.ycombinator.com/item?id=45735877 - Oct 2025 (130 comments) Safepoints and Fil-C - https://news.ycombinator.com/item?id=45258029 https://news.ycombinator.com/item?id=45258029 - Sept 2025 (44 comments) Fil's Unbelievable Garbage Collector - https://news.ycombinator.com/item?id=45133938 https://news.ycombinator.com/item?id=45133938 - Sept 2025 (281 comments) InvisiCaps: The Fil-C capability model - https://news.ycombinator.com/item?id=45123672 https://news.ycombinator.com/item?id=45123672 - Sept 2025 (2 comments) Just some of the memory safety errors caught by Fil-C - https://news.ycombinator.com/item?id=43215935 https://news.ycombinator.com/item?id=43215935 - March 2025 (5 comments) The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=42226587 https://news.ycombinator.com/item?id=42226587 - Nov 2024 (1 comment) Rust haters, unite Fil-C aims to Make C Great Again - https://news.ycombinator.com/item?id=42219923 https://news.ycombinator.com/item?id=42219923 - Nov 2024 (6 comments) Fil-C a memory-safe version of C and C++ - https://news.ycombinator.com/item?id=42158112 https://news.ycombinator.com/item?id=42158112 - Nov 2024 (1 comment) Fil-C: Memory-Safe and Compatible C/C++ with No Unsafe Escape Hatches - https://news.ycombinator.com/item?id=41936980 https://news.ycombinator.com/item?id=41936980 - Oct 2024 (4 comments) The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=39449500 https://news.ycombinator.com/item?id=39449500 - Feb 2024 (17 comments) In addition, here are the major related subthreads from other submissions: https://news.ycombinator.com/item?id=45568231 https://news.ycombinator.com/item?id=45568231 (Oct 2025) https://news.ycombinator.com/item?id=45444224 https://news.ycombinator.com/item?id=45444224 (Oct 2025) https://news.ycombinator.com/item?id=45235615 https://news.ycombinator.com/item?id=45235615 (Sept 2025) https://news.ycombinator.com/item?id=45087632 https://news.ycombinator.com/item?id=45087632 (Aug 2025) https://news.ycombinator.com/item?id=44874034 https://news.ycombinator.com/item?id=44874034 (Aug 2025) https://news.ycombinator.com/item?id=43979112 https://news.ycombinator.com/item?id=43979112 (May 2025) https://news.ycombinator.com/item?id=43948014 https://news.ycombinator.com/item?id=43948014 (May 2025) https://news.ycombinator.com/item?id=43353602 https://news.ycombinator.com/item?id=43353602 (March 2025) https://news.ycombinator.com/item?id=43195623 https://news.ycombinator.com/item?id=43195623 (Feb 2025) https://news.ycombinator.com/item?id=43188375 https://news.ycombinator.com/item?id=43188375 (Feb 2025) https://news.ycombinator.com/item?id=41899627 https://news.ycombinator.com/item?id=41899627 (Oct 2024) https://news.ycombinator.com/item?id=41382026 https://news.ycombinator.com/item?id=41382026 (Aug 2024) https://news.ycombinator.com/item?id=40556083 https://news.ycombinator.com/item?id=40556083 (June 2024) https://news.ycombinator.com/item?id=39681774 https://news.ycombinator.com/item?id=39681774 (March 2024) https://news.ycombinator.com/item?id=39542944 https://news.ycombinator.com/item?id=39542944 (Feb 2024)
erichocean 1y ago
I would really like to see Omarchy go this direction. A fully memory-safe userland for Omarchy is possible with existing techhnology.
- timeon 1y ago
  Can you elaborate why Omarchy? I'm asking, in context of recompiling with Fil-C, because that seems to be just Arch + configurations.
  - erichocean 1y ago
    For cultural reasons, I would like Omarchy—culturally—to adopt straightforward security as one of their goals, in addition to usability and beauty. It's low hanging fruit, and a great way to further differentiate their Linux distribution.
fjfaase 1y ago
I am a bit surprised that the build_all_fast_glibc.sh script requires 31Gbyte of memory to run. Can somebody explain? I would like to try out Fil-C.
- ComputerGuru 1y ago
  Building and linking llvm sucks.
sheepscreek 1y ago
I’m glad Phil’s work is finally getting the recognition it deserves. There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!
- gpm 1y ago
  > particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds! As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.
  - quotemstr 1y ago
    He could add an API to mint a capability out of thin air. It could even be done out of process. In fact, I think Fil-C and CHERI could implement 90% the same programmer-level API!
  - hedgehog 1y ago
    For securing and maintaining a complex legacy application it seems like a reasonable approach would be to move the majority into Fil-C, then hook the bits that don't fit up via RPC. Maybe some bits get formal verification, rewritten in Rust, ported to new platform APIs, whatever, but at least you get some safety for the whole app without a rewrite.
twic 1y ago
> Debian using Fil-C (Filian?) DJB SMACKER CONFIRMED?!
fngjdflmdflg 1y ago
Is there a reason that some of the linked benchmarks, if I'm reading it right, have Fil-C running faster than C?[0] I assume it's just due to micro-benchmark variability but I'm curious. Some of them seem impossibly fast compared to C so I wonder if there are some correctness issue there. [0] https://cr.yp.to/2025/20251028-filcc-vs-clang.html https://cr.yp.to/2025/20251028-filcc-vs-clang.html
- jeffjeffbear 1y ago
  Usually garbage collection does improve alot of benchmarks, just look at the hans boem gc benchmarks.
  - fragmede 1y ago
    Back in the day, the cheat was to set up the GC so that the GC happened outside the timed portion of the benchmark. You know what's faster than the fastest GC? Not doing it.
    - jeffjeffbear 1y ago
      Classic example: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
  - fngjdflmdflg 1y ago
    The two extreme outliers I see are labeled "aead/clx192q/opt,-O3" and "aead/schwaemm128128v2/opt,-Os" according to clicking on the points with devtools. aead/schwaemm128128v2/opt,-Os looks like it is almost at 0x. 1x is at about y = 659 and that test is at 769 out of I guess 780 based on the graph.
stevefan1999 1y ago
djb uses a surprisingly low amount of RAM (12GB) considering my laptop already has 64G which is possible to expand to 128G in the future
gkfasdfasdf 1y ago
Does Fil-C catch uninitialized memory reads?
- jitl 1y ago
  malloc'd memory is zeroed in fil-c: > *zgc_alloc* > Allocate count bytes of zero-initialized memory. May allocate slightly more than count, based on the runtime's minalign (which is currently 16). > This is a GC allocation, so freeing it is optional. Also, if you free it and then use it, your program is guaranteed to panic. > libc's malloc just forwards to this. There is no difference between calling malloc and zgc_alloc. from https://fil-c.org/stdfil https://fil-c.org/stdfil
HexDecOctBin 1y ago
Can a program be written only partially in Fil-C? That is to say, can we link regular C and Fil+C object files in a single executable?
- jitl 1y ago
  > There is no interoperability with Yolo-C (i.e. classic C). This is both a goal and the outcome of a non goal. https://fil-c.org/runtime https://fil-c.org/runtime (worth reading, i think all the stuff Fil writes is both super informative & quite entertaining.)
  - HexDecOctBin 11mo ago
    This is disappointing. I can write the networking parts in Rust and the rest of the program in C, but apparently can't do the same with Fil-C.
    - loeg 11mo ago
      You could run the two parts in separate processes and pass messages via shared memory.
deleted 1y ago
[deleted]
deleted 11mo ago
[deleted]
blessinghit 11mo ago
[dead]

365 points by transpute 1y 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 1y 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. https://en.wikipedia.org/wiki/Daniel_J._Bernstein https://en.wikipedia.org/wiki/Daniel_J._Bernstein
- Slothrop99 1y ago
  Just to be clear, I mean to venerate Bernstein for earning his 3letters, not to trivialize him.
  - ggm-at-algebras 1y 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.
    - deleted 1y ago
      [deleted]
    - vkazanov 1y 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 1y 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 1y 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 https://wiki.c2.com/?ThreeLetterPerson
        debugnik 1y 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.
        overfeed 1y ago
        Yes: the fame is the subtext. It's akin to mononyms; they'd be referring to famous people like Shakira, Madonna, or Beyoncé. A lot of us have first names, but the point isn't that one's family calls them "Dave" without ambiguity. There were many unix instances, and likely multiple djb logins around the world, but there's only one considered to be the djb, and it's dur to fame.
  - deleted 1y ago
    [deleted]
  - jabwd 1y 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 1y ago
      Sorry, can you explain what he did to himself?
      - bgwalter 1y ago
        I would like to know as well. All that is public is that a couple of IETF apparatchiks want to ban him for criticizing corporate and NSA influence: https://web.archive.org/web/20250513185456/https://mailarchive.ietf.org/arch/msg/tls/nqouPVfPtU7hm-RF0lSDHCfze54/ https://web.archive.org/web/20250513185456/https://mailarchi... The IETF has now accepted the required new moderation guidelines, which will essentially be a CoC troika that can ban selectively: https://mailarchive.ietf.org/arch/msg/mod-discuss/s4y2j3Dv6DS4qns7AwqRunowIHY/ https://mailarchive.ietf.org/arch/msg/mod-discuss/s4y2j3Dv6D... It is very sad that all open source and Internet institutions are being subverted by bureaucrats.
        pas 1y ago
        ... if he thinks some WG is making a mistake and he's not welcome there (everyone else seems to be okay with what's happening based on the quoted email on the first link), then - CoC or not - he should then leave, and publicly post distance himself from the outcome. (Obviously he was never the one to back down from a just fight, but it's important to find the right hill to die on. And allies! And him not following RFC 2026 [from 1996, hardly the peak of Internet bureaucracy] is not a CoC thing anyway.)
        bgwalter 1y ago
        Why should he leave? The IETF pretends on its sponsor page (https://www.ietf.org/support-us/endowment/ https://www.ietf.org/support-us/endowment/): The IETF is a global standards-setting organization, intentionally created without a membership structure so that anyone with the technical competency can participate in an individual capacity. This lack of membership ensures its position as the primary neutral standards body because participants cannot exert influence as they could in a pay-to-play organization where members, companies, or governments pay fees to set the direction. IETF standards are reached by rough consensus, allowing the ideas with the strongest technical merit to rise to the surface. Further, these standards that advance technology, increase security, and further connect individuals on a global scale are freely available, ensuring small-to-midsize companies and entrepreneurs anywhere in the world are on equal footing with the large technology companies. With a community from around the world, and an increased focus on diversity in all its forms, IETF seeks to ensure that the global Internet has input from the global community, and represents the realities of all who use it. There is only one IETF, and telling dissenters to leave is like telling a dissenting citizen to go to another country. I don't think that people (apart from real spammers) were banned in 1996. The CoC discussion and power grab has reached the IETF around 2020 and it continues. "Posting too many messages" has been deemed a CoC violation by for example the PSF and its henchmen, and functionally the IETF is using the same selective enforcement no matter what the official rationale is. They won't go after the "director" Wouters, even though his message was threatening and rude.
- pixelpoet 1y ago
  It's wild how much he looks like ryg, another 3 letter genius
deleted 1y ago
[deleted]

scandox 1y ago

Interesting to see some bash curl being used by a renowned cryptologist...

IshKebab 1y ago
Almost like it's actually fine. https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d6676eb607c9 https://medium.com/@ewindisch/curl-bash-a-victimless-crime-d...
- oguz-ismail 1y ago
  [flagged]
- uecker 1y ago
  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 1y ago
    s/webserver/DNS/
    - arthur2e5 1y 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.
      - zzo38computer 1y ago
        It is not only that directly; the domain name might be reassigned to someone else, resulting in a valid certificate which is different than the one you wanted. (If you have the hash of the file which you have verified independently then it is more secure (if the hash algorithm is secure enough), although HTTPS is not needed in that case, it can still be used if you wish to avoid spies knowing which file you accessed. You can also use the server's public key if you know what it should be, although this has different issues, such as someone compromising the server (or the key) and modifying the script.) (There is also knowing if the script is what you intended or not anyways (or if there is something unexpected due to the configuration on your computer); if that is your issue, you can read it (and perhaps verifying the character encoding) before executing it, whether or not you trust the server operator and the author of that script.)

jeffrallen 1y ago

Wish we were talking about making Fil-C required for apt, not Rust...

phicoh 1y 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 1y 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 1y ago
    > disadvantages are speed, and garbage collection. And size. About 10x increase both on disk and in memory $ stat -c '%s %n' {/opt/fil,}/bin/bash 15299472 /opt/fil/bin/bash 1446024 /bin/bash $ ps -eo rss,cmd | grep /bash 34772 /opt/fil/bin/bash 4256 /bin/bash
    - nialse 1y ago
      How does that compare with rust? You don't happen to have an example of a binary underway moving to rust in Ubuntu-land as well? Curious to see as I honestly don't know whether rust is nimble like C or not.

testdelacc1 1y ago

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. https://fil-c.org/ https://fil-c.org/ The posted article has a detailed explanation of djb successfully compiling a bunch of C and C++ codebases.

commandersaki 1y 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?
- kragen 1y ago
  So far we haven't found a viable alternative; CHERI has holes in its temporal integrity guarantees.
  - Findecanor 1y ago
    Both Fil-C and CHERI rely on a concurrent GC/a GC-like task to find and invalidate all pointers to free()'d memory objects (in "quarantine") before putting them back into the memory pool. The difference is that because Fil-C has bounds in each object's header, it only has to nullify it to remove access whereas in CHERI a quarantined object can still be accessed through any pointer that hasn't been invalidated yet. I've seen discussions on adding an additional memory tag to CHERI for memory in quarantine, but I dunno what is best. Fil-C relies on the compiler being trusted whereas CHERI does not. If we do, then perhaps we could come up with a hardware-accelerated system that is more lightweight than either.
    - kragen 1y ago
      I didn't know this, but aside from the GC, Fil-C promptly revokes capabilities to freed objects, not relying on a concurrent task to do it eventually; CHERI cannot AFAIK.

nitinreddy88 1y 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 1y 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 1y ago
  Thanks for checking! I was wondering.
  - mbrock 1y 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 1y ago
      Thanks!
- SQLite 11mo ago
  SQLite runs about 5 times faster compiled with GCC (13.3.0) than it does when compiled with FIL-C. And the resulting compiled binary from GCC is 13 times smaller.
  - mbrock 11mo ago
    Interesting! I guess that's from your standard benchmark setup. Please note that Fil-C makes no secret of having a performance penalty. It's definitely a pre-1.0 toolchain and only recently starting to pick up some momentum. The author is eager to keep improving it, and seems to think that there's still plenty of low hanging and medium hanging fruit to pick. It does (or did, at some point) pass the thorough SQLite test suite, so at least it's probably correct! The famous SQLite test coverage and general proven quality might make SQLite itself less interesting to harden, but in order to run less comprehensively verified software that links with SQLite, we have to build SQLite with Fil-C too.

kragen 1y 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.

le-mark 1y 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 1y ago
I think that's the build of LLVM+Clang itself.
- collinfunk 1y ago
  Yes, linking LLVM takes up a lot of memory. The documented guidance is to allow one link job per 15 GB of RAM [1]. [1] https://llvm.org/docs/CMake.html#frequently-used-llvm-related-variables https://llvm.org/docs/CMake.html#frequently-used-llvm-relate...
  - brucehoult 1y ago
    And, fairly uniquely, LLVM has a LLVM_PARALLEL_LINK_JOBS setting that is distinct from the number of parallel jobs for everything else. I think I was using that 15 years ago. I wish GCC had it. I have a quad core machine with 16 GB RAM that OOMs on building recent GCC -- 15 and HEAD for sure, can't remember whether 14 is affected. Enabling even 1 GB of swap makes it work. The culprit is four parallel link jobs needing ~4 GB each. There are only four of them, so a -j8 build (e.g., with HT) is no worse.
  - Narishma 1y ago
    Is that why the Rust toolchain can't be compiled on a 32-bit system?
    - the_mitsuhiko 11mo ago

quotemstr 1y 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

Klonoar 1y ago
Fil-C has come up on HN plenty of times before. If it was going to make much of a dent in the discussions, it would have by now.
- quotemstr 1y ago
  It's strange how ideas seem to explode at random into the discourse despite being known for a long time. It's as if some critical mass stumbles on a thing and it becomes "the current thing" everyone talks about until the next current thing.
- jitl 1y ago
  odd fallacy. things grow in popularity / awareness over time
ddalex 1y ago
I'm on camp 2.
dev_l1x_be 1y ago
We have a saying that jam is made of fruit that gave up the fight becoming a brandy.
Rebelgecko 1y ago
Obviously someone needs to rewrite Rust in Fil-C
- pizlonator 1y ago
  Yeah since Fil-C is just an LLVM transform we could make Rust memory safe with it

1vuio0pswjnm7 1y ago

For those who might miss it, the notes cite a new 64-bit version of cdb that supports exabyte databases https://cdb.cr.yp.to https://cdb.cr.yp.to Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve

loeg 1y ago
https://news.ycombinator.com/item?id=45663435 https://news.ycombinator.com/item?id=45663435 (discussed 11d ago)
Panino 1y ago
> Also maybe of interest is that the new cdb subdomain is using pqconnect instead of dnscurve This is not correct. There isn't a cdb subdomain because cdb.cr.yp.to doesn't have NS records, which is where DNSCurve fits in. If you have a DNSCurve resolver, then your queries for cdb.cr.yp.to will use DNSCurve and will be sent to the yp.to nameservers. From there, if you have pqconnect, your http(s) connection to cdb.cr.yp.to will happen over pqconnect. Maybe the confusion is because both DNSCurve and pqconnect encode pubkeys in DNS, but they do different things. Here is DNSCurve: $ dig +short ns yp.to uz5jmyqz3gz2bhnuzg0rr0cml9u8pntyhn2jhtqn04yt3sm5h235c1.yp.to. Here is pqconnect: $ dig +short cdb.cr.yp.to pq1htvv9k4wkfcmpx6rufjlt1qrr4mnv0dzygx5mlrjdfsxczbnzun055g15fg1.yp.to. 131.193.32.108 Like CurveCP, pqconnect puts the pubkey into a CNAME.
deleted 1y ago
[deleted]
1vuio0pswjnm7 1y ago
Use of pqconnect at yp.to is probably old news but the cdb.cr.yp.to CNAME does appear to be new as of around 21 Oct The notes on using Fil-C were submitted three days ago https://news.ycombinator.com/item?id=45765718 https://news.ycombinator.com/item?id=45765718
- 1vuio0pswjnm7 11mo ago
  s/CNAME/alias/

lquidfire 1y ago

Cool project! I take it the goal is that, overhead being acceptable, most C / C++ programmes don't actually "have to be" rewritten in something like Rust? I wonder how / where Epic Games comes in?

pornel 1y ago
Note that Fil-C is a garbage-collected language that is significantly slower than C. It's not a target for writing new code (you'd be better off with C# or golang), but something like sandboxing with WASM, except that Fil-C crashes more precisely.
- thesz 1y ago
  From the topic starter: "I've posted a graph showing nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4). Typically code compiled with Fil-C takes between 1x and 4x as many cycles as the same code compiled with clang" Thus, Fil-C compiled code is 1 to 4 times as slow as plain C. This is not in the "significantly slower" ballpark, like where most interpreters are. The ROOT C/C++ interpreter is 20+ times slower than binary code, for example.
  - silotis 1y ago
    Cryptographic software is probably close to a best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. As long as Fil-C is able to avoid doing anything expensive in the inner loops you get good performance.
    - thesz 1y ago
      > best case scenario since there is very little memory management involved and runtime is dominated by computation in tight loops. This describes most C programs and many, if not most, C++ programs. Basically, this is how C/C++ code is being written, by avoiding memory management, especially in tight loops.

dang 1y ago

Related: Fil-C: A memory-safe C implementation - https://news.ycombinator.com/item?id=45735877 https://news.ycombinator.com/item?id=45735877 - Oct 2025 (130 comments) Safepoints and Fil-C - https://news.ycombinator.com/item?id=45258029 https://news.ycombinator.com/item?id=45258029 - Sept 2025 (44 comments) Fil's Unbelievable Garbage Collector - https://news.ycombinator.com/item?id=45133938 https://news.ycombinator.com/item?id=45133938 - Sept 2025 (281 comments) InvisiCaps: The Fil-C capability model - https://news.ycombinator.com/item?id=45123672 https://news.ycombinator.com/item?id=45123672 - Sept 2025 (2 comments) Just some of the memory safety errors caught by Fil-C - https://news.ycombinator.com/item?id=43215935 https://news.ycombinator.com/item?id=43215935 - March 2025 (5 comments) The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=42226587 https://news.ycombinator.com/item?id=42226587 - Nov 2024 (1 comment) Rust haters, unite Fil-C aims to Make C Great Again - https://news.ycombinator.com/item?id=42219923 https://news.ycombinator.com/item?id=42219923 - Nov 2024 (6 comments) Fil-C a memory-safe version of C and C++ - https://news.ycombinator.com/item?id=42158112 https://news.ycombinator.com/item?id=42158112 - Nov 2024 (1 comment) Fil-C: Memory-Safe and Compatible C/C++ with No Unsafe Escape Hatches - https://news.ycombinator.com/item?id=41936980 https://news.ycombinator.com/item?id=41936980 - Oct 2024 (4 comments) The Fil-C Manifesto: Garbage In, Memory Safety Out - https://news.ycombinator.com/item?id=39449500 https://news.ycombinator.com/item?id=39449500 - Feb 2024 (17 comments) In addition, here are the major related subthreads from other submissions: https://news.ycombinator.com/item?id=45568231 https://news.ycombinator.com/item?id=45568231 (Oct 2025) https://news.ycombinator.com/item?id=45444224 https://news.ycombinator.com/item?id=45444224 (Oct 2025) https://news.ycombinator.com/item?id=45235615 https://news.ycombinator.com/item?id=45235615 (Sept 2025) https://news.ycombinator.com/item?id=45087632 https://news.ycombinator.com/item?id=45087632 (Aug 2025) https://news.ycombinator.com/item?id=44874034 https://news.ycombinator.com/item?id=44874034 (Aug 2025) https://news.ycombinator.com/item?id=43979112 https://news.ycombinator.com/item?id=43979112 (May 2025) https://news.ycombinator.com/item?id=43948014 https://news.ycombinator.com/item?id=43948014 (May 2025) https://news.ycombinator.com/item?id=43353602 https://news.ycombinator.com/item?id=43353602 (March 2025) https://news.ycombinator.com/item?id=43195623 https://news.ycombinator.com/item?id=43195623 (Feb 2025) https://news.ycombinator.com/item?id=43188375 https://news.ycombinator.com/item?id=43188375 (Feb 2025) https://news.ycombinator.com/item?id=41899627 https://news.ycombinator.com/item?id=41899627 (Oct 2024) https://news.ycombinator.com/item?id=41382026 https://news.ycombinator.com/item?id=41382026 (Aug 2024) https://news.ycombinator.com/item?id=40556083 https://news.ycombinator.com/item?id=40556083 (June 2024) https://news.ycombinator.com/item?id=39681774 https://news.ycombinator.com/item?id=39681774 (March 2024) https://news.ycombinator.com/item?id=39542944 https://news.ycombinator.com/item?id=39542944 (Feb 2024)

erichocean 1y ago

I would really like to see Omarchy go this direction. A fully memory-safe userland for Omarchy is possible with existing techhnology.

timeon 1y ago
Can you elaborate why Omarchy? I'm asking, in context of recompiling with Fil-C, because that seems to be just Arch + configurations.
- erichocean 1y ago
  For cultural reasons, I would like Omarchy—culturally—to adopt straightforward security as one of their goals, in addition to usability and beauty. It's low hanging fruit, and a great way to further differentiate their Linux distribution.

fjfaase 1y ago

I am a bit surprised that the build_all_fast_glibc.sh script requires 31Gbyte of memory to run. Can somebody explain? I would like to try out Fil-C.

ComputerGuru 1y ago
Building and linking llvm sucks.

sheepscreek 1y ago

I’m glad Phil’s work is finally getting the recognition it deserves. There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

gpm 1y ago
> particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds! As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.
- quotemstr 1y ago
  He could add an API to mint a capability out of thin air. It could even be done out of process. In fact, I think Fil-C and CHERI could implement 90% the same programmer-level API!
- hedgehog 1y ago
  For securing and maintaining a complex legacy application it seems like a reasonable approach would be to move the majority into Fil-C, then hook the bits that don't fit up via RPC. Maybe some bits get formal verification, rewritten in Rust, ported to new platform APIs, whatever, but at least you get some safety for the whole app without a rewrite.

twic 1y ago

> Debian using Fil-C (Filian?) DJB SMACKER CONFIRMED?!

fngjdflmdflg 1y ago

Is there a reason that some of the linked benchmarks, if I'm reading it right, have Fil-C running faster than C?[0] I assume it's just due to micro-benchmark variability but I'm curious. Some of them seem impossibly fast compared to C so I wonder if there are some correctness issue there. [0] https://cr.yp.to/2025/20251028-filcc-vs-clang.html https://cr.yp.to/2025/20251028-filcc-vs-clang.html

jeffjeffbear 1y ago
Usually garbage collection does improve alot of benchmarks, just look at the hans boem gc benchmarks.
- fragmede 1y ago
  Back in the day, the cheat was to set up the GC so that the GC happened outside the timed portion of the benchmark. You know what's faster than the fastest GC? Not doing it.
  - jeffjeffbear 1y ago
    Classic example: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125 https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...
- fngjdflmdflg 1y ago
  The two extreme outliers I see are labeled "aead/clx192q/opt,-O3" and "aead/schwaemm128128v2/opt,-Os" according to clicking on the points with devtools. aead/schwaemm128128v2/opt,-Os looks like it is almost at 0x. 1x is at about y = 659 and that test is at 769 out of I guess 780 based on the graph.

stevefan1999 1y ago

djb uses a surprisingly low amount of RAM (12GB) considering my laptop already has 64G which is possible to expand to 128G in the future

gkfasdfasdf 1y ago

Does Fil-C catch uninitialized memory reads?

jitl 1y ago
malloc'd memory is zeroed in fil-c: > *zgc_alloc* > Allocate count bytes of zero-initialized memory. May allocate slightly more than count, based on the runtime's minalign (which is currently 16). > This is a GC allocation, so freeing it is optional. Also, if you free it and then use it, your program is guaranteed to panic. > libc's malloc just forwards to this. There is no difference between calling malloc and zgc_alloc. from https://fil-c.org/stdfil https://fil-c.org/stdfil

HexDecOctBin 1y ago

Can a program be written only partially in Fil-C? That is to say, can we link regular C and Fil+C object files in a single executable?

jitl 1y ago
> There is no interoperability with Yolo-C (i.e. classic C). This is both a goal and the outcome of a non goal. https://fil-c.org/runtime https://fil-c.org/runtime (worth reading, i think all the stuff Fil writes is both super informative & quite entertaining.)
- HexDecOctBin 11mo ago
  This is disappointing. I can write the networking parts in Rust and the rest of the program in C, but apparently can't do the same with Fil-C.
  - loeg 11mo ago
    You could run the two parts in separate processes and pass messages via shared memory.

deleted 1y ago

[deleted]

deleted 11mo ago

[deleted]

blessinghit 11mo ago

[dead]