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:

1. 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.
2. 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.

I created a Nushell plugin in Rust that merely converts between Nushell and BSON data formats.

It works, but I still have a fundamental lack of understanding of the magic abstract generalized data transformation framework/interface.

I wish there were fewer magic conversions and transformations, and less required knowledge of them and calling or knowing the correct ones. Magic traits leading to magic conversions for magic reasons. Or something.

Or, borrowed from another “proverb”: Pre-mature abstraction is the root of all evil

I find that even without abstractions, code can be fairly unreadable if it goes in strong on Uncle Bob’s Clean Code ideas and you’re bouncing up and down the code/stack frames trying to see where the work actually happens.

i find this one sentence for each paragraph to be hard to read as a blog post.