Earlier quoted context omitted.
Fzf is written in go fwiw
Oops, looks like I misremembered. :) Thanks!
Ah, now I know what I confused it with: fd[0]. That one is written in Rust.
Leaving Rust gamedev after 3 years
991–996 of 996 posts
Re: Leaving Rust gamedev after 3 years
#992Earlier quoted context omitted.
"I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it." 100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on…
It does in my domain of systems programming with async data handling. Tokio works like a dream - slipping into the background and just working so I can concentrate on the business logic.
This seems strange to me. If you don't have millions of concurrent requests to handle at the same time, why would you bother with a whole async framework? Just straight up spawning OS threads to do parallel work when you need it is both easier to reason about and does not mess with your program's stack.
Isn't the point of async/await that spawning OS threads is not scalable when you reach ridiculous numbers of simultaneous blocking I/O? It doesn't sound like you're really dealing with this sort of problem.
Re: Leaving Rust gamedev after 3 years
#993Earlier quoted context omitted.
Threading, probably.
I don't think so, because there isn't a performance drawback compared to threads when using async. In fact there's literally nothing preventing you from using a thread per task as your future runtime and just blocking on `.await` (and implementing something like that is a common introduction to how async executors run under the hood so it's not particularly convoluted). Sure there's no reason to do that , because non…
> I don't think so, because there isn't a performance drawback compared to threads when using async.
There is. When you write async functions, they get split into state machines and units of non-blocking work which need to be added and taken from work queues. None of this has to happen if you just spawn an OS thread and tell it "execute this function". No state machine, no work queue. It's literally just another sequential program that can do blocking I/O independently of your main thread.
If you insist on implementing a thread-based solution in exactly he same way that an async solution would, then yes they'll both pay the price of the convoluted runtime. The point is, there's no need to do that.
Re: Leaving Rust gamedev after 3 years
#994Earlier quoted context omitted.
> The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?
The current popularity of the async stuff has its roots in the classic "c10k" problem. ( https://en.wikipedia.org/wiki/C10k_problem ) A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale." Putting aside that not all of use are building web applications (heterodox here in HN, I know)... Most people in the real world with real appl…
Hit the nail on the head.
Unless you're really dealing with absurd numbers of simultaneous blocking I/O, async has entirely too many drawbacks.
Re: Leaving Rust gamedev after 3 years
#995I'm a Rust enthusiast and really surprised to discover so many people are apparently trying make games in pure Rust.
I think Rust is an amazing language for building a generic game engine, but a pretty crappy one for actually implementing a finished game.
Isn't it basically standard practice to have an engine written in a systems-level language with generality, reliability and performance as the top objectives, and the game itself written in a scripting/interpreted language that allows very quick iteration?
And it can even in many cases be a pretty horrendous home-brewed language. Despite having people without the computer-science knowledge to create a good language (and yes, inventing a new language is one of these things that leads to horrible results if you just learn on the job). This structure will still get you there easier and faster than trying to implement the whole game in a systems language.
Re: Leaving Rust gamedev after 3 years
#996Earlier quoted context omitted.
> My priorities are reasonable performances and the fastest iteration time possible. I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on... // 2024-02-01 $ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l 29 // 2023-12-21 $ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l 6 // 2023-12-14 $ curl https://www.taleworlds.com/en/…
I can't really comment on the quality of the game or experience or how buggy it feels because I've never played it, but I will say that counting fixed crash situations is a somewhat arbitrary and useless metric. If each of those crashes affected and was reported by a single person or even nobody because no regular person could really encounter it is a vastly different situation than if each of those crashes was exper…
Mount & Blade 2 was released very early and despite constant improvement (they keep patching it at a strong pace), it's only slowly evolving.
It was even downright unfinished on release, with many game systems claiming to be doing something actually being simply unimplemented.
But despite all that it was and is still fairly playable and enjoyable, even at release. A game only needs a great core gameplay loop to succeed, even if large parts of it are completely broken.
Interestingly, Taleworlds make their own engine with fairly unique capabilities. 200 players can fight in fast paced, precise melee combat on a single server. Even more than in fast-paced shooters, it can be extremely frustrating for players when the game doesn't behave in exactly the way that you would expect (for example, standing undefended just a few centimeters away from the reach of an opponent's swing, or relying on interrupting their attack with your own landing 100 milliseconds before). They've made their own scripting language for everything related to policy. So this scripting language is what modders interact with. And it is absolutely atrocious as a language, but it serves the purpose well enough.