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.

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.

The idea is that these rules just do what you’d expect the language to do in those situations. The additional advantage of Rust is that if you’re wrong, the consequences are just a compilation error, not a crashing program.

Please don’t use pointers in Rust!

Anyways, my feedback:

Your http module just wraps another inline module, this is unnecessary. Usually inline modules are only useful for tests. Your readline implementation doesn’t account for systems with two-character line endings (Windows and DOS) and I’m also unclear on why you need that for stdin.

Concerning http in the standard library, Rust has learned from the mess in python, which has multiple implementations in the standard library that are all outdated but can’t be updated due to needing to handle backwards compatibility. Rust only has the basic stuff there, and handles other needs by external dependencies, which are managed by a great package manager (again, unlike python) on crates.io.

In my case, it was in Dart. Dart allows extending existing classes with new methods, but unfortunately this doesn’t allow implementing abstract mixins (which is the equivalent of Rust’s trait) on other types. Dart is in this weird middle where it’s not really strictly typed (it has dynamic, which is like the any type in TypeScript), but the compiler doesn’t allow ducktyping anyways.

I recently caught myself trying to do traits in an OOP language. Failed spectacularly of course.

But it would be so much easier to read…

I stopped worrying about this when I had a project with two async runtimes (tokio and bastion) and it worked fine without any special setup.

I used parking_lot back then.

As someone who has tried doing multithreaded design with Arc/Mutex, this is a complete nightmare. You constantly get into deadlocks and performance is abysmal, because Mutex is serializing access (so it’s not really async or multithreaded any more).

Tokio handles that through feature flags.

tokio uses thread pools for scheduling async tasks, which generally is what you want (because spawning threads is expensive and can lead to DoS vulnerabilities).

If you block in an async task, the thread the task is running on is no longer available to other async tasks. If you have the same amount of tasks currently blocking as you have threads, the whole system grinds to a halt.