← Back to context

Comment by jmyeet

1 day ago

The lesson here is that people have an unrealistic view of how complex it is to write correct and safe multithreaded code on multi-core, multi-thread, assymmetric core, out-of-order processors. This is no shade to kernel developers. Rather, I direct this at people who seem to you can just create a thread pool in C++ and solve all your concurrency problems.

One criticism of Rust (and, no, I'm not saying "rewrite it in Rust", to be clear) is that the borrow checker can be hard to use whereas many C++ engineers (in particular, for some reason) seem to argue that it's easier to write in C++. I have two things to say about that:

1. It's not easier in C++. Nothing is. C++ simply allows you to make mistakes without telling you. GEtting things correct in C++ is just as difficult as any other language if not more so due to the language complexity; and

2. The Rust borrow checker isn't hard or difficult to use. What you're doing is hard and difficult to do correctly.

This is I favor cooperative multitasking and using battle-tested concurrency abstractions whenever possible. For example the cooperative async-await of Hack and the model of a single thread responding to a request then discarding everything in PHP/Hack is virtually ideal (IMHO) for serving Web traffic.

I remember reading about Google's work on various C++ tooling including valgrind and that they exposed concurrency bugs in their own code that had lain dormant for up to a decade. That's Google with thousands of engineers and some very talented engineers at that.

7 comments

jmyeet

Reply
marcosdumay  1 day ago

> The Rust borrow checker isn't hard or difficult to use. What you're doing is hard and difficult to do correctly.

There are entire classes of structures that no, aren't hard to do properly, but the borrow checker makes artificially hard due to design limitations that are known to be sub-optimal.

No, two-directional linked lists and partially editable data structures aren't inherently hard. It's a Rust limitation that a piece of code can't take enough ownership of them to edit they safely.

wordisside  1 day ago

[dead]

  • aw1621107  1 day ago

    > The implementations of sort in Rust are filled with unsafe.

    Strictly speaking, the mere presence of `unsafe` says nothing on its own about whether "it" is easier in C++. Not only does `unsafe` on its own say nothing about the "difficulty" of the code it contains, but that is just one factor of one side of a comparison - very much insufficient for a complete conclusion.

    Furthermore, "just" writing a sorting algorithm is pretty straightforwards both in Rust and C++; it's the more interesting properties that tend to make for equally interesting implementations, and one would need to procure Rust and C++ implementations with equivalent properties, preferably from the same author(s), for a proper comparison.

    Past research has shown that Rust's current sorting algorithms have different properties than C++ implementations from the time (e.g., the "X safety" results in [0]), so if nothing substantial has changed since then there's going to be some work to do for a proper comparison.

    Edit: forgot to add the reference [0]: https://github.com/Voultapher/sort-research-rs/blob/main/wri...

wordisside  1 day ago

[dead]

  • aw1621107  1 day ago

    > Also, the Linux kernel developers turned off strict aliasing in the C compilers they use, because they found strict aliasing too difficult.

    I'm not sure "they found strict aliasing too difficult" is an entirely correct characterization? From this rather (in)famous email from Linus [0]:

        The fact is, using a union to do type punning is the traditional AND
    STANDARD way to do type punning in gcc. In fact, it is the
    *documented* way to do it for gcc, when you are a f*cking moron and
    use "-fstrict-aliasing" and need to undo the braindamage that that
    piece of garbage C standard imposes.

    [snip]

    This is why we use -fwrapv, -fno-strict-aliasing etc. The standard
    simply is not *important*, when it is in direct conflict with reality
    and reliable code generation.

    The *fact* is that gcc documents type punning through unions as the
    "right way". You may disagree with that, but putting some theoretical
    standards language over the *explicit* and long-time documentation of
    the main compiler we use is pure and utter bullshit.

    [0]: https://lkml.org/lkml/2018/6/5/769