News for hackers. Stuff that matters.
Re:The rise of wgpu by bluejekyll on Thursday March 07, 2019 @09:15AM (#19328113)
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.

Re:The rise of wgpu by alkonaut on Thursday March 07, 2019 @12:49PM (#19330229)
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.

Re:The rise of wgpu by flohofwoe on Thursday March 07, 2019 @01:02PM (#19330371)
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()
    }
Re:The rise of wgpu by masklinn on Thursday March 07, 2019 @01:31PM (#19330684)
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.