142
'Rust makes coding fun again': Why Linux is moving away from C, according to Greg Kroah-Hartman (www.zdnet.com)
submitted 3 months ago by to c/rust@programming.dev
63 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 3 months ago (9 children)

You can trivially use C libraries in Rust, or any system language that supports the C ABI for that matter, and this includes many hobbyist languages. Zig is not special.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 3 points 3 months ago (2 children)

    No Zig definitely is special. You don't have to do any extra busy work to call C code - you can pretty much just #include the header and that's that. It's similar to calling C from C++.

    In any other languages - including Rust - you have to do some work declaring functions, wrapping them and so on. It's not hard but it definitely is a non-zero amount of tedious work (especially before AI). There's absolutely no way you could describe it as "trivial", unless someone else has already done that work for you.

    But I don't think it is a significant Zig advantage really. When I'm writing Rust, it's extremely rare that I want to call any C code that someone else hasn't already done the tedious wrapping for.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago (5 children)

    zig is a bit special in this regard though as it is a c compiler not just using ffi. this means you could swap out gcc, make autotools etc and drop in zig with a build.zig. mostly useful if you want to migrate large code bases as you can incrementally port the parts you want.

    if you're picking it up for a new project then yeah this probably doesn't impact you much.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 3 months ago (4 children)

    a c compiler not just using ffi.

    Beyond what amounts to a packaging difference, what does that even mean?

    How do you think zero-cost C ABI support (including fully working cross-lang LTO) works in lang implementations that have that? And how do you think that's different from what Zig gives you?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 3 months ago (3 children)

    from rust docs:

    Note: “Zero-cost” means zero runtime cost, not zero compile cost. The compiler does real work — monomorphization and inlining — to make abstractions disappear, and that work shows up as longer build times. See Reducing Compile Time for the trade-off.

    most of the benefits come from a shared code base, one compiler (which is insanely fast with incremental rebuilds and can watch files for changes) means changes in the c code reflect in a single build step within seconds. the benefit is primarily for the developer as the compiler output should be relatively similar.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] -1 points 3 months ago (2 children)

    That has nothing to do with what we were talking about. And in any case:

    insanely fast

    Needs qualification vs. other languages for binaries with comparable runtime performance.

    (Hint: you will be surprised.)

    with incremental rebuilds

    Not special or unique.

    and can watch files for changes

    Not only not special, but literally exists in all workable build tools. bindgen+build.rs is the Rust version of this.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago (1 child)

    I'm not sure what you're talking about then, in zigs case you don't need an exposed ABI to use existing c code?

    in terms of performance it will always be ambiguous as implementations are hard to compare across languages, however they use llvm as an alternative to support architectures as they build out their native compiler. in the transition for x86_64 they were seeing up to 70% increase in compile speeds. its still ambiguous as its dependent on their implementation of llvm, though its such a large increase it is still meaningful.

    but i say all this as a rust and zig advocate where i would happily choose either over the the majority of alternatives.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 3 months ago

    exposed ABI

    ABI is not something that gets "exposed" or not.

    it will always be ambiguous as implementations are hard to compare across languages

    Correct.

    in the transition for x86_64 they were seeing up to 70% increase in compile speeds

    And that was a part of what I was hinting at, because you get >>70% speed-up with Cranelift in most Rust projects. But in either case, faster code generation is not free lunch, hence the mention of comparable runtime performance of generated binaries.

  • permalink
  • fedilink
  • source
  • parent