https://godotengine.org/article/godot-4-will-discontinue-visual-scripting
Ok, visual scripting doesn't interest me.
Beta "very close" is nice.
Rust used as much as C++ for extensions is interesting.
Visual scripting being removed / beta very close
- Edited
Yeah, it makes sense. The visual scripting never really worked and was badly maintained. It was basically just the GDScript API in visual form, which is not very useful. Because in order to use it, you'd need to know how to use GDScript, in which case it would be easier and faster to just write the code. Blueprints and some other visual languages provide a lot of helpers and high-level constructs, which Godot was missing. So I can understand dropping it, since no one was using it and it would be a ton of work to do properly.
Yep I agree and personally couldn't care less about visual scripting. GDscript is high level enough to get work done effectively.
It's very sad, actually.
Well, C++ has quite an edge, but still.Tomcat I was planning on using it.
If you tried it, you would have changed your plans. That was the whole issue discussed in the blog post. A bunch of people (mostly people NOT using Godot) requested the feature, but then no one actually used it. One because it wasn't very well designed or implemented, but also because GDScript works so well. It's not like the case with Unreal where you are forced to use C++ (if you don't want Blueprints) and C++ was never supposed to be a scripting language. Unity has some nice visual plug-ins, though, that do work well for the people that want it, and I think the intention is that this could be handled in a similar manner for Godot.
- Edited
cybereality One because it wasn't very well designed or implemented
If it was improved, then it would be used.
I'll just remind that:
It can be a great tool for non-programmers like game designers and artists.
This phrase is particularly amusing now:
In fact, Visual Scripting integrates so well to Godot that it's hard to believe it was added only in version 3.0.
- Edited
I would use visual scripting and shadergraph, if they were good/well designed. IMO they never were.
cybereality A bunch of people (mostly people NOT using Godot) requested the feature,
I was one of the voices asking for visual scripting, and I don't think we really got what was asked. But there were like a billion voices each asking for something different tbqh.
Tomcat If it was improved, then it would be used.
I honestly think it was beyond saving/improvement. I'd rather see someone create a new system from scratch, which might well become an opportunity now.
Yeah, I'm not saying visual scripting as a concept can't work. Just that the implementation, as is, was basically useless. Even Blueprints is not perfect, and even simple things that would be 4 or 5 lines of GDScript would be a full 4K screen worth of spaghetti.
At the risk of repeating myself again, godot is free software -- if you want something, the best way to get it is to add it yourself. If you want visual scripting to continue, find some fellow enthusiasts, start a project, and build it the right way. 
- Edited
duane At the risk of repeating myself again, godot is free software -- if you want something, the best way to get it is to add it yourself. If you want visual scripting to continue, find some fellow enthusiasts, start a project, and build it the right way.
With GD extensions that will likely be a very valid and viable options option, even now with GDNative it might be, though not as convenient. But back then neither of these options even existed.
- Edited
duane At the risk of repeating myself again, godot is free software -- if you want something, the best way to get it is to add it yourself.
It is a perverse argument and a road to nowhere. If, for example, you decide to bake a bun, do you start by ploughing the land, planting the grain or, still, do you go to the shop to get the flour? If you start adding all the necessary functions yourself, you will no longer have the time or energy for the project itself. This, by the way, is a common mistake made by developers of their own engines.
There is another aspect that is not obvious. Godot is seen as a game engine. Perhaps it will become one at some point. But right now there are no big memorable projects on it. What is there and what has it already achieved? At the moment, it's a great start for learning engines and programming — it's easy to learn initially. And throwing out a pretty serious thing, and visual programming (setting it up) gives important experience, is extremely reckless.
Tomcat If, for example, you decide to bake a bun
No, I would buy a bun or pay someone to sell me dough. However, in a free software project there usually isn't any money to pay people, so the participants are best advised to do for themselves. When there is money, the people providing the bulk of it generally have the say in where the project goes, not the folks who are using it for free. Given that 0.5% of godot users are using visualscript, I doubt that they're footing the bill for more work on it, but if someone with big bucks and a visual orientation comes along, they could change a lot of minds -- I'm not holding my breath.
On the other hand, if people strongly interested in visualscript, band together, they might get more accomplished on their own.
- Edited
duane No, I would buy a bun or pay someone to sell me dough.
But I would prefer to make the dough myself, as it is the defining feature of home baking. 
There's already a discussion going on about cooking. 
But the analogy is actually pretty accurate — to what level game developers can rely on off-the-shelf assets (ready-made ingredients) and when they need to write their own tools.
duane However, in a free software project there usually isn't any money to pay people, so the participants are best advised to do for themselves. When there is money, the people providing the bulk of it generally have the say in where the project goes, not the folks who are using it for free.
The problem with funding free software does exist. There are ideas on how to solve it, but… the "first million" problem isn't going anywhere. 
- Edited
So what does cooking and programming have in common ?
Certainly the breaking down into tasks ("If you want an apple pie from scratch you must first create the universe !"), if it is a multi course meal then also setting of milestones ("What's smelling ? Gosh, I forgot the roast !"), testing ("Get your fingers out of the dessert !"), customer delivery (everyone's holding their breath), eventually bug search (yeuch). Possibly dealing with some internal friction ("But I want spaghetti !"). And, in rare cases, utter failure ("The salmon mousse !").
So, yeah, some analogy can't be totally rejected :-)
Tomcat It can be a great tool for non-programmers like game designers and artists.
This is the whole problem, though. Visual scripting is not easier than coding, it's actually harder.
- Edited
cybereality This is the whole problem, though. Visual scripting is not easier than coding, it's actually harder.
Why do some people think that Visual Scripting is easier to use than GDScript?
My impression is that the main use case would be a team project, where the team includes a non-programming artist. The programmers would set up some pieces of the project using VS, so that the artist could make tweaks to the art without having to use "real code".