The Rust implementation is also faster than the newer stb library even though it copied stb's SIMD code.
This Rust library dates back to 2014, which is like K&R C for Rust. That was before Rust 1.0.0 release, before Rust had any SIMD support, before Rust had noalias support.
But with the safety guarantees, and painless testing and benchmarking tooling, Rust codebases are easier to refactor and evolve.
A fourth hack may still be better than having to develop the four features on top of a wrong abstraction.
If you end up having a poorly fitting abstraction, then you'll be spending extra effort on doing things "properly", but not really getting any benefit out of it. You just loose the agility of hacking things quick'n'dirty, or you end up hacking around the bad abstraction, and get worst of both worlds.
The rest depends on having management that understands trade-offs between doing things properly and efficiently long-term vs getting stuff out of the door quickly (if you're a startup with a short runway, or racing to be the first to win some opportunity, shipping ugly hacks now may be the only way to survive to even have "later" to worry about).
That may be true, but it’s still a problem if you can never create new abstractions, because that prevents you from creating good abstractions too, not just bad ones.
When search is cheap and quick, it's possible to improve search by postprocessing search results and running more queries when necessary.
I use Tantivy, and add refinements like: if the top result is objectively a low-quality one, it's usually a query with a typo finding a document with the same typo, so I run the query again with fuzzy spelling. If all the top results have the same tag (that isn't in the query), then I mix in results from another search with the most common tag excluded. If the query is a word that has multiple meanings, I can ensure that each meaning is represented in the top results.
Frustrating that almost nothing else has. In particular Ninja has been dragging its feet on this for most of a decade (they have an epic GitHub feature request and like six submitted attempts, none merged). All the "build system" components in the ecosystem want to be the Root of all Execution and don't feel like they should have to play in a sandbox with their competitors.
Really, the older I get and the more I see of the cmake/ninja/Bazel/whatever world... GNU Make was a better tool even 20 years ago.
There's a lot to hate about make, but looking for good alternatives there are very, very few out there and none of them provided anything extra I was looking for.
The one thing I wish were possible (trivially) in make, and I understand why it's not, is the ability to define a dependency not on whether a file exists or not but on the result of executing a process.
For example, do I need to rebuild this docker container? The current method to determine that is to create a stamp file; create the docker container then `touch .docker-image-created.stamp`. Unfortunately, those stamps can become out of date if the docker container is removed (or old, etc.) so it leads to confusing situations where make's interpretation of the current state is separate from the reality, and in large complex projects where there are lots of interconnected parts, sometimes your only feasible route is to remove everything and completely rebuild from scratch.
There's also an inexplicable lack of debugging output insofar as printing what target make is currently running. It has a ton of debug output, but no option I can find that says "I am running this target right now", "okay I'm done this target now" without manually adding $(info ...) statements to your makefile.
Rust's exclusive ownership can be used for things that can be called at most once (a method can require a non-copyable object as an argument, and takes ownership of it away from you, so you can't call the method again).
Rust also has wrapper types like OnceCell that have `get_or_init()` which will init the thing only once, and then it's guaranteed to be immutable. Unlike singletons, these don't have to be globally accessible.
The strong criticism Rust got in this area is being poorly suited for rapid throwaway prototyping. I think that's fair — slow compile times and language's focus on writing things properly on the first try are the opposite of what you want when trying out random ideas and seeing what sticks. I think that may be fixable. Partly it's a skill issue (with enough experience, you can cut corners when you known which ones to cut). Partly it could be improved by tooling for hot reloading, and perhaps a scripting language integrated with Rust.
In Bevy in particular almost everything happens through ECS, and the ECS has a Reflection API, so you can hook it up to whatever you want, and manipulate it from any language.
I also wonder what about the rest of the game development lifecycle. Games are taking many years to develop, and not all of that is quick exploration. The more of the game starts taking shape, the more you actually need stuff to work. You need ability to refactor, polish, and extend the implementation without breaking things. You need to be fixing gameplay bugs, not wasting time on hard-to-reproduce crashes.
Before Rust, C was my preferred language. It's really hard to talk about Rust in a way that doesn't sound like talking trash about C, because Rust's main reason to exist is preventing safety issues that… people programming in C usually say are not C's fault, so there's nothing to fix there.
The other aspect is that Rust has been developed recently, and didn't have to deal with all the legacy constraints of C. The features that Rust has would be mostly boring compared to modern GC or scripting languages, but they're notable for being in a language that can be as low-level as C. Comparing them directly to C does like trashing C — namespaced modules instead of textual inclusion, macro preprocessor based on AST (do-while tricks not needed), no headers, no need for build scripts in most programs, package management that works on Windows and macOS too, etc. Many other languages have this stuff, but C doesn't, so they're an interesting upgrade from C just because C is so old.
This Rust library dates back to 2014, which is like K&R C for Rust. That was before Rust 1.0.0 release, before Rust had any SIMD support, before Rust had noalias support.
But with the safety guarantees, and painless testing and benchmarking tooling, Rust codebases are easier to refactor and evolve.