After 4 years with Rust, I love the language – but I’m starting to think the ecosystem has an abstraction addiction. Or: why every Rust crate feels like a research paper on abstraction.
This to me feels like the author trying to understand library code, failing to do so, then complaining that it’s too complicated rather than taking the time to learn why that’s the case.
For example, the example about nalgebra is wild. nalgebra does a lot, but it has only one goal, and it does that goal well. To quote nalgebra, this is its goal:
nalgebra is a linear algebra library written for Rust targeting:
General-purpose linear algebra (still lacks a lot of features…)
Real-time computer graphics.
Real-time computer physics.
Note that it’s a general-purpose linear algebra library, hence a lot of non-game features, but it can be used for games. This also explains its complexity. For example, it needs to support many mathematical operations between arbitrary compatible types (for example a Vector6 and a Matrix6x6, though nalgrbra supports arbitrary sized matrices so it’s not just a 6x6 matrix that needs to work here).
Now looking at glam:
glam is a simple and fast linear algebra library for games and graphics.
“For games and graphics” means glam can simplify itself by disregarding features they don’t need for that purpose. nalgebra can’t do that. glam can work with only square matrices up to 4x4 because it doesn’t care about general linear algebra, just what’s needed for graphics and games. This also means glam can’t do general linear algebra and would be the wrong choice if someone wanted to do that. glam also released after nalgebra, so it should come as no surprise that they learned from nalgebra and simplified the interface for their specific needs.
So what about wgpu? Well…
wgpu is a cross-platform, safe, pure-Rust graphics API. It runs natively on
Vulkan, Metal, D3D12, and OpenGL; and on top of WebGL2 and WebGPU on wasm.
GPUs are complicated af. wgpu is also trying to mirror a very actively developed standard by following WebGPU. So why is it so complicated? Because WebGPU is complicated. Because GPUs are very complicated. And because their users want that complexity so that they can do whatever crazy magic they want with the GPU rather than being unable to because the complexity was hidden. It’s abstracted to hell and back because GPU interfaces are all incredibly different. OpenGL is nothing like Vulkan, which is nothing like DirectX 11, which is nothing like WebGPU.
Having contributed to bevy, there’s also two things to keep in mind there:
Bevy is not “done”. The code has a lot of churn because they are trying to find the right way to approach a very difficult problem.
The scope is enormous. The goal with bevy isn’t to create a game dev library. It’s to create an entire game engine. Compare it to Godot or Unreal or Unity.
What this article really reminds me of isn’t a whole lot of Rust libraries that I’ve seen, but actually Python libraries. It shouldn’t take an entire course to learn how to use numpy or pandas, for example. But honestly even those libraries have, for the most part, a single goal each that they strive to solve, and there’s a reason for their popularity.
@TehPers@cm0002 I guess I can somewhat empathize with the author. But you’re right, the author seems to be frustrated that some things are inherently complex. Though, Rust has terrific documentation and a lot of literature to get enough understanding to where things aren’t necessarily runes anymore, but rich in meaning.
I will say though, does nalgebra require custom derive macros? If you need to parse ast on the regular to use a library, I can definitely agree with his point on complexity.
I’m not aware of any custom derives needed to use nalgebra. I’ve never needed to write any. At most, I’ve written macro_rules! macros to help with trait impls, but not specifically for nalgebra.
I’m not too sure what the author is referring to there.
This to me feels like the author trying to understand library code, failing to do so, then complaining that it’s too complicated rather than taking the time to learn why that’s the case.
For example, the example about nalgebra is wild. nalgebra does a lot, but it has only one goal, and it does that goal well. To quote nalgebra, this is its goal:
Note that it’s a general-purpose linear algebra library, hence a lot of non-game features, but it can be used for games. This also explains its complexity. For example, it needs to support many mathematical operations between arbitrary compatible types (for example a Vector6 and a Matrix6x6, though nalgrbra supports arbitrary sized matrices so it’s not just a 6x6 matrix that needs to work here).
Now looking at glam:
“For games and graphics” means glam can simplify itself by disregarding features they don’t need for that purpose. nalgebra can’t do that. glam can work with only square matrices up to 4x4 because it doesn’t care about general linear algebra, just what’s needed for graphics and games. This also means glam can’t do general linear algebra and would be the wrong choice if someone wanted to do that. glam also released after nalgebra, so it should come as no surprise that they learned from nalgebra and simplified the interface for their specific needs.
So what about wgpu? Well…
GPUs are complicated af. wgpu is also trying to mirror a very actively developed standard by following WebGPU. So why is it so complicated? Because WebGPU is complicated. Because GPUs are very complicated. And because their users want that complexity so that they can do whatever crazy magic they want with the GPU rather than being unable to because the complexity was hidden. It’s abstracted to hell and back because GPU interfaces are all incredibly different. OpenGL is nothing like Vulkan, which is nothing like DirectX 11, which is nothing like WebGPU.
Having contributed to bevy, there’s also two things to keep in mind there:
What this article really reminds me of isn’t a whole lot of Rust libraries that I’ve seen, but actually Python libraries. It shouldn’t take an entire course to learn how to use numpy or pandas, for example. But honestly even those libraries have, for the most part, a single goal each that they strive to solve, and there’s a reason for their popularity.
@TehPers @cm0002 I guess I can somewhat empathize with the author. But you’re right, the author seems to be frustrated that some things are inherently complex. Though, Rust has terrific documentation and a lot of literature to get enough understanding to where things aren’t necessarily runes anymore, but rich in meaning.
I will say though, does nalgebra require custom derive macros? If you need to parse ast on the regular to use a library, I can definitely agree with his point on complexity.
I’m not aware of any custom derives needed to use nalgebra. I’ve never needed to write any. At most, I’ve written macro_rules! macros to help with trait impls, but not specifically for nalgebra.
I’m not too sure what the author is referring to there.