> That’s right, our raycast is returning an untyped dictionary.
This is probably the biggest red flag for me, why would you use an untyped dictionary for something as essential and commonly used as a raycast result?
It does support classes with strongly typed fields, though, which are the next best thing. It's just a poorly designed API, it's not a reflection of language limitations.
Godot has always made a point of prioritizing features and simplicity of modification over speed. In a lot of instances it does just ignore low-hanging opportunities for performance because the simple thing works and needs less code, which isn't always useful, but means it's easier to replace.
Like, my reaction to the blogpost is, "oh, OK, if raycasting nodes are fast, and I need a lot of raycasts, then worst case, I will introduce a custom node designed to do 300 raycasts in one call or whatever."
The corresponding WTF in Unity tends to be "sorry, no code access, SOL" so the inclination of a Unity dev is that they need as direct an API as possible and it needs to be as fast as possible. There are tremendous numbers of shipped Unity games that don't trust the engine to do what it's supposed to and just use it as a HAL, and so there's a culture clash in approach which makes Godot the wrong tool for a dev that wants that kind of system.