Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

741–750 of 996 posts

Re: Leaving Rust gamedev after 3 years

#741

Earlier quoted context omitted.

> a crashing released game is better than a half-finished "perfect" game For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.

Hell no. Lots of these games take 5-7 years to make. You want to turn that into 10-14? I can live with the rare crash bugs.

What if it's 5-7, but only after there is a deep enough dev pool and language tooling to address some of the productivity issues mentioned in the blog? Why make up arbitrary x2 factors?

Re: Leaving Rust gamedev after 3 years

#742

The Rust community is one of the top arguments against rust. I've never before been so condescended to as when attempting to ask questions there. Their lack of care for perf also drives me up a wall. Anytime they propose adding an extra layer of indirection to get around the borrow checker, I have to explain yet again that with the way modern CPUs work, extra layers of indirection have serious cache-related perf cost…

> when attempting to ask questions there Could you please give an indication of which venues you've encountered this kind of condescension in? I don't tend to see this in the spaces I frequent, but I know it is happening, and I wish it weren't. We try, sometimes, to provide some official messaging discouraging this kind of condescension, but perhaps there's something more we can do.

In my view, here's an example from this HN comment section: https://news.ycombinator.com/item?id=40177534

If this is the kind of attitude I would get from using Rust and having to be part of the Rust community, then I think I will pass.

Re: Leaving Rust gamedev after 3 years

#743

Earlier quoted context omitted.

> Bevy has the advantage of being built using the "right way" from the start I think the article is precisely criticizing this type of comment... You make people believe that Bevy is some kind of safe bet for the future, that it took inspiration from the greatest to build even better foundations for a game engine... And it seems common in the Rust community: make audacious unverifiable claims to enroll other "believe…

I don't think anyone ever claimed that Bevy is finished. As for audacious unverifiable claims: it's quite verifiable that Bevy never used DirectX 9, DirectX 10, shadow volumes, HLSL, Cg, Vulkan, or Metal (I'm not sure about OpenGL or GLSL; those were before I got involved with the project). It chose the better path (wgpu) early on. That's all I was saying.

I'm not a pro engine dev, but from what I've heard, the graphics backend is a minor part of what makes a good and fully-fledged game engine. I see it more as a strength than other engine can ship on older and more legacy hardware. Moreover wgpu is still in its infancy but evolving rapidly. We'll see in the future how bevy will develop, and I really hope it works out, because I liked some of the ergonomics of the ECS when I used it, but for now I am very doubtful

Re: Leaving Rust gamedev after 3 years

#744
post #97
post #15

Earlier quoted context omitted.

> Seems like Rust was the wrong tool for the job. Sure, but the problem is when you have a community around that tool that insists otherwise.

Can you please give an example of that? Rust is very much advertised as a systems programming language . Can't really blame people for using it and going "oh it's harder than go and python"...

https://bevyengine.org/

Re: Leaving Rust gamedev after 3 years

#745

Rust... what is it good for? "Systems programming" ... Rust is not good for raw performance. Neither for prototyping and iteration. Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades. Anyone really unhappy with Linux/BSD/Windows/macOS performance? What systems are we talking about that benefits from Rust? Advanced weapon systems that should a…

Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything. This is silly. "Syzbot and the Tale of a Thousand Kernel Bugs" [1] is my favorite talk on this subject. The Linux kernel is adding security bugs faster than they can be fixed. This is an unsustainable situation--it is not "good enough"--and nobody really has any ideas t…

> Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything.

No, not at all, that's not what I meant. I think it's forte for now is better security at the cost of some performance and productivity (iteration speed).

Re: Leaving Rust gamedev after 3 years

#746
post #554

Earlier quoted context omitted.

By "care about programming" I basically mean writing maintainable code. By "inadequate code" I mean code that does what the author wants at this point in time, but is completely unmaintainable and just bad. Sloppy practices, etc

Some people "care about shipping a product" others "care about programming". That is why virtually no videogame is made with Rust.

In other words, "shipping a product" is incompatible with decent code.

This is why virtually all proprietary codebases aimed at "shipping a product" are a clusterfuck.

Re: Leaving Rust gamedev after 3 years

#747

Earlier quoted context omitted.

> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are…

Here's a trace of a Bevy demo: https://i.imgur.com/oXUxC2h.png You can see that all the CPUs are being maxed out. This actually does result in significant FPS increases. Does it matter for every game? No. But it does result in better performance!

That makes no difference if the game is boring.

Re: Leaving Rust gamedev after 3 years

#748

Earlier quoted context omitted.

Lamothe's Black Art book came out in '95. Abrash's black book came out in '97. Borland C++ was pretty common and popular in 93 and we even had some not-so-great C++ compilers on Amiga in 92/93 that had some use in gamedev. SimCity 2000 was written in C++, way back in '93 (although they started with Cfront) An absolute fuckton of shareware games I was playing in the 90s were built with Turbo C++.

I also remember by videogame magazines I was reading back in early 90s that another C++ compiler that was a favourite among devs was Watcom C++ that was released in 88.

That doesn't mean that it was used primarily with C++ though. IIRC Watcom C/C++ mainly became popular because of Doom, and that was written in C (as all id games until Doom 3 in 2004 - again IIRC though).

The actual killer feature of Watcom C/C++ was not the C or C++ compiler, but its integration with DOS4GW.

Re: Leaving Rust gamedev after 3 years

#749

Earlier quoted context omitted.

> Oh, come on, we're yet again extrapolating from "Rust is bad at rapid iteration on an indie game" to "Rust is bad at everything". I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise.

> I am saying that Rust development has a lower velocity than mainstream GC'ed languages (Java, C#, Go, whatever). That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages". > I didn't think that you are disputing this claim; if you are disputing this, I'd like to know why you think otherwise. Depending on the domain, I am disputing t…

> That's not what you said: you said you're going to be less productive in Rust than nearly any other language, not "mainstream GC'd languages".

I feel that you're selectively reading only what you have talking points to respond to.

Here is exactly what I said:

> Unless you are writing something in which any GC time other than 0ns is a dealbreaker, and any bug is also a dealbreaker, you're going to be less productive in Rust than almost any other language.

I mean, I literally carved out an exception use-case for Rust; viz for software that can't handle GC.

I wrote a single sentence with a single point, not a a single point diluted over multiple paragraphs. You have to literally read only half-sentences to interpret my point the way you did.

If you aren't going to even bother reading full sentences, why bother engaging at all?

Re: Leaving Rust gamedev after 3 years

#750
post #460

Earlier quoted context omitted.

> I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection. I agree so much that I've been working on this for a whole year. There is a sweet spot : non-GC, with pointers (but bounded), i…

For me, this is Odin-Lang, it doesn't meet all the requirements you have listed, but it's ergonomic, fast, and comes with extensive core and vendor libraries. It's all just fun and reasonable. https://odin-lang.org/

Oh, that's quite on the mark!

Nitpicking: I'm not fond of reserving keywords like len or append.

  len(arr)
  append(arr, v)
Better is

  arr.len
  arr.append(v)
Also

  x: [dynamic]int
is quite verbose

Maybe better would be

  x: [int]   //dyn
  x: [int,2] //fixed
Post reply on HN