Hi.

i just hear alot these days about Rust language. it seems that it outperformes c++ and is faster than c++. its managed like c# and java and has not problem of memory allocation and management and has efficient Garbage collection system. there are some news that some studios prefer to start code on Rust and just use c++ for maintenance. like this:

im just searching to see that is Rust worth learning for game development or not. as good replacement for c++ is there any plan to see gamedev Api,s like graphics API,s on Rust?

I am just a hobby programmer, so what i write is probably not very ripe and sophisticated ?

I spent some time recently checking out Rust and D, very superficially. Rust has this site where they advertise their game ready-ness. I personally had problems with the syntax of Rust, that object.function..subfunction.whereisthis and so on. Also, the philosophy of "you can't count to 8 so i won't let you" wakes the rebel in me. Their learning tutorials spend too much time and space reiterating how it is different from the rest of the languages and that that is good. Actually, i'd like to see how a rust program really runs as fast as a good c program. They are a pretty committed community, so it appears to me.

I had more luck with D. Its syntax is pretty clear and there are actually games written in it, i found even a game engine, because C apis can be integrated without extra gymnastics. And it is not that much slower than C (Mandelbrot set ~30%) when compiled with gdc, the gcc front end for D. But the reference compiler dmd is much slower than gcc, really a factor of 2-3, probably due to bad optimization.

Am very interested in other, more experienced opinions than mine as well !

Edit: i read a gcc frontend for rust is in preparation/being spoken about.

Editedit: Yes, the tweet was proudly presented on the rust forums ?

7 hours ago, Green_Baron said:

i'd like to see how a rust program really runs as fast as a good c program

ripgrep is a good and fast program to to come from the rust community.

C api's can be bound in rust.
Rust is more restrictive than other languages, hence it's "guarantees". Some will like this, some won't.

Can rust change the future of game making?
I'll say yes, and it already has. Not in the sense that all games will be made in Rust, but that it will popularize ideas and then these ideas may be incorporated into c++.

i will say it is nice to have another systems level language. so far I've enjoyed it.

14 hours ago, moeen k said:

it seems that it outperformes c++ and is faster than c++. its managed like c#...

It seems like a contradiction to me. I don't know Rust, but c++ is not inherently fast. It is only fast if you use it properly. There are a lot of pitfalls that can slow a c++ program down. Maybe Rust has much less of these pitfalls because of this:

6 hours ago, Plotnus said:

Rust is more restrictive than other languages, hence it's "guarantees".

In conclusion, I guess the "average programmer dude" might generally be able to write faster code with Rust than with c++, because he is not allowed to mess around with stuff he barely understands.

On the other hand, an experienced programmer will use the extra control of c++ to his advantage and will probably generate faster code with C++.

14 hours ago, moeen k said:

has not problem of memory allocation and management and has efficient Garbage collection system.

Memory management is not a problem. It's actually a gift if you know how to utilize it to your advantage. If you don't know how to handle it, it might be a problem. However, using a garbage collection system is probably not what you want if you aim for maximum performance since it always comes with a management overhead. That's why I said that 'fast' and 'managed' seems like a contradiction to me.

In general, more control means, more pitfalls but also more possibilities. In the end, all that matters for performance is machine code (cache/memory issues neglected) and that depends on the capability of your compiler to translate C++/Rust into effective machine instructions. The language you use is only important in the context of how well you can explain to the compiler what you are intending to do.  The better he knows what you want, the better he is capable of optimizing the code. Therefore, it needs to be precise and also rich enough to cover all possible problems. It's a little bit like ordering a pizza. If you want one with salami and extra mozzarella and you say  'cheese' because your language does not know the term 'mozzarella', you might end up getting gouda instead.

To sum it up:

Since C++ is designed to be as close as possible to the hardware in a portable way (in contrast to assembly, which is hardware-specific), I doubt that Rust generally outperforms optimized c++. It might get equally fast with less verbose/complicated code but I am also not sure of that (garbage collection). I might be wrong. I don't know everything... YET! ?

Greetings

Programming language of choice isn't what makes a program fast.  Sure, there are small benchmark type things (like doing matrix transformations, etc.), but those are not a reflection of reality.  It starts with the architecture of your program: how are your the different components defined and implemented?  How do those components interact with each other?  From those interactions, how is the data defined and how does the data flow through the program?  How many nested loops do you have in your functions? How many levels of polymorphism or inheritance? Then there is memory access, how cache friendly are the components in your program?  Are there a lot of components being iterated over whose data is only partially touched within a function?  If you are using a compiled language, do you know what all of the optimization flags do?  Last, know the platform that you are developing for.  Understand the hardware.  At risk of getting on my soapbox, the Right Once, Run Everywhere© mindset is why we have really bad applications that appear to run slower than programs written 20 years ago despite having processor speeds that are orders of magnitude faster (looking at you Photoshop). 

Programming languages are just tools.  Use the best tool for the task at hand.  Sure, you can use a hammer to drive a screw through a piece of wood, but you would find better (and neater) results with a screw driver.

Others have chimed in so a few words may mirror theirs.  Remember the programming language is a tool.  

I've worked on many major AAA games over the years.  All of them were developed with a slew of programming languages.  I cannot think of any major game I've worked on that was limited to a single programming language.  Most in my experience use at least five.  A relatively simple port that we did recently (Duck Game) only used three. The most complex game I worked with (The Sims) used so many languages and variants that it was hard to count, mid-twenties at least.

Rust has some great features.  For some tasks it may be a wonderful fit.  If that's the case for what you're building, absolutely you should use it.  However, for some tasks it may be a bad fit. If that's the case for what you're building, look to another language.

C++ has some great features. For some tasks it may be a wonderful fit.  If that's the case for what you're building, absolutely you should use it.  However, for some tasks it may be a bad fit. If that's the case for what you're building, look to another language.

Repeat this for every programming language.

Every feature you mentioned has the potential to be a boon, and the potential to be a hindrance.

• "it seems that it outperformes c++ and is faster than c++" --- raw computing is raw computing regardless of the language used.  Ultimately all programming languages boil down to the CPU instructions fed to the processor.  Usually it is the broad algorithm choices and not the individual instructions that make the difference here.
• "its managed like c# and java" --- In some contexts this is a boon, in other contexts it is a severe penalty.  Managed languages must be processed through a secondary system. While managed languages permit a few additional optimizations at runtime, that optimization comes with a cost at runtime when invoked, often in the form of a rather painful initial startup. The older style of languages, unmanaged if you will, require more time when you compile them but can generate heavily elided output. Complex systems that must remain in managed code in order to satisfy demands of the intermediate language for reflection and introspection system can often be completely eliminated in unmanaged code, resulting in faster --- sometimes many orders of magnitude faster --- execution performance.  Managed languages offer those features like reflection that greatly simplify some tasks, and help enable features like plugin architectures and game mods. Pros and cons depend entirely on the situation.
• "has efficient garbage collection" --- Garbage collection systems are amazing in some situations. When your system has tons of idle time, when the system has scads of memory in the pool, when using an advanced generational garbage collector and tools that allow incremental processing, garbage collection enables great things.  In those situations resources are cleaned up when the system is otherwise idle, in contrast to the naive method most simple c++ programs use that performs memory work during the busiest processing times.  However, games rarely have tons of idle time, and memory is often at a premium in games. So many times over the years we've had random stutters in games that are tracked back to garbage collection.  Because garbage collection has a nightmare scenario, that's when expensive GC routines must be run in order for execution to proceed because the pool is fragmented or exhausted or polluted or otherwise not able to satisfy a request.  Then the entire program must stop and wait for the garbage collection to run.  The more memory in the pools the longer the delay.  Even a moderately sized 256 MB pool can take multiple graphics frames to complete a GC scan.

If Rust works for your product and satisfies your needs, then use it.  If something you are doing is easier or more efficient or otherwise objectively better in Java or C# or Python or Perl or Go or Rust or JavaScript or C++ or C or Pascal or raw assembly language, by all means use that language.

On 9/23/2019 at 3:50 PM, moeen k said:

and has efficient Garbage collection system.

Note: Rust does not use garbage collection. It uses scope and lifetimes at compile time, and reference counts at runtime.

thank you for answering my friends.i know games are developed with many different languages and many angines suport many languages but we all know c++ is most language near the hardware and gives lots of optimization responsiblity to developer. graphics APIs like DX and OPENGL officially are made to work with c++. graphics processing is based to with with c++.  one big example is that microsoft tried to make DX for c# but they couldnt as c# base features. now we have rust with mentioned features. i want to know can it replace c++ with these optimization features? @frob

Rust positioning as alternate to C not quite C++.

But C dying 20 years and still young. :D