@froztbyte @mhoye it puzzles me frankly particularly the rust part. rust is a microsoft fucking product now but nobody listens to packagers about bootstrap deps. i used rust for 10 years and made the zip crate the safest and fastest zip impl ever and i cannot contribute code to that system again until gccrs is complete
@hipsterelectron @mhoye ito puzzlement, my thesis as to how we got here is: 12~15y of "developer ease"
over the years of flush vc cash shartups, so much focus has shifted from the _outputs_, instead moving to the _personal_. many good engineering things got traded out, simply to "be comfortable"
@froztbyte @mhoye having worked on python packaging until they suddenly released "oh wait this guy is going to make things actually good" https://web.archive.org/web/20250218154403/https://cfp.packaging-con.org/2023/talk/hpuhu7/ and then having astral steal credit for my work and sell to openai and then seeing uv pop up fucking EVERYWHERE having fucking EVERYONE rave about HOW FUCKING FAST IT IS when I FUCKING DID THAT SHIT—i think labor needs rights and protections
@mhoye @froztbyte @hipsterelectron fun fact I was using uv to manage things for a work project (idek why I normally use poetry) and then found out they ship Tk support but they don't bind with Xft which means the fonts look fucking awful
@hipsterelectron @froztbyte @mhoye This shit right here is why I am not working on my seL4/Idris crap in public. Giving your shit away to comrades is fundamentally different from giving your shit away to the people in the power structures above you, and we need a way to encode and defend that distinction before we can have free software that doesn't feed the monsters.
@hipsterelectron @froztbyte @mhoye Not that my shit is any good; just look at the rest of what I've put up prior to this if you doubt me. But it's the principle of the thing!
@lykso @froztbyte @mhoye i like idris a lot and i have mixed feelings on seL4 but it is definitely cool software
@hipsterelectron @froztbyte @mhoye Yeah, your work sounds awesome and I am only pursuing the route I am because it seems like a good fit for my relatively limited abilities. These are the pieces I can see and use, and things feel like they are on fire right now so I'm doing what's in front of me. seL4 is juuust beyond the already-available, and I can reach that. You're reaching farther than I am; one day maybe I'll be building atop your work, but laying that groundwork is beyond me.
@lykso that is remarkably kind of you
@mhoye @hipsterelectron @froztbyte recently I started trying to make a pure Rust Nixpkgs style bootstrap. Assuming you have a Rust compiler binary because that's a given we accept for C ++ (I think an older version of GCC was the only pure-C implementation that was reasonably modern? Less confident on that I thing there might be a C based EDG thing).
But guess what? That's nearly impossible even assuming you start with a binary! First you have to use Cranelift (still billed as experimental, doesn't ship unwinding by default because it possibly bloats binaries though I didn't encounter it) because otherwise you need C++ for LLVM. And even then you don't have an assembler which you need. So okay you write that because I don't think any currently exist.
And then I'm sure you hit some new issue but that's where I stopped for now.
Meanwhile somehow, incredibly, even with the rise of LLM produced projects redoing all kinds of things (I get it, it's a fun exercise) nobody has made a full C compiler in Rust yet. The closest is some Anthropic demonstrator that's been abandoned and isn't finished and a project @jyn started as far as I can tell.
So even if you get there and want to bootstrap from C to a whole compiler chain afterwards to get LLVM support for your Rust, too fucking bad.
I won't accept any issues people claim because you need a compiler binary I think it's arbitrary to allow the C++ compiler but not Rust, but holy shit if your language is going to be self hosting why on earth isn't that actually a full stack even on one platform?
@Lunaphied @mhoye @froztbyte @jyn gcc has a reasonably well-documented bootstrap path from C99. even if i'd like it to be shorter the project takes it seriously and discusses bootstrapping as a concern on the mailing list which i really appreciate. i'm looking to improve the story for emacs atm
@froztbyte @jyn @mhoye @hipsterelectron yeah I mean I think it's stupidly long but at least it's possible. But it should still be one step from an existing binary of the compiler to a new binary of the compiler imo
@Lunaphied curious about this since that is generally my experience with gcc. personally my build system will be maintaining an entirely acyclic bootstrap path from C99 and i absolutely agree that should be a goal for every language
Oct 14, 2026, 7:31 PM@wyatt @Lunaphied haven't heard this before and not quite sure of the distinctions but that should probably work. unfortunately i will be cheating by building the whole gcc bootstrap chain which since nobody does that may break in practice
@wyatt @Lunaphied possibly more concerned about OS support but i'm not gonna be doing anything non-POSIX and since i'm doing weird shit to virtualize i/o with patches to gcc i also won't require too much OS support for the fun parts
Oct 14, 2026, 7:45 PM
@wyatt @hipsterelectron @Lunaphied also variables don't have to be defined at the top of the block since c99 iirc
Oct 14, 2026, 7:50 PMOct 14, 2026, 7:51 PM@SRAZKVT @wyatt @Lunaphied i'm fine with hoisting local vars by hand
Oct 14, 2026, 8:17 PMOct 14, 2026, 8:19 PM@navi @Lunaphied @wyatt @SRAZKVT i'll cry about stdint but if i'm writing C89 i'm probably gonna autoconf up a config.h anyway
Oct 14, 2026, 9:12 PM@wyatt @Lunaphied @navi @SRAZKVT i'm also concerned about autoconf for other reasons even though zack weinberg is wonderful and very committed to portability. i'm also concerned about automake's perl requirement
@wyatt @Lunaphied @navi @SRAZKVT i implemented functionality equivalent to #include with sed and then made a shell script compiler with more and more sed even though sed is obnoxiously limited and i realized i was building the shell language with built in parsing framework i had always wanted and then resolved to just make that language as a programming language instead of hacking it together
@wyatt @Lunaphied i only use /* */ for comments anyway, // is for losers
Oct 14, 2026, 7:45 PM
@hipsterelectron @Lunaphied
That's what I'm trying to do though I am adding shims to allow some C23 things to work even on a C99 compiler.
...
Is shims the right word? I've seen the term "polyfills" used for the web but never seen it used for C versions.
@kirtai @Lunaphied as the lone remaining coffeescript contributor i would like to see "polyfills" as a term taken up more broadly. i would also argue "shim" to me evokes OS compat whereas "polyfill" tends to be associated pretty specifically with language versions
@kirtai @Lunaphied i have this awful idea about coffeescript for c i.e. a transpiler generating C89 because it would be terribly simple to implement rust's surprisingly basic unsafe mechanism
@kirtai @Lunaphied it also kinda pisses me off that lifetimes have such complicated inference machinery because it produces terrible fucking error messages and i don't actually want the compiler to infer lifetimes for me in the first place. i've also come to find the mutability restrictions incredibly obnoxious for the single type of code i write all the time i.e. buffered i/o and string search operations
@kirtai @Lunaphied fuck is this just describing C with Classes
@kirtai @Lunaphied here's another thing i don't like about lifetimes which is that they're bound to a mysterious rust-specific concept that essentially translates to nested scopes in the form of stack frames, which like, fine, but rust leaves it to LLVM to actually calculate pointer provenance so information like "this returns a pointer from the same contiguous allocation as provided in argument 1" is not expressible as a type annotation
@kirtai @Lunaphied also coming from coffeescript where the only way to get any type safety at all (i actually implemented JSDoc type annotations which was heroic and nobody cares somehow) is to ensure you dereference a field by name from an enclosing object, it's remarkable to me that rust not only requires a macro to perform struct->field address offsets, but doesn't have a distinct type for "field name X from struct Y", or indeed "offset of some multiple of struct X from address A". these would be really useful to have as visible type annotations imho
@kirtai @Lunaphied one thing coffeescript does that is extremely important is variable hoisting at function scope which also happens to be required by C89 and i would argue is furthermore a really useful thing for a C transpiler to do (in my emacs i have a keybinding that compiles the current file to js and jumps to the corresponding point in the output and this would be very useful for C imho)
@kirtai @Lunaphied also rust does this absurd thing where traits are used for two wildly distinct purposes and they're completely fucked up as a result:
dyn operatorand i'm pretty sure i've never once wanted the compiler to generate a vtable for me in my entire life, but in order for rust to emulate this very niche c++ feature it requires every trait impl to be implicitly bound to a concrete type i.e. every trait has this secret implicit initial generic type parameter which is desperately confusing and directly leads to most of my issues with lifetimes in traits
@kirtai @Lunaphied this is so crazy! i think this could work!
@kirtai @Lunaphied i could even write this in c++ or whatever because release archives can include the generated output and in particular the very simple file-level module system can be converted to a .h and a .c file and i'm pretty sure i can avoid performing any introspection of C source code
@kirtai @Lunaphied rust does this absolutely TERRIBLE fucking thing where it has this distinct "bindgen" tool that runs clang and generates function prototypes and then rustc just takes you at your word that these functions exist and generates code for them and this is super problematic because the rust libc crate not only does not read your system libc but actively lies about the function signatures because it just fucking packages its own patched musl libc to implement the rust stdlib which is a fucking terrifying thing to do because that comes from microsoft CI along with the rest of the rust toolchain unless you build rust and provide your own musl correctly
@kirtai @Lunaphied and instead of doing anything like that i can completely just compile down to .c and .h and i think everything that might require calling back into C (like asserting a function signature or a struct name) can be expressed by generating a function prototype or by generating a compile test like autoconf has. so maybe it'll be like a .c, a .h, and a .compile_test.c or something so my build system can pick that up
Oct 14, 2026, 8:11 PM@Lunaphied @mhoye @hipsterelectron @froztbyte i’m confused why a pure-rust bootstrap path matters in practice