Rust's Low-Level Graphics Abstraction Layer Is Showing A Lot Of Potential

[kpedersen]

So if it is actually backed by Mozilla, it is much closer to being part of the "standard library"? Like Java's javax.swing?

C/C++ is certainly missing this but I understand completely the difficulties in actually adding one to the spec so it will be quite interesting to see how this turns out with Rust. I predict that in about 10 years when GFX-RS is old and crusty, it will really cause issues to replace and modernise without lots of breakage.

[GunpowaderGuy]

jacob from what i have heard , they abandoned the safety to increase performance ; which makes one wonder why just not use vulkano and have both and not introduce yet another completly new api

[GunpowaderGuy]

To me it seems gfx rs was born out of incorrect assumptions ; that a new api would be needed to map over the different low level native ones, and that speed has to come at the price of safety

[TheOne]

Maybe the future of game development will shift to Rust...

[RahulSundaram]

jacob from what i have heard , they abandoned the safety to increase performance ; which makes one wonder why just not use vulkano and have both and not introduce yet another completly new api

Where is the source for the claim that they have abandoned safety?

[GunpowaderGuy]

RahulSundaram https://gfx-rs.github.io/2017/07/24/low-level.html

[emblemparade]

Nobody who cares about open source and open standards should support Metal. I suggest they remove direct Metal support and only support Metal indirectly via MoltenVK. Apple should not be rewarded for their aggression.

Thank you for considering my suggestion.

[ssokolow]

So if it is actually backed by Mozilla, it is much closer to being part of the "standard library"? Like Java's javax.swing?

C/C++ is certainly missing this but I understand completely the difficulties in actually adding one to the spec so it will be quite interesting to see how this turns out with Rust. I predict that in about 10 years when GFX-RS is old and crusty, it will really cause issues to replace and modernise without lots of breakage.

Because it integrates so well with Cargo, Rust doesn't even include parts of its standard library in the standard library. (I always like to point to how crates like rand and regex are maintained by the Rust maintainers, but are distributed as separate crates so that, among other reasons, they can be versioned and depended on independently from libcore and libstd.)

jacob from what i have heard , they abandoned the safety to increase performance ; which makes one wonder why just not use vulkano and have both and not introduce yet another completly new api

Reading that, I get the impression that they're aiming to reduce duplicated effort in the ecosystem by becoming an analogue to -sys crates to be shared by people who want to write higher-level crates.

(When writing bindings for a libfoo C library in Rust, it's standard practice to produce a libfoo-sys crate which merely provides a highly-unsafe, minimal-thickness adaptation of the C library's API to equivalent Rust language constructs and then wrap it in a foo crate which provides a higher-level safe Rust API.)

[GunpowaderGuy]

ssokolow what disqualifies gfx rs from such a venture , is that it needlesly reinvents the wheel . Its creator thought vulkano could now use it as a backend , but that library would be better off using no, or a completly zero cost and vulkan specific ( read thin ) wrapper ; and a compatibility layer only when neccesary

[Serafean]

Did I misread something? They are creating a yet another new low level api? Instead of just using vulkan and coverting to/from that if on mac?

No, you read it right. This is the basic information.
As for Rust idioms and safety is in play, and what good it brings, that remains to be seen...