A New High-Performance, Bindless Graphics API Comes To Rust

[bjz_]

Is there a reason why you're using u32s for the Handles?
If a backend were to use opaque objects as handles instead of numbers, wouldn't that cause unnecessary indirection?

Yeah, this is one of the reasons why we are not ready for the publicity yet - we are still waiting for associated types to finish being implemented (slated for 1.0, so should be soon). This should make the device API much cleaner and more flexible.

[mark45]

If it translates to GL it cannot really improve on it much.

Yes, it can't possible do anything better, I guess it just chooses the best API options available (one can do the same thing in GL in different ways) and wraps it into an abstraction layer.

Anyway, it's only good for a transitional period (if at all) between GL and GLNext, or for a long period if GLNext fails, which is unlikely.

[CrystalGamma]

Yeah, this is one of the reasons why we are not ready for the publicity yet - we are still waiting for associated types to finish being implemented (slated for 1.0, so should be soon). This should make the device API much cleaner and more flexible.

But aren't associated types just syntactical sugar (meaning you can do anything they can do already)?
But I'm glad I'm not the first to think about this.

[cmr~]

But aren't associated types just syntactical sugar (meaning you can do anything they can do already)?
But I'm glad I'm not the first to think about this.

No, associated types in their complete form in Rust are a particular instance of a more general type system feature called "type families", which are essentially type-level functions. This is the distinction between an "output" type and an "input" type. For example:

trait A {
    type B;
}

A is an input type, and B is an output type. A particular instance of A uniquely determines B. You can't emulate this with Rust's existing type system, you'd need to also be generic over all possible B, and it interacts with "multiparameter type classes" (which we just call multidispatch) in ways that conspire towards very nice APIs. You're right that associated types alone are merely sugar. See this section of the RFC for more details.

[bjz_]

Yes, it can't possible do anything better, I guess it just chooses the best API options available (one can do the same thing in GL in different ways) and wraps it into an abstraction layer.

Anyway, it's only good for a transitional period (if at all) between GL and GLNext, or for a long period if GLNext fails, which is unlikely.

Bear in mind you also get static type and memory safety. And with the emergence of lower level GPU APIs like Mantle, we could bypass OpenGL completely.

[Szzz]

Yes, it can't possible do anything better, I guess it just chooses the best API options available (one can do the same thing in GL in different ways) and wraps it into an abstraction layer.

Anyway, it's only good for a transitional period (if at all) between GL and GLNext, or for a long period if GLNext fails, which is unlikely.

Rust itself (and it seems that this library in particular) is all about catching most errors at compile time and provide a lot of guaranties about generated code. Rust e.g. gives guaranty that there are no data races in compiled executable (unless you are using unsafe keyword). With OpenGL it is easy to mess up something, e.g. you can forget to provide necessary parameters for a shader and it will only become apparent at run-time. With this library you will probably get compile time error.