My experience has been that good documentation is mostly something done if somebody gets paid for the work. People working on stuff in their spare time just don’t care enough to document their project.

Only if they have a 100% tax rate, which I doubt.

I just checked again, and apparently they finally added some documentation since I last checked. The section about the macro stuff just used to say “look at the examples”.

clap and bevy are big offenders there. It’s really hard to learn how to use them due to this.

OP is talking about a different kind of skill issue than the article. The article is about skill issues in writing Rust code, while OP is about skill issues in choosing the right technology for the right task.

Not picking Rust for code that has to be prototyped quickly and iterated a lot is kinda obvious. The solution would be to use Rust for the core engine where the requirements are clear and something else (lua? Python?) for the gameplay code. Even the engine the author wants to switch to does the same with with the divide between C++ and C#.

Bevy’s ECS is tied up with Rust’s trait system, therefore it’s impossible to use a different language.

Bevy has added runtime-defined systems and components to enable scripting integration in recent updates.

What’s the error bar on that statement of yours?

I’d instantly reject such an approach. Find a better way to do things.

Rust had the same issue with tokio vs. async-std. I don’t think this was ever resolved explicitly, async-std just silently died over time.

My company is just doing a kanban board with weekly meetings to discuss the progress and what tickets will be worked on next. The major problem we ran into was when management asked “So, when is the release going to be? When are you done with that project?” about one month before we actually released. I simply had no answer at that point, because that’s not something these tickets with no estimates and no velocity tracking can provide.

The gleam name is also already taken by some OpenGL bindings on crates.io.

Bevy UI is so far off from what I need that I didn’t even bother. I started integrating Flutter instead.

Here is a short summary. The compile-time reflection project was stopped, and now nobody wants to touch that subject any more due to fear of getting the wrath of the Rust project again (the person responsible for the whole thing is still part of the leadership).

Unfortunately, it’s not guaranteed to be the same string all the time, so it’s rather useless for anything but debugging and logging.

No, the Rust Project recently made sure that Rust can’t have compile-time reflection.

let bar: Result<T, E> = ...;
let foo = bar.inspect(|value| log::debug("{}", value));

is equivalent to

let bar: Result<T, E> = ...;
let foo = bar.map(|value| {
    log::debug("{}", value);
    value
});

Oh, inspect has finally arrived! That will help a ton with debug logging.

I’m comfortable with debugging, but I rarely use it with Rust. With the language being so strict in everything, it’s clear most of the time what’s happening, and most situations can be resolved by simple logging of variables.

In JavaScript, I have to use the debugger all the time, since variables can get some really weird invalid values with the completely wrong type.

Necessary skills:

• Development processes: advanced git usage (like fixing history after a bad rebase, merging multiple completely divergent branches, etc), issue tracking
• Devops: continuous integration, continuous deployment, Docker (also, how to build your own Docker images out of Rust projects), Kubernetes
• Social: how to interact with coworkers without creating enemies for life

The Linux devs are hesitant to use Rust, because it doesn’t compile to all platforms Linux supports. So, it can only be used for drivers that are only useful on specific platforms that are supported by the compiler, which meant that until now it only was experimental ones like the graphics driver for Apple Silicon Macs.