Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

471–480 of 996 posts

Re: Leaving Rust gamedev after 3 years

#471
post #358

Earlier quoted context omitted.

My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.

> My impression is that this is due to their non-robust programming style. It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job. > They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash. This is a pretty big feedback loop: * The programmer puts the null into the code * The code is release…

50+ years and people still fail to grasp this.

You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing.

Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.

Re: Leaving Rust gamedev after 3 years

#472
post #455
post #408

Earlier quoted context omitted.

Use Rust if crashes or memory bugs are not an option. For everything wasm, Rust is much more pleasant with good libraries than the competition.

Wasm seems more convincing to me than the magical 'no crashes or bugs' promise. Here's my wasm use case: tell me how I can use Rust. I have a command line tool written in C that ..say.. takes strings and outputs strings. How would I go about making a usable REPL out of this in Rust and wasm without rewriting the tool?

But when you look at the disaster that was c++ for cloudflare, and the switch to rust.

This is precisely the argument given against rust for video games: too much typing induced by memory safe, which is too restrictive.

Is there any use if your c code works, the advantage of rust over wasm is the easy-to-use packages (which is a pain in c++), and the ease with which you can make a wasm project with wasm-pack that generates the wasm, js and ts interface.

There really are a lot of libraries that support wasm, it's even a problematic point raised in the article on bevy, with wasm support (so webgl) limiting the api.

Re: Leaving Rust gamedev after 3 years

#473
This is a decent article, but although the points themselves are valid, I think there's a core "issue" with (indie) gamedev itself.

The vibe that I'm getting is that it's filled with people that don't particularly care about programming, they just want to get stuff done(TM), this is also highlighted by the fact that they are willing to write completely inadequate code just to see things working. Rust is not that, and that's a good thing.

More generally, I'd say that in gamedev anything goes, as long as it's fun and isn't too buggy. Rust is not, and never will be able to accomodate that mindset, which again, is a good thing if you think for 2 seconds and consider what Rust is actually aimed at, which is safe systems programming.

You can have the core engine written in Rust and have a scriptable language on top of it, there aren't any major pain points in this regard. The scriptable language will be able to provide all of this hot-reloading-anything-goes-yes-sir bullshit that we all know and love.

tl;dr: Use the right tool for the job. A language designed for safe systems programming can't do non-safe non-systems programming very well. Who knew!

Virtually all of the points outlined in the article stem from the above.

Re: Leaving Rust gamedev after 3 years

#474
post #32
post #24

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 soun…

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.

Golang is indeed much more opinionated. To quote @bcantril, "Go is like steampunk for programming."

Re: Leaving Rust gamedev after 3 years

#475
post #443

Earlier quoted context omitted.

The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more. Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a…

Jonathan Blow’s Jai is an attempt at something like this. It’s looking promising so far!

Interesting. I went through the primer spec. Appears to be a different kind of D or Go with some key points. Any new language should begin with a specific thesis of specific competitive advantages and problems it solves over existing customary and alternative tools. Kai appears to fulfill this property, so that's a good sign.

Re: Leaving Rust gamedev after 3 years

#476

Earlier quoted context omitted.

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 b…

A language is in large part the ecosystem. If I can't use the expected ecosystem I can't search for answers.

Re: Leaving Rust gamedev after 3 years

#477
post #448

Earlier quoted context omitted.

> But you still need a resolution mechanism to fix the error At least initially, the resolution mechanism could be "don't include more than one implementation".

Assuming you have no control over trait implementation, how would that work? To reuse the canonic example: // crate "types" pub struct Thing; // crate "traits" pub trait Action {} // crate "alpha_v0" impl traits::Action for types::Thing {} // crate "beta_v1" impl traits::Action for types::Thing {} // Doesn't exist for beta_v0 Say by transitive dependencies, alpha_v0 and beta_v0 are imported, and due to vulnerability,…

Yes, that's the downside of relaxing the orphan rule. That doesn't mean there has to be a way for the top-level crate to work around that, other than avoiding having both of those in its dependency tree.

Ideally, people would tend to put trait implementations for a given pair of crates in a unique library crate, implement them in the obvious way, and provide that as a library for people to use.

Re: Leaving Rust gamedev after 3 years

#478
post #450

Earlier quoted context omitted.

It's C++ replacement just not yet there for game dev (maybe never for game dev)

A C++ replacement must have really strong and seamless C++ interop to be considered by anyone currently using C++. You can't have a C++ replacement by ignoring existing C++ users and libraries, no matter how good the the language is. Swift from Apple and Carbon from Google are stronger contenders at this point.

No language from Apple / Google / Microsoft / whatever can ever be a serious replacement for C++. When the development of the language is dominated by a single entity, the risk that the interests of that entity override those of other users is simply too high.

Vendor-specific languages are fine, if you are developing something for that vendor's ecosystem. But if you don't want to lock your code to a specific ecosystem, an independent language such as C++ or Rust is a better choice.

Re: Leaving Rust gamedev after 3 years

#479

Earlier quoted context omitted.

Repo contributor here, just to curb some expectations a bit: it's one very smart guy (Kenny), his unpaid volunteer sidekick (me), and a few unpaid external contributors. (I'm trying to draw a line between those with and without commit access, hence all the edits.) There's no other internal or external Microsoft /support/ that I'm aware of. I wouldn't necessarily use it as a signal of the company's intentions at this…

That's disappointing on Microsoft's part, because their docs make it seem like windows-rs is the way of the future. Thanks for your work, though!

I wish Microsoft had any direction on the 'way of the future' for native apps on Windows

Re: Leaving Rust gamedev after 3 years

#480
post #262

Earlier quoted context omitted.

Well the problem with Jonathan's argument here is that he's spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games. So it turn out that even if he's opinion on Rust is correct, he would still have been much more productive using it than trying to build his own language for a decade… (But he already shipped his masterpiece and he's a millionaire…

He is actively developing his new game in parallel to creating the language. Not to mention smaller projects like 'Braid- anniversary edition'.

Yeah, and it's taking him YEARS to implement a simple grid-walking Sokoban clone, and Braid anniversary edition had to be delayed.
Post reply on HN