Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

Post reply on HN
Print view View original

461–470 of 996 posts

Re: Leaving Rust gamedev after 3 years

#461

Post by cableshaft »

meheleventyone wrote: post #350
pcwalton wrote: post #326

Earlier quoted context omitted.

I'd say Rust does have that big ticket ecosystem push. Microsoft has been embracing Rust lately, with things like official Windows bindings [1]. The bigger problem is just inertia: large game engines are enormous. [1]: https://github.com/microsoft/windows-rs

I'd say the inertia is far more social than codebase size related. Right now whilst there are pockets of interest there is no broader reason to switch. Bevy as the leading contender isn't going to magic it's way to being capable of shipping AAA titles unless a studio actually adopts it. I don't think it's actually shipped a commercially successful indie game yet. Also game engines emphatically don't have to be huge.…

> Also game engines emphatically don't have to be huge. Look at Balatro shipping on Love2d.

Balatro convinced me that Love2D might be a good contender for my next small 2D game release. I had no idea you could integrate Steamworks or 2D shaders that looked that good into Love2D. And it seems to be very cross-platform, since Balatro released on pretty much every platform on day 1 (with some porting help from a third party developer it seems like).

And since it's Lua based, I should be able to port a slightly simpler version of the game over to the Playdate console.

I'm also considering Godot, though.

Re: Leaving Rust gamedev after 3 years

#462

Post by beders »

MerrimanInd wrote: post #281
fidotron wrote: post #71

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…

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…

I shall recommend this talk for you https://www.youtube.com/watch?v=rX0ItVEVjHc

Re: Leaving Rust gamedev after 3 years

#463

Post by FridgeSeal »

andersa wrote: post #437
Animats wrote: post #137

That's a good article. He's right about many things. I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust. Notes: * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be writ…

> I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives. The main reason is that you can't ship that Rust code on PS5 in a sensible manner. People have tried, got useless toys to compile, but in the end even Embark gave up. I remember seeing something from them that they had moved Rust to server-only.

> The main reason is that you can't ship that Rust code on PS5 in a sensible manner.

Really - why’s that?

Re: Leaving Rust gamedev after 3 years

#464

Post by pcwalton »

TillE wrote: post #432
meheleventyone wrote: post #360

Earlier quoted context omitted.

Looks cool and well received but at ~300ish reviews hardly a shining beacon if we extrapolate sales from that. But I'll say that's a good start.

Speaking as a Godot supporter, I don't think sales numbers of shipped games are relevant to anyone except the game's developer. When evaluating a newer technology, the key question is: are there any major non-obvious roadblocks? A finished game (with presumably decent performance) tells you that if there are problems, they're solvable. That's the data.

Agreed. We've learned a lot from Godot, by the way. I consider all us open source engines to be in it together :)

Re: Leaving Rust gamedev after 3 years

#465

Post by [deleted] »

IshKebab wrote: post #332
jandrewrogers wrote: post #133

Earlier quoted context omitted.

> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database. Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinit…

> modern C++ is essentially as safe as Rust This isn't even close to being true. I think memory safety isn't as important for games as it is for most software (though it is still quite important for multiplayer games!). But even if you write the most modern C++ possible I guarantee you are going to spend some of your time debugging segfaults, memory corruption and heisenbugs. Don't try and claim "I don't write bugs".…

[deleted]

Re: Leaving Rust gamedev after 3 years

#466

Post by hi-v-rocknroll »

celdon25 wrote: post #434
hi-v-rocknroll wrote: post #386

Earlier quoted context omitted.

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.

I haven't tried it yet but I've wondered if Elixir might be a good choice for a game server with many concurrent players.

Definitely and for chat.

BEAM/HiPE VM allows native linking using NIFs so it's possible to integrate Erlang or Elixir with C-compatible projects for critical code sections, library interfacing, and perhaps even the majority of a performance-critical game engine as native code. Rustler also exists to write NIFs in Rust. Recall how VMware ESXi core tech was implemented mostly as Linux kernel modules and heavily-modified Linux to turn it inside-out as a type-1 hypervisor.

Re: Leaving Rust gamedev after 3 years

#467

Post by modeless »

I decided that Rust wasn't for me after a week long side project. But I doubted myself for a long time, as Rust seemed like such a great idea for so many reasons and it seemed like a bunch of other people were using it successfully. So I'm glad to see this article and know that it wasn't just me.

Re: Leaving Rust gamedev after 3 years

#468

Post by troupo »

pcwalton wrote: post #279
mrkeen wrote: post #211

Earlier quoted context omitted.

> There's decades of work to catch up on First you gotta get OpenGL going, with its horrible stateful API, give up on it and go to DirectX9. Do a complete rewrite when DirectX10 comes out. Get your real-time lighting happening with shadow volumes, run into patent issues and get strong-armed into putting Creative sound into your game. Cycle between GLSL, HLSL, and Cg. End up switching to shadow mapping anyway. Drop Li…

Exactly. Bevy has the advantage of being built using the "right way" from the start. This makes an enormous difference in the ease of hacking on rendering code. Ironically, the main thing holding Bevy back is the bickering at the W3C. WebGPU is still not widely supported, so we have to support WebGL 2 (with reduced functionality in some cases), and that adds a lot of complexity.

> and that adds a lot of complexity.

Well, the example code for a simple button referenced in the article has insane complexity that has nothing to do with WebGL though. It's precisely "the right way" that adds a lot of complexity.

Re: Leaving Rust gamedev after 3 years

#469

Post by netbioserror »

celdon25 wrote: post #444
netbioserror wrote: post #429

Earlier quoted context omitted.

Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications. My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the…

> Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams I hate hearing this argument, because it glosses over the hard realities of building products, even if it sounds good on paper. Companies don't often have the resources to hire people that can do this early on, or the time to do this early on even if…

I have a personal experience that is literally the polar opposite of everything you just described. Atypical, yes, but on the other hand, testimonials about life in most other software teams describe an unnecessary mess of middle-management and bureaucratic cruft. I'm sure at many companies there are many roadblocks in the way between their developers and a better product, but my company doesn't have them. Not a startup, either. A 50-year-old engineering company that learned hard lessons after 20 years of stagnation.

I'm not going to be very sympathetic to counter-arguments about what "proper" practices we "should" follow, because quite frankly we're delivering features and value for our clients and catapulting back to the leadership position in our industry. Programming as a studied profession is barely half a century old, and the current zeitgeist of "best practice" is younger than some peoples' stints at the company they still work at. I'm very inclined to believe none of it is correct. No structural or architectural approach is one-size-fits-all and everything will be contingent on who you have and what you're trying to deliver.

Re: Leaving Rust gamedev after 3 years

#470

Post by nialv7 »

popcar2 wrote: 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…

> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial.

So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?

Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?

Post reply on HN