I guess what you mean is that Rust doesn't advertise the compiler as being bug-free?
The massive difference here is that C++ has no soundness guarantees even when the compiler is working as intended, whereas Rust actually does in fact give soundness guarantees in the absence of compiler bugs.
Yeah, and that falls under the first category, bugs in the compiler: https://github.com/rust-lang/rust/issues/25860
(All exploits in that repo are possible due to that bug.)
"You don't have the hiring and firing power."
-- Kitty, Arrested Development
Strictly speaking, no. The borrow checker was a true innovation.
Both GitHub Actions and GitLab CI let you specify filepath rules for triggering jobs.
I wrote a longer reply with links, but somehow it didn't actually post; so this will be shorter and unsourced. Sorry about that.
There already was a discussion, over the course of several years, about whether to add Rust to the kernel. Linus merged rust/kernel into the mainline in 2022, and it was released in Linux 6.1. The patch that Hellwig opposed did not introduce Rust, it just added more Rust.
Hellwig also made it pretty clear that he wasn't open to discussion. If you read the thread, there were numerous attempts to "talk things over."
You may be right that Marcan's posts on Mastodon added nothing productive, though I honestly think there's some value in sharing behavior like Hellwig's with the broader programming community. But his posts in the actual mailing list seem pretty sensible, albeit provocatively worded.
Also, in case you didn't know, similar behavior (to Hellwig's) led the primary Rust for Linux maintainer, Wedson Almeida Filho, to step down back in August. Marcan is correct that the anti-R4L maintainers are successfully demoralizing the R4L people.
🤷 That wasn't my experience, and I used it as my primary dev environment for four years.
It doesn't go through a translation layer, though. WSL 2 has a whole separate kernel. You can even use GUI apps with Wayland.
The second one!
Honestly, wouldn't it be great if POSIX eventually specified a WASM runtime?
I tried NeoVim pretty early on, I think, around 2014. My primary editor at the time was gVim (I prefer a proper graphical front-end to running in a terminal).
I used nvim on and off, primarily with nvim-qt as the front-end, though briefly with a custom setup that launched a new terminal emulator window and ran nvim there.
Once nvim incorporated nvim-qt into the base install, I started using it more regularly; eventually I switched entirely to Neovide and haven't even installed gVim on my last few work computers.
I now primarily use VSCode with nvim integration. Unfortunately, I do have a weird issue where "undo" combines more operations than I'd expect, or, in some rare cases, it seems to corrupt the buffer and produce states that didn't previously exist (!!). I don't know if that's an issue with the plugin, though.
Ah. No, keep reading:
In a less than optimal world, you might decide to do something less inspired. You might take that break from the C runtime and then just implement threads again, with basically the same semantics, except that they are scheduled in userspace. Your users would be required to implement concurrency in terms of threads, locks and channels, just like they had always been in the past. You might also decide your language should have other classic features like null pointers, default constructors, data races and GOTO, for reasons known only to you. Maybe you would also drag your feet for years on adding generics, despite frequent user requests. You might go do that, in a less than optimal world.
(Emphasis on "go" is in the original.)
I have managed to mostly avoid needing to code in either language, but my strong inclination is to agree that they are indeed hacks.