The upshot is likely that a community-created Lua or JS binding will gain a significant userbase.
"JS" - they want a better language, not worse one.
Why C++ for Unreal 4
41–50 of 178 posts
Re: Why C++ for Unreal 4
#42The phrase > 'What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.' is beautiful and is a pattern I've seen multiple times before. Its not feature creep per-se, but more something a bit more insidious in software development.
That's a good lessons for people wanting to create a new languages too. One of the reasons C++ was successful in the first place is that it needs almost no glue to interface with C code. Contrast that with all the languages providing a more or less cumbersome FFI.
Rust for instance looks very promising but you still have to go through the tedious task of redeclaring all the prototypes of the C functions before you call them, it cannot directly parse C headers (as far as I know). That makes writing hybrid code (for instance incrementally porting code from C into Rust) much more difficult and error prone than they need to be.
Re: Why C++ for Unreal 4
#43> Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell. Replace "C++" with "JavaScript/client-side processing" and "script" with "server-side scripting" and I feel like this adequately describes web-development.
JavaScript only survived on client because we have to support legacy code across different platforms. There is no reason to pick same crappy language for server-side as well, unless you happen to be more familiar with it than modern languages.
Re: Why C++ for Unreal 4
#44Earlier quoted context omitted.
Exactly. What's most distressing is people (as normal) are completely ignoring the garbage collection overhead, which is mostly where the advantage of having complete control is, in terms of micro-managing your memory allocation, e.g. using slab allocators, memory pools, pre-allocation, etc. C# code in theory (ignoring things like intrinsics support and inline asm) can be as fast as C++ for tight loops, but in my exp…
Note that Unreal uses a C++ GC.
I'm neither an Unreal nor a C++ expert, but I assume that this kind of GC still allows exact control over when the collection happens since it's not language- but a library feature. In this case this should still be better for game engine purposes, since the GC can for example be hidden behind GPU rendering time.
Re: Why C++ for Unreal 4
#45A(programming) language gets very powerful by simply being accepted as standard. Take English as example.
Re: Why C++ for Unreal 4
#46The phrase > 'What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.' is beautiful and is a pattern I've seen multiple times before. Its not feature creep per-se, but more something a bit more insidious in software development.
That's a good lessons for people wanting to create a new languages too. One of the reasons C++ was successful in the first place is that it needs almost no glue to interface with C code. Contrast that with all the languages providing a more or less cumbersome FFI. Rust for instance looks very promising but you still have to go through the tedious task of redeclaring all the prototypes of the C functions before you ca…
Actually, one of the first tools to appear in the Rust ecosystem was a port of the "bindgen" program written for the Clay language, which has been solving the problem of parsing C headers for years now:
https://github.com/crabtw/rust-bindgen/
There are also long-term plans for adopting this into the compiler itself:
Re: Why C++ for Unreal 4
#47> Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell. Replace "C++" with "JavaScript/client-side processing" and "script" with "server-side scripting" and I feel like this adequately describes web-development.
JavaScript only survived on client because we have to support legacy code across different platforms. There is no reason to pick same crappy language for server-side as well, unless you happen to be more familiar with it than modern languages.
There is at least one reason I can think of: Code sharing with mobile client implementations.
Re: Why C++ for Unreal 4
#48Earlier quoted context omitted.
Note that you'll need a language capable of AOT compilation if you want to target consoles which only run signed code (or use an interpreter, which will be rather slow). JIT is not an option on those systems.
The LuaJIT interpreter is surprisingly fast. Still not as fast as the JIT or an AOT compiled language though...
His point though is that JITs (like LuaJIT) are often not allowed on consoles for security reasons - they don't allow running of unsigned code. So LuaJIT might not be an option.
Re: Why C++ for Unreal 4
#49It will be interesting if any major game engines pop up using Rust as the core language, or even Go. C++ has been the king of highly optimised game engines for so long, I can't help but feel it has become so entrenched in the industry that it will take something monumental to disrupt it.
There already exists a subcommunity devoted to exploring Rust's applicability to game development and computer graphics. The most active person in this department is probably Brendan Zabarauskas: http://voyager3.tumblr.com/post/82419271783/i-found-this-anc...
I also know of a few game development studios with R&D departments who have had an eye on Rust in the past, though I bet it will be a long time before a major studio is willing to make the risk that writing an engine in Rust would entail.
Re: Why C++ for Unreal 4
#50Looking at the comments around the post, the amount of people who don't really understand pointers but who seem to be Unreal developers is a little surprising!