> However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch.
If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.
It's for this reason that I appreciate this article, even though it has a (playful, well-intentioned) negative tone toward Godot which is a project I donate to.
This is wonderful criticism! It's thoughtful and well-researched. Hell, even I'm inspired to finally dive into Godot's internals, which I've yet to do despite following the project for several years. I hope this inspires even more contribution and constructive criticism.
It feels like a breath of fresh air to me. Yes, random people, come in and start using Godot, the more eyes are on this project the better. They're articulating gripes I have had but couldn't express. It would be great if, like JS, all the attention became an impetus to make Godot really fast.
Totally agree, that's why I submitted this article. I'm personally invested in seeing Godot become successful, but this type of constructive criticism is great for the ecosystem (even though some people get very defensive). I think it's exciting that there's so much room for improvement and shining light into Godot internals is a great way to expose what needs to be done.
JavaScript is fast because it is used by every person every day, so lots of smart people from big companies put lots of thought how to make it fast, and I still get a feeling of overwhelming anger when browsing the new web Reddit on a 4-years old phone. Godot is a game engine supported by a community (not big companies).
They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
> so lots of smart people from big companies put lots of thought how to make it fast, and I still get a feeling of overwhelming anger when browsing the new web Reddit on a 4-years old phone.
That's more the problem of Reddit's code being a pile of bull dung. Someone high-level in there decided to ditch the "old" API for the "redesign" in favor of GraphQL and as everyone who has ever worked with GraphQL is likely to have discovered, GraphQL is a hell in itself.
And because whoever was moronic enough to call that decision doesn't want to admit they have fucked up and Reddit can't/doesn't want to afford maintaining two distinct APIs, they decided to rather shut down the old, working and performant API.
Javascript was also once upon a time just some randomly strung together mess of code (with urban legends saying it was made in 10 days) by a not-big company. Gotta start somewhere.
There's no point comparing year 30+ of Javascript to year ~10 of Godot. Remember that year 10 of JS was the time when Flash reigned supreme.
>They are not really comparable. And sometimes, there are still performance ceilings imposed by a nature of the tool.
I agree and am glad that we're finally putting a halt to bandaging up the leaky pipes known as JS and releasing stuff like WebASM. Fortuantely, Godot is nowhere near as heavily bandaged and has easier access to change.
> JavaScript is fast because it is used by every person every day, so lots of smart people from big companies put lots of thought how to make it fast, and I still get a feeling of overwhelming anger when browsing the new web Reddit on a 4-years old phone. Godot is a game engine supported by a community (not big companies).
I'm glad to see that tools can exist in only one of 2 states, massive world wide adoption and support by big corporate, or a couple of devs screwing around. I wonder if it is possible for a tool to transcend this limitation?
If only there was a way for multiple people to use a tool, push for it, enhance it and for it's adoption to grow and spread to large pieces of the community eventually gaining corporate support. But nah, things like that don't happen. After all if there is one thing I've learned a scripting/game/animation engine that is easy enough to use and is flexible is something no one really needs anyone, a product like that would probably disappear in a FLASH, after all.
Solving some of those performance problems can also require a massive amount of engineering resources and investment, though. For example the way browsers (generally) overcame interop overhead was by self-hosting almost everything in JavaScript or making things into JIT intrinsics. That's a tall order for something like Godot with two languages.
Python is still slow today. I've worked with performance sensitive python at Google, there is no way to make it fast no matter what tool you use except to rewrite it in a lower level language.
Javascript is fast since it is such a simple language that is easy to optimize, more complex runtimes wont see nearly the same amount of gain from optimization efforts.
It's possible (Unity did it to C#, a magnitude more complex a language than Python), but at the same time we are not short on choices for other languages to extend upon. Google even made a few of those languages themselves.
There's just been no demand to make Python crazy fast, not to the scale where even Google will throw their engineers at it. Python's use cases aren't in real-time applications so that level of performance concern is simply not needed for many. And those that do will use anything else on the backend, from C to Go, maybe even Javascript.
JavaScript is very fast if you want/need it to be. Emscripten/asm.js approach is in the same category as native for example. Your simple code won't be too fast, but not all code needs to be.
Mostly because Linus won't accept anything other than C on his beloved kernel.
Sun had experimental support for Java drivers on Solaris, Android has support for writing drivers in Java, Android Things only allowed for Java written drivers.
> However, one major issue holds it back - the binding layer between engine code and gameplay code is structurally built to be slow in ways which are very hard to fix without tearing everything down and rebuilding the entire API from scratch.
If there is one thing I've learned from the prevalence of Java, or JavaScript, is that performance problems will get sorted out fairly quickly if people start flocking to a tool.