By primitive shapes I suppose you mean drawing primitive shapes? Being able to simulate 2D and 3D physics is very important in many games. Defold would in most cases not be a complete engine without it. BUT at the time, we had no extension system, so the decision was made to include Box2D and Bullet in the engine. Now, many years later, it is possible to exclude the physics engine from the binary if it is not included, thus reducing the binary size.
If you look at APIs for high level gui components such as lists, buttons and so on, you find that most APIs are very opinionated. Some people like GUI framework X, while others prefer Y. We do not want to force a certain style of GUI design onto our users and instead we decided to provide only the very very basic building blocks. Was it a good decision? Maybe. There are some great Defold specific frameworks out there, with Druid being the most advanced. There is also a Dear ImGUI extension, and several other alternatives.
The fact that these things are extensions is not necessarily a bad thing, but I do think we could make a better job of promoting them.
For us, size is everything. And Lua is tiny compared to JS or C# or anything else. And LuaJIT delivers great performance. And the interop with C is great.
I’m not sure I follow. We have an internal/private C API for the engine. Selected parts of this API is exposed through Lua. Later on, when we introduced native extensions, we also started to move some of the private C APIs to public headers available to native extensions. We’ll continue to expand on the public C API, but it is unlikely that the C API will ever have feature parity with the Lua API.
Correct. This is a very conscious choice. My personal opinion is that OOP should be kept as far from game development as possible. It adds a lot of overhead and complexity for very little gain (if any!). We believe in a data centric approach with systems operating on the data to produce a new state, rather than complex hierarchies of objects with the data spread out among the objects of the system. This is in many ways similar to ECS, and it is also what you find in the engine code if you study it closely.
I think @JCash and others in the team can provide even deeper insights into some of the design decisions.