Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

421–430 of 996 posts

Re: Leaving Rust gamedev after 3 years

#421

Earlier quoted context omitted.

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

> 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".…

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.

Re: Leaving Rust gamedev after 3 years

#422

Earlier quoted context omitted.

Threading, probably.

Async/await isn't related to threading (although many users and implementations confuse them); it's a way of transforming a function into a suspendable state machine.

I know. But threading, and earlier processes, were less scalable but potentially faster ways of handling concurrent requests.

Re: Leaving Rust gamedev after 3 years

#424

Earlier quoted context omitted.

> incendiary responses to rust criticism can be I've not experienced this. Do you have examples of the rust community flaming someone for having negative opinions about the language?

I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community. Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.

I'm active on both and have not seen this behavior.

In fact, my experience has been the polar opposite, the rust community has been very friendly and accepting of critique.

So again, I'm going to ask for an example of rust language fanatics frothing at a criticism. If it's such a community problem this should be easy to find correct?

Here's the OPs article on /r/rust and it's both got a fair number of up votes and the top comments are all really positive towards this article. That's what I've seen at typical in the rust community.

https://www.reddit.com/r/rust/comments/1cdqdsi/lessons_learn...

Re: Leaving Rust gamedev after 3 years

#425
post #51

Earlier quoted context omitted.

That's not an argument against parallelism in game design in general.

Almost all parallelism in game engines is for very specific parts of the engine and almost none of the gameplay stuff is paralellizable. What people who haven't actually had to go through and solve the problems presented in game engines often times misunderstand is that when your game is running poorly because everything is happening on a single thread, almost all of this speed issue is because of rendering. Then phy…

> almost none of the gameplay stuff is paralellizable

Define gameplay. If you have some simulation happening as part of the gameplay, parallelizing it can be quite useful vs killing one CPU core on it. Physics is just one common example, but not everything is about physics. You can simulate whatever.

Re: Leaving Rust gamedev after 3 years

#426

Earlier quoted context omitted.

I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community. Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.

If it helps, they can't possibly be as toxic as Lisp programmers used to be, where more or less any online conversation would start with someone new asking a question and Erik Naggum replying that they were a moron who should die.

Lol, I had a similar example with perl as a young teen programmer.

They've gotten way nicer.

Re: Leaving Rust gamedev after 3 years

#427

Interesting to me to have [iteration speed] [maintainability] spelled out as opposite ends of a spectrum... and that sometimes [iteration speed] is the right thing to optimize for.

It's not news though? Favoring iteration speed at the cost of future maintainability is a common argument for dynamically typed languages.

Certainly--just having it spelled out like this was new to me?

Re: Leaving Rust gamedev after 3 years

#428
My favorite thing about rust is when rust devs say that the slow compile things aren't a big deal and then show how that just by dropping a few dependencies you can get hello world down from 90 seconds to 30 seconds.

Re: Leaving Rust gamedev after 3 years

#429

I use Nim at work. It is a joy. I replaced a prototype Rust application which was confirmedly not a joy. None of Rust's highly opinionated safety semantics necessarily imply a better end product, and often make delivering an end product much more difficult. Rust has use cases, but it is a specialized hammer for a specific domain of nails. It is not the cure-all everyone wants it to be. If you're asking if you should…

> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all. This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pas…

Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications.

My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.

Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.

Re: Leaving Rust gamedev after 3 years

#430
post #262

Earlier quoted context omitted.

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

Isn't the traditional advice that if you try to write both a game engine and a game that you'll get neither?

I mean, it's not like there are no games in existence that shipped with a custom engine.

Even in hindsight it's hard to judge whether building your own engine was good or bad decision, and we are nowhere near "the hindsight" level of knowledge.

Post reply on HN