P.S. I'd bet some clueless HN users would chastise Ken Thompson for writing software in C.
Knowing KT worked on Go, I'd guess he'd say concurrency, but that's difficult to get right without sacrificing low-level control. What's your take?
C just needs:
1. A solid and modern standard library, with basic data structures, sane strings, higher level sockets, ...
2. A very simple object system. No inheritance, no advanced features at all, just the ability to call object->method(1,2,3) and getting a 'self' reference.
3. Ability to perform operations on function exit in order to clean-up locally allocated things. So as I allocate things or open files and alike, I can specify some cleanup code doing things like if (fp) fclose(fp); that is executed when the function returns in any case.
list_add(&mylist,1);
mylist->add(1);
mylist->class->add(&mylist,1);
e.g. Nim has it, and it lets you do this:
proc add(self: MyList, e: int) =
# [insert append code here]
mylist.add(1) # equivalent to
add(mylist, 1)
Let me explain, I feel iteration speed is of utmost importance. So C++'s mistake of mixing interface and implementation (data layout specifically) leads to massive include bloat, and ultimately contributes significantly to the compilation time problem in C++. In contrast, in C, functions are almost entirely decoupled from structure data layout, and implementation, this promoting much more svelte headers and reduced compilation time for many projects.
So, IMO, it would be important to seperate object interface, from the layout, or risk a major, if not the most major, advantage of using C over C++
Or if C had been standardized, but C++ didn't exist, maybe they would have added features like this simply because contemporary languages like Object Pascal and Ada 95 supported object oriented programming better in practice.
https://www.cs.purdue.edu/homes/rompf/papers/xhebraj-ecoop22...
Also would be super if C had first class types.
How is it special at all?
> you have full control on low level details.
Yeah, if you add random attributes to the language and control the compiler. C still can’t properly do vector instructions, while even Java can, but so can C#, Rust, C++. It’s simply not a low-level language.
This code started as the Telegram bot Stonky, it's on Github, and you'll see the bot does a lot of financial analysis things, including Montecarlo simulations. I really needed the speed. Later my daughter was diagnosed with scoliosis, and requires to wear a corset. To take track of the time she wears it was a pita, so I wrote another bot (not released so far) and put it in our family channel.
Then... I needed another bot. And I finally extracted the common parts from the two. So:
1. For Stonky, speed was essential, but not for my next bot.
2. Once I needed to write the new bot for the corset I tried the Python lib. And... I started to have the first code compatibility issues (accross versions) of the modern software stack (context here: https://twitter.com/antirez/status/1726305869032570992).
3. Meanwhile Stocky was no longer able to work because I did the unescapable error of basing it on the Yahoo Finance API, now retired :( So I told myself, I don't want to relay on a software stack that will make this bot unable to work or obsolete in 2/3 years because all the libraries will change fast (and, if you check, you will see there was a lot of work that went into Stonky back in the couple of weeks when I worked at it constantly).
On top of that, with Stonky I decided to serve each request with a thread, and not in multiplexing. In the specific case of a Telegram bot this is basically able to simplify many things: many bot requests are long living, because you want to call an LLM API, or Whisper to transcribe, or do a Montecarlo simulation on a stock history, (btw the Whisper thing will be one of the official examples of this library) and so forth. Now in Stonky this approach worked so well because it's written in C, so each thread consumes only minimaul resources associated with the OS thread creation.
Finally: With SDS lib, my JSON and Sqlite3 wrapper (the wrappers are the interesting part of the project IMHO) it is not so different than writing Python code. So, I said, why not?
P.S. this library is just a work in progress, hacked while I'm doing many other stuff. I hope it will improve in the next weeks. I use Telegram for more than 10 years now, with all my friends and family. So it is very likely I'll require to write more bots in the future :D