Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

641–650 of 996 posts

Re: Leaving Rust gamedev after 3 years

#641

Earlier quoted context omitted.

Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.

Haha. Nope. Maybe Nim, V*, Go*, or Elixir would be a better choice for such a use-case. * So fast, they really don't need HCR.

HCR provides changing things while th game is running in it's current state. fast recompile does not.

Start game, wait for engine to initialize, select level, wait for it to load, move player or camera to desired location. Now iterate on something at that location via HCR. If you have to recompile and restart the game you're not going to have fast iteration

Re: Leaving Rust gamedev after 3 years

#642
post #46

> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot. My experience was instantly terrible. Slow compile times and iterations, huge pack…

> Rust game development feels like a solution looking for a problem to fix. The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that…

This is not necessarily a bad thing. Especially given that Rust is an immediate upgrade with no downsides when moving away from C or C++. It is easy to see with people never wanting to go back, which also involves getting companies and products to adopt it as you would otherwise be forced by the market to work with inferior tools.

As a counterexample, .NET suffers a lot from the lack of evangelism - big chunk of community that started out back in .net framework days still thinks of it as poorly as people outside the ecosystem because they never bothered to drop old and obsolete tools and targets and give new versions a proper try (as the code is often vastly simplified and performance is vastly better).

Other programming languages, not only Rust, also do better at self promotion - take for example Go that managed to convince everyone to put it in the same bucket as Rust (which, personally, I find absolutely insulting as C# is a much closer alternative to Rust both in performance, features and access to low-level bits).

Re: Leaving Rust gamedev after 3 years

#643
post #265
post #109

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 go…

> User experience is ultimately all that matters. It should be but current state of web will show you that it is often not.

Really? Why web?

Re: Leaving Rust gamedev after 3 years

#644

Earlier quoted context omitted.

I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community. Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.

If it helps, they can't possibly be as toxic as Lisp programmers used to be, where more or less any online conversation would start with someone new asking a question and Erik Naggum replying that they were a moron who should die.

"toxic" is also to generalize from one person / one forum, to an extremely diverse group, many which never used Usenet

Re: Leaving Rust gamedev after 3 years

#645

Earlier quoted context omitted.

I've been playing around with an idea about OOP for awhile, not sure if it'll ring true or not but I'll run it up the flagpole for feedback. I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is . But when you're creating models of the world it's usually really conv…

It's not hard/fast but I would tend to agree with an approximation of this. Back when I worked properly on big games the UI libs would often be trees of widgets with injectable functions for modifying the rendering, which is actually one of the points in this blog the writer would like. (The UI lib of classic Sims was exactly like that). These days the stuff I've done, although entirely in JS, at https://luduxia.com/…

>Much of the anti-OOP noise is the result of people that have suffered from others creating hierarchies of the world too literally.

I think one of the problems is that a heirarchy is inherently opinionated. You have to choose the criteria around how to group the objects/nodes in your graph and that criteria is context-dependent. The example I've used with animal taxonomy is grouping your objects via things you can eat vs things you can pat. Thsoe are two very different graph structures of the same group of objects and if you started with one then realized you need to change, how you use your objects you're gonna have a bad time. Multiple inheritance is the bandaid solution that usually comes with more hassle than it's worth.

Building a UI is a good example of a heirarchical structure where you know exactly how you want to use your objects and how they'll relate to each other, Not having access to that programming structure would be frustrating and just feel like a loss. But I've also done multiple large refactors of Python projects because I relied on OO inheritance models that turned out to not be quite the right implementation. In those situations, Rust traits are a breath of fresh air for offering the right kind of polymorphism.

Re: Leaving Rust gamedev after 3 years

#646
Rust is good for software following a strict spec and design doc. A lot of what I do is exploratory in nature. Rust sucks there, fighting me. Best kind of languages in those cases are Lisp, Python and (unironically) C with Visual Studio debugger.

Re: Leaving Rust gamedev after 3 years

#647
post #46

> Rust gamedev ecosystem lives on hype I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot. My experience was instantly terrible. Slow compile times and iterations, huge pack…

Just a small addition: Godot also has great C# support. It is a real charm to work with.

Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.

Re: Leaving Rust gamedev after 3 years

#648

I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#. It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year. Also for ECS... one thing I tended to realize is that when developing a game…

Many people are choosing Rust because they want to use Rust. Rust has the reputation being "the best" programming language: Fast, safe, reliable, modern. I can rely on that very much. Who wouldn't like the feeling of using the best tech for their project.

What many overlook is that using Rust has very high costs, but the edge over alternative languages is often only marginally - depending on the use case of course.

Those costs of Rust get in the way of developing the actual product. You loose speed, efficiency, but potentially gain no benefit to the users of your product.

Re: Leaving Rust gamedev after 3 years

#649

I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants I have a simple question that maybe someone smarter than me can answer confidently: If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose? Originally, I prototyped something out using React, PixiJS, and ReactPixi ( https://github.com/M…

If you're targeting the browser first why not use a browser first library like PhaserJS [0]?. I don't see a reason to work around with WASM; HTML5 canvas might be everything that you need. [0] https://phaser.io/

I'm aware of Phaser and evaluated it, but didn't try prototyping something out using it.

My primary concerns were: lack of any coherent plan towards supporting WebGPU, TS bindings being best effort rather than being written natively in TS, and, crucially, Phaser4 being stuck in development hell.

Phaser 4 was announced in 2019, https://www.patreon.com/posts/28467752, and hasn't shipped. Current version on GitHub is v3.8. It made me deeply uncomfortable planning to build ontop of an engine that's stalled out for 5 years. I would not reasonably expect to be given support for WebGPU ever and I strongly feel that WebGPU is going to be the defining way web games are written in the coming year(s).

I also wasn't able to find any super compelling games written using Phaser. Since I evaluated it, it appears that Vampire Survivors was written using it, but then they abandoned Phaser and adopted Unity in v1.6.

Re: Leaving Rust gamedev after 3 years

#650
post #560

Earlier quoted context omitted.

Definitely makes code harder to reason about.

If you were to write the same code without using async you'd be trudging through a mess of callbacks and combinators. This is what writing futures code before 2018 was like. It was doable if you needed the perf but it sucked. Async is a huge improvement to readability and reasoning that we didn't have before.

No, actually that was just javascript. Programming environments with threading models don't have to live that way. Separate threads can communicate through channels and do quite well for themselves. See how it works is, you do something like let data = file.read(); and the it just sits there on that line until the read is done and then your data has the actual bytes in it and you just use them and go on with your life.
Post reply on HN