Good luck with that. Companies simply don't want to invest in security. It's simply cheaper to write a post-mortem and apology blog post after the fact.
The sad thing is that people are used by now that anything they enter on a website is sooner or later going to be leaked, if not sold as if often happens with email addresses.
The obvious additional good from this approach is that you no longer couple everything so tightly with just one scripting language, so in some ways it's a bit easier to introduce bindings for other languages. The downside, however, is that it leads to fragmentation in the community, duplication of effort (suddenly you need the double amount of docs), more difficulty and friction in development with new mechanisms demanding that you take the limitations of both languages in mind, oh and if you dare to write your own language then suddenly you have to support both it, as well as any dev tools for it. For what was and still is a communtiy project without strong financial backing (just look at how much money Unity burns on useless stuff, and how much more the people behind Godot could do with that money), that's quite the gamble.
Maybe if they focused on the core engine more, then deltaV: Rings of Saturn wouldn't have odd performance issues for a 2D game and wouldn't get confused with multi-monitor setups. Maybe Road To Vostok wouldn't crash when loading into the Village map on an Intel Arc GPU, and also start on the wrong monitor same as deltaV. Maybe even demos like "Realistic Jungle Demo" on itch.io wouldn't have all white textures on said Intel Arc GPU. Maybe we'd be two or three whole releases of features ahead by now, if all of the hours spent on GDScript to date would have been spent elsewhere.
On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected. Similarly, if they didn't try with GDScript, the community would be smaller, due to its ease of prototyping, and being simpler and more approachable for the folks who don't know C# yet, even if it's also unnecessary to the folks who like tools like Rider/Visual Studio or are coming from Unity or engines with scripting in C# or just C++. I'm pretty split on it overall.
> Or maybe without GDScript the engine would not get the traction it has and would not have the resources to do anything at all.
Or the developers might not find C# to be as interesting to work on and some people that stick around in part due to getting to iterate on GDScript wouldn’t contribute at all! All of those are possibilities, that’s for sure, Godot definitely has a lot of appeal due to fast prototyping too!
> Intel Arc GPU rendering issues have nothing to do with Godot’s choice of high-level scripting language.
The GitHub repo for Godot has 83'164 commits. Let me pull an arbitrary unimportant number out of my ass, which is 6 hours of work per commit on average (lots of small ones, some that take weeks, doesn't matter) and we get 498'984 hours which we can round to 500k for our napkin maths.
There's around 52k LoC for the gdscript module, about 1'380 files. Around 5% of the overall commits in the repo are in that module, we can up that to like 7% to account for docs and editor and other parts, but we don't have to assume higher. That gives us about 35k hours spent on GDScript.
Remove GDScript and you get 35k hours to put elsewhere, including Intel Arc support. It's the exact same principle of Linux distros having like a dozen desktop environments and the efforts being so fragmented that it's impossible to make a single really good one (though there are different goals for the projects, for example KDE vs something lightweight like LXQt).
Of course, I addressed the possibility that people working on GDScript just wouldn't be able to work on the other stuff, so one should argue that redistributing work would be quite complex and since it's a lot of volunteer work, people might just not care to work on X instead of Y, that was addressed here:
> On the other hand, there's no guarantee that any of those devs would fix the other issues if their efforts were to be redirected.
That said, the above is more or less why Unity benefitted in regards to development velocity from saying goodbye to ECMAScript and Boo (or maybe they shot themselves in the foot, cause prototyping is slower compared to GDScript).
Most of recent issues, including this incident, happened not due to smart superintelligent "agents" taking over the world - chatbots and other text generators are about as intelligent amd powerful as a dead starfish - but due to the combined stupidity of the said chatbots amd lazy idiots who use them to hide their own incompetence and thus produce such embarassing mistakes. A few years ago, they would be fired for exposing secrets in plain text, but since their manager wanted an AI-Workflow...
(GP here) Its true that we need to be cautious about continuing to exercise our thinking muscles, undoubtedly. Ofc you can do that without using legacy techniques, but each to their own.
I fear the author and most commenters are not aware of the law of demand and supply. If there is demand for consumer RAM, there will be supply for consumer RAM. It just takes time and risk-assessment to scale up operations.
We have RAM shortage now, we will have very cheap RAM tomorrow. It’s not like production is bottlenecked by raw materials. Chip companies just need to assess if the demand by AI companies will last so it’s better to scale up, or perhaps they should wait it out instead of oversupplying and cutting into their profits.
We're talking about advanced semiconductor manufacture. It takes years and 100s millions to billions of dollars to scale up operations. That's something you don't do unless you know there's demand to sustain it in future.
>I fear the author and most commenters are not aware of the law of demand and supply
I cannot stand how you and people like you try to justify everything by supply and demand. Also you act like it's some natural law of nature. It's not a law of nature- if you took an economics class you would realize it's try to maximize PROFIT. It's not for the good of the people.
All of these things are a CHOICE that people are making to now completely screw the average person for, again, the needs of big corporations and the top 0.01%.
The sad thing is that people are used by now that anything they enter on a website is sooner or later going to be leaked, if not sold as if often happens with email addresses.
reply