Coming from Unity (and Unreal) - is Godot for me?

Question

Hello.
I've come a long way with game developing getting from GM Studio, bare C++ and OpenGL, Unity (and a bit Unreal Engine 4), before reaching Godot.
I'm still in the quest to find and settle down to an engine that I can really connect with.
The reason I haven't yet settled to one, is the only and most powerful reason: I want to code in C++. I'm so determined with C++ that even the last 2 years of earning my living with Unity (still in progress) doesn't stop me to abandon it. Had Unity had the possibility to natively code in C++, my quest was long time ended.

I've been prospecting UE4 for the last couple of weeks as it looked like the ideal candidate but I came to notice a few drawbacks that I admit upfront - they are totally subjective and personal. So in no particular order:
- It's very cumbersome. I mean it's not as straightforward as Unity or GM Studio. I haven't understood eventually how to relate the GUI editor to the C++ code behind it. And In order to achieve the same thing you would with other game engines, in UE4 I have to write like 4 times more code.
- It forces you through predetermined paths with its actors, pawns, characters, game mode, game state etc. Not to mention the game templates. Not only that, but these classes have a ton of inherent code I don't need and I noticed people start from a template and then remove unneeded code down the road.
I prefer an "additive" way of making games, not "subtractive" or "ignoring".
- MSVS 2017 still doesn't work perfect with Unreal API in that the intellisense displays errors where there aren't and the autocomplete doesn't kick off.
- Not much documentation for C++. Most of it is for blueprint coding.

So in the Wikipedia list of game engines I ruled them out one by one until I was left with about 3, out of which Godot is at the top mainly due to C++, features and lightweight (in this order!).
I'm aware that Godot is still young and developed by the community and so it probably has its shortcomings. But where there's a will there's a way. I'm not that experienced so to be able to contribute to the engine, I'm merely a potential regular user. But I can promise that if I'll ever get the chance, I'll donate so those who are able can develop it.

I've read about GDScript and will use it, alright, but what I'm really after in a game engine is coding in C++. And doing it with absolutely 0 overhead. Unity has the possibility to write "native plugins" in C++ but they incur a little overhead with calling functions in the plugins. Moreover I guess you can't call C# API code from within C++ code (if I got it correctly).

Further research on C++ capabilities of Godot on the internet revealed the question asked multiple times but all I got to learn of was the 2 modes of coding:
1. Code as a module.
2. GDNative.
1. From what I got to read, this looks pretty much like the Unity way so I need some clarifications. I don't mind recompiling over and over with the smallest edit in code - no problem.
2. Documentation for GDNative reads:

Since GDNative runs native code it has literally zero overhead when it
comes to raw computation power (provided you don't make calls into the
script system all the time).

It's what's in the parentheses that worries me.

So in short:
A. Is there any way to code in C++ in Godot with absolutely 0 overhead at all? If yes, which of the ways to go?

B. I'm interested in your personal opinion: given what I let you know about me, do you think Godot would be for me too? (keeping my fingers crossed)

Comments

In my opinion, Godot is better with 2D games

But in 3D, there many things the engine needs

Don’t forgot there
1- unreal
2- unity
3- cryengine

So, i don’t think godot is the right choice for 3d, (currently)

And about developing games in c++, I really don’t know people just hate c++

Most of people, consider c++ in game engine is CON, which i find it is PRO

Godot written in c++ but games development is in gdscript and c# (3.0)

Even addons , there no coding in c++ to make a game with godot

That’s why, i liked godot for 2d more than 3d

But i hope one day see godot among the best engines

Best regards

---

Thanks for your thoughts. Indeed I want 3D mostly.
And about those engines, I've already seen each of their workflow and genres target. Cryengine is the most limiting and specialized ("focused") , followed by Unreal. They're made with certain genres in mind and expect you to choose one of them. The rest of the engines give you freedom to take whatever path your imagination would surprise you with, in making a game.

C++ language is IMHO the perfect compromise between grace, elegance, style on one hand and low level access, freedom, on the other hand. This at least compared to say, C# or Java.
And if we mention that at the same time it's more intuitive and consistent (with itself)... unlike C# that despite its higher level (simpler), 1. it has a lot of exceptions from its own rules and 2. it ties your hands in many aspects directing you to take detours (workarounds) or purely throwing a dry "you don't want that" at you.

---

you can go full C++ either as a module or using gdnative . Here's an example of a game implemented as a C++ module.
https://github.com/vnen/godot-platfomer-cpp
Is Godot for you ? Only you can answer that question ..

---

2 very substantial comments.
@MrMonk: thanks for the link - very useful! About the answer to the question "is Godot for me", I'm not able to answer because I only know half of the matter - my preferences. Those who read this question know the whole picture: what I'm after since I stated it, and the ins and outs of Godot.
@Zylan: Thanks. Very informative! I'm not looking for anything else than what the engine has to offer but I want to make use of it in C++. This could be an answer, why did you comment?

---

Changed to be an answer.

Answer 1

If you want freedom of C++ coding with very few overhead without having to recompile the engine, use GDNative. The key is, it communicates with the engine with an abstract C API and you need to fit into a "scripting workflow" rather than "engine workflow", so that's why there is still a small overhead (but tests I've done show it's only about 1% difference compared to in-engine calls). It's a recent technology though, so there could be a few bugs which get fixed over time.

If you want fewer overhead and more engine integration, write a module. This is basically modiying the engine directly, but in a clean way because modules are designed to be folders in the source code that you can add or remove without hassle. It also means you need to learn the engine's build system, which isn't complicated fortunately (get a C++ compiler, install Python, SCons, git clone and you're done).

If you want even fewer overhead to the point of calling the OS and drivers directly (say win32 API or OpenGL), you may need to modify the engine itself in a deeper way, but then the point of using such an engine becomes questionnable because you could be making your own in the end^^ (unless you feel like contributing your stuff to Godot).

I only made some noise generator in Unity C++, and I know even less about UE4, so I cannot say which one is best for you. But I can say that C++ in Godot is not bad, having written a few modules myself ;)