• GravitySpoiled@lemmy.ml
    link
    fedilink
    English
    arrow-up
    21
    arrow-down
    3
    ·
    2 months ago

    I don’t want to watch a video about it.

    I’d like to know it, but a couple of sentences wouldn’t have hurt

    • blackbrook@mander.xyz
      link
      fedilink
      arrow-up
      15
      ·
      2 months ago

      FWIW, it’s a 9 min video and doesn’t contain anything earth shattering or easily summarized. Basically there is some friction between C and Rust devs, and Linus doesn’t think that it’s such a bad thing (there has be interesting discussion) and it’s way too early to call Rust in the kernel a failure.

  • Arthur Besse@lemmy.mlM
    link
    fedilink
    English
    arrow-up
    18
    arrow-down
    1
    ·
    2 months ago

    This video is full of jarring edits which initially made me wonder if someone had cut out words or phrases to create an abbreviated version. But, then I realized there are way too many of them to have been done manually. I checked the full original video and from the few edits i manually checked it seems like it is just inconsequential pauses etc that were removed: for instance, when Linus says “the other side of that picture” in the original there is an extra “p” sound which is removed here.

    Yet another irritating and unnecessary application of neural networks, I guess.

  • toastal@lemmy.ml
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    2 months ago

    If you believe in ADTs, limiting mutation, & a type system that goes beyond Rust’s affine types + lack of refinements (including a interleaved proof system), you could be writing kernel code in ATS which compiles to C.

      • toastal@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 months ago

        Correct me if I am wrong, but my understanding is that you use Coq to prove your theroem, then need to rewrite it in something else. I think there is some OCaml integration, but OCaml—while having create performance for a high level language & fairly predictable output—isn’t well-suited for very low-level kernel code. The difference in the ATS case (with the ML syntax similarity 🤘) is you can a) write it all in a single language & b) you can interweave proof, type, & value-level code thru the language instead of separating them; which means your functions need to make the proof-level asserts inside their bodies to satisfy the compiler if written with these requirements, or the type level asserting the linear type usage with value-level requirements to if allocating memory, must deallocate memory as well as compeletly prevent double free & use after free.

        For those in the back: Rust can’t do this with its affine types only preventing using a resource multiple times (at most once), where linear types say you must use once & can only use once.

        • ☆ Yσɠƚԋσʂ ☆@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          2 months ago

          You’r right that only OCaml and Haskell can be used as extraction target for Coq programs. However, it is possible to use Coq to write verified C software. On example is the Verified Software Toolchain that lets you translate C programs to a format that Coq understands and can prove theorems regarding their behavior.