Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rust Is the Future of Game Development

thefuntastic.com

Post reply on HN
Print view View original

101–110 of 247 posts

Re: Why Rust Is the Future of Game Development

#101

Post by steveklabnik »

rhodysurf wrote: post #88
FartyMcFarter wrote: post #62

Earlier quoted context omitted.

It's still quite easy to shoot oneself in the foot with modern C++: #include #include #include int main() { std::string_view v = std::string("xyz"); std::cout

OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below

Isn't it a use-after free? (I haven't had time to compile and run it)

You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.

Re: Why Rust Is the Future of Game Development

#102

Post by HappySweeney »

zyxzevn wrote: post #72
dimes wrote: post #47

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.

Jai used to be interesting, but after a while it feels like Jon believes his language is a competitive advantage, and will never come out. It's either that or he painted himself into a corner and needed years to get some must-have feature working.

Re: Why Rust Is the Future of Game Development

#103

Post by tomovo »

HappySweeney wrote: post #102
zyxzevn wrote: post #72

Earlier quoted context omitted.

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.

Jai used to be interesting, but after a while it feels like Jon believes his language is a competitive advantage, and will never come out. It's either that or he painted himself into a corner and needed years to get some must-have feature working.

Just shipped 31st beta AFAIK.

Re: Why Rust Is the Future of Game Development

#104

Post by pirocks »

na85 wrote: post #90
tormeh wrote: post #86

Earlier quoted context omitted.

GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.

>GC is a no-go, as it causes unacceptable frame-rate dips. Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.

I play a lot of minecraft and GC related framerate issues are usually not a problem, but when they are a problem they can be quite annoying. You tune gc performance for your gameplay workload to a certain extent but obviously most players don't.

Re: Why Rust Is the Future of Game Development

#105

Post by cylon13 »

adamnemecek wrote: post #49
hvasilev wrote: post #43

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.

I mean C and CPP are used in both fields so it's not hard to imagine that since Rust is trying to replace both languages, that it would become popular in the two fields as well.

You do usually find the C preprocessor where you find C, yes.

Re: Why Rust Is the Future of Game Development

#106

Post by clappski »

rhodysurf wrote: post #88
FartyMcFarter wrote: post #62

Earlier quoted context omitted.

It's still quite easy to shoot oneself in the foot with modern C++: #include #include #include int main() { std::string_view v = std::string("xyz"); std::cout

OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below

The issue isn’t anything to do with copying - the issue is that a string_view is a non-owning reference, and that std::string on the right side is an rvalue. Meaning that when you deref the char* in the string_view you’ll segfault or summon demons or something.

Re: Why Rust Is the Future of Game Development

#107

Post by AsyncAwait »

andrewmcwatters wrote: post #34

This article doesn't actually talk about "Why Rust Is the Future of Game Development." You could have taken out the game development piece, and it still doesn't talk about "Why Rust Is the Future of Development," more than talking about Rust features themselves. I should be able to complete the sentence, "Rust is the future of game development because...," but I can't in any meaningful way. Here are the highlights of…

> It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust.

I think multiplayer is an area where you'd want "fearless concurrency". Rust could do well here.

Re: Why Rust Is the Future of Game Development

#108

Post by kbenson »

coddle-hark wrote: post #96
jrsj wrote: post #93

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.

Actually "won't let you do" or "makes you clearly mark where you did those things"? That is, are you referring to things it doesn't actually support doing that you want/need to do, or just that it's unsafe?

Re: Why Rust Is the Future of Game Development

#109

Post by thom »

Realistically, do current practices even work for game development? Obviously many games are wildly profitable, but the amount of human suffering and crunch time that goes into the release of an AAA title, and indeed into its day zero multi-gigabyte patch to make it actually playable, seems to imply that we should at least be open minded. But also I suspect many of the issues aren't just your choice of language.

Re: Why Rust Is the Future of Game Development

#110

Post by Semaphor »

ThePadawan wrote: post #59
lstodd wrote: post #9

Let me tell you that the future of game development is in developing games, and any particular language has nothing to do with it. Does anyone care what language were any particular games that keep being replayed or remembered fondly? No. Never.

> Does anyone care what language were any particular games that keep being replayed or remembered fondly? > No. Never. I certainly remember games more that still have an active modding community, which is (somewhat) enabled by the choice of programming language. I doubt Rimworld or Minecraft would have the thousands of mods they do if modders had to write OCaml instead of Java or C#.

Thanks to Unity Mod Manager and Harmony (C# Monkey patching Framework), unity games even get mods pretty much for free without the devs doing anything to support them.
Post reply on HN