It depends on what "success" means but I can tell you for a fact even marginal languages, in the grand scheme of things, it is very very expensive to run infrastructure that is well oiled and usable for the modern programmer that they can rely on, unless you are careful. You may not have many of the same luxuries others have. The demands are generally high, even if users of smaller languages are more forgiving.
I used to help run Haskell.org. I think people would hardly call it a top 5 language or anything with a gazillion programmers. We didn't have the luxury of designing our systems around infinite free GitHub bandwidth by exploiting Git repositories or anything like that, back when they were designed; so we had to stick with what we had, which was "A server running a daemon we wrote that stored files on the filesystem." Hardly "corporate" in any sense. It still used many dozens of terabytes a month on bandwidth for the package system. The only reason we were able to handle that is because CDNs like Fastly can eat the cost for us, for free, and because we got major free tiers from hosting providers (RIP Rackspace) to provide the servers. It can easily run into thousands of dollars a month for things like this, and that's before you get into assholes who try to ruin things by making it even harder. Oh, and I'm not even counting the actual money spent on the engineers, in terms of hourly wages, spent on this. I worked for "free."
The rise of integrated CI systems in particular, in most software projects, has had a tremendously positive effect, but one of the externalities associated with this is that they demand tremendous resources from upstream systems like this.
> After all we had successful languages and ecosystems long before any corporations became interested in funding such things.
People really need to understand that "the passage of time" is a real thing and has many consequences. It turns out the world is not the same as it was 20 years ago or 40 years ago. No amount of denialism will change that. The CI system demands are a good example of this.
> Is it true that all that code is native to the go project
Yes, the cryptography libraries for Go are written by experts on the Go team. Anyone can write a cryptography library and even have it work. Not everyone can write a library high quality enough to ship to billions of people as the default in a language with a good API, rigorous quality control, and active security review. That is what Go offers, it's not just a simple piece of code.
> Any open source language could do the same without massive investment (many have).
Sorry, but you're wrong, and it frankly indicates to me you have no experience in this, unless you simply believe that people's time and engineering effort isn't valuable or worth money. Can I ask what programming languages you have helped design and run the infrastructure and developed community libraries for? Because I dislike Go as a language for many reasons but you can't get away from this. The native crypto stacks for e.g. Haskell took years to reach relative maturity, same with Rust. Those projects weren't marginal, many people believe them to be very important, and people worked actively on them. Unless you simply believe "multiple talented people working for years on something of critical importance" isn't equivalent to "a massive investment", in which case I simply don't know what to tell you. It's a hard project. There is no way around it.
