171–180 of 556 posts
Earlier quoted context omitted.
It's a requirement if you do network I/O whether you realize it or not.
If a bug in a game's network IO crashes/takes over the whole OS, the security vulnerability is in the OS, not in the game.
Wasn't Rollercoaster Tycoon also written in C?
> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
> If you have a garbage collector that runs in 200us The problem is GCs for popular languages are nowhere near this good. People will claim their GC runs in 200us, but it's misleading. For example, they'll say they have a 200us "stop the world" time, but then individual threads can still be blocked for 10ms+. Or they'll quote an average or median GC time, when what matters is the 99.9th percentile time. If you run GC…
> The stop-the-world garbage collection is a big pain for games, stopping the world is something you can't really afford to do. I love this opinion from games programmers because they never qualify it and talk about what their latency budgets are and what they do in lieu of a garbage collector. They just hand wave and say "GC can't work". The reality is you still have to free resources, so it's not like the garbage c…
Disclaimer: I'm not a game developer; but, I've worked on a lot of projects with tight frame time requirements in my time at Netflix on the TVUI team. I also have no experience in Go so I can't comment on the specifics of that garbage collector vs. V8. I don't think it's necessarily that it "can't" work as much as it takes away a critical element of control from the game developers and the times you find yourself "at…
Earlier quoted context omitted.
Actually you're not. I would very much prefer a stripped down version of Go used for these situations rather than throwing more C at it. The main benefits of using Go are not the garbage collection, its the tooling, the readability (and thus maintainability) of the code base, the large number of folks who are versatile in using it.
Are you saying that there are more go developers than c developers? Is there a user survey that shows such things? I'm curious what the ratio is.
There may be more "C programmers" by number but a Golang codebase is going to be more accessible to a wider pool of applicants.
Earlier quoted context omitted.
If a bug in a game's network IO crashes/takes over the whole OS, the security vulnerability is in the OS, not in the game.
No. Security is a full-stack endeavor. At all levels it is incumbent upon software professionals to build secure and resilient systems, any time they're exposed to a network. The OS should backstop your efforts, not replace them.
Earlier quoted context omitted.
That's true, and it's why the alternative to GC is generally not "malloc and free" or "RAII" but "custom allocators." Games are very friendly to that approach- with a bit of thought you can use arenas and object pools to cover 99% of what you need, and cut out all of the failure modes of a general purpose GC or malloc implementation.
Interestingly, it's fully possible to disable the automatic garbage collection in Go to achieve this. Disable the garbage collector: debug.SetGCPercent(-1) Trigger garbage collection: runtime.GC() It is also possible to allocate a large block of memory and then manage it yourself.
He dismisses C# without even knowing what options he has. The latest stuff Unity has been doing is heavily biased towards data driven design where almost everything is a struct. There are very few classes to be found that use any kind of polymorphism, and it is actively discouraged. You could easily treat Unity as a cross platform rendering engine and asset loading system, and then build your own engine on top of it.…
That said, I'd love to see a pure C# engine on .NET core 3 that has access to Span. C# is set up as a great high level language with low level features as long as you're willing to do the work you would have done in C or C++.
Didn't even consider Rust...
”Similarly I want to avoid tying myself to a particular OS, and ideally I'd like to have the option of developing for consoles. So it's important that my programming language is portable, and that it has good portable library support”
Availability of Rust across platforms is nowhere near C or C++. It may, and I hope it will, change in the future but right now it is not so.