Leaving Rust gamedev after 3 years

There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing.

The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest.

[0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large scale changes across your program, like changing a type everywhere. Instead, we want you to quickly discover that bad ideas won’t work, without first requiring you to propagate the type changes throughout your program."

https://blog.darklang.com/real-problems-with-functional-lang...

[1] "If you like, you can run a program that has compile-time errors like this. (If the program reaches the error at runtime, it will crash.)"

https://www.roc-lang.org/friendly

As I said above, cult-like. They will swiftly call you names if you even dare to question their beliefs. Thank you for proving me right kind sir.

If they tried to use C++ it would have ended absolutely the same way.

As someone who works in gamedev I can assure you C++ is same bad choice for 2 man indie project. In search of fast iteration times games have moved away from writing code in low level languages. Hardware for casual games is much bigger and faster than anything small team is able to make.

I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript).

So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore wrong.

* For the sake of argument, we can pretend I only know rust. In reality I know a fair number of other languages as well, but the list doesn't happen to include C# or "random game engine specific scripting language", which seems to be the options if we're going with an established engine for big 3d games.

This is a sobering read. Thank you for sharing.

This sums it up for me:

> Rust as both language and community is so preoccupied with avoiding problems at all cost that it completely loses sight of what matters, delivering an experience that is so good that whatever problems are there aren't really important. This doesn't mean "ship crap games", it means focusing on the game being a good game, not on the code being good code.

I think this can be easily extrapolated to projects outside of game development as well.

User experience is ultimately all that matters. If you're in prototyping stages of whatever it is you're building, and games spend a lot of time in this phase, then your focus should always be on testing what the user experience will be like, rather than absolute code correctness, maintainability, and everything else that makes a long-term project successful.

The fact Rust seemingly can't deliver this rapid prototyping workflow should be a large factor when deciding which language to use.

I've been using Go as my main language for the better part of a decade now, and I think it strikes the perfect balance of code quality and rapid prototyping. It's far from the side of absolute freedom of a language like Python, which becomes a nightmare to work with after the prototyping phase is over (though this might have improved in the past few years), but it's also far from languages like Rust, and allows me to be very productive, very quickly, while also being easy to pick up for newcomers. I probably wouldn't pick it for GUI or game development either, though, but for things like CLI, network and web tooling, it's perfect.