No, it's not. (As should not be a surprise given how extensively LLMs are used to draft English-language articles these days.) It's actually incredibly blatant. Just look at this second paragraph:
> The same six months I had closed three other tickets against the same product, each of which had presented to its filer as the only bug. A customer's name had appeared with its letters unjoined on a printed agreement, the way a sign-painter would have laid them out in 1962, because the PDF library on the receipt server pre-dated the existence of a shaping engine in its language runtime. A search index had been returning empty for accounts the customer service team could see in the database because a 2017 import had encoded twelve thousand names using fossil Unicode codepoints from 1991 instead of regular ones from 1995, and the index, very reasonably, treated the two encodings as different strings, So, that ragged-left ticket was the smallest of the four, HOWEVER, it sat on top of the same iceberg and pointed at the same thing.
And you can punch the essay into Pangram if you have any doubt (omit Arabic text and formatting if you do this, focus on just plain English to be safe). For example, go to the end* and try "Everything in this story that actually works was paid for by almost nobody...Somebody will close it, probably unpaid, possibly reading this (or writing it? who knows)." '100% AI.'
* I always check sections towards the end instead of the beginning, because a lot of authors will write the introduction by hand and then give up and let the AI write the rest; and also more advanced sloppers will fiddle with the opening until it beats Pangram, which is not hard since Pangram heavily favors false negatives on AI contribution, and skip the rest because they assume readers will be too lazy to check beyond that.
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.
FWIW not many C/C++ programmers like package managers for some reason. We wrote custom cmake to pull from Artifactory and built our own packages with zip files. There isn’t a rich ecosystem of C/C++ packages.
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.
Strings (and arrays) being length/ptr is a freaking enormous win, in simplicity, performance, and overflow bug elimination.
One of D's secret features is that string literals still have a 0 appended to them, even though the length of the string does not include the 0. This makes it super slick to call C functions, like printf, using a string literal for the format string.
I'm baffled why C spends its energy doing things like normalized Unicode identifiers (an abomination) instead of something incredibly useful like length/ptr arrays.
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.
Like. He's done the first 90%, leaving only the other 90%. And I mean that a little as a joke but also very sincerely. The supported platforms are a decent starting point, but mainstream OSs on little-endian 64-bit processors doesn't strike me as "the hard targets". NetBSD ( https://wiki.netbsd.org/ports/ ) is ultra portable. This is just portable.
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
The title says 'standard library'. Are you saying that, in the context of C, that it is an error to take that to mean an implementation of libc?
Yes, I know the author's writeup then goes on to say that it is not a libc with a pile of questionable justfication. This is a custom runtime, in a single header no less, which is admittedly impressive, especially considering it provides runtime and thread safety primitives. This does not rise to the level of claiming the idea of a 'standard libarary' though, IMO. In that, I think the author misses the point.
reply