i'm not minding writing You Have Died in C but it really requires a lot of discipline to make sure everything you do is error checked, even if it's just an assert

fortunately i'd gotten used to writing code very defensively anyway even in C# cause crashing is just about the worst thing you can do, but still. it's a lot

@eniko I just want to note that I find it funny that you're doing a blobber in pure C because that's what I've been working on, too 😀

I've found the game code to be pretty straightforward and generally not very error-prone in C, but that may be because of choices I made with how structuring most of it (as few pointers exposed as possible) and the game still being very very simple. The editor/tools code on the other hand is a goddamn nightmare in C, even with things like the new defer statement.

@seanmiddleditch yeah i find if you try to avoid pointers/malloc as much as possible game code is quite amenable to C

but yeah i wouldn't wanna write tools in it. i can barely tolerate writing the code to load bespoke formats that i crafted to make them easier to load >_>

@eniko "But have you tried making an Arena Allocator™?"

Said the Odin programmer quietly

@NullTheFool not in C, but i made them in C# >_> https://github.com/Enichan/Arenas
GitHub - Enichan/Arenas: Unmanaged arena memory allocators for C#/CSharp with easy interactions between managed and unmanaged references

Unmanaged arena memory allocators for C#/CSharp with easy interactions between managed and unmanaged references - Enichan/Arenas

GitHub
@eniko Thanks, I was just looking for this lmao

@eniko this! I had so much fun recently writing a simple game without ever touching malloc.

Entity entities[ENTITY_MAX];

I think I had just one segfault, easily fixed. Most joyful C programming I ever did.

@eniko honestly when i make a complex program in c the only thing i miss from other languages are interfaces / typeclasses, but those would be a mess so i'm fine with c not having them
@SRAZKVT i sometimes miss built in vectors/hashmaps
@eniko yea those are nice too, but i don't think c is the right language for them

@SRAZKVT this is about as far as i got when experimenting to see if such a thing as dict-passing would be plausible https://gist.github.com/AlexCeleste/a2f5dc3ddae9144ac99a59824446a2e7

i guess it's an exercise in seeing which sharp corners would need to be sanded off the core language
"...several"

@eniko

typeclasses, because apparently i never added this

typeclasses, because apparently i never added this - main.c

Gist
@erisceleste @eniko abusing the preprocessor is imo something that should never be done as it makes the code significantly more difficult to read, as a reader needs to think about what the macro will do, and such macros are usually written in a way that is completely unreadable

@SRAZKVT well, you get into interesting library design philosophy questions there

a well-designed library interface for any feature shouldn't leave the user needing to think about how its macros expand any more than they usually should think about what lies behind a function call boundary - which is a non-zero amount of the time but it is comparatively very low

(obviously anything built with #include INCREMENT failed hard at the first hurdle but ygwim)

@eniko

@SRAZKVT on a personal level (and i don't think i can say this with the safety-critical hat anywhere near me lol) i do think that if you're not extending the syntax, you're not writing with the full language

syntactic abstractions are one of your tools for expression
if your high-level logic expresses things like allocation modes you should feel safe expressing your intent with blocks like no_gc { /* statements */ } or summat

the ideal of any API is composability
obviously, many C interfaces (of all kinds) fail dramatically at it

@eniko

@erisceleste @SRAZKVT @eniko I feel like you can say it with the safety-critical hat on, you just *also* have to say that writing with the full language leads only to madness and disaster.
@eniko You Have Died In C? I hear if you die in C, you die in real life!
@datarama @eniko they do say undefined behaviour can do anything
@datarama @eniko @0x00string I once died in rust, luckily my memory was safe.

@datarama @eniko

There would definitely be no C programmers left.

@datarama @eniko my musical ass: What a boring tone to die in

@datarama @eniko Oh now I *know* that's untrue because I died in my very first C. (My very first program returned a stack pointer.)

Also, it's "died *at* C." I think. 🤔

@tekhedd @datarama no no, dying at sea is sailors
@tekhedd @datarama or people on cruise ships >_>
@eniko
she sells C shells by the C shore
@eniko I have yet to encounter a problem on my own that is properly Rust- or Haskell-shaped, but the Result<T,E> (or Haskell's "Either<L,R>" equivalent) has spoiled me forever when it comes to error-checking.