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

231–240 of 247 posts

Re: Why Rust Is the Future of Game Development

#231

Post by [deleted] »

Arainach wrote: post #202
samatman wrote: post #113

Earlier quoted context omitted.

I think it's more likely than not, yes. Jonathan Blow has a reputation for taking a rather long time to release something eagerly awaited, and the result being impressive and critically acclaimed. I hope Jai will be the same way. We'll see what happens.

Sure, but that works for a game where you can release it once and then everyone consumes it. Languages are ecosystems. They have tools, and libraries, and shims to integrate with other tools. They need evangelism. They grow with community involvement. As far as I know, no one has ever released a new language that was perfect in its initial release - there has always been feedback and syntax quirks that get addressed…

[deleted]

Re: Why Rust Is the Future of Game Development

#232

Post by halvnykterist »

Iwan-Zotow wrote: post #213
jayd16 wrote: post #15

I think Rust would eat into C++ more than C#. Microsoft is pushing C# and the tooling fairly hard right now. Performance is pretty good and even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. I don't think the population of studios that chose C#'s performance and convenience over C++ but would now choose Rust is all that large. But hey, lets start talking about bindings…

Not in a game business, but I could tell you - until Rust is supported (down to debugging) in Visual Studio, there would be no C#/Rust apps, and plenty C#/C++ apps.

Debugging in VS actually works pretty well already, the msvc target generates PDB files. It's what I use when need to attach a debugger to something. Actual language support would be really nice, though. Hopefully MS are already working on this.

Re: Why Rust Is the Future of Game Development

#233

Post by jstimpfle »

pjmlp wrote: post #191
Scramblejams wrote: post #147

Earlier quoted context omitted.

Those games will have been written in such a way as to avoid allocations like the plague, giving the GC very little to do. Sometimes your game can be written that way -- sometimes it can't.

Just like you have to avoid malloc() in C written games.

First, you don't have to avoid malloc() or similar allocators in games necessarily. You should avoid it in performance constrained situations. And you only should avoid calling malloc. It's not necessarily a problem to use these allocations in those situations. That's quite unlike Java, unless you're a GC wizard, and I'm not sure how far even those wizards can circumvent problems.

Second, to my knowledge it's still very cumbersome to avoid GC allocations in Java. By comparison, it's easy to reduce calls to global heap allocators in C.

Re: Why Rust Is the Future of Game Development

#234

Post by rafaelvasco »

> The performance of C++ with the convenience of C#

Convenience is a relative term. Convenience to what ? Personally, I find that far from the truth. Rust is very powerful, offers lots of flexibility in memory managing and allocation, which makes a difference in gamedev, but overall it's far slower to code in, because of that. And that is very bad for gamedev, in which fast iteration times is crucial. You code something, test it. Scratch it. Fix it. Test it. And so on.

Re: Why Rust Is the Future of Game Development

#235

Post by pharke »

HelloNurse wrote: post #222
pharke wrote: post #143

Earlier quoted context omitted.

That's counter productive when it comes to gamedev. Most of the code you write for a game is going to be thrown out at some point. Being able to get the idea onto the screen and iterate rapidly is worth a lot more than not having a dev build crash after a while. Make it work, make it right, make it fast except the last two are usually transposed in gamedev.

> iterate rapidly is worth a lot more than not having a dev build crash after a while You are missing the part about wasting hours or days to investigate the crash, easily offsetting the time saved with fast and loose coding. It would be nice to see examples to judge whether a stricter language like Rust can save more time on the debugging and fixing side (by reducing mistakes) than it costs with verbose syntax and "…

You only have to debug the code if you're going to keep it. I'm not going to spend days debugging a prototype made of spaghetti, it'll have served its purpose and I'll start over with optimization in mind and refine the idea. If you wanted a programming language that would be a real win for game development you'd choose something that had the option of no type or memory safety and no boilerplate for prototyping with an option to turn those options on for when you actually integrate the feature with the rest of the code.

Re: Why Rust Is the Future of Game Development

#236

Post by pjmlp »

jstimpfle wrote: post #233
pjmlp wrote: post #191

Earlier quoted context omitted.

Just like you have to avoid malloc() in C written games.

First, you don't have to avoid malloc() or similar allocators in games necessarily. You should avoid it in performance constrained situations. And you only should avoid calling malloc. It's not necessarily a problem to use these allocations in those situations. That's quite unlike Java, unless you're a GC wizard, and I'm not sure how far even those wizards can circumvent problems. Second, to my knowledge it's still v…

First, also possible in GC enabled languages. That is what profilers are for.

Second, it is relatively easy to do native memory allocation in Java, but apparently people keep forgetting to learn their toolbox properly.

Third, calling malloc() is such an issue that there used to be companies specialised in selling optimised versions of malloc()/free().

Re: Why Rust Is the Future of Game Development

#237

Post by jstimpfle »

pjmlp wrote: post #236
jstimpfle wrote: post #233

Earlier quoted context omitted.

First, you don't have to avoid malloc() or similar allocators in games necessarily. You should avoid it in performance constrained situations. And you only should avoid calling malloc. It's not necessarily a problem to use these allocations in those situations. That's quite unlike Java, unless you're a GC wizard, and I'm not sure how far even those wizards can circumvent problems. Second, to my knowledge it's still v…

First, also possible in GC enabled languages. That is what profilers are for. Second, it is relatively easy to do native memory allocation in Java, but apparently people keep forgetting to learn their toolbox properly. Third, calling malloc() is such an issue that there used to be companies specialised in selling optimised versions of malloc()/free().

Oh, come on.

Re: Why Rust Is the Future of Game Development

#238

Post by ibobev »

blub wrote: post #169
bsoft16385 wrote: post #152

Earlier quoted context omitted.

The one thing I will note is that most of what you have said about performance is relevant primarily in the AAA game space (and in higher end mobile titles, which increasingly look like AAA games). In the indie space, you see a lot more titles where performance is a secondary consideration. The concept (and the style of the visuals) is often more important than having cutting edge graphics. There are also segments of…

"In the indie space, you see a lot more titles where performance is a secondary consideration" With the added mention that the game still has to run smoothly, otherwise it's extremely annoying, no matter how great the concept.

But for a lot of indie games smooth running is not a significant problem, because simply their scenes are not complex enough and it is not a big deal even if they are written on some programming language which is not of the highest performance ones like C# or Java (The original version of Minecraft for example is written in Java). There are many successful indie games which are even not 3D (FTL or Darkest Dungeon for example).

Re: Why Rust Is the Future of Game Development

#239

Post by iphorde »

pjmlp wrote: post #190
iphorde wrote: post #172

Earlier quoted context omitted.

There is nothing wrong with Java except the issues surrounding protecting your code from reverse engineering.

That applies to any language. Hex-Rays and similar are also a thing for native compiled code.

Yes/no, what hex-rays ida gives you is not worth the effort. It is a guess, and it doesn't do well with complex algorithms. Go try it on libjpeg. Compile it to release, no symbols, and let me know what you can extract. That is what I tested it with, and I didn't get much.

Re: Why Rust Is the Future of Game Development

#240

Post by ncmncm »

shmerl wrote: post #200
ncmncm wrote: post #195

Earlier quoted context omitted.

They have work to do, and tooling to do it with. Show them Rust, and they will say "what can it do that my tooling doesn't?", and then you must be silent.

It means they aren't curious about progress. Not someone you want to hire, unless those who run projects don't care about anything either. And sure, you can explain to them what better tools can offer. That was the point of the linked post. And if they don't want to hear the answer, then again someone probably hired wrong people there.

Also: you assume you are the arbiter of progress. Not everybody agrees with your assessment.

For example: spending an extra hour or three each day, waiting for the compiler, might not seem like progress to everybody. Their assessment is as valid as yours.

Furthermore: you assume that people who hire must also agree with you. But, some people who hire want coders coding more and waiting for builds less. That is a legitimate desire.

Post reply on HN