Visual scripting being removed / beta very close
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".
cybereality Visual scripting is not easier than coding, it's actually harder.
It's not easier to coding — yep, but it's easier to change. @DaveTheCoder said exactly the right thing.
cybereality Yeah, my experience with it is that it's harder, but that might be because I learned text script first. It always ends up looking like text script because you have drop down boxes with text choices. The trouble with it is it's so unsightly when it's done. It's so much easier to read text code. The visual scripting for the unreal engine seemed unsightly at first, but after I played with it for a while, I started to at least not hate it. I think I like it better than c++, but I wouldn't say I like it better than gdscript.
Yeah, Blueprints is alright. Most people don't know how to use it, especially beginners have one large screen with like a million nodes and connections. But you can use events and functions and macros to make things clean. If visual scripting in Godot worked like Blueprints, that would be a different discussion. The problem is that it didn't work.
I'm not sad that visual scripting is being removed, but I am sad that it was implemented in such a way that it basically was completely useless to newcomers to game development, thus rendering its entire existence moot in the first place.
If the Godot developers could have made it more like Unreal's Blueprint system, I've no doubt it would have taken off and helped bring in a lot of new users. I'm hoping someone can develop a plugin that makes the system much more approachable and friendly like Blueprints. In my time with UE4 some time ago, I used Blueprints and C++ together and it made life a lot easier for several tasks, however the same couldn't really be said for visual scripting in Godot because as others have said, it was basically just GDScript in a visual form and thus pointless to use. Blueprint is NOT C++ in a visual form, and could actually be immensely useful and easier to use in several cases over C++. That's what I (and many others, it seems) was hoping visual scripting in Godot would be like, and not at all what was delivered.