- > If it's a headers-only library in a language such as C++, if the project is not dead then the very least anyone would expect from it is being updated to support any of the modern C++ versions.
Did I miss a new C++ version released <2 days ago perhaps?
- > They lack security updates
Very few projects update dependencies that often, and only very big ones are found with security issues that often.
> lack integrations with new platforms
You don't need a new intration _every 2 days_, not to mention that many projects don't need such integrations at all. Moreover some popular and updated projects lack such integrations despite having lot of commits.
> lack support for new HW architectures
This is something that many projects get for free. But also, you don't get a new HW architecture every 2 days.
> lack newer privacy guarantees
What more privacy guarantees do I need from projects that don't communicate with external services or store data at all?
- OSCP stapling (which OP mentions) is supposed to fix that though.
- The article does link in multiple places to another article discussing why revocation checks do not work for privacy (you're telling someone your browsing history basically) and reliability (what if the CA's revocation checker goes down?) reasons.
- We do this, but if you're redeploying fast enough thre's a change that a user loads a cached old page (or performs a client-side navigation to an old page) and makes a requests for a URL that's no longer served by the origin nor is cached by the CDN.
- > This allows ubuntu to avoid releasing security fixing patches if they so choose. You can't do that with GPLed code. It means they can send out binary security fixes and delay the source code release for as long as they like or indefinitely
The GPL does not state that the source code for any modification must be released immediately, it doesn't even set some kind of time limit so it technically doesn't prevent indefinite delays either.
- > just turned the entire package vertical so the die was end-on to space (the mountains around were shielding the horizontal direction), and the problem went away.
That's a pretty cool solution! For some reason I was expecting something a lot more elaborated
- > So it validated in the input and failed in an unsafe way. Is that what you’re saying? Instead of rejecting the input and failing in a safe way.
It rejected the input and "failed" in a loud way (showing an error) for the user, as opposed to not rejecting the invalid input and continuing anyway in a degraded/invalid state, which would instead have allowed users to continue browsing but would not have worked properly for some other purposes (e.g. it probably would not have continued blocking malicious/bad scraper requests). Neither is ideal, though of course depending on your priorities one might be better than the other.
> My only point was, the language doesn’t matter. It could have been written in brainfuck.
Yeah I definitely agree. My point was that the error was also somewhere else, since an internally-controlled input was invalid.
- Changes are the leaked spec might already be in the popular LLMs' training data, so you could probably skip to step 2 without having to do the (potentially problematic) training yourself.
- If the PAUSE instruction is too fast doesn't that kinda defeat its purpose?
- Rustc supports backends other than LLVM btw
- > I would think that americans would be much more vigilant about what medication they take, the price it cost, and so would have much lower pricing. That's just how free market work, and technically there are many medication manufacturer and many customer.
(Not american) This assumes they have a choice, no? Do these medications have real alternatives?
- > And yet somehow the internet went down because of a program written in rust that didn’t validate input.
No, it _did validate_ the input, and since that was invalid it resulted in an error.
People can yap about that unwrap all they want, but if the code just returned an error to the caller with `?` it would have resulted in a HTTP 500 error anyway.
- You can create `Io` instances whenever you want (although that kinda goes against its spirit) and you can also pass them inside structs, not necessarily as a function argument. Moreover you can reuse all the existing "sync" functions when using I/O and viceversa (ever tried doing an async call inside a `Option::map` in Rust?)
By the way, Rust's runtime also have a similar issue to Zig's `Io` (making the runtime available to the code, similarly to how you need to make an `Io` instance available in Zig). Rust runtimes just decided to use thread locals for that, and nothing stops you from doing the same in Zig if you want to.
I hope you can see that this is all orthogonal to the "colored functions" problem. When I was talking about tradeoffs however I was referring to the use of a threaded/green thread implementation under the hood as opposed to a stackless coroutine. The first two are less invasive at the language level and don't require function coloring (hence why Zig didn't solve, but also doesn't have, function coloring!) however they can be more limiting (they are not always available, especially on embedded and on wasm) and less extensible (most operations need to be explicitly supported in `Io`, as opposed to being implementable by anyone).
- > First things first, Zig does compile async fns to a state machine: https://github.com/ziglang/zig/issues/23446
Maybe I'm missing something, but that's still a proposal, which also assumes an implementation for the other proposal you linked and that also doesn't exist yet.
For now I would refrain from commenting on non-existing functionality.
> I still think sans-io at the language level might be the future, but this isn't a complete solution.
I'm not sure what about this is really at the language level (only stackless coroutines appear to require language level support, and it's still unclear if it's really possible to implement them). However I do agree that a sans-io, or at least dependency injection for I/O is a great improvement on the library side, and it's something I'd like to see in Rust too.
- Most likely no, division instructins generally take as much as 10-20 other arithmetic/logic instruction.
- > int bar(int num) { return num / 2; } > > Doesn't get optimized to a single shift right, because the that won't work if num is negative.
Nit: some might think the reason this doesn't work is because the shift would "move" the sign bit, but actually arithmetic shifting instructions exist for this exact purpose. The reason they are not enough is because shifting provides the wrong kind of division rounding for negative numbers. This can however be fixed up by adding 1 if the number is negative (this can be done with an additional logical shift for moving the sign bit to the rightmost position and an addition).
- It's more akin to awaiting *any* condition from a list.
- Maybe I'm missing something, but how do you get a `Future` for receiving from a channel?
Even better, how would I write my own `Future` in a way that supports this `select` and is compatible with any reasonable `Io` implementation?
> If a project hasn't gotten a new commit in 2 days then the project is claimed dead.
You don't need a commit every day to support C++26, and surely not every day for 3 years until the next major version releases.