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.
Leaving Rust gamedev after 3 years
741–750 of 996 posts
Re: Leaving Rust gamedev after 3 years
#742The 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.
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
#743Earlier 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.
Re: Leaving Rust gamedev after 3 years
#744Earlier 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"...
Re: Leaving Rust gamedev after 3 years
#745Rust... 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…
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
#746Earlier 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.
This is why virtually all proprietary codebases aimed at "shipping a product" are a clusterfuck.
Re: Leaving Rust gamedev after 3 years
#747Earlier 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!
Re: Leaving Rust gamedev after 3 years
#748Earlier 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.
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
#749Earlier 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…
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
#750Earlier 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/
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 verboseMaybe better would be
x: [int] //dyn
x: [int,2] //fixed