Hacker News Reader

Comment by crq-yml | Hacker News Reader

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.

View on HN

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.

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...) syntax. Don't get me wrong, I like the concept of memory safety, but I think too many languages are going "We have to stand out!" and therefore are creating completely new syntaxes. That may work for you, but frankly, I'm happiest in a language that sticks close to C++ syntax (which is probably one reason I love D so much).

Also, C build errors have nothing to do with C++? What are you getting at there?

I'd be a little interested to hear what you like about C++'s syntax! As a non-C++ programmer, I mostly think of the language as a pile of mistakes that kinda had to happen for other languages to learn from them, very much including syntax (ex. types preceding declarations, necessitating `auto` and complicating parsing) - and I actually think the ugliest parts of Rust copy those mistakes (ex. using <> for generics, which are ambiguous with less-than greater-than when used with no whitespace, necessitating the turbofish).

(I've heard plenty of complains about Rust syntax, so I'm less so interested in that than what C++ syntax gets right. Unless it's just a familiarity thing...)

It's pretty much familiarity. If I'd learned Rust back in the day, I'd probably not want to learn C++ for syntax reasons as well.

One thing I think Rust gets wrong is classes. I absolutely don't understand why you would require a separate `impl` block to provide methods. C++ has a reasonable syntax of providing methods in the class.

Well, they're not classes, they're interfaces, and so you can implement multiple interfaces for multiple types, and so you have to implement them separately from the type declaration. There's not too much of a way around that, I think.

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 + y }

C++ is the one that tries hard to standout.

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;
    };

> 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.

> 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.

Reply on news.ycombinator.com