Comment by bdw5204
9 months ago
My impression of Rust is that it's a very opinionated language that wants everybody to program in a specific way that emphasizes memory safety above everything. That's a good idea, I think, for the systems programming use cases that it was intended for. I don't see that as a particularly useful thing to value for game development. The part in the article about the Rust borrow checker constantly forcing refactors sounds extremely obnoxious to deal with.
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 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.
> 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 indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.
Rust's safety is designed more for normal dynamic memory applications.
> 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". Everyone does.
That assertion was specifically qualified in the context of database engines, for which it is true. I definitely write bugs but I haven't seen a segfault or memory corruption in years. That is more of a C thing than a C++ thing.
It is kind of difficult to have a segfault or memory corruption with explicitly paged object memory, since there can't be any pointers and these complex objects are bound-checked at compile-time. If you care about performance and scalability, you don't need to concern yourself with multi-threading as an issue either. The main way you'd expect to see memory corruption is if you try to read/write a page in the middle of a DMA operation to the same memory, and Rust doesn't help you with that either (though this would be just a normal logic bug in the scheduler).
It is pretty easy to avoid segfaults and memory corruption in modern C++ if the software architecture doesn't allow you to create the conditions under which those are likely to occur.
5 replies →
This kind of extends to embedded/low level systems programming as well - the assumption that memory can only change as an effect of program execution just does not hold true there. What's the value of tracking mutability and data ownership when a DMA engine can just decide to overwrite the memory you supposedly have exclusive access to?
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), inference, basic OOP + tacking, and all the comforts of scripts. All in a good looking syntax without semi-colons.
So you can program fast and get a fast program.
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.
Better is
Also
is quite verbose
Maybe better would be
Seeing presence/absence of semicolons in the list of primary features makes me wary.
And it takes a lot of people to make good tooling.
I'm 100% fed up typing those damned semis all the time.. That's the very initial reason I embarked on a dialect of C. (That and strings)
They're mostly useless and a visual annoyance.
IMO it’s not opinionated enough. Golang for example doesn’t let you customize go fmt, while Rust does. Rust also has many ways to do things in general (mod.rs vs name_of_folder.rs for example) and seems to not want to provide a useful baseline for most projects via its standard library (unlike Golang).
But to go back to our subject: Rust is a great language and that’s all you need. I wish I could use it with unity.
The mod vs folder rs stuff is just embarrassing for Rust. I have no idea why they support more then 1 method.
The do it because the first one sucked ass and the second is a huge improvement but you still have to support the old way.
8 replies →
I speculate that they wanted to support just `mod.rs`, but because VS Code became the editor for rust people hated seeing all tabs named `mod.rs`.
Golang is indeed much more opinionated. To quote @bcantril, "Go is like steampunk for programming."
Most modern languages are memory safe and they don't get called out for emphasizing that or being opinionated. I think with Rust that attention results from its choice of memory management model which gets in the way a lot in ways described in the article.
> My impression of Rust is that it's a very opinionated language
It's not though. There's only one thing Rust is opinionated about.
> that wants everybody to program in a specific way that emphasizes memory safety above everything.
Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory.
> 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
As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.
Rust also is opinionated that you don't want to write shared libraries or plugins. You can do both, but only if you drop down to memory unsafe C interfaces. The default is statically compile all applications into one program. Rust also really wants you do to use their build system and package manager, you can avoid both but everything will fight you.
> Rust also is opinionated that you don't want to write shared libraries or plugins.
Not having a solution is not the same as having an opinion.
If you have years to spend on plugging at ABI stabilisation, generics and proc macros in dynamic linking, and redistributable std, I’m sure the core devs would be happy for you to.
> Rust also really wants you do to use their build system and package manager, you can avoid both but everything will fight you.
What do you mean everything will fight you? It sounds like you’re confusing rust and its ecosystem.
1 reply →
> As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.
So have your network protocol parser in Rust and the entire rest of your game in whatever the hell you want.
All the practical safety you could desire without any language constraints for the other 99% of the code
You more or less described Zig
Sort of, although Zig certainly pushes itself towards the embedded world. I have tried Zig a bit and like it a lot, and I am sure it would be better for game dev than Rust, but I don't want to pass allocators around all day to all the objects in my game.
Go without GC is more like a Go and Zig baby.
nothing really prevents you from defining global allocator in Zig
and having explicit allocator in standard library is actually a good thing, cause it's quite a common case in game development to use arena allocators which are being freed once per frame - so you don't really need to reinvent your data structures in Zig
I do have some concerns about Zig because it also introduces some friction for correctness sake like requiring to always use all variables, explicit casts everywhere - I want some compiler toggle to disable all of that and focus on problem but unfortunately it's not there
I am playing with Zig now and haven't really formed my opinion about game development specifically but I like it a lot so far
2 replies →
Odin is almost precisely that, and has many useful gamedev features and bindings.
> 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
Sounds like Common Lisp or OCaml would work well. With Ocaml I find myself being able to iterate extremely quickly because of the inferred types and extremely fast compilation times. You also have the ability to tweak the GC to your needs and the assembly is easy to read.
Lisp is well… built for interactive development