Live data from Hacker News

Converting the Kernel to C++

lore.kernel.org

41–50 of 56 posts

Re: Converting the Kernel to C++

#41
post #30

Earlier quoted context omitted.

The reasoning behind switching to C++ today rather than Rust, Zig, or any other language is familiarity. C++, while it currently doesn't have memory safety, is extremely easy for any C programmer to ease into, especially given the limited subset that Anvin is proposing for kernel use. Meanwhile, Zig and Rust look absolutely awful. As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and..…

This feels like a personal statement of familiarity rather than looking ahead to designing a language that has to be taught to next generation of software engineers. AFAIK, the only operator Rust introduces over C++ is the try operator (aka. ?) and match statements. Furthermore I can't imagine how someone could prefer &&auto my_closure = [&](int x, int y) { return x + y } to just let my_closure = |x: int, y: int| { x…

The difference is negligible in real syntax:

    auto my_closure = [](int x, int y) { return x + y; };

    let  my_closure = |x: int, y: int| { x + y }
and frankly, the option of an explicit capture-list with aliases and mixing moves and copies is a benefit:

    int sum = 0, diff = 0;
    
    auto adder = [&sum](int num) {
        sum += num;
    
        // compilation error, author didn't
        // mean to capture diff.
        diff -= num;
    };

Re: Converting the Kernel to C++

#43
post #20

The path to migrate to Zig is, or would be, the most straightforward, except that that language is not ready. But in design terms it's definitely got the things the OP is championing C++ for, and a better story for actually addressing longstanding systems programming issues instead of heaping stuff onto the C toolchain and therefore making everyone debug C build-time errors.

Seeing that the last time I tried to use Zig–completely inexperienced, trying to do completely basic stuff–I hit a compiler bug within two hours, I'd say that "not ready" is about right. To be fair, the latest Github version had the bug already fixed, but it's still a sign the language is basically still in an alpha stage.

I think the standard library has some bugs too.

Re: Converting the Kernel to C++

#44
post #37
post #32

Earlier quoted context omitted.

> Rust actually is a nice language. C++ requires deciding which features to use? With Rust you have to choose which features to use. Unlike C++, with it's "you pay for what you use" model, Rust's features are arguably still broken, unstable, and under active development. See async rust for example. > don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only…

Should I use boost style? Qt/Eigen styling? Can I get a subset of the language and stdlib without allocations? Should I use multiple inheritance with I classes or template duck typing? What’s the cycle and storage cost of smart pointer wrappers? Atomics kill pipelines and caches. Yeah the zero cost isn’t actually zero cost sorry to say. Are closed over stack variables moved or referenced? If referenced, what happens…

Google style guide is good tbh.

You should use the right tool for the job.

std::unique_ptr is just a move-only ergonomics type over a bare pointer, it doesn't have extra state. std::shared_ptr is basically no different than Rust's Arc.

Closures specify capture semantics explicitly, so you will always know, and default to copy.

And yes, you can capture local references and leave. Don't do that, or return references to local variables, or lots of other fun stuff.

Re: Converting the Kernel to C++

#45
post #37
post #32

Earlier quoted context omitted.

> Rust actually is a nice language. C++ requires deciding which features to use? With Rust you have to choose which features to use. Unlike C++, with it's "you pay for what you use" model, Rust's features are arguably still broken, unstable, and under active development. See async rust for example. > don’t know modern C++ but it seems to have a kind of cult like indoctrination where everything else is wrong and only…

Should I use boost style? Qt/Eigen styling? Can I get a subset of the language and stdlib without allocations? Should I use multiple inheritance with I classes or template duck typing? What’s the cycle and storage cost of smart pointer wrappers? Atomics kill pipelines and caches. Yeah the zero cost isn’t actually zero cost sorry to say. Are closed over stack variables moved or referenced? If referenced, what happens…

> Should I use boost style? Qt/Eigen styling?

You use whatever you wish to use. You can also waste time debating whether you should name your variables in camelCase or snake_case. It doesn't matter, and no one will berate you for whatever choice you made.

It's your call. Do you think that having a choice is bad?

Re: Converting the Kernel to C++

#48
post #30

Earlier quoted context omitted.

The reasoning behind switching to C++ today rather than Rust, Zig, or any other language is familiarity. C++, while it currently doesn't have memory safety, is extremely easy for any C programmer to ease into, especially given the limited subset that Anvin is proposing for kernel use. Meanwhile, Zig and Rust look absolutely awful. As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and..…

This feels like a personal statement of familiarity rather than looking ahead to designing a language that has to be taught to next generation of software engineers. AFAIK, the only operator Rust introduces over C++ is the try operator (aka. ?) and match statements. Furthermore I can't imagine how someone could prefer &&auto my_closure = [&](int x, int y) { return x + y } to just let my_closure = |x: int, y: int| { x…

> This feels like a personal statement

Because it is. And is a statement I agree 100% being a +20-years C developer with a hardwired C parser in my brain: Rust, Zig and some (most?) newer C++ syntax is contorted at minimum (to my eyes).

I wish the only difference were about just new operators, but just the fact that the type has to come after the variable declaration is awful to me (also for returning types in functions declarations). One can tell me 100 reasons why Rust does it this way and they'll probably be all true and right, and you can call me all sort of things but this kind of new syntax puts me off right away.

Re: Converting the Kernel to C++

#49
post #39

> We do a lot of metaprogramming in the Linux kernel, implemented with some often truly hideous macro hacks. If you do a lot of meta-programming… why not used a more principled approach like Lex & Yacc? Why not go all the way to design mini-languages and compile them to C? Or design C extensions and compile them to C? You can still have good debugging support with line markers. https://gcc.gnu.org/onlinedocs/cpp/Prep…

You'd just be reinventing C++.

I sure hope not.

Re: Converting the Kernel to C++

#50
post #30
post #20

The path to migrate to Zig is, or would be, the most straightforward, except that that language is not ready. But in design terms it's definitely got the things the OP is championing C++ for, and a better story for actually addressing longstanding systems programming issues instead of heaping stuff onto the C toolchain and therefore making everyone debug C build-time errors.

The reasoning behind switching to C++ today rather than Rust, Zig, or any other language is familiarity. C++, while it currently doesn't have memory safety, is extremely easy for any C programmer to ease into, especially given the limited subset that Anvin is proposing for kernel use. Meanwhile, Zig and Rust look absolutely awful. As somebody who's been using C++ for eight years, I despise Rust and Zig (and Nim and..…

> C++, while it currently doesn't have memory safety [...] Meanwhile, [...] Rust look absolutely awful

Memory safety is the primary reason people are advocating for Rust in kernel! Given that goal, C++ looks absolutely awful.

Post reply on HN