1 minute ago, Fulcrum.013 said:

Yes. Managed and GC is not acceptable for realtime

Then you have a different view of what's acceptable than most other people.

Managed languages like C# can be used to make games just fine, e.g. in Unity. They have been made to make games just fine. For example the absolutely gorgeous and amazing Ori and the Blind Forest.

Just now, Lactose said:

Managed languages like C# can be used to make games just fine, e.g. in Unity.

Uniti is just a ugly primitive tool that ever can not handle basic phisic lows so good for school-boys approaches only, not for real games production.

Just now, Fulcrum.013 said:

not for real games production.

No true Scotsman fallacy. Real games are produced in Unity. This is not hard to prove; I already did so in my previous post.

3 minutes ago, Fulcrum.013 said:

Yes. Managed and GC is not acceptable for realtime becouse have unpredicable time of GC and JIT operations and also not able to place a temparary data on stack so uses massive heap reallocations were it not needed.. Also automatic GC limit abilities of automatic objects lifetime managment so it better way to have a memory leaks. Really GC able to collect automatically only garbadge that language core shit   to heap. In case language core not used heap without direct programmer command it just no need a GC. Also GC under hood limit prograamer in garbage collection mechanisms to primitive one that can not be ajusted to specific tasks realities. For example it makes a huge headpain with self deletion of objects and so on. Really semi-automatic strategy that works on 2-way pointers and weak owning an processng lists many tmes much robust, flexble and reliable than managed languages GC. Really  languages wth GC not capable ever to create a good desktop gui framework becouse not allow to complete control a objects lifetame.

I have a lot of the same pet peeves about managed languages and I mostly  use C++ for everything that isn't scripted, however I think a lot depends on what you are doing.  If you are using a library that does the heavy lifting in C++ already, then a managed language might be acceptable. However if you are writing something that takes  a lot of CPU and/or allocates and deallocates a lot of small objects then I think C++ is probably a better choice. Also I hate mixing languages if I don't have to. So if I have to write a a lot of code in C++ anyway I might as well write the whole thing in C++ and avoid that headache

Then again Minecraft was written in Java and it's been wildly successful so it's really hard to make the argument you should never use a managed language.

9 minutes ago, Lactose said:

Real games are produced in Unity. This is not hard to prove; I already did so in my previous post.

Just look to docs. Ever in pro version it can not handle over 200 players per server. It just to slow for serious games that can have 5000+ clients on location for MMORG or 100k clients per server on MOBA. Also look at docs. It architecture not ready to complexive game mechanics. Rendering engine implements news of rendering technologies with 7-10 years delays. And so on. Really engeenes that good for serious development nobody will give for free or sold for 100.  In case it sold it usualy  sold together with company that made it.

1 minute ago, Fulcrum.013 said:

It just to slow for serious games that can have 5000+ clients on location for MMORG or 100k clients per server on MOBA

Again, this is still the No True Scotsman fallacy. A game can be "a real game" without needing to support 200 players per server, 5000+ clients in an MMORPG or 100k clients in a MOBA. There are other "real games" than MMOs and MOBAs.

Unity/C# and managed languages might not be the best choice for all kinds of games, especially games with fairly extreme requirements end-to-end, but Unity/C# and managed languages are perfectly fine for most "real games" most game developers will ever work on. Especially if in the situation where you are able to choose your own tech stack like this.

4 minutes ago, Lactose said:

No true Scotsman fallacy. Real games are produced in Unity. This is not hard to prove; I already did so in my previous post.

Maybe we could agree upon GC, stl, scripts etc being 'mostly good enough' for non performance critical game play code, but too slow for physics simulation or likewise.

There was a time when those things had being considered a no go for game dev in general, which implies we do waste performance and energy if we use them on more powerful current hardware of today. Is it more productive, or just lazy / incompetent to code more and more parts or even full games this way?

Not sure myself, but it's good some people still point out it's inefficiency.

6 minutes ago, Lactose said:

but Unity/C# and managed languages are perfectly fine for most "real games" most game developers will ever work on.

Managed languages is not ready for any complexive software. Microsoft has developt C# as replacement of VBA for internal purposes. It abilities limited by tiny one form utilites like calculator and etc.  Just for tiny apps where is no sense  to involve qualified software engeneers to devlopment. But it costs a huge overheads. For example  Win10 calculator made by C# use more RAM than Win95 has require to installation on HDD and use more threads then have buttons, while have same functionality that Win95 calculator. and so on.

9 minutes ago, Lactose said:

There are other

In close future we wil have to kinds of games - multiplayer games and no games

2 minutes ago, Fulcrum.013 said:

Managed languages is not ready for any complexive software.

(Emphasis added).

False. Lots of good, real, succesful and completed games have been developed using managed languages. You are trying to dismiss managed languages for all games ever, which is going too far.

24 minutes ago, Lactose said:

You are trying to dismiss managed languages for all games ever, which is going too far

Really managed languages not ready to implement a self-managed hierarhies of objects so not good for any serious development. Main reason - if you can not control wich object needed and weech not needed/can not work any more by specific task field rules you can not control anything without huge head pain and tons of unnessesary garbage code. For most of tasks objects lifetime determined by specific to object field rules, not by count of active refs. So real garbage is refs to not needed oblects that still active. So it require mechanism that clean its refs automatically that managed GC makes to hard to implement. By other world managed languages "solve" problems that newer exists making a huge set of hard to solve problems as cost of solution. Really GC can not protect from memory leaks, even more it hide a leaks making it more hard to detect. For example situation with ref that placed to long-life array. It have to be nulled manually to destroy object that conceptually is same as to call a delete operator manually. So managed languages have no any advantages over native and have huge sets of disadvsntages that make it useless for any complexive software. Usual appilation of managed evangielists  to usage of a weak refs where it needed is a death sintence to a managed GC becouse proper usage of weak refs able to handle cyclic refs  without GC mechanism.