Not in 2023, but this one has the exact same score: https://nvd.nist.gov/vuln/detail/CVE-2020-17541

making the same mistakes

This is key, and I feel like a lot of people arguing about "hallucinations" don't recognize it. Human memory is extremely fallible; we "hallucinate" wrong information all the time. If you've ever forgotten the name of a method, or whether that method even exists in the API you're using, and started typing it out to see if your autocompleter recognizes it, you've just "hallucinated" in the same way an LLM would. The solution isn't to require programmers to have perfect memory, but to have easily-searchable reference information (e.g. the ability to actually read or search through a class's method signatures) and tight feedback loops (e.g. the autocompleter and other LSP/IDE features).

No; Wayland is also a protocol, and Niri relies on that protocol, so Niri doesn't bypass the need for Wayland support.

This is hilarious. I'm not sure how often anyone would actually need to verbalize arbitrary binary data, but I do see an advantage over base64 since the English letter names are so often phonetically similar.

What's wrong with the Windows one, and/or what's better about Gnome's or KDE's?

I wonder what the best programming analogue is for combining words into one where other languages keep them separate; maybe the functional-style chains of adapters?

Compiled code is already effectively write-only. But I can imagine there being some efficiency gains in not always shelling out for arithmetic, so possibly that's a future improvement for the project.

That said, my reaction to this project overall is to wonder whether there are really very many situations in which it's more convenient to run a compiled Bash script than to run a compiled binary. I suppose the Bash has the advantage of being truly "compile once, run anywhere".

At the time, she called it a "compiler", but its function was more akin to what we'd call a linker or assembler today.

Sorry, my phrasing was sloppy. Most popular IDEs and editors do not have a plug-in or setting that implements elastic tabstops correctly. In particular, there's no implementation for vim, emacs, VSCode, eclipse, or any JetBrains IDEs. (I had forgotten that there's one for Visual Studio and one for Notepad++.)

Sure. But the author cites that as a disadvantage of emacs and links to an article about the person who invented ctrl-c and ctrl-v for copy and paste.

That’s a bad apples-to-oranges comparison, unique_ptr frees memory upon destruction, which with the raw pointer version you don’t do.

I intentionally crafted an example where the code is simply using unique_ptr (and Box) without freeing the memory, just as it uses the raw pointer without freeing it. The consumes function would of course free it, hence the name. Freeing the memory shouldn't be all that different between free, ~unique_ptr, and Box::drop.

Moreover, the Rust code is doing the same thing the C++ code is doing; Box frees memory just like unique_ptr does.

The least you could do is use rvalue references.

I was surprised to see how much lower-overhead that looks, and I couldn't remember why I originally wrote the example as passing by value until I reviewed Carruth's video. But he actually talks about using rvalue references around the 22 minute mark, and then goes back to passing by value, so I assume that's why I wrote it the way I did. I do think it's pretty counterintuitive that a type that's semantically a pointer needs to be passed by reference for efficiency.

The class layout of unique_ptr is also hard to optimize away (unless via LTO)...

The "class layout" of unique_ptr is just a pointer; are you talking about the struct needing to be on the stack in order to satisfy the ABI? That's true, but people do in fact need to pass data between multiple different translation units (and even into and out of dynamically-loaded libraries), so that should be possible to do in an efficient manner. And, again, both the raw-pointer version and the Rust version manage to make this work.

you’re using Clang 9 by the way...

Oops, good catch; I crafted this example a long time ago and did try it with the most recent version, but I guess that must have been in a different tab. But it doesn't actually make much of a difference here.

Then, if you additionally make the functions’ bodies accessible to the compiler and add a free to the raw pointer version... and the non-zero difference should disappear altogether once you actually use those functions...

Yes, sure, compiling in one translation unit helps, but as I mentioned above, passing an owning pointer between translation units shouldn't be inherently inefficient. But also, as far as I can tell, making those changes doesn't actually make the unique_ptr and raw-pointer assembly equivalent. The && in the signature for "consumes" is odd because the function doesn't actually take ownership of the pointer so it doesn't actually free it, and consequently the inlining of the function is a no-op and the destructor is called inside foo. But that doesn't hinder the raw-pointer comparison much, because the C version just inlines consumes. I don't read assembly well enough to understand whether the extra mov in the unique_ptr version is very significant or why it exists. (The print_global function is only here to prevent the other functions from being turned into no-ops.)

https://godbolt.org/z/83T8Gfszv

"Abseil and Carbon rule..."

Abseil is...a collection of C++ libraries? How does that make him biased against the C++ standards committee? Carbon was announced in 2022, and the talk I linked was given in 2019, so I don't know if Carruth was on his "rant spree" in your opinion at that point. But the point of linking to Carruth's talk was just to explain where that example originally came from and to let someone more knowledgeable than myself explain why it would require ABI breakage for C++ to optimize unique_ptr as well as Rust optimizes Box.

FORTRAN does work on punch tape; that's why column numbers matter.