Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

311–320 of 996 posts

Re: Leaving Rust gamedev after 3 years

#311
> wait I can't add this new thing because things will no longer compile, and there's no workaround other than code restructuring

I definitely think that's a great feature. I want to learn on day 2 that the design is a dead end, not on day 101 when I ship on day 100 and there was a race condition on day 2 I never noticed.

But the thing about gamedev (I guess - I'm not a game developer) is that the code being great and doing what you hope it will do isn't 100% of the job as it is in other disciplines. In gamedev you may want to run the code, and the way it runs (fun, feel, whatever) might be bad even though it compiles, works according to a spec and so on. So while I'm usually happy to write code for a week and never run it - game development feels like it's all about the iteration.

That said, game development is also game engine development. And Rust seems absolutely perfect for engine development (you need "fearless" concurrency and performance and there are zero mainstream languages that will do that other than rust). For people who feel it's too rigid or hard to iterate with perhaps hybrid could work. Like Rust + Lua or something sounds like it could be worth trying.

Re: Leaving Rust gamedev after 3 years

#312

I've become wary of commenting on articles that mention the pros and cons of various languages, but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on. When it should be the other way around. The joke he mentioned about having 50 engines written but only 5 games certainly rings true and I d…

The hardest part of a project is finishing it. I think the main issue is the fun problems to solve happen very early in the project and once those are done it becomes incredibly tedius and boring and I usually lose focus until the project dies. Its difficult to maintain motivation.

Right. If someone could come up with a pill or something to maintain motivation and make all the bugs and hairy annoying details feel fresh again, just like the feeling of starting over, I would certainly part with my money. But there's no such thing unfortunately.

Re: Leaving Rust gamedev after 3 years

#313
Oh my, this has to be my favorite quote in a blog in a long long time.

"... many if not most of the problems don't go away if one isn't willing to constantly refactor their code and treat programming as a puzzle solving process, rather than just a tool to get things done."

I have thought it was just me for a long time, but many of the popular styles of programming that we push definitely seem to require constant refactors in the pursuit of a solution. And I definitely see more tire spinning for the sake of the build than I do for whatever it was folks were building.

Great quote.

Re: Leaving Rust gamedev after 3 years

#314

Earlier quoted context omitted.

Exactly, it's all about the ecosystem and very little about the language features

Disagree the adoption of C++ was more about Moore's law than ecosystem, although having compilers that were beginning to not be completely rubbish also helped.

Also C++ could be adopted incrementally by C developers. You could use it as “C with classes”, or just use operator overloading to make vector math more tolerable, or whatever subset that you happened to like.

So there’s really three forces at play in making C++ the standard:

1) The Microsoft ecosystem. They literally stopped supporting C by not adopting the C99 standard in their compiler. If you wanted any modern convenience, you had to compile in C++ mode. New APIs like Direct3D were theoretically accessible from C (via COM) but in practice designed for C++.

2) Better compilers and more CPU cycles to spare. You could actually count on the compiler to do the right thing often enough.

3) Seamless gradual adoption for C developers.

Rust has a good compiler, but it lacks that big ticket ecosystem push and is not entirely trivial for C++ developers to adopt.

Re: Leaving Rust gamedev after 3 years

#315
post #48

I find that Jonathan Blow ranting about Rust game development here https://www.youtube.com/watch?v=4t1K66dMhWk . He adds interesting perspectives to the discussio, how the language makes the Rust game developer resort to arrays and their so called Rust point of views.

Well the problem with Jonathan's argument here is that he's spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games. So it turn out that even if he's opinion on Rust is correct, he would still have been much more productive using it than trying to build his own language for a decade… (But he already shipped his masterpiece and he's a millionaire…

I mean, he does like a good rant lol. But this seems like a bad take. The witness came out ~8 years ago, and Braid came out ~8 years before that. Braid Anniversary is launching next week, he's actively developing his language and next game (occasionally streams). "he's just resting on his laurels now" I think is clearly wrong

Re: Leaving Rust gamedev after 3 years

#316
post #154
post #28

This article describes almost exactly why I think gradual typing is actually a good thing. Type checkers shouldn't get in the way of your code compiling. Yes, the language has to be designed with this property from the beginning. Yes, you should always enforce complete checking in CI. But you should also be able to try half-baked ideas.

> Type checkers shouldn't get in the way of your code compiling. I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed. I understand (and have used in produ…

>I don't get it, what's the point of type checking if not to reject invalid programs?

Because not every program that doesn't compile is necessarily invalid.

Re: Leaving Rust gamedev after 3 years

#317
post #299

As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Usin…

I mean, if you agree that the ideal for bevy would be lua integration, you are kinda agree with the author that Rust itself is suboptimal (at least in layer of game scropting), don't You?

I think whether you prefer Rust or a scripting language like Lua for high-level game logic comes down to what your needs are and personal preference. There are reasonable arguments on both sides.

Re: Leaving Rust gamedev after 3 years

#318

Excellent article. Rust is my favorite language for several uses, but I'm becoming less optimistic about it as a versatile language long-term. An important point regarding the article is that it mixes rust shortfalls, and shortfalls of any language other than C++ for games. I've personally used Bevy for a 3D wave function renderer, but moved away from it in favor of a custom WGPU-engine due to Bevy's complicated ECS…

I think the async Rust shortcomings are largely solvable, but I sympathize with everyone running into the numerous problems right now.

Re: Leaving Rust gamedev after 3 years

#319
post #187

Starting by saying I fundamentally agree wrt iteration speed. This is ultimately why [C/C++]/Lua was such a thing for a while, and it seems quite plausible that you could benefit from a core engine in rust bound to a scripting language. But ultimately I sense the subtext here is much the same as with other Rust problems: the object oriented baby has been thrown out with the bathwater, often in the name of premature o…

> but also with a sense of misplaced religious purity regarding the evils of state To clarify, Rust isn't against state at all. Rust bends over backwards to make mutation possible, when it would have been far easier (and slower, and less usable) to have a fully-immutable language. What Rust is against is global mutable state, and an aversion to global mutable state isn't a religious position, it's a pragmatic positio…

[deleted]

Re: Leaving Rust gamedev after 3 years

#320
post #47

Earlier quoted context omitted.

Since every other language now has higher order functions and lexical closures and things like that Lisp isn't as special as it used to be. Now it's mostly just a really ugly version of those languages but with a weird emphasis on recursion and a very fancy macro facility. I find I can move between dynamic languages and Scheme pretty easily.

as someone who writes elixir all day, I really love what lisp is but I feel lisp's major weakness is that it makes everythign unergonomic in order to make macros very ergonomic. You will never find another language in which writing macros is easier. the problem is it comes at the cost of doing everything else a bit of a pain in the ass. I love elixir because it feels like the syntax clojure would have if it had a syn…

> major weakness is that it makes everythign unergonomic in order to make macros very ergonomic.

Generally Lisp has two main goals:

* allow code to be data and data to be code

* make coding and coding code (let code manipulate code) interactive

The s-expression based syntax was found to be useful for both. For the latter it means that code can be manipulated interactively for example by structure editors or in read-eval-print-loops which work with data. That makes interactive code writing very ergonomic.

Post reply on HN