5 ms·

For me, the C version looks actually cleaner than the Rust one.

• kvark 8y ago
  I'm genuinely interested in why you find it cleaner, please elaborate?
  • gpm 8y ago
    Three thoughts: - The types help, seeing "WGPUSwapChainId" tells me exactly what sort of object is returned (a reference to some object held elsewhere), we don't get this in Rust because of type inference. - Rust doesn't help in this example because it's just a bunch of API calls... so it's a more complex language for nothing. Obviously this doesn't generalize. - The event handling is much simpler in the C code, this also doesn't generalize.
    • asddgsgsaxg 8y ago
      > seeing "WGPUSwapChainId" tells me exactly what sort of object is returned (a reference to some object held elsewhere) Check out RLS (the rust language server) to get intellisense like this working in your favorite editor.
      • jonathanyc 8y ago
        I think that in reviewing code this is definitely something where languages with type inference lose clarity; Rust is even worse because of the Deref/Into idioms. I think the solution is for diff viewers incl. those on the web to support something like intellisense, but obviously we are a very long way away from that.
        • devit 8y ago
          You could have the compiler produce a fully explicit version (I'm not sure if Rust can do that out of the box at the moment)
          • steveklabnik 8y ago
            ~~It can't.~~ See below, it can! I tend to find, personally, that this kind of thing doesn't interfere strongly with reviewing. I think this is because I have an extensive background in dynamically typed languages and ones with strong inference like Rust, so I'm more used to it, whereas people who don't come from said backgrounds prefer more explicitness. YMMV of course!
            • jonathanyc 8y ago
              I don’t think it’s just “strong” inference that’s the problem; I find I have an easier time reading ML because the inference somehow feels more obvious. After thinking about it some more, I think it really is deref coercion that is the gotcha, especially with function chaining.
              • steveklabnik 8y ago
                By "strong" I really mean "type inference" over "type deduction", to be clear. But yeah, I could see that.
            • Tohquai7 8y ago
              It can. -Z unstable-options -Zunpretty=hir,typed // source pub fn square(num: i32) -> i32 { num * num } // expanded use ::std::prelude::v1::*; extern crate std; pub fn square(num: i32) -> i32 ({ ((num as i32) * (num as i32) as i32) } as i32) You can try on https://rust.godbolt.org/ https://rust.godbolt.org/
              • steveklabnik 8y ago
                Oh dang! That's very cool, thank you!
    • mrec 8y ago
      > we don't get this in Rust because of type inference Might be worth mentioning that (AFAIK) type inference is entirely optional in Rust. If you prefer to write explicit types on your decls that's fine. (I suspect there are pathological cases where the type is impractical to write, but you'd have been screwed then anyway.) This won't help you when reading other people's code, obviously.
• bluejekyll 8y ago
  Is this because you’re not as familiar with Rust as you are with C? Rust has more syntactic elements than the C, in this code that’s clear, but cleanliness can mean different things. Rust has a module system, so no global namespace issues, but does require all of the :: separators. Rust has cleaner ways of dealing with cross platform compile time switches, thus we don’t see the CPP macros for different platform targets. To me, those are cleaner, but I’m familiar with Rust and C, which is why I asked.
  • alkonaut 8y ago
    I think the Rust style that uses ”constructorless” struct initialization really makes the code too verbose in this case. It’s nice and explicit in a way but having to say e.g entrypoint: ”main” as the argument for a shader program seems like it could be turned into a default. Convention over configuration isn’t always the answer, but some times at least it can help reduce clutter. In the future the api will perhaps have builders as an option.
    • flohofwoe 8y ago
      I'm not sure if the builder pattern is better than designated initialization... AFAIK in Rust you can get something similar (fill up missing members with their default values) with ..Default::default(), like: &BlaDesc { bla: 1, blub: 2, ..Default::default() }
      • masklinn 8y ago
        One annoyance of this is that you can't require fields to be explicitly provided anymore. With the builder pattern, you can do so: require them in the builder constructor.