Hacker News Reader

Comment by roca | Hacker News Reader

> If you want to write device drivers, then C is great for you.

No, it really isn't. It's 2024, people who should know better should stop saying this.

Alright, I'll assume you know better; what should we use? Preferably on a variety of OSs; ex. I imagine you can write Windows or Haiku drivers in C++, but I'm only aware of C being an option in any BSD, and Linux support for anything but C is spotty (obviously Rust is making headway, but last I heard you could only write certain kinds of drivers using it as the underlying support is built out).

If your platform is supported by LLVM, Zig is worth serious consideration. It is able to target any of the operating systems you mention, from any of the operating systems you mention. Linking to the syscall interface / libc / C libraries is straightforward, exporting functions which respect the local ABI is quite simple.

Latest release of zig is 0.13. I guess it’s fine for hobby projects and learning…

It's true that, as a pre-1.0 language, choosing Zig means taking on the implementation burden of changing code to keep up with language changes. But it's already being used in production in a surprising number of places.

Wanting to wait until 1.0 to get started is a respectable choice. I prefer to get a head start, compile against master every few weeks, and change what needs changing.

At some point it becomes a bit ridiculous to be pre 1.0 for nearly a decade. It is symptomatic of a level of complexity and confusion about the core language use cases* that is a nonstarter for me.

* In other words, I think it's trying to do way too much and would have benefitted from aggressive scope reduction years ago.

Avoiding C's biggest issues can overcome a good amount of pre-1.0 problems.

For drivers? I suppose if it has really good C interop that might work... is that a thing?

Yes, Zig has excellent C interop.

https://ziglang.org/documentation/master/#C

Zig has near-seamless C interop and the Zig compiler is also C cross-compiler:

https://zig.news/kristoff/cross-compile-a-c-c-project-with-z...

The Linux kernel only compiles with GCC the last I heard though. Also the libc is probably different, so I suspect it'd be trickier than expected.

https://www.kernel.org/doc/html/latest/kbuild/llvm.html

For what it's worth, on Windows Rust is also a Microsoft supported, though "not yet recommended for production use", option.

https://techcommunity.microsoft.com/blog/surfaceitpro/open-s... / https://github.com/microsoft/windows-drivers-rs

Oh nice - I'd heard they were using it internally but I didn't know they were working to make it an (official?) option for 3rd parties. I'll also say that Windows has an advantage in the form of a stable driver ABI, which AIUI should make it easier for people to write drivers in arbitrary languages.

C being the only option doesn't make it a great option.

Whatever else your platform supports. Literally anything else would be better, other than raw assembly.

Usually there are some options. Rust is supported (to a degree) on both Linux and Windows. Both macOS and Windows support C++, which if used correctly is at least safer than C.

I've wanted to try writing a Linux driver in Nim for fun.

I've ported and used Nim in a couple of RTOS'es and it's pretty straightforward. Of course there wouldn't be official support or anything, but it wouldn't be too hard. Mapping pointers to Nims RC refs would be a bit tricky, but doable.

What else would you use instead of C?

Rust if possible. But really my point was that even if C is your only option, it should not be considered "great".

In reality, if you know your requirements up front, you do not need to dynamically allocated memory

My requirement is to store and process arbitrary uploaded data. How’s that work out?

Couldn't that work? Upload by chunks via static buffer (which I kinda thought is how most web servers actually do uploads?), save to a file, then likewise load+process+store in 1k chunks or whatever. Depending on what processing you're doing and the workload characteristics (most obviously, number of clients) it might be painful, but I think it could work fine with a fixed memory footprint?

Reply on news.ycombinator.com