I actually agree that there are many parts of Rust's ecosystem that are relatively immature — I just don't see how the Actix situation reflects on that. It's not like Actix was a core part of the Rust ecosystem. It was a framework that was most notable for doing very well on the Techempower benchmarks. People get hurt feelings and have flameouts in the C, Java, JavaScript, etc. ecosystems too.
Go's is more pragmatic. Rust's is more purist, and that reflects on the language features (more functional, more free in allowing you to use it for any purpose where Go is network-app specific, more strict in typing), the licensing and the attitude towards collaboration.
That collaboration thing is why Actix exploded I think. While mostly an isolated incident it does show some clash between the author's values (and possibly the author's employer's (MSFT) values) and the values of the general Rust community. I would not say that reflects on the maturity of the langues or ecosystem.
In Go a lot of stuff is Google dictated. In Rust it's a true open governance innovation project (looking to become a non-profit). Since the Go is a very specific language --made for networked apps and only has one way to do concurrency-- and Rust very broad --a true general purpose prog lang-- it is easy to see how Go mature so quickly (not much to mature) and also why it got a bit old so quickly as well (ignores most innovations in computer science of the last decades).
The Go community has a very similar story, where someone released a web framework, with an unorthodox set of features, and was flamed to the point where he abandoned the project and quit OSS.
Martini used the service injection pattern and made use of reflection to do so. It was a very popular framework and one of the first in Go (it currently has ~10k stars), and the use of reflection became a very contentious viewpoint in the community.
Just because it is used most for "network apps" doesn't mean it's limited to that. On the other hand, you could argue that Rust is a wrong fit for anything _except_ performance-critical applications, because for anything else it's not worth to saddle yourself with the added complexity.
> and Rust very broad --a true general purpose prog lang-- it is easy to see how Go mature so quickly (not much to mature) and also why it got a bit old so quickly as well
This simplicity is the thing Go opponents like to point out (or mock) most, and what Go fans actually would tell you is one of the best features of the language. It's actually refreshing to have one language that doesn't try to be everyone's darling by implementing every conceivable feature - we already have enough of those, Rust, C++, Java etc. etc. But you don't have to take my word for it, you can also read the first sentences from this blog post: https://bradfitz.com/2020/01/30/joining-tailscale - he puts it better than I could...
As the grant parent commentor i cannot down vote, so that wasn't me.
Google explicitly shown no intent to make Go a fit beyond network apps. You can hack something into doing more than originally intended, but then you are usually operating "outside of warranty".
> On the other hand, you could argue that Rust is a wrong fit for anything _except_ performance-critical applications
Well, Rust does more than C-level high perf. It also allows for very safe/maintainable code that's high perf. Both of these are not something like a special feature, nope, ANY software needs to be high perf, bug free and maintainable to some degree. And as the size of the codebase grows, lack of these properties in a languages rears is ugly head.
The added complexity cost, as you mentioned, is IMHO not a real cost. It's more like an investment. You go with Rust, you have to pay up front: learning new concepts, slower dev't, more verbosity/syntax/gibberish-y code. But once the codebase grows, you(r team) have grown accustomed to this and you start to reap the benefits of Rust's safety, freedom to choose your concurrency patterns, maintainability and verbosity.
Now I do want to point out a REAL cost that was not mentioned yet, that Rust brings with it much more than Go: compile time. This sucks for Rust. Given the complexity of Rust, I dont expect it to ever come close to Go's lightning compiles. It will improve/ it constantly improving. And IDE features that prevent compiles (e.g.: error highlights) are maturing and will help too. But this is a big reason for picking Go.
Your Jedi mind trick about Go's "simplicity" does not work on me :) ... It's fast compiles (a result of simplicity) are the bonus. Not being able to use the language beyond network apps or go-routine-concurrency are simply a minus for every learner (not for Google as a creator), as you limit the use of your new skill. The reason they kept the 1B$ mistake (null) in there is simply unforgivable.
And if Go will never add features we have to see. Java also intended to stay lean, well...
Go is a general purpose programming language. It is suitable for a large variety of programming tasks beyond network services (though itself a massive problem domain)
For example Go is great for building cli apps. Simple, easy to install and easy to understand.
For another Go has surprisingly good windows support. Google didn’t do that.
For a third Go has robust cryptography libraries.
There are actually lot’s of other contributions from the community if you’d take the time to look.
Seriously? Does Google say that "native GUI devt" is intended use? And how about that it only supports one concurrency method, and does not allow one to implement one yourself.
> For example Go is great for building cli apps.
Ok, your joking right? CLI apps are simply a networked app that does not necessarily use the network. That's not an entirely new domain, like OpenGL, native GUIs, embedded systems, kernel programming, ...
> There are actually lot’s of other contributions from the community if you’d take the time to look.
That's good, but it still is not "open innovation" to the level of say Rust.
I wouldn't call rust ecosystem less mature than go, but it wouldn't call either of them mature.
Both have ups and downs. Rust definitely has immature web service ecosystem and it's a result of immature async i/o ecosystem. At the same time go has those things otb.
