91–100 of 247 posts
Two weeks ago Rust was the future of embedded systems (it is not) and now it is the future of Game Development (it is not). I'm starting to think that people's opinion shouldn't be taken seriously unless they have like at least 20 years of experience in a particular field.
Hey, Rust is the future of bitcoin and vice versa.
Rust is not even on the table even in the future.
Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefi…
To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of cost that's spent dealing with bugs in the future.
This is, by far, the most credible argument in the piece. Access and tooling for new platforms is a critical factor for games.
Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefi…
Agreed. The extremely slow compile time and extremely limited data flexibility is blocking rapid development. As an alternative to C++, JAI is more promising in my opinion.
Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefi…
Isn't this basically saying that you can't have the compiler guaranteeing you aren't including bugs in those optimizations / global variable usage because it's more efficient to just write and then ultimately ship some bugs? To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of…
Earlier quoted context omitted.
Isn't this basically saying that you can't have the compiler guaranteeing you aren't including bugs in those optimizations / global variable usage because it's more efficient to just write and then ultimately ship some bugs? To me it seems like this would require a significant adjustment in how certain problems are approached, but the outcome would likely be more effective development as you could eliminate a lot of…
No, it’s saying that you can do clever memory optimizations that the Rust compiler won’t let you do.
Earlier quoted context omitted.
There are some AAA game engine and graphics developers actively using Rust in their main codebase like RAD and Embark, and many are Rust curious and using Rust for side projects or tools. It's true that it will be a while before wide Rust adoption happens in the game industry (if ever) and C++ will stay around for a while. As for tech in games moving slowly... there is some truth to that but some things also move muc…
Chucklefish, the developer of Starbound, uses Rust too. The lead dev on the project gave a great presentation [1] at RustConf. [1] https://youtu.be/aKLntZcp27M
Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefi…
One of my first experiences interacting with a golang programmer, was in the context of my game server project. As an optimization, I had a race condition in the code that disconnected clients. After all, if the connection is about to die, I don't care if it dies in frame n, n+1, n+2...etc. This golang programmer was totally out to tell me I'm stupid, ugly, and bad, because I should always be using -race and always have 0 race conditions.
Like, it would have been one thing if he could've had a cogent discussion around how the build should be free of warnings, because that makes such signals super clear, but no, it was just pure dogmatism.
Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state.
In ECS, why should object ownership be an issue? The Systems can just own everything.
Right now, I'm writing something 3D game related. It needs considerable parallelism. The existing tool in this area is mostly single threaded, it's a mess internally, and everyone who looks at it is scared to try to parallelize it.
So I'm writing in Rust. Safe concurrency is a plus. There are some other wins. You can be bolder about not copying things. When decoding an incoming packet with a lot of structure, I'm creating linked data structures where most of the big byte array stuff is borrowed from a packet buffer that went into the structure creator. No allocations; it's all on stack. There's no risk of someone using an item from one of those structures and keeping a reference to data that's going to go away. Wouldn't dare do that in C++.
I get along with the borrow checker just fine. Once you realize that single ownership is a tree, it makes sense. It's the type inference system that causes headaches. Rust has type inference in both directions. There are places where the result type influences what goes in. When the inference system guesses right, it's great. When it can't solve the problem on its own, trying to figure out what it wants is annoying. Go and C++ only have forward type inference; result types are computed by the compiler.
Rust is really a single assignment language, not a functional one. There's a lot of "let foo =", and not much "let mut foo =". After a while, you get the idea that if you write "let mut", you're doing it wrong. Single assignment has most of the benefits of functional, but without multi-line expressions that go on to infinity. Plus you're not limited to a tree of results; you can have directed acyclic graphs, because you can usually re-use the value from a "let".
The type of error objects is still a mess. Rust needs something like Python's exception type hierarchy and a consistent way to convert special error types into more general ones. I notice there's a Rust working group on error handling, again.
Rust needs a good book. Not "The Rust Programming Language". That's too hard for an introductory book and not detailed enough for a reference manual. A book by someone who didn't develop the language is needed.
The library situation has improved quite a bit since the last time I tried Rust, a few years ago. Back then, finding a library to do HTTP was "No, the one you're using is obsolete, use ...". Now I'm finding usable libraries for obscure things like analyzing files from "tcpdump".
They missed a chance on something important to 3D work. Each library which uses 3D vectors has its own structure for them. There's a proposal for a common format, "mint", but it's not getting traction. This is an old headache in 3D programs with components from different sources. Back when I was developing ragdoll physics, I had four 3D vector types in one C++ program.