softirq

I think you missed the part about systems programming. When you are programming real hardware, the focus is entirely on low level details. You need to know the commands being sent to the device, the device state, and the ownership of resources by the device (which Rust doesn't solve for) are correct.

The innovation of Rust is the borrow checker, which is primarily of interest to systems programmers. If your primary interest is highly abstracted business logic, there are tools that don't require manual memory management or being pedantic about the different types of strings. You could just use Go, Java, Haskell, Python, etc.

I agree, at some point they do build up to the point that change is inevitable. There's usually a lot of false starts along the way (AI is a good example of this). No matter what it is, there's going to be a lot of fighting against entrenchment and a lot of us old timers simply have to retire for newer developers, whether they be Rust developers to come in and elicit change.

I'm not really looking for a replacement for C, the ecosystem of system programming is still really C centric, it would take a large shift in the industry for me to justify investing in another language. I've dabbled with Rust only because early support was merged into Linux. IMO most languages are only marginal improvements over the previous generation that don't outweigh fighting against the entrenchment of expertise, documentation, and integration that come with established languages. It's also hard to be a true expert at a low level domain and multiple programming languages unless you're willing to give up all of your free time.

In my experience as a kernel programmer tracing allocations isn't the hard part, it's keeping the correct view of hardware state and the different type of mappings at play, be it an MMU or IOMMU device mapping, and register state. Use after free bugs and overflows do happen, but there are more and more tools that come out every year that can find these things in C code, some of them are even hardware based. IMO the code quality of the kernel is very high and the defect rate isn't greater than projects I've worked on that use garbage collection.

> Low-level Operating Systems Sr. User Experience Researcher

Wow, I didn't even know this job existed. IMO Rust as a C++ replacement is fine, Rust as a C replacement has more trade-offs than I still care to make. C is still far simpler (you can still read K&R in one day and keep most of the language in your head), has faster compile times, and the pain points cough macros are still often pain points in Rust.

I think the biggest thing is that systems programming still requires a language that gets out of the way so you can focus on very technical problem domains where what the hardware is actually doing really matters. Rust is a language designed to get in your way and force you to create type abstractions. Adding too many abstraction can be exceedingly dangerous in an environment where not having a full view of how memory and hardware registers are laid out leads to even worse errors than just buffer overflows. IMO Rust makes this type of programmer more difficult just as C++ does.

All I care about when it comes to editors is availability (on every platform, can be used in a terminal), longevity, and the community for third party plugins. Vim still checks all of those boxes and the only real other contender is still Emacs.

Vim is super crusty, Kakoune and helix have better takes on the unix philosophy, integrations. VSCode is easier for absolute beginners to click around in. IntelliJ has better semantic parsing. But none of that matters. None of that holds me back from being successful. I just need an editor I can type code in that I will never have to give up, that will just be there, and I can use at the next job. In fact Vim's quick editing is just a nice to have, it's never been the difference between me killing it and getting killed at work. That's why I'm sticking with Vim.

Always wrapping errors can be a good way to get a stack trace of the error path in the logs.

> Already parts of the Linux kernel as well as Windows are being written in Rust, so if it's good enough for them, it should be good enough for those bunch of C experts.

The C experts I was referring to are the subsystem maintainers and none of them are currently working on migrating to Rust AFAIK. So far the work in Linux with Rust has been a few driver rewrites. Keep in mind that there are subsystems like eBPF, io_uring, etc. that are under rapid development and are completely in C. I think if you really believe that kernel code should be written in Rust, you should start submitting patches instead of telling people that they have some sort of moral obligation to use Rust when you aren't the one that has to do any of the work.

> extremely difficult to do in programming languages that do not have algebraic data types.

And this is why people like me avoid ML based languages, type astronauts, and shiny new toys. You're misrepresenting inconveniences as fatal flaws when we've been successfully running all of modern society on kernels written in C for fifty years. Most of the kernel subsystem maintainers aren't even considering Rust as anything more than an experiment at this point. No one cares about ADTs and the perfect representation of state transitions in the type system when we have actual problems to solve, and we can and have been solving them in C.

> You are committing the perfect solution fallacy.

Rust is also not a perfect solution. You have to prove that the benefits of solving for the bugs Rust can prevent outweighs the downsides of asking a bunch of C experts who are currently developing kernel subsystems in C to stop what they are doing and rewrite millions of lines in C in a language that has very low marketshare in the space and is far, far more complex in terms of abstracting over assembly. People write systems software in C not because they have a fetish for bugs, but because we do in fact still have to stay close to the hardware and not get lost in a minefield of abstractions.

> Beauty is a useless concept in a programing language.

Maybe not aesthetic beauty, but readability in many contexts matters more than performance. Code that isn't readable hides bugs and can't be maintained (FYI Rust doesn't stop you from writing bugs into your code). A language like C or Go where you can fit most of the syntax and mechanisms into your head are simply easier to read and reason about than a language where you need a PhD in type theory to understand one signature.

> If it is not memory safe, does not support static typing with algebraic data types, and does not have null safety it does not meet those minimum requirements and is not suitable for use.

You'd better stop interacting with technology then, because the vast majority of it is still running something compiled from C. We're talking about control systems, life saving technology, technology that's running in outer space.

After writing primarily no standard library C for 15 years, I have to say that I find Rust just as ugly and cumbersome as C++ (not debating its safety guarantees). It seems like languages that add sufficiently advanced type/macros systems always spiral into unwieldy beasts where you spend a bunch of your time arguing with the type systems and writing blog posts about some new piece of type theory to solve a problem you would have never have had with C. People just get greedier with deriving code and wanting more "magic" until every program only makes sense to its author.

I don't think I will ever like kitchen sink languages. Experience has taught me that the most effective tool is the simplest one, which for most use cases today would be Go. For systems programming I just shudder to think how convoluted and hard to read things will become when we take already extremely complex code written in the simplest terms in C and port it to Rust.

Just doing a basic google search shows me at least 4 plugins that interface with chat GPT. I personally don't use them because my workplace doesn't allow feeding our code to another companies backend.

I use vim and don't futz around with my config. I feel like this is a perpetual myth that vim or emacs requires endless tinkering. I maybe touch it once a year, and I still have:

- LSP support - code actions, hover, gotos, linting.

- Fuzzy finding with previews (with syntax highlighting thanks to bat)

- Integrated Git

- Integrated Terminal

- Integrated Debugger

It's a real shame that IntelliJ and VSCode users scare beginners off from trying out all the amazing editors like Vim, Barebones, Nova, etc. with this FUD that they won't get anything done. I've seen people swap between editors like SOs in high school and I've been able to consistently stick with Vim my entire career, so maybe the FOTM editor crowd are really not seeing the gains in productivity they believe they are getting by always picking the "out of the box" editor.

How do you feel about Rust?

My approach to my terminal tools is to avoid eye Candy as much as possible. It distracts and complicates without adding value. Eye candy often is not easily portable, and it can break.

I use color very intentionally to mean something. The only time I theme something is if it’s already themeable and I can set the theme to use 3 bit terminal colors so I can drive all themes from one place (my terminal profile).

As I said I have done research work and a written a PhD thesis on operating systems, and I've worked on several production kernels including Linux and I find it hard to fathom this hill you all are trying to die on. You can't just redefine important concepts however you like as the arguer is trying to do. Names mean things. If you want to pretend that x is y and blue is red, then we simply can't discuss the topic because you're not able to agree on the basic particles the community uses to have discussions. It's just contrarianism.

Microkernels are defined by privilege levels. It's not debatable. You wouldn't say that something is true microkernel because it's modular. We could have more interesting discussions about the actual topic if you and the original poster could accept common definitions like any sane technologist.

Let's go over what I said:

io_uring remaps a contiguous chunk of pages in both the kernel and userspace vas.

This is a true statement - io_uring makes a compound page and calls remap into the usersapce vas in mmap, and I did not say that the pages were kernel or userspace page. However, you've said "userspace pages" in your own argument which by your own admonition is incorrect. You are correct in saying that pages are just pages, because a page is just a chunk of physical addresses assigned to a pfn and has no meaning in userspace or kernel space without a vma.

There is a difference between kernel and userspace mappings, and mapping userspace virtual address to point to direct mapped kernel addresses that the kernel is manipulating is dangerous and there are many CVEs that have taken advantage of these types of command buffers on other kernels.

Yes, and it's not that it's just slow, it also freezes Emacs completely when it borks (and it does bork). I also found that none of the emacs terminals could correctly display my prompt and I ended up writing a bunch of bash conditionals to make my prompt dumber to work in Emacs. Just worked out of the box with Vim's :term.

Vim has terminal support, gdb support built in. We have vim plugins maintained by the top Vim plugin specialist for git and project management. We have vimwiki, markdown, org mode support. We have fuzzy finding, autocomplete, lap support. I really don't think you can reasonably tell me you can't live in Vim, when I have had the same session open editing the linux source tree for like two months now.

1. Org mode - I will admit that I'm not a fan of org mode and find it to be oversold and another time waster for people who are already wasting time configuring their editors. I personally use vimwiki, there is a vim plugin for org mode.

2. Magit - Tim Pope is the pope of Vim plugins and fugitive is easily as good or better than Magit. I have never had any issue doing any sort of complex task in git or fixing conflicting using fugitive.

3. Wdired - Tim Pope again has vim-vinegar to improve netrw. Never had a problem or thought about manipulating directories inside of Vim.

4. Again, if you believe in the Unix philosophy then you have to admit that Emacs is simply bloated and trying to do too much and therefore is not really the best at anything. And more importantly, if there's something that Emacs can't do you've screwed yourself because you haven't built an environment around many distinct tools on the command line and it's going to be awkward to integrate.

Why would I want to run an emacs layer adding more latency to my work to turn Emacs in to Vim when, as I said, I can do everything in Emacs I can do in Vim.

> (I also don't see how tramp is an issue -- it opens up workflows I wouldn't even have access to without it!)

Because it will randomly freeze and it's single threaded, it's slow, and it's also not novel. Vim can also edit files over SSH, VSCode can run itself remotely.

I did the same experiment and came to the same conclusion. There’s really nothing killer in Emacs that makes it a huge sell over just using vim which is a much better editor unless you just love Emacs lisp. Emacs also has some glaring issues - tramp being a major one. It’s slow and very unreliable.

Vim is much more in line with the Unix philosophy. It’s a great editor that can be extended with fzf, ripgrep, lsps, git etc. Emacs has three versions of every plugin and they’re all usually not as good as the thin vim wrapper around fzf etc. If you’re not editing and need email, mutt is a great email client. Irssi is a great chat client. Emacs is very much an all or nothing computing environment.

I am glad I tried Emacs though, because I did love which-key and ended up adding it to my Vim config. And Emacs is slightly easier to quit?

ADVICE: Try both Emacs and Vim vanilla before you do anything else. Downloading a "distro" is really doing yourself a disservice by not showing you just how much either can do without the chrome. And for the love of RMS DON'T USE VSCODE.

Yes, you're looking at kernel pages through userspace virtual memory mappings, this isn't the case with copy to user. You're just copying data from a userspace page to a kernel page, but only in kernel mode. You don't get to "see" kernel pages and in fact post spectre/meltdown the kernel is unmapped in userspace.

Micro kernel-ish behavior would be features that allow for drivers/modules in userspace, which Linux does provide (and I do agree that Fuse is an example of this). eBPF is not sort of, or kind of, or remotely related to micro kernels and I'm not being pedantic. It really, really isn't related to microkernels because it is doing the exact opposite of what a microkernel does. Pluggable policy in kernelspace is not the same as running something in userspace that's implementing a system function like a filesystem, a networking stack, etc. which would be analogous to FUSE, DPDK, etc.

eBPF is no different from runtime loadable kernel modules, which has never made Linux a microkernel. Modules allow for runtime extension, but they are still running in the kernel. The point of eBPF is that kernel modules are dangerous and error prone to write, and eBPF allows non-kernel programmers to write reasonably safe modules that can also be ported to different kernels via CO-RE. They are pluggable policy points or probes.

The Fuse developers just figured out the same thing microkernel developers figured out in the late 80s/early 90s. Performance is much better if you move more processing to the kernel.

It's not the same thing. io_uring remaps a contiguous chunk of pages in both the kernel and userspace vas. For read/write the data is copied from userspace into kernelspace.

I think you really need to understand that the term micro kernel refers to a very specific thing. Please go read the wikipedia definition because it does a good job of summarizing it. A microkernel handles only the basic kernel primitives in the highest privilege level and critically provides an rpc like communication mechanism for authenticating and delegating everything else.

eBPF does not do that, it does not enable doing that. It does the inverse. It adds code to the kernel in the exact same way a kernel module adds code to the kernel, but in very specific places to allow extending the kernel at points of policy. It does not run kernel code in userspace. It does not run userspace code in the kernel. It loads code from userspace into the kernel and runs it as kernel code.

The kernel talks to NICs in kernel mode and can actually segregate a device's view of memory via an iommu. While there's some overlap in potential vulnerabilities, bad hardware/firmware is a different vector than userland having a shared mapping active to use in exploits that read arbitrary kernel data.

io_uring is also very complex. It's now it's own subsystem, has it's own worker pool, and even the dance of the rings themselves moving pointers around and using data structure that must be manipulated from both sides is not simple and thus probably not that secure.

It's still running code inside of the kernel. The point of a microkernel is to run as little in ring 0 as possible and have a very thin resource manger that can talk to system servers. The point of eBPF is to move even more stuff dynamically into the kernel to avoid expanding the kernel's static interfaces (syscalls).

io_uring (and eBPF for that matter) are still super concerning attack vectors and we've already seen eBPF being used in the wild by bad actors. kernel_lockdown explicitly disables eBPF and other methods of kernel injection and is turned on by secure boot. In io_uring's case sharing a userspace mapping with kernel space is simply always going to be dangerous. End of story.

The jury is also out as to what the performance benefits of io_uring are and whether the benefits outweigh the risks versus sticking to what's available. I've seen a lot of good results, but I've also seen bad results, and I haven't seen a lot of real world data at scale yet.