42 ms·

Migrating away from Rust

• meisel 1y ago
  Aren't there some scripting languages designed around seamless interop with Rust that could be used here for scripting/prototyping? Not that it would fix all the issues in that blog post, but maybe some of them.
• k__ 1y ago
  Good for them. From a dev perspective, I think, Rust and Bevy are the right direction, but after reading this account, Bevy probably isn't there yet. For a long time, Unity games felt sluggish and bloated, but somehow they got that fixed. I played some games lately that run pretty smoothly on decade old hardware.
• byearthithatius 1y ago
  Love to have this comparison analysis. Huge LOC difference between Rust and C# (64k -> 17k!!!) though I am sure that is mostly access to additional external libraries that did things they wrote by hand in Rust.
  • nh2 1y ago
    The article says it's 64k -> 17k.
    • Ygg2 1y ago
      That's not unexpected they went from Bevy which is more of a game framework, than a proper GUI engine. I mean, you could also write how we went from C# code 1mil code of our mostly custom engine to 10k in Unreal C++.
    • byearthithatius 1y ago
      Updated, good catch haha
  • CharlieDigital 1y ago
    C# is a very highly underrated (and oft misunderstood) language that has become more terse as it has aged -- in a very good way. C#'s terseness has not come at the cost of its legibility and in fact, I feel like enhances it in many cases. > The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. This is also a highly underrated aspect of C# in that its surface area has largely remained stable from v1 (few breaking changes (though there are some valid complaints that surface from this with regards to keyword bloat!)). So the historical volume of extremely well-written documentation is a boon for LLMs. While you may get out-dated patterns (e.g. not using latest language features for terseness), you will not likely get non-working code because of the large and stable set of first party dependencies (whereas outdated 3rd party dependencies in Node often leads to breaking incompatibilities with the latest packages on NPM). > It was also a huge boost to his confidence and contributed to a new feeling of momentum. I should point out that Blake had never written C# before. Often overlooked with C# is its killer feature: productivity. Yes, when you get a "batteries included" framework and those "batteries" are quite good, you can be productive. Having a centralized repository for first party documentation is also a huge boon for productivity. When you have an extremely broad, well-written, well-organized standard library and first party libraries, it's very easy to ramp up productivity versus finding different 3rd party packages to fill gaps. Entity Framework, for example, feels miles better to me than Prisma, TypeORM, Drizzle, or any option on Node.js. Having first party rate limiting libraries OOB for web APIs is great for productivity. Same for having first party OpenAPI schema generators. Less time wasted sifting through half-baked solutions. > Code size shrank substantially, massively improving maintainability. As far as I can tell, most of this savings was just in the elimination of ECS boilerplate. C# has three "super powers" to reduce code bloat which is its really rich runtime reflection, first-class expression trees, and Roslyn source generators to generate code on the fly. Used correctly, this can remove a lot of boilerplate and "templatey" code. --- I make the case that many teams that outgrow JS/TS on Node.js should look to C# because of its congruence to TS[0] before Go, Java, Kotlin, and certainly not Rust. [0] https://typescript-is-like-csharp.chrlschn.dev/ https://typescript-is-like-csharp.chrlschn.dev/
    • smittywerben 1y ago
  • bob1029 1y ago
    > I am sure that is mostly access to additional external libraries that did things they wrote by hand in Rust This is the biggest reason I push for C#/.NET in "serious business" where concerns like auditing and compliance are non-negotiable aspects of the software engineering process. Virtually all of the batteries are included already. For example, which 3rd party vendors we use to build products is something that customers in sectors like banking care deeply about. No one is going to install your SaaS product inside their sacred walled garden if it depends on parties they don't already trust or can't easily vet themselves. Microsoft is a party that virtually everyone can get on board with in these contexts. No one has to jump through a bunch of hoops to explain why the bank should trust System or Microsoft namespaces. Having ~everything you need already included makes it an obvious choice if you are serious about approaching highly sensitive customers.
    • CharlieDigital 1y ago
      Hugely underrated aspect of .NET. If a CVE surfaces, there's a team a Microsoft that owns the code and is going to patch and ship a fix.
    • bunderbunder 1y ago
      I worked in a regulated space at one time, and my understanding is that this is a big reason they chose .NET over Java. Java relies a lot more on third-party libraries, which makes getting things certified harder. Log4shell was a good example of a relative strength of .NET in this area. If a comparable bug had happened in .NET's standard logging tooling, we likely would have seen all of the first-party .NET framework patched fairly shortly after, in a single coordinated release that we could upgrade to with minimal fuss. Meanwhile, at my current job we've still got standing exceptions allowing vulnerable version of log4j in certain services because they depend on some package that still has a hard dependency on a vulnerable version, which they in turn say they can't fix yet because they're waiting on one of their transitive dependencies to fix it, and so on. We can (and do) run periodic audits to confirm that the vulnerable parts of log4j aren't being used, but being able to put the whole thing in the past within a week or two would be vastly preferable to still having to actively worry about it 5 years later. The relative conciseness of C# code that the parent poster mentioned was also a factor. Just shooting from the hip, I'd guess that I can get the same job done in about 2/3 as much code when I'm using C# instead of Java. Assuming that's accurate, that means that with Java we'd have had 50% more code to certify, 50% more code to maintain, 50% more code to re-certify as part of maintenance...
• gbuk2013 1y ago
  Don’t see any content on that article for some reason (from iPhone)
  • maartenscholl 1y ago
    I experienced the same, I had to disable my adblocker to view it, it seems the content is inside a tag `<article class="social-sharing">` but I am unsure whether this triggered my adblocker.
  • janice1999 1y ago
    Adblocking seems to cause issues with the site. Disabling uBlock Origin worked for me as did readability mode in Firefox.
  • deleted 1y ago
    [deleted]
• WesolyKubeczek 1y ago
  Somehow I can't read this with uBlock Origin on. Hm.
  • ryanisnan 1y ago
    Strange, I had no such issue.
    • nottorp 1y ago
      Me neither. Default uBlock Origin settings though, maybe the OP is more strict.
• nu11ptr 1y ago
  I did the same for my project and moved to Go from Rust. My iteration is much faster, but the code a bit more brittle, esp. for concurrency. Tests have become more important. Still, given the nature of what my project is (APIs and basic financial stuff), I think it was the right choice. I still plan to write about 5% of the project in Rust and call it from Go, if required, as there is a piece of code that simply cannot be fast enough, but I estimate for 95% of the project Go will be more than fast enough.
  • akkad33 1y ago
    Is calling Rust from Go fast? Last time I checked the interface between C and Go is very slow
    • dralley 1y ago
      Rust is no different from C in that respect.
    • dangoodmanUT 1y ago
      it's reasonably fast now
    • spiffyk 1y ago
      I have no experience with FFI between C and Go, could anyone shed some light on this? They are both natively compiled languages – why would calls between them be much slower than any old function call?
      • fsmv 1y ago
        There's some type translation and the Go runtime needs to turn some things off before calling out to C
      • atombender 1y ago
        There are two reasons: • Go uses its own custom ABI and resizeable stacks, so there's some overhead to switching where the "Go context" must be saved and some things locked. • Go's goroutines are a kind of preemptive green thread where multiple goroutines share the same OS thread. When calling C, the goroutine scheduler must jump through some hoops to ensure that this caller doesn't stall other goroutines on the same thread. Calling C code from Go used to be slow, but over the last 10 years much of this overhead has been eliminated. In Go 1.21 (which came with major optimizations), a C call was down to about 40ns [1]. There are now some annotations you can use to further help speed up C calls. [1] https://shane.ai/posts/cgo-performance-in-go1.21/ https://shane.ai/posts/cgo-performance-in-go1.21/
• runjake 1y ago
  https://archive.is/6gTdc https://archive.is/6gTdc
• ryanisnan 1y ago
  This seems like the right call. When it comes to projects like these, efficiency is almost everything. Speaking about my own experiences, when I hit a snag in productivity in a project like this, it's almost always a death-knell. I too have a hobby-level interest in Rust, but doing things in Rust is, in my experience, almost always just harder. I mean no slight to the language, but this has universally been my experience.
  • mikepurvis 1y ago
    The advantages of correctness, memory safety, and a rich type system are worth something, but I expect it's a lot less when you're up against the value of a whole game design ecosystem with tools, assets, modules, examples, documentation, and ChatGPT right there to tell you how it all fits together. Perhaps someday there will be a comparable game engine written in Rust, but it would probably take a major commercial sponsor to make it happen.
    • ryanisnan 1y ago
      One of the challenges I never quite got over completely, was that I was always fighting rust fundamentals, which tells me I never fully assimilated into thinking like a rustacean. This was more of a me-problem, but I was constantly having to change my strategy to avoid fighting the borrow-checker, manage references, etc. In any case, it was a productivity sink.
      • mikepurvis 1y ago
        I bet, and that's particularly difficult when so much of modern game dev is just repeating extremely well-worn patterns— moving entities around and providing for scripted and emergent interactions between those entities and the player(s). That's not to say that games aren't a very cool space to be in, but the challenges have moved beyond the code. Particularly in the indie space, for 10+ years it's been all about story, characters, writing, artwork, visual identity, sound and music design, pacing, unique gameplay mechanics, etc. If you're making a game in 2025 and the hard part is the code, then you're almost certainly doing it wrong.
• je42 1y ago
  I wonder why Godot wasn't picked. Did I miss the points in the article?
  • ziddoap 1y ago
    I also would have liked to have seen the pro/con lists for each of the potential choices. I've been toying with the idea of making a 2d game that I've had on my mind for awhile, but have no game development experience, and am having trouble deciding where to start (obviously wanting to avoid the author's predicament of choosing something and having to switch down the line).
    • jerf 1y ago
      The key is, you gotta be pretty cold in the analysis. It's probably more important to avoid what you hate than to lean in too hard to what you love, unless your terminal goal is to work in $FAVE_LANG. Too many people claim they want to make a game, but their actions show that their terminal goal was actually to work in their favorite language. I don't care if your goal is just to work in your favorite language, I just think you need to be brutally honest with yourself on that front. Probably the best thing in your case is, look at the top three engines you could consider, spend maybe four hours gather what look like pros and cons, then just pick one and go. Don't overestimate your attachment to your first choice. You'll learn more just in finishing a tutorial for any of them then you can possibly learn with analysis in advance.
      • ziddoap 1y ago
        Thanks, I appreciate the comment! I'm certain that my goal is not to work in a specific language, but to bring a long-time idea to life, and ideally minimize the amount of avoidable headaches along the way. You're probably right that it'd be best to just jump in and get going with a few of them rather than analyze the choice to death (as I am prone to do when starting anything).
      • elktown 1y ago
        This is goes for a lot of things in tech unfortunately. For example, being stuck in a SRE/devops amusement park can be incredibly frustrating and surprisingly resource intense. Sometimes it feels like we could use some kind of a temperance movement, because if one can just manage to walk the line one can often reap great rewards. But the incentives seem to be pointing in the opposite direction.
• krapht 1y ago
  The article title is half-true. It wasn't so much they migrated away from Rust, but that they migrated away from Bevy, which is an alpha quality game engine. I wouldn't have read the article if it'd been labeled that, so kudos to the blog writer, I guess.
  • ivanjermakov 1y ago
    More surprising part for me is not migrating from Rust/Bevy, but migrating _to_ C#/Unity. Although points mentioned in the post are quite valid.
    • koakuma-chan 1y ago
      Where would you migrate to?
      • sadeshmukh 1y ago
        Maybe godot? The unity scandal recently is not great for developers.
        • koakuma-chan 1y ago
          https://news.ycombinator.com/item?id=43825086 https://news.ycombinator.com/item?id=43825086
        • pjmlp 1y ago
          People forget that Unity and Unreal are industry darlings for a reason. The amount of platforms they support, the amount of features they support, many of which could be a PhD thesis in graphics programming, the tooling, the store,....
      • gh0stcat 1y ago
        Not OP, but it seems that there is still a huge sentiment that Unity is not a "safe" platform to migrate to because of their relatively antagonistic approach to monetization guidelines compared to other open source game engines. I do think it makes sense to also consider Godot given his coworker is his brother who is stated to be new to game development, it has a scripting language even simpler than C#, more like python. Additionally, one might expect that someone more into Rust might prefer the C++ integration that Unreal offers. I think the timeline had an effect here too, as it's not been until recently that people have been taking Godot more seriously.
• yyyk 1y ago
  GC isn't a big problem for many types of apps/games, and most games don't care about memory safety. Rust's advantages aren't so important in this domain, while its complexity remains. No surprise he prefers C# for this.
  • seivan 1y ago
    [dead]
  • palata 1y ago
    Except that C# is memory safe.
  • foderking 1y ago
    great summary
  • loeg 1y ago
    Not just GC -- performance in general is a total non-issue for a 2d tile-based game. You just don't need the low-level control that Rust or C++ gives you.
    • trealira 1y ago
      I wouldn't say it's a non-issue. I've played 2D tile-based, pixel art games where the framerate dropped noticeably with too many sprites on screen, even though it felt like a 3DS should have been able to run it, and my computer isn't super low-end, either. You have more leeway, but it's possible to badly make optimized 2D games to the point where performance becomes an issue again.
      • loeg 1y ago
        These are gross, macro-level design problems; not the kind of thing where C# vs C++/Rust makes any difference.
  • maccard 1y ago
    Disagree on both points. Anyone who has shipped a game in unity has dealt with object pooling, flipping to structs instead of classes, string interpolation, and replacing idiomatic APIs with out parameters of reused collections. Similarly, anyone who has shipped a game in unreal will know that memory issues are absolutely rampant during development. But, the cure rust presents to solve these for games is worse than the disease it seems. I don’t have a magic bullet either..
• forrestthewoods 1y ago
  Rust is not good for video game gameplay logic. The ownership model of Rust can not represent the vast majority of allocations. I love Rust. It’s not for shipping video games. No Tiny Glade doesn’t count. Edit: don’t know why you’re downvoting. I love Rust. I use it at my job and look for ways to use it more. I’ve also shipped a lot of games. And if you look at Steam there are simply zero Rust made games in the top 2000. Zero. None nada zilch. Also you’re strictly forbidden from shipping Rust code on PlayStation. So if you have a breakout indie hit on Steam in Rust (which has never happened) you can’t ship it on PS5. And maybe not Switch although I’m less certain.
  • queuebert 1y ago
    > The ownership model of Rust can not represent the vast majority of allocations. What allocations can you not do in Rust?
    • forrestthewoods 1y ago
      Gameplay code is a big bag of mutable data that lives for relatively unknown amounts of time. This is the antithesis of Rust. The Unity GameObject/Component model is pretty good. It’s very simple. And clearly very successful. This architecture can not be represented in Rust. There are a dozen ECS crates but no one has replicated the worlds most popular gameplay system architecture. Because they can’t.
      • yuriks 1y ago
        Which part of that architecture is impossible in Rust? Actually an honest question, I'm wondering if I'm missing something. From what I remember from my Unity days (which granted, were a long time ago), GameObjects had their own lifecycle system separate from the C# runtime and had to be created and deleted using Destroy and Create calls in the Unity API. Similarly, components and references to them had to be created and retrieved using the GetComponent calls, which internally used handles, rather than being raw GC pointers. Runtime allocation of objects frequently caused GC issues, so you were practically required to pre-allocate them in an object pool anyway. I don't see how any of those things would be impossible or even difficult to implement in Rust. In fact, this model is almost exactly what I used to see evangelized all the time for C++ engines (using safe handles and allocator pools) in GDC presentations back then. In my view, as someone who has not really interacted or explored Rust gamedev much, the issue is more that Bevy has been attempting to present an overtly ambitious API, as opposed to focusing on a simpler, less idealistic one, and since it is the poster child for Rust game engines, people keep tripping over those problems.
• airstrike 1y ago
  [flagged]
• monkeyelite 1y ago
  It’s incredible how many projects and articles have been written around ECS with very little results. Quake 1-3 uses a single array of structs, with sometimes unused properties. Is your game more complex than quake 3? The “ECS” upgrade to that is having an array for each component type but just letting there be gaps: transform[eid].position += … physics[eid].velocity = …
  • dist-epoch 1y ago
    Quake 1-3 were written for computers where memory was not much slower than the CPU as is the situation today. But yeah, probably you don't need an ECS for 90% of the games.
    • fooker 1y ago
      Memory is sometimes faster today!
      • pornel 1y ago
        In absolute terms yes, but relative to the CPU speed memory is ridiculously slow. Quake struggled with the number of objects even in its days. What you've got in the game was already close to the maximum it could handle. Explosions spawning giblets could make it slow down to a crawl, and hit limits of the client<>server protocol. The hardware got faster, but users' expectations have increased too. Quake 1 updated the world state at 10 ticks per second.
        • monkeyelite 1y ago
          > Quake struggled with the number of objects even in its days. Because of memory bandwidth of Iterating the entities? No way. Every other part - rendering, culling, network updates, etc is far worse. Let’s restate. In 1998 this got you 1024 entities at 60 FPS. The entire array could no fit in L2 cache of a modern desktop. And I already advised a simple change to improve memory layout. > Quake 1 updated the world state at 10 ticks per secondo That’s not a constraint in Quake 3 - which has the same architecture. So it’s not relevant. > users' expectations have increased too Your game is more complex than quake 3? In what regard?
• Jyaif 1y ago
  Very useful writeup, thank you for taking the time to do it. PS: I love the art style of the game.
  • johnisgood 1y ago
    You might like Don't Starve, then.
• lynndotpy 1y ago
  I love Rust, but this lines up with my experience roughly. Especially the rapid iteration. Tried things out with Bevy, but I went back to Godot. There are so many QoL things which would make Rust better for gamedev without revamping the language. Just a mode to automatically coerce between numeric types would make Rust so much more ergonomic for gamedev. But that's a really hard sell (and might be harder to implement than I imagine.)
  • Seattle3503 1y ago
    What numeric types typically need conversions?
    • koakuma-chan 1y ago
      The fact you need a usize specifically to index an array (and most collections) is pretty annoying.
      • anticrymactic 1y ago
        This could be different in game dev, but in the last years of writing rust (outside of learning the language) I very rarely need to index any collection. There is a very certain way rust is supposed to be used, which is a negative on it's own, but it will lead to a fulfilling and productive programming experience. (My opinion) If you need to regularly index something, then you're using the language wrong.
        • ChadNauseam 1y ago
          This is getting downvoted but it's kind of true. Indexing collections all the time usually means you're not using iterators enough. (Although iterators become very annoying for fallible code that you want to return a Result, so sometimes it's cleaner not to use them.) However this problem does still come up in iterator contexts. For example Iterator::take takes a usize.
          • 1y ago
• _QrE 1y ago
  > I failed to fairly evaluate my options at the start of the project. The more projects I do, the more time I find that I dedicate to just planning things up front. Sometimes it's fun to just open a game engine and start playing with it (I too have an unfair bias in this area, but towards Godot [https://godotengine.org/ https://godotengine.org/]), but if I ever want to build something to release, I start with a spreadsheet.
  • gh0stcat 1y ago
    Do you think you needed to have those times to play around in the engine? Can a beginner possibly even know what to plan for if they don't fully understand the game engine itself? I am older so I know the benefits of planning, but I sometimes find that I need to persuade myself to plan a little less, just to get myself more in tune with the idioms and behaviors of the tool I am working in.
    • _QrE 1y ago
      I think even if you don't have much experience with tools, you can still plan effectively, especially now with LLMs that can give you an idea of what you're in for. But if you're doing something for fun, then you definitely don't need much planning, if any - the project will probably be abandoned halfway through anyways :)
• YesBox 1y ago
  Related: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033 - Leaving Rust gamedev after 3 years (982 comments) - 4/26/2024
  • malkia 1y ago
    https://loglog.games/blog/leaving-rust-gamedev/#hot-reloading-is-more-important-for-iteration-speed-than-people-give-it-credit-for https://loglog.games/blog/leaving-rust-gamedev/#hot-reloadin... Hot reloading! Iteration! A friend of mine wrote an article 25+ years ago about using C++ based scripting (compiles to C++). My friend is super smart engineer, but I don't think he was thinking of those poor scripters that would have to wait on iteration times. Granted 25 years ago the teams were small, but nowadays the amount of scripters you would have on AAA game is probably dozen if not two or three dozen and even more! Imagine all of them waiting on compile... Or trying to deal with correctness, etc.
• Sleaker 1y ago
  Anyone else get an empty page on mobile Firefox when they try to go the article? All that renders for me is a comment entry box. If I go back to news I can see the article list just fine.
  • fotta 1y ago
    Same on mobile safari
  • firesteelrain 1y ago
    Works for me on mobile Chrome
  • deleted 1y ago
    [deleted]
• shmerl 1y ago
  Using poor quality AI suggestions as a reason not to use Rust is a super weird argument. Something is very wrong with such idea. What's going to be next, avoiding everything where AI performs poorly? Scripting being flexible is a proper idea, but that's not an argument against Rust either. Rather it's an argument for more separation between scripting machinery and the core engine. For example Godot allows using Rust for game logic if you don't want to use GDScript, and it's not really messing up the design of their core engine. It's just more work to allow such flexibility of course. The rest of the arguments are more in the familiarity / learning curve group, so nothing new in that sense (Rust is not the easiest language).
  • tptacek 1y ago
    Yes, a lot of people are reasonably going to decide to work in environments that are more legible to LLMs. Why would that surprise you? The rest of your comment boils down to "skills issue". I mean, OK. But you can say that about any programming environment, including writing in raw assembly.
    • shmerl 1y ago
      First argument sounds like a major fallacy to me. It doesn't surprise me, but it find it extremely wrong.
      • tptacek 1y ago
        Why?
        • shmerl 1y ago
          Because it's a discouragement of learning based on mediocrity of AI. I find such idea perpetuating the mediocrity (not just of AI itself but of whatever it's used for). It's like imagine saying, I don't want to learn how write a good story because AI always suggests me writing a bad one anyway. May be that delivers the idea better.
• blueredmodern 1y ago
  [dead]
• deleted 1y ago
  [deleted]
• cube2222 1y ago
  That's an excellent article - it's great when people share not only their victories, but mistakes, and what they learned from them. That said regarding both rapid gameplay mechanic iteration and modding - would that not generally be solved via a scripting language on top of the core engine? Or is Rust + Bevy not supposed to be engine-level development, and actually supposed to solve the gameplay development use-case too? This is very much not my area of expertise, I'm just genuinely curious.
  • talldan 1y ago
    It does solve the gameplay development use case too. Bevy encourages using lots of small 'systems' to build out logic. These are functions that can spawn entities or query for entities in the game world and modify them and there's also a way to schedule when these systems should run. I don't think Bevy has a built-in way to integrate with other languages like Godot does, it's probably too early in the project's life for that to be on the roadmap.
• akkad33 1y ago
  [flagged]
• ninjis 1y ago
  The "Learning" point drives home a concern my brother-in-law and I were talking about recently. As LLMs become more entrenched as a tool, they may inevitably become the crutch that actually holds back innovation. Individuals and teams may be hesitant to explore or adopt bleeding edge technologies specifically because LLMs don't know about them or don't know enough about them yet.
  • gwd 1y ago
    New languages / packages / frameworks may need to collaborate with LLM providers to provide good training material. LLM-able training material may be the next important documentation thing. Another potentially interesting avenue of research would be to explore allowing LLMs to use "self-play" to explore new things.
    • SoKamil 1y ago
      How can it compete with vast amount of trained codebases on Github? For LLMs, more data equals better results, so people will naturally be driven to better completion with already established frameworks and languages. It would be hard to produce organic data on all ways your technology can be (ab)used.
      • gwd 1y ago
        Allegedly one of the ways they've been training LLMs to get better at logic and reasoning, as well as factual accuracy, is to use LLMs themselves to generate synthetic training data. The idea here would be similar: generate synthetic training data. Generating this could be aided by LLMs, perhaps with a "playground" of some sort where LLMs could compile / run / render various things, to help select out things that work and things that don't work (as well as if you see error X, what the problem might be).
      • int_19h 1y ago
        In a similar way to how this works for natural languages. Turns out that if you train the model on e.g. vast quantities of English, teaching it other languages doesn't require nearly as much, because it has already internalized all the "shared" parts (and there's a lot more of those than there are surface differences). But, yes, it does mean that new things that are drastic breaks with old practices are much harder to teach compared to incremental improvements.
• adamnemecek 1y ago
  For anyone considering Rust for gamedev check out the Fyrox engine https://fyrox.rs/ https://fyrox.rs/ here's a web demo https://fyrox.rs/assets/demo/animation/index.html https://fyrox.rs/assets/demo/animation/index.html
  • hu3 1y ago
    Sorry but this engine had(s) problems rendenring a simple rectangle with alpha channel texture, not longer than 3 months ago (I'm assuming it was fixed). Is it normal for Rust ecosystem to suggest software with this level of maturity? https://github.com/FyroxEngine/Fyrox/discussions/725 https://github.com/FyroxEngine/Fyrox/discussions/725
    • adamnemecek 1y ago
      > Is it normal for Rust ecosystem to suggest software with this level of maturity? Yeah, all Rust programmers are obligated by a blood pact to do this.
  • appleaday1 1y ago
    [flagged]
• morning-coffee 1y ago
  Expect many more commits like #12. ;)
  • nickkell 1y ago
    Awww that's not fair. C# actually has fairly good null-checking now. Older projects would have to migrate some code to take advantage of it, but new projects are pretty much using it by default. I'm not sure what the situation is with Unity though - aren't they usually a few versions behind the latest?
• deleted 1y ago
  [deleted]
• shadowgovt 1y ago
  Excellent write-up. On the topic of rapid prototyping: most successful game engines I'm aware of hit this issue eventually. They eventually solve it by dividing into infrastructure (implemented in your low-level lanuage) and game-logic / application logic / scripting (implemented in something far more flexible and, usually, interpreted; I've seen Lua used for this, Python, JavaScript, and I think Unity's C# also fits this category?). For any engine that would have used C++ instead, I can't think of a good reason to not use Rust, but most games with an engine aren't written in 100% C++.
• excerionsforte 1y ago
  I love Rust, but I would not try to make a full fledged game with it without patience. This post is not so much a moving away from Rust as much as Bevy is not enjoyable in its current form. Bevy is in its early stages. I'm sure more Rust Game Engines will come up and make it easier. That said, Godot was great experience for me but doesn't run on mobile well for what I was making. I enjoy using Flutter Flame now (honestly different game engines for different genres or preference), but as Godot continues to get better, I personally would use Godot. Try Unity or Unreal as well if I just want to focus on making a game and less on engine quirks and bugs.
• 12_throw_away 1y ago
  More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the informally specified, ad hoc and bug-ridden game engine called "Unity")
  • doctorpangloss 1y ago
    And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero.
    • qustrolabe 1y ago
      If anything, making your own game engine makes process more frustrating, time consuming and leads to burnout quicker than ever, especially when your initial goal was just to make a game but instead you stuck figuring out your own render pipeline or inventing some other wheel. I have a headache just from thinking that at some point in engine development person would have to spend literal weeks figuring out export to Android with proper signage and all, when, again, all they wanted is to just make a game.
      • turtledragonfly 1y ago
        Speaking as someone who has made their own game engine for their indie game: it really depends on the game, and on the developer's personality and goals. I think you're probably right for the majority of cases, since the majority of games people want to make are reasonably well-served by general-purpose game engines. But part of the thing that attracted me to the game I'm making is that it would be hard to make in a standard cookie-cutter way. The novelty of the systems involved is part of the appeal, both to me and (ideally) to my customers. If/when I get some of those (:
      • 1y ago
• malkia 1y ago
  [flagged]
  • deleted 1y ago
    [deleted]
• ChadNauseam 1y ago
  I love Bevy, but Unity is a weapon when it comes to quickly iterating and making a game. I think the Bevy developers understand that they have a long way to go before they get there. The benefits of Bevy (code-first, Rust, open source) still make me prefer it over Unity, but Unity is ridiculously batteries-included. Many of the negatives in the post are positives to me. > Each update brought with it incredible features, but also a substantial amount of API thrash. This is highly annoying, no doubt, but the API now is just so much better than it used to be. Keeping backwards compatibility is valuable once a product is mature, but like how you need to be able to iterate on your game, game engine developers need to be able to iterate on their engine. I admit that this is a debuff to the experience of using Bevy, but it also means that the API can actually get better (unlike Unity which is filled with historical baggage, like the Text component).
• worik 1y ago
  Migrating away from Bevy is the main thrust. Rust is a niche language, there is no evidence it is going to do well in the game space. Unity and C# sound like a much better business choice for this. Choosing a system/language.... > My love of Rust and Bevy meant that I would be willing to bear some pain ....that is not a good business case. Maybe one day there will be a Rust game engine that can compete with Unity, probably already are, in niches.
• quotemstr 1y ago
  Rust is fine as a low-level systems programming language. It's a huge improvement over C and (because memory safety) a decent improvement over C++. However, most applications don't need a low-level systems programming language, and trying to shoehorn one where it doesn't belong just leads to sadness without commensurate benefit. Rust does not * automatically make your program fast; * eliminate memory leaks; * eliminate deadlocks; or * enforce your logical invariants for you. Sometimes people mention that independent of performance and safety, Rust's pattern-matching and its traits system allow them to express logic in a clean way at least partially checked at compile time. And that's true! But other languages also have powerful type systems and expressive syntax, and these other languages don't pay the complexity penalty inherent in combining safety and manual memory management because they use automatic memory management instead --- and for the better, since the vast majority of programs out there don't need manual memory management. I mean, sure, you can Arc<Box<Whatever>> many of your problems away, but that point, your global reference counting just becomes a crude form of manual garbage collection. You'd be better off with a finely-tuned garbage collector instead --- one like Unity (via the CLR and Mono) has. And you're not really giving anything up this way either. If you have some compute kernel that's a bottleneck, thanks to easy FFIs these high-level languages have, you can just write that one bit of code in a lower-level language without bringing systems consideration to your whole program.
  • killme2008 1y ago
    I completely agree with you—Rust is not well-suited for application development. Application development requires rapid iteration, acceptable performance, and most importantly, a large developer community and a rich software ecosystem. Languages like Go , JavaScript, C# or Java are much better choices for this purpose. Rust is still best suited for scenarios where traditional system languages excel, such as embedded systems or infrastructure software that needs to run for extended periods.
• jheriko 1y ago
  [dead]
• taylorallred 1y ago
  I love Rust and wanted to use it for gamedev but I just had to admit to myself that it wasn't a good fit. Rust is a very good choice for user space systems level programming (ie. compilers, proxies, databases etc.). For gamedev, all of the explicitness that Rust requires around ownership/borrowing and types tends to just get in the way and not provide a lot of value. Games should be built to be fast, but the programmer should be able to focus almost completely on game logic rather than low-level details.
  • littlestymaar 1y ago
    Bevy solves the ownership/borrowing issues entirely with its ECS design though. I had two groups students (complete Rust beginners) ship a basic FPS and Tower Defense as learning project using Bevy and their feedback was that they didn't fight the language at all. The problem that remains is that as soon a you go from a toy game to an actual one, you'd realize that Bevy still has tons of work to do before it can be considered productive.
• 999900000999 1y ago
  Unity is still probably the best game engine for smaller games with Unreal being better for AAA. The problem is you make a deal with the devil. You end up shipping a binary full of phone home spyware, if you don't use Unity in the exact way the general license intends they can and will try to force you into the more expensive industrial license. However, the ease of actually shipping a game can't be matched. Godot has a bunch of issues all over the place, a community more intent on self praise than actually building games. It's free and cool though. I don't really enjoy Godot like I enjoy Unity , but I've been using Unity for over a decade. I might just need to get over it.
• skeptrune 1y ago
  >I wanted UI to be easy to build, fast to iterate, and moddable. This was an area where we learned a lot in Rust and again had a good mental model for comparison. I feel like this harkens to the general principle of being a software developer and not an "<insert-language-here>" developer. Choose tools that expose you to more patterns and help to further develop your taste. Don't fixate on a particular syntax.
• hyllos 1y ago
  To which extent was the implementation in C# benefitting off both the clarified requirements (so the Rust experience could be seen more as prototyping mixed with production)? Was it actually in major parts just a major refactor in a different language (admittedly with much more proven elements)?
  • peterfirefly 1y ago
    I bet a C# to C# rewrite would also have been quick and led to a cleaner codebase. Especially from C#-as-written-by-beginners...
• eftychis 1y ago
  This comment might not be liked by the usual commenters in these threads, but I think it is worth stressing: First: I have experience with Bevy and other game engine frameworks; including Unreal. And I consider myself a seasoned Rust, C etc developer. I could sympathize with what was stated by the author. I think the issue here is (mainly) Bevy. It is just not even close to the standard yet (if ever). It is hard for any generic game engine to compete with Unity/GoDot. Nevermind, the de facto standard of Unreal. But if you are a C# developer and using Unity already, and not C++ in Unreal, going to a bloated framework that is missing features that is Bevy makes little sense. [And here is also the minor issue, that if you are a C# developer, honestly you don't care about low level code, or not having a garbage collector.] Now if you are a C++ developer and use Unreal, they only point to move to Rust (which I would argue for the usual reasons) is if Unreal supports Rust. Otherwise, there is nothing that even compares to Unreal. (That is not custom made game engine.)
  • ecshafer 1y ago
    Imo the place for rust in game dev isnt in games at all, but base libraries and tools. Writing your proc generation library in rust that is an isolated package you can call in isolation, or similar is where its useful.
    • eftychis 1y ago
      I agree. [Unless fully adopted by a serious game engine, of course.] Rust's "superpower" is substituting critical C++ code in-place, with the goal of ensuring correctness and soundness. And increasing the development velocity as a result.
  • the__alchemist 1y ago
    The way I read about Bevy in online discussions obfuscates this. Someone who is new to game development could be confused into thinking Bevy is a fair competitor with the other engines you mentioned. And equate Bevy with Rust, or Bevy with Rust in game dev. I think stomping this out is critical to expectation management, and perhaps rust's future in game dev.
• noelwelsh 1y ago
  Not a game dev, but thought I'd mess around with Bevy and Rust to learn a bit more about both. I was surprised that my code crashed at runtime due to basics I expected the type system to catch. The fancy ECS system may be great for AAA games, but it breaks the basic connections between data and use that type systems rely on. I felt that Bevy was, unfortunately, the worst of both worlds: slow iteration without safety.
  • rellfy 1y ago
    I've always liked the concept of ECS, but I agree with this, although I have very limited experience with Bevy. If I were to write a game in Rust, I would most likely not choose ECS and Bevy because of two reasons: 1. Bevy will have lots of breaking changes as pointed in the post, and 2. ECS is almost always not required -- you can make performant games without ECS, and if with your own engine then you retain full control over breaking changes and API design compromises. I think all posts I have seen regarding migrating away from writing a game in Rust were using Bevy, which is interesting. I do think Bevy is awesome and great, but it's a complex project.
• johng 1y ago
  I signed up for the mailing list. The game looks interesting, I hope there is a Mac version in the future.
• deleted 1y ago
  [deleted]
• klabb3 1y ago
  The fact that people love the language is an unexpected downside. In my experience the rust ecosystem has an insanely high churn rate. Crates are often abandoned seemingly for no reason, often before even hitting 1.0. My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game. Once all the fun parts are solved, they leave it for dead. Conversely and ironically, this is why I love Go. The language itself is so boring and often ugly, but it just gets out of the way and has the best in class tooling. The worst part is having seen the promised land of eg Rust enums, and not having them in other langs.
  • bmitc 1y ago
    I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.
    • klabb3 1y ago
      Huh? Usually languages that are ”ignored” turns out to be for reasons such as poor or proprietary tooling. As an ignorant bystander, how are things like Cross compilation, package manager and associated infrastructure, async io (epoll, io_uring etc), platform support, runtime requirements, FFI support, language server, etc. Are a majority of these things available with first party (or best in class) integrated tooling that are trivial to set up on all big three desktop platforms? For instance, can I compile an F# lib to an iOS framework, ideally with automatically generated bindings for C, C++ or Objective C? Can I use private repo (ie github) urls with automatic overrides while pulling deps? Generally, the answer to these questions for – let’s call it ”niche” asterisk – languages, are ”there is a GitHub project with 15 stars last updated 3 years ago that maybe solves that problem”. There are tons of amazing languages (or at the very least, underappreciated language features) that didn’t ”make it” because of these boring reasons. My entire point is that the older and grumpier I get, the less the language itself matters. Sure, I hate it when my favorite elegant feature is missing, but at the end of the day it’s easy to work around. IMO the navel gazing and bikeshedding around languages is vastly overhyped in software engineering.
• palata 1y ago
  I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM language "because the JVM is slow" (spoiler: it is not) or for C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project). It's a bit like choosing Gentoo "because it's faster" (or worse, because it "sounds cool"). If that's the only reason, it's probably a bad choice (disclaimer: I use and love Gentoo).
  • djmips 1y ago
    I agree with you except for the JVM bit - but everyone's application varies
    • peterashford 1y ago
      You think the JVM is slow?
      • mceachen 1y ago
        IME large linear algebra algos run like molasses in a jvm compared to compiled solutions. You're always fighting the gc.
        • za3faran 1y ago
          Do you have any benchmarks to show, out of curiosity?
        • deleted 1y ago
          [deleted]
        • light_hue_1 1y ago
          Ok. But we have plenty of C libraries to bind to that for. They're far slower in Python but that hasn't stopped anyone.
• nrvn 1y ago
  > Bevy is young and changes quickly. Each update brought with it incredible features, but also a substantial amount of API thrash > Bevy is still in the early stages of development. Important features are missing. Documentation is sparse. A new version of Bevy containing breaking changes to the API is released approximately once every 3 months. I would choose Bevy if and only if I would like to be heavily involved in the development of Bevy itself. And never for anything that requires a steady foundation. Programming language does not matter. Choose the right tool for job and be pragmatic.
  • eYrKEC2 1y ago
    I like not getting paged at night, so I like APIs written in Rust.
• mamcx 1y ago
  This can be summarized in a simple way: UI is totally, another world. There is not chance for any language, not matter how good is it, to match the most horrendous (web!) but full-featured ui toolkit. I bet, 1000%, that is easier to do a OS, a database engine, etc that try to match QT, Delphi, Unity, etc. --- I made a decision that has become the most productive and problem-less approach of make UIs in my 30 years doing this: 1- Use the de-facto UI toolkit as-is (html, swift ui, jetpack compose). Ignore any tool that promise cross-platform UI (so that is html, but I mean: I don't try to do html in swift, ok?). 2- Use the same idea of html: Send plain data with the full fidelity of what you wanna render: Label(text=.., size=..). 3- Render it directly from the native UI toolkit. Yes, this is more or less htmx/tailwindcss (I get the inspiration from them). This mean my logic is full Rust, I pass serializable structs to the UI front-end and render directly from it. Critically, the UI toolkit is nearly devoid of any logic more complex that what you see in a mustache template language.. Not do the localization, formatting, etc. Only UI composition. I don't care that I need to code in different ways, different apis, different flows, and visually divergent UIs. IS GREAT. After the pain of boilerplate, doing the next screen/component/wwhatever is so ridiculous simple that is like cheating. So, the problem is not Rust. Is not F#, or Lisp. Is that UI is a kind of beast that is imperious to be improved by language alone.
  • peterashford 1y ago
    I disagree. The issue, which the article mentions, is iteration time. They were having issues iterating on gameplay, not UI. My own experiences with game dev and Rust (which are separate experiences, I should add) resonate with what the article is expressing. Iterating systems is common in gamedev and Rust is slow to iterate because its precision ossifies systems. This is GREAT for safety, it's crap for momentum and fluidity
    • maccard 1y ago
      This is why game engines embedded scripting languages. Who gives a crap if the engine takes 12 hours to compile if 80% of the team are writing lua in a hot reload loop.
• dmitrygr 1y ago
  Honey, a new incantation to summon Cthulhu just dropped. pub fn randomize_paperdoll<C: Component>( mut commands: Commands, views: Query<(Entity, &Id<Spine>, &Id<Paperdoll>, &View<C>), Added<SkeletonController>>, models: Query<&Model<C>, Without<Paperdoll>>, attachment_assets: Res<AttachmentAssets>, spine_manifest: Res<SpineManifest>, slot_manifest: Res<SlotManifest>, ) {
• Animats 1y ago
  Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues. I find myself having to break too much new ground, trying to get things to work that others doing first-person shooters should have solved years ago. The lower levels are buggy and have a lot of churn The stack I use is Rend3/Egui/Winit/Wgpu/Vulkan. Except for Vulkan, they've all had hard to find bugs. There just aren't enough users to wring out the bugs. Also, too many different crates want to own the event loop. These crates also get "refactored" every few months, with breaking API changes, which breaks the stack for months at a time until everyone gets back in sync. Language problems: Back-references are difficult A owns B, and B can find A, is a frequently needed pattern, and one that's hard to do in Rust. It can be done with Rc and Arc, but it's a bit unwieldy to set up and adds run-time overhead. There are three common workarounds: - Architect the data structures so that you don't need back-references. This is a clean solution but is hard. Sometimes it won't work at all. - Put everything in a Vec and use indices as references. This has most of the problems of raw pointers, except that you can't get memory corruption outside the Vec. You lose most of Rust's safety. When I've had to chase down difficult bugs in crates written by others, three times it's been due to errors in this workaround. - Use "unsafe". Usually bad. On the two occasions I've had to use a debugger on Rust code, it's been because someone used "unsafe" and botched it. Rust needs a coherent way to do single owner with back references. I've made some proposals on this, but they require much more checking machinery at compile time and better design. Basic concept: works like "Rc::Weak" and "upgrade", with compile time checking for overlapping upgrade scopes to insure no "upgrade" ever fails. "Is-a" relationships are difficult Rust traits are not objects. Traits cannot have associated data. Nor are they a good mechanism for constructing object hierarchies. People keep trying to do that, though, and the results are ugly. [1] https://www.animats.com/sharpview/index.html https://www.animats.com/sharpview/index.html
  • echelon 1y ago
    We've got another one on our end. It's much more to do with Bevy than Rust, though. And I wonder if we would have felt the same if we had chosen Fyrox. > Migration - Bevy is young and changes quickly. We were writing an animation system in Bevy and were hit by the painful upgrade cycle twice. And the issues we had to deal with were runtime failures, not build time failures. It broke the large libraries we were using, like space_editor, until point releases and bug fixes could land. We ultimately decided to migrate to Three.js. > The team decided to invest in an experiment. I would pick three core features and see how difficult they would be to implement in Unity. This is exactly what we did! We feared a total migration, but we decided to see if we could implement the features in Javascript within three weeks. Turns out Three.js got us significantly farther than Bevy, much more rapidly.
• nine_k 1y ago
  Sounds like "Migrating away from Bevy towards Unity"; the Rust to C# transition is mostly a technical consequence. Bevy: unstable, constantly regressing, with weird APIs here and there, in flux, so LLMs can't handle it well. Unity: rock-solid, stable, well-known, featureful, LLMs know it well. You ought to choose it if you want to build the game, not hack on the engine, be its internal language C#, Haskell, or PHP. The language is downstream from the need to ship.
  • deleted 1y ago
    [deleted]
• efnx 1y ago
  I think this is a problem of using the right abstractions. Rust gamedev is the Wild West, and frontier development incurs the frontier tax. You have to put a lot of work into making an abstraction, even before you know if it’s the right fit. Other “platforms” have the benefit of decades more work sunk into finding and maintaining the right abstractions. Add to that the fact that Rust is an ML in sheep’s clothing, and that games and UI in FP has never been a solved problem (or had much investment even), it’s no wonder Rust isn’t ready. We haven’t even agreed on the best solutions to many of these problems in FP, let alone Rust specifically! Anyway, long story short, it takes a very special person to work on that frontier, and shipping isn’t their main concern.
• lovegrenoble 1y ago
  Why not the awesome Gamemaker engine?
• chaosprint 1y ago
  I completely understand, and it's not the first time I've heard of people switching from Bevy to Unity. btw Bevy 0.16 just came out in case you missed the discussion: https://news.ycombinator.com/item?id=43787012 https://news.ycombinator.com/item?id=43787012 In my personal opinion, a paradox of truly open-source projects (meaning community projects, not pseudo-open-source from commercial companies) is that development seems to show a tendency of diversity. While this leads to more and more cool things appearing, there always needs to be a balance with sustainable development. Commercial projects, at least, always have a clear goal: to sell. For this goal, they can hold off on doing really cool things. Or they think about differentiated competition. Perhaps if the purpose is commercial, an editor would be the primary goal (let me know if this is alreay on the roadmap). --- I don't think the language itself is the problem. The situation where you have to use mature solutions for efficiency is more common in games and apps. For example, I've seen many people who have had to give up Bevy, Dioxus, and Tauri. But I believe for servers, audio, CLI tools, and even agent systems, Rust is absolutely my first choice. I've recently been rewriting Glicol (https://glicol.org https://glicol.org) after 2 years. I start from embedded devices, switching to crates like Chumsky, and I feel the ecosystem has improved a lot compared to before. So I still have 100% confidence in Rust.
  • koakuma-chan 1y ago
    > and even agent systems Is there a Rust equivalent of openai-agents-sdk?
• lostmsu 1y ago
  Related: just tried to switch to Rust when starting a new project. The main motivation was the combination of fearless concurrency and exhaustive error handling - things that were very painful in the more mature endeavor. Gave up after 3 days for 3 reasons: 1. Refactoring and IDE tooling in general are still lightyears away from JetBrains tooling and a few astronomical units away from Visual Studio. Extract function barely works. 2. Crates with non-Rust dependencies are nearly impossible to debug as debuggers don't evaluate expressions. So, if you have a Rust wrapper for Ogg reader, you can't look at ogg_file.duration() in the debugger because that requires function evaluation. 3. In contrast to .NET and NuGet ecosystem, non-Rust dependencies typically don't ship with precompiled binaries, meaning you basically have to have fun getting the right C++ compilers, CMake, sometimes even external SDKs and manually setting up your environment variables to get them to build. With these roadblocks I would never have gotten the "mature" project to the point, where dealing with hard to debug concurrency issues and funky unforeseen errors became necessary.
  • neonsunset 1y ago
    > 3. In contrast to .NET and NuGet ecosystem, non-Rust dependencies typically don't ship with precompiled binaries, meaning you basically have to have fun getting the right C++ compilers, CMake, sometimes even external SDKs and manually setting up your environment variables to get them to build. Depending on your scenario, you may want either one or another. Shipping pre-compiled binaries carries its own risks and you are at the mercy of the library author making sure to include the one for your platform. I found wiring up MSBuild to be more painful than the way it is done in Rust with cc crate, often I would prefer for the package to also build its other-language components for my specific platform, with extra optimization flags I passed in. But yes, in .NET it creates sort of an impedance mismatch since all the managed code assemblies you get from your dependencies are portable and debuggable, and if you want to publish an application for a specific new target, with those it just works, be it FreeBSD or WASM. At the same time, when it works - it's nicer than having to build everything from scratch.
    • lostmsu 1y ago
      The big advantage of precompiled is that hundreds of people who downloaded the package don't have to figure out building steps over and over again. Risks are real though.
• mogoh 1y ago
  Bevy warns about stability: https://bevyengine.org/learn/quick-start/introduction/ https://bevyengine.org/learn/quick-start/introduction/
• promiseofbeans 1y ago
  One of the smartest devs I know built his game from scratch in C. Pretty complex game too - 3D open-world management game. It's now successful on steam. Thing is, he didn't make the game in C. He built his game engine in C, and the game itself in Lua. The game engine is specific to this game, but there's a very clear separation where the engine ends and the game starts. This has also enabled amazing modding capabilities, since mods can do everything the game itself can do. Yes they need to use an embedded scripting language, but the whole game is built with that embedded scripting language so it has APIs to do anything you need. For those who are curious - the game is 'Sapiens' on Steam: https://store.steampowered.com/app/1060230/Sapiens/ https://store.steampowered.com/app/1060230/Sapiens/
  • ryao 1y ago
    Do you know why he supports MacOS, but not Linux?
    • Rohansi 1y ago
      Most likely because they don't use Linux. Or because it's kind of a mine field to support with bugs that occur on different distros. Even Unity has their own struggles with Linux support. They're distributing their game on Steam too so Linux support is next to free via Proton.
      • fc417fc802 1y ago
        > it's kind of a mine field to support with bugs that occur on different distros Non-issue. Pick a single blessed distro. Clearly state that it's the only configuration that you officially support. Let the community sort the rest out.
        • rounce 1y ago
          This is a terrible solution, you're better off just making it Windows only and ensuring it can be run via Proton/Wine.
• cantrecallmypwd 1y ago
  API churn is so expensive, largely unnecessary, and rarely value-add. It's an anti-pattern that makes things otherwise promising things unusable.
• deleted 1y ago
  [deleted]
• ezekiel68 1y ago
  This is a personal project that had the specific goal of the person's brother, who was not a coder, being able to contribute to the project. On top of that, they felt the need to continuously upgrade to the latest version of the underlying game engine instead of locking to a version. I have worked as a professional dev at game studios many would recognize. Those studios which used Unity didn't even upgrade Unity versions often unless a specific breaking bug got fixed. Same for those studios which used DirectX. Often a game shipped with a version of the underlying tech that was hard locked to something several years old. The other points in the article are all valid, but the two factors above held the greatest weight as to why the project needed to switch (and the article says so -- it was an API change in Bevy that was "the straw that broke the camel's back").
• corysama 1y ago
  Professional high-performance C++ game engine dev here. At a glance, their game looks great. But, to be frank, it also looks like it could have been made in the DOS era with sufficient effort. Going hard with Rust ECS was not the appropriate choice here. Even a 1000x speed hit would be preferable if it gained speed of development. C# and Unity is a much smarter path for this particular game. But, that’s not a knock on Rust. It’s just “Right tool for the job.”
• DarkmSparks 1y ago
  The best language for game logic is lua, switching to C# probably isnt going to help any.... IMHO.
  • Rohansi 1y ago
    What makes Lua the best for game logic? You don't even have types to help you out with Lua.
    • trealira 1y ago
      Yeah, I actually recently tried making a game in Lua using LOVE2D, and then making the same one in C with Raylib, and I didn't feel like Lua itself gave me all that much. I don't think Lua is best for game logic so much as it's the easiest language to embed in a game written in C or C++. That said, maybe some of its unique features, like its coroutines, or stuff relating to metatables, could be useful in defining game logic. I was writing very boring, procedural, occasionally somewhat object-oriented code either way.
      • Rohansi 1y ago
        Lua would definitely help with iteration times vs. C/C++/Rust but C# compiles very quickly. Especially in Unity where you have an editor that keeps assets cached and can hot reload code changes (with a plugin). Coroutines can definitely be very useful for games and they're also available in C#.
    • DarkmSparks 1y ago
      Stuff that hooked me: you integrate it tightly with the engine so it only does game logic, making files small and very quick and easy to read. platform independent, no compiling, so can modify it in place on a release build of the game. the "everything is a table" approach is very easy to concept mentally means even very inexperienced coders can get up and running quickly. great exception handling, which makes most release time bugs very easy to diagnose and fix. All of which means you spend far more time building game logic and much, much less time fighting the programming language. Heres my example of a 744 flight data recorder (the rest of the 744 logic is in the containing folders) https://github.com/mSparks43/747-400/blob/master/plugins/xtlua_fdr/scripts/B747.01.xt.fdr/B747.01.xt.fdr.lua https://github.com/mSparks43/747-400/blob/master/plugins/xtl... All asynchronously multithreaded, 100% OS independent.
• jokethrowaway 1y ago
  Congrats on the rewrite! I think the worst issue was the lack of ready-made solution. Those 67k lines in Rust contains a good chunk of a game engine. The second worst issue was that you targeted an unstable framework - I would have focused on a single version and shipped the entire game with it, no matter how good the goodies in the new version. I know it's likely the last thing you want to do, but you might be in a great position to improve Bevy. I understand open sourcing it comes with IP challenges, but it would be good to find a champion with read access within Bevy to parse your code and come up with OSS packages (cleaned up with any specific game logic) based on the countless problems you must have solved in those extra 50k lines.
• rorylaitila 1y ago
  For my going on 5 year side game project, this is why I can only write in vanilla tools (java, typescript) and with small libraries that are easy to replace. I would loose all motivation if I had to refactor my game and update the engine every time I come back to it. But also, I don't have the pressure of ever finishing the game...
• stemlord 1y ago
  Unity is predatorial. I work in a small studio which is part of a larger company (only 5 of us use Unity) and they have suddenly decided to hold our accounts hostage until we upgrade to Industry license because of the revenue our parent company makes even though that's completely separate cash flow versus what our studio actually works with. Industry license is $5000 PER SEAT PER YEAR. Absolute batshit crazy expensive for a single piece of software. We will never be able to afford that. So we are switching over to Unreal. It's really sad what Unity has become.
  • jmpavlec 1y ago
    Definitely not cheap, but I assume developer cost and migrating to unreal is probably not cheap either. I'm not too familiar with either engine, are they similar enough that it's "cheaper" to migrate? I imagine that sets back release dates as well. Such a crappy thing for a company to do.
  • syspec 1y ago
    That's BS, does your team of 5 work for free? Imagine you all cost 100k/year to employ by the larger company (since you all apparently don't make money). Then imagine you are all now cost 105k a year to the parent company. It's no difference.
• cyprx 1y ago
  wow every rust topics have uncountable number of comments, it's indeed a successful language
• virtualritz 1y ago
  It sounds to me that it may have been better to limit performance-critical parts to Rust and write the actual game in something like Lua (embedded in Rust)? That's the approach I've been taking with a side project game for the very reason alone that the other contributors are not system programmers. I.e. a similar situation as the author had with his brother. Rust was simply not an option -- or I would be the only one writing code. :] And yeah, as others mentioned: Fyrox over Bevy if you have few (or one) Rust dev(s). It just seems Fyrox is not on the radar of many Rust people even. Maybe because Bevy just gets a lot more (press) coverage/enthusiasm/has more contributors?
  • int_19h 1y ago
    But why, when you can write performance-critical parts in low-level C# (with structs, stackalloc etc) and game logic in high-level object-oriented C#, and have seamless interop between the two with no effort at all?
• LAC-Tech 1y ago
  Are scripting languages not a thing in gamedev anymore? I feel most of the things mentioned (rapid prototyping, ease of use for new programmers, modability) would be more easily accomplished by embedding a Lua interpreter in the rust project. Glad C# is working out for them though, but if anyone else finds themselves in this situaton in Rust, or C, C++, Zig, whatever - embedding lua might be something else to consider, that requires less re-writing.
• deleted 1y ago
  [deleted]
• lpln3452 1y ago
  Using Rust in a project felt less like implementing ideas and more like committing to learning the language in depth. Most projects involve messy iteration and frequent failure. Doing that in Rust is painful. Starting a greenfield project in it feels more like a struggle with the language than progress on the actual idea unless you're a Rust enthusiast.
• Havoc 1y ago
  Throwing someone who is new to coding straight into rust AND game dev is pretty ambitious But yeah my first thought here was Lua too like others said
• hombre_fatal 1y ago
  Man, they seems kinda cracked. He migrated each of the subsystem experiments in about one day each having never used Unity before? I've ported code between engines, and that makes my productivity feel very... leisurely. Also, it's endearing that he builds things with his brother including that TF2 map that he linked from years ago.
• justinhj 1y ago
  I worked on games for 20 years and was always interested in alternative languages to C and C++ for the purpose. Java was my first hope. It was a bit safer than C++ but ultimately too verbose and the GC meant too much memory is wasted. Most games were very sensitive to memory use because consoles always had limited memory to keep costs down. Next I spent years of side projects on Common Lisp based on Andy Gavin’s success there with Crash Bandicoot and more, showing it was possible to do. However, reports from the company were that it was hard to scale to more people and eventually a rewrite of the engine in C++ came. I have explored Rust and Bevy. Bevy is bleeding edge and that’s okay, but Rust is not the right language. The focus on safety makes coding slow when you want it to be fast. The borrow checker frowns when you want to mutate things for speed. In my opinion Zig is the most promising language for triple A game dev. If you are mid level stick to Godot and Unity, but if you want to build a fast, safe game engine then look at Zig first.
• jfndbdbdb 1y ago
  Nice write up! Nevertheless, these are very specific circumstances: * They didn't select Rust as the best tool available to create a game, they decided to create a Rust project which happens to be a game * When the objective and mental model of a solution is clear, the execution is trivial. I bet I could recreate a software which took me 3 months to develop in 3 days, if I just have to retype the solution instead of finding a solution. No matter which language * They seem to struggle with the most trivial of tasks. Having to call out being able to utilize an A* library (an algorithm worth like 10 lines of code) or struggling with scripting (trivial with proven systems like lua) suggests a quite novice team That being said, I'm glad for their journey:)
• AIPedant 1y ago
  I realize there were bigger problems, but this makes me very sad: Learning - Over the past year my workflow has changed immensely, and I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. The maturity and vast amount of stable historical data for C# and the Unity API mean that tools like Gemini consistently provide highly relevant guidance. While Bevy and Rust evolve rapidly - which is exciting and motivating - the pace means AI knowledge lags behind, reducing the efficiency gains I have come to expect from AI assisted development. This could change with the introduction of more modern tool-enabled models, but I found it to be a distraction and an unexpected additional cost. In 2023 I wondered if LLM code generation would throttle progress in programming language design. I was particularly thinking about Idris and other dependently-typed languages which can do deterministically correct code generation. But it applies to any form of language innovation: why spend time learning a new programming language that 100% reliably abstracts boilerplate away, when an LLM can 95% reliably slop the boilerplate? Some people (me) will say that this is unacceptably lazy and programmers should spend time reading things, the other will point to the expected value of dev costs or whatever. Very depressing.
• josvdwest 1y ago
  I wonder what the dev speed-up would have been if they used Unity with Coplay