dboon

Thanks for the reply, I'm sure you're also just a regular person writing about the stuff you like and regardless of whether you end up agreeing with me or deciding that, no, that was exactly the tone you wanted, I appreciate the thought.

I promise I'm not normally uptight like this, but there's a difference between having a laugh and whatever this is. Like I said, this feels (a) legitimately angry and (b) in a spit flecked enraged way that has become popular. I guess if you're cool with people calling whatever you work on clown-car turboslop then more power to you.

This prose feels extremely angry and ungenerous; abstractly, I agree with a lot of the points, but when I read this:

My conclusion is that OpenCode is clown-car turboslop with a security posture of “let me bend over for you daddy”. Everyone using it should stop using it.

I do not want to keep reading. There are regular people who wrote this software. When did it become normal to talk about open source like this? How would you feel if someone wrote this about some software that you wrote? Reading this article made me feel extremely gross

I remain deeply unconvinced. I respect your writing and opinion enough to have actually put chunks of the essay into Pangram, including the part you label "blatantly Claude", and...they come out as 100% human. The 2023 and 2024 samples do, in fact, sound like OP, doubly so given that people change.

In 2020, I wrote a kitschy story where the characters talked with a cowboy affectation (https://spader.zone/the-fastest-gun/) which frankly borders on embarrassing for me now. I don't think my writing sounds much like it did then.

I think it's fucking embarrassing when people use LLMs to write prose for them. It's fundamentally different than software, for me. But I think your sensors are a bit miscalibrated. Regardless, thanks for all the good stuff over the years and thanks for the response.

What? This is one of the most clearly human written articles I could imagine. Can you explain what you mean?

Yeah, recreating Conan minus the foundational idea stated at the beginning of the post. Yup.

I am making Cargo for C. I have 3/4 of a working demo; the tool can build itself, including some non-trivial dependencies which I've ported to build natively with the tool (instead of wrapping their Make or CMake or whatever).

The pitch: It's insane that we have to pull in Python or Lua to build C code. CMake is an abomination against god that has become usable in spite of itself. Zig cc is proof that this entire ecosystem is an embarrassment. My tool gives C projects a TOML manifest, and builds scripts written in C and JIT compiled by the tool. Now, you can write build scripts in the language itself, pull in dependencies you wanted to use anyway.

It also provides a stable ABI. There's an HTTP-backed index and a Git-backed index. And it generally does the same thing for C that, say, Bun did for JS/TS. You'll be able to run C files from source and have the entire ecosystem available. You'll be able to trivially generate single file static binaries, or dynamically link to an older glibc without arcane tricks. It will fix C.

I'm also still working on my "what if we wrote a real standard library for C"; I added some feedback I got from the release.

https://github.com/tspader/sp

The library provides a few basic allocators.

A comment from a legend. Thanks for reading and thanks for the response! I agree; the dynamic array is typed as a T* for ergonomics sake but is similarly a pointer and a length (and an allocator).

Could I pick your brain a little more on the design? I'm spader at spader.zone; if you have time, drop me an email. I promise not to take too much of your time and I'd love to hear from you.

I have no philosophical complaints with supporting odd architectures in general. I agree that most obscure targets are probably not that much code, since the library is factored with this in mind (e.g. basic WASM support took an afternoon).

It's stated as a non-goal simply because it's not the most valuable thing I can do with my time. My fundamental stance is that writing new Windows or Linux or macOS or WASM programs in C is a good idea, and those are the programs that I write, so that's where my focus is. But if someone would like to come along and write the ~30 syscalls needed to port the library to a new platform, or even register any interest in such, I'd be happy to look into it at that point.

People are very silly and very entitled. I'd bend over backward to help anyone contribute to or use the library in any way. In response, all I ask is for some common courtesy and friendliness. Spending more than exactly zero seconds on people who won't give you that is a waste of time.

In other words, you hit the nail on the head. Anyone who acts this way can get fucked! We'll be having a good time and making friends without them

Haha jk…but really? Lol just kidding…unless?

Yeah, AI has done a number to this place

No problem and thanks for the apology. Happens to the best of us. Regardless, thanks for the comment — I definitely didn’t mean to slip by the pthread stuff on a “well technically this isn’t libc.so”. It’s just code that’s pretty hard to get right and I haven’t had a chance to rewrite it!

Thanks! I didn’t know this.

Thanks for reading and thanks for the link. I'll read anything DJB wrote.

It...is not a libc implementation. That's an impressive level of misunderstanding!

It looks like I need to update my macOS machine! Thanks for the sanity, and thanks for reading.

Man, this place has become strange. This person has no idea who I am. But thanks for commenting on my 'library' nonetheless!

Thank you, but why's that?

Yes, unfortunately the threading primitives require libc. Ditto subprocesses. It's on my list.

But regarding: "Oops... apparently this is vibecoded. Welp, I just wasted ten minutes of my life reviewing slop that I'm not going to get back."

Do not talk to people like this. I don't care if you don't like the library, or if you found a flaw in it. I am a regular person who wrote this code for no other reason than I thought it would be good to exist. It's unbelievably rude to call it vibecoded slop, or a waste of your life, and it makes me sad that someone who would write an otherwise thoughtful comment would say something like that.

If your code depends on a bunch of initialization from libc, then you should continue to link to and use libc. sp.h can coexist with libc just fine; if you link to it, the library makes sure to conform where it needs to (e.g. not stomping on the register that holds the TLS base pointer).

What sp.h does not do is reimplement all of libc's initialization code. If you want to build a freestanding binary, there are a few utilities in there for defining a _start so the loader can actually jump to your code. But it's not, and isn't meant to be, a libc replacement in this sense.

sp_math.h is, as noted at the top of the file, a repackaging of https://github.com/HandmadeMath/HandmadeMath

It is not part of the core library. It is certainly not meant as a reference-level implementation of math functions. It's there so you can write an easing function for a game without pulling in libc. It seems like its existence has offended you. If that's the case...I'm sorry? At every possible point, I note as loudly as possible exactly what that library is. I found your tone extremely dismissive and disrespectful and I don't care to engage with that any more than I already have.

Have you considered compiling it into a binary of your choice? It works perfectly well as a traditional library. The only cost you pay is re-parsing the header part once per TU. Because C is so simple, this is virtually free. In any case, calling it insane makes me feel disrespected and I would prefer if you didn't do that.

Thank you!

How would you write https://github.com/tspader/sp/blob/main/example/ls.c in your statically typed language of choice? To be fair, this is definitely the kindest example to my library, but one reason I felt this project was worth pursuing was that that example reads basically like a slightly worse TypeScript to me. In other words, quite nice for how low level the code really is.

Can you show me a realistic case with a longer path?

The point of the library is that you do not call the low level allocation primitive to allocate a single string. Of course, in simple programs which exit immediately, there is no difference between using a page allocator and a heap allocator. In real programs, I use an appropriate allocator for the allocation rather than making arbitrary calls to malloc(). In the sp.h examples, I use the page allocator to keep freestanding Linux simple. I could swap out a single line to be backed by an arena, but it misses the forest for the trees.

sp_log() writes directly to an IO writer. An IO writer can be buffered or unbuffered, but is unbuffered by default. This is a feature, not a bug. Have a look through the IO code!

Cheers and thanks for reading.

I don't support non-macOS BSDs explicitly yet. Not for any reason of design, just hasn't been a priority.

Thanks for reading. "There is no heap" is meant to say that your mental model of memory shouldn't be one heap from which all memory is pulled. It should be many heaps, owned by many different allocators and providing different semantics. Hence the opinionated stance of the library; there is no allocation function that does not force you to specify the specific heap you want to allocate from. I'm sorry if I didn't explain that well.

As far as the syscall thing, it's actually quite interesting. NT is also extremely stable. Likewise for the stock Darwin syscalls on macOS. In practice, though, Windows loads kernel32.dll automatically, so there's no drawback in using it when appropriate. I still call directly into NT sometimes (mostly to skip complex userspace path translations that aren't useful). On macOS, you are likewise forced to link to libc (libSystem.dylib), and so I usually just end up using the syscall-wrapper libc functions there.