Replies

• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 14, 2026, 11:01 PM

  @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

  💬 1🔄 1⭐ 0
• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 14, 2026, 11:06 PM

  @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)

  💬 1🔄 0⭐ 0
• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 14, 2026, 11:31 PM

  @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:

  1. ocaml/scala-like matching of function signatures to a concrete function
  2. vtable generation with the dyn operator

  and 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

  💬 1🔄 0⭐ 0
• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 14, 2026, 11:42 PM

  @kirtai @Lunaphied this is so crazy! i think this could work!

  💬 1🔄 0⭐ 0
• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 14, 2026, 11:52 PM

  @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

  💬 1🔄 0⭐ 0
• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 15, 2026, 12:01 AM

  @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

  💬 1🔄 0⭐ 0
• 

  d@nny disc@hipsterelectron@circumstances.run

  Oct 15, 2026, 12:06 AM

  @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

  💬 0🔄 0⭐ 0