max_k
After my Mythos experience, I was wondering if there is really still a market for human code audits. I guess yes, but the work will be different, just like coding (and marketing and so on...) is different now. You still need to have an expert to wield the new powerful tools.
To err is human, I know that as much as anybody. Before the advent of LLMs, there were several (human) audits of my code for vulnerabilities, but they found little, which I was proud of. And now, Mythos had a quick look and found hundreds and hundreds of bugs (many of which were critical and even more were really emberassing).
Of course, I knew there were bugs that just weren't found because the auditors weren't looking closely enough, didn't have enough time/budget etc., but this unspecific feeling is different from having all the bugs accumulated over a quarter century slapped in your face at once.
But that doesn't matter for me. It shows me real bugs and less than 1% false positives. Some bugs are truly nasty and urgent, most are trivial and not exploitable at all, but they're bugs and so I'm fixing them.
Mythos isn't mythically superb for being the best LLM model, but only for not having these annoying guard rails that make all others randomly refuse to cooperate when you need them the most. Whoever invented guard rails - please stop! - they just slow the good guys down in the race.
Bottom line: it's a good thing. My software will be better after that. Even if it's currently not good for my ego (and my health). But I'm glad for all the tools that help me improve quality.
And sure, I can just ask LLMs to fix the bugs, which works well half of the time, and produces bad slop in the other half. This is where human expertise and judgement is still necessary to avoid letting our code bases drift into LLM spaghetti hell.
Mutating a std::vector is much more difficult because you need a coarse lock and serialize every access with it - there's no other option. Linked lists, on the other hand, can be made thread-safe with a single coarse lock, or many finer-grained locks, or atomics, or fancier tricks like RCU.
All of that is difficult, sure, but what is less difficult than thread-safe linked lists?
Of course, "it depends". There are things that better live in tightly-packed arrays (large lists of free-standing objects), but there are things that are almost impossible without linked lists. In these cases, being "intrusive" has massive advantages.
I guess you can spend an entire coder career without having to use linked lists, and then you cannot imagine why anybody would ever use them (and make it a meme). The linked lists that do exist in your programs may be abstracted away from your visibility.
Therefore: sure, an article about linked lists will spawn numerous HN comments from such coders who don't know the shoulders they're standing on. It's linked lists all the way down... below the flat surface of high-level frameworks.
But they are interchangeable!
FastCGI and HTTP/1.1 are indeed on the same level. Both are transport protocols for HTTP requests.
It would be technically possible to implement FastCGI as alternate transport protocols in browsers and web servers, just like HTTP/2 (SPDY) and HTTP/3 (QUIC) are alternate transport protocols for HTTP requests.
(This is not what the article and my comment are about, as others already pointed out.)
Though I'd like to make another protocol known: Web Application Socket (WAS). I designed it 16 years ago at my dayjob because I thought FastCGI still wasn't good enough.
Instead of packing bulk data inside frames on the main socket, WAS has a control socket plus two pipes (raw request+response body). Both the WAS application and the web server can use splice() to operate on a pipe, for example. No framing needed. Also, requests are cancellable and the three file descriptors can always be recovered.
Over the years, we used WAS for many of our internal applications, and for our web hosting environment, I even wrote a PHP SAPI for WAS. Quite a large number of web sites operate with WAS internally.
It's all open source:
- library: https://github.com/CM4all/libwas - documentation: https://libwas.readthedocs.io/en/latest/ - non-blocking library: https://github.com/CM4all/libcommon/tree/master/src/was/asyn... - our web server: https://github.com/CM4all/beng-proxy - WebDAV: https://github.com/CM4all/davos - PHP fork with WAS SAPI: https://github.com/CM4all/php-src
This is one of the things I removed in our WordPress fork. I found it horrifying to learn that an open source software does such a user-hostile thing, and wondered why nobody but me objects.
It's a pity computers are so fast and have so much memory that people can get away with not caring about minimalism.
Of course not. The post you're replying to explicitly said the discussion was off-topic. That means it's not discussing the point of the article.
> In an actual UI, you will have labels or indicators telling you what the toggle means and what the options are
If it only were that way, we wouldn't complain. But it's not.
> checkbox without labels is equally bad UX
Of course, I agree. But nobody asked for that.
Your post ignores the things that were said and replies to things that were not said.
My post replied to "checkboxes vs UI toggles", and replying to that aspect was my main point. That's slightly off-topic, of course. It has to do with animations only because checkboxes wouldn't really benefit from animation, whereas toggles are an obscure visual representation for the same control, and adding animation is a feeble attempt to make it somewhat less obscure, even though it doesn't even try to address the main problem: what does toggle "left" and "right" really mean?
I believe checkbox not benefting from animation is a good thing: it's so clear and obvious that you don't need to animate it.
Custom list control: do Home/End buttons work? How to select multiple items, does Shift-Cursorkeys work? Does Ctrl-Click work? Of course not.
Custom text control: does Ctrl-Left/Right for word jumping work? Does Ctrl-Up/Down for paragraph jumping work? Can I select everything with Ctrl-A or does it select the whole website? Can I select everything from cursor until the end with Ctrl-Shift-End work? Does Copy/Paste work at all? (I have never figured out why Copy/Paste in Teams simply doesn't work. Apparently I'm the only one with this problem.)
Custom dropdown control: does Alt-Down work? Can I scroll the list with the usual keys?
If (web) developers would just use standard controls, everything would work the same, and they wouldn't have to reimplement all the basic things from scratch (or not at all). Web devs could write forms that work without megabytes of JavaScript.
Hamburger menus. Those horrible things didn't need to exist even in old times with small monitors and 640x480 (or less) - but now they exist everywhere on my 32" 4K monitor for no reason.
Agree, that sums my opinion well.
And much software doesn't even look like they preferred eye candy over clarity; it rather looks like they forgot about clarity completely.
Why do only old nerds complain about this, when today's UIs are so "easy" that every toddler can use the smartphone? Are we just living in the past, getting old; are we the problem, why is our opinion unpopular?
That's funny interpretation, because what is this mysterious "UNIX model" and what does it have to do with implementation language?
Also, C++ used to be "C with classes", but has outgrown this single-paradigm thing quite quickly. I do a lot of C++, but I rarely use inheritance and virtual methods. These are not the features that make C++ worthwile for me.
> The simplicity of flat memory model, [C], a unified file interface
This "unified file interface" is a nice theoretical idea, and it leaks many nice things to the real world, but has nothing to do with the implementation language - quite contrary, it allows many different languages to communicate. Similar with "flat memory model" - you can have either language in segmented memory and flat memory. There used to be "far pointers" in both C and C++, and now they're gone, so what.
> If C++ were actually better for engineering large systems, GNU wouldn't have had a chance.
Oh, if only it were that way, if only inferior engineering systems would just lose and disappear. The sad truth is that survival of a language proves little about quality.
If you believe C is better than C++, fine by me, just opinions. You can say "C++ is bad because it's more complex" or "has too many features", I can understand that, or "C++ is confusing because you can overload operators". My features are your bugs, okay. But I can't comprehend your actual arguments because they are orthogonal to the choice of language.
There are lots of plain C container libraries which are probably suited better for C, if you really must use C, or prefer C for whatever reason that escapes my imagination.
Your library demonstrates that C++ is the superior language because it can to template specialization, resulting in better machine code. For example, your std::span implementation needs to store the element size, resulting in a larger structure (24 instead of 16 bytes), more memory memory accesses, costly integer multiplications everywhere.
C++ can omit all this, and can do simple bit shifts instead of multiplications.
There are many more places where you demonstrate C++'s superiority (e.g. it can safely do deep copies with no special code, while your library can't do copies at all, and even if it could, doing so safely/deeply would be extremely cumbersome with C, both for your library code AND for the code calling your library; all a piece of cake in C++).
Oh, and "Implements a dynamic array similar to std::array" .... that's factually wrong. std::array is not a dynamic array. std::vector is. Interestingly, your std::array implementation uses your std::vector, while adding some more runtime overhead. Hey, it's C, it's slower than C++ is what I learn again here!
It's a rather pointless library, unless your point is to demonstrate that C is a bad programming language.
Your comments put TAOCP in a historical context. Yes, for the time, TAOCP was a huge achievement and it is a magnificient work. History is interesting, but the question here is about today, and I don't think it's the best way to learn the stuff today. (Again, just my opinion, there's no right and no wrong here.)
It's used for example by our "myproxy" project: https://github.com/CM4all/myproxy/blob/master/src/Connection... (Ctrl-F Lua::CoAwaitable) - a Lua coroutine is launched from within a C++20 coroutine and the C++20 coroutine awaits the Lua coroutine. Everything integrated in a non-blocking I/O event loop.
Agree - and the Linux kernel is extremely fragile because it is full of ad-hoc manual code like that.
Unfortunately, Rust won't be the rescue, because (in the foreseeable future) Rust will only be available in leaf code due to the many hard problems of transitioning from fragile C APIs to something better. Writing drivers in Rust is useful, but limits the scope of how Rust helps.
Many of Rust's advantages at a tiny fraction of the effort could be had easily with a smooth transition path by switching the compiler from C to C++ mode. The fruit hangs so low, it nearly touches the ground, but a silly Linus rejects C++ for the wrong reasons ("to keep the C++ programmers out", wtf).
Every time I work on the Linux kernel source, I'm horrified by how much pain the kernel developers inflict on themselves. Even with C, it would be possible to install a mandatory coding style that is less fragile.
For example, in the aftermath of the Dirty Pipe vulnerability last year, I submitted a patch to make the code less fragile, a coding style that would have prevented the vulnerability: https://lore.kernel.org/lkml/20220225185431.2617232-4-max.ke... - but my patch went nowhere.