As I said I love golang. I invested a lot of my own time into learning it and its ecosystem.
The time developers spend learning a language and its libraries should not be discounted.
Maybe we overestimate how much corporate backing is required to make a language a success.
After all we had successful languages and ecosystems long before any corporations became
interested in funding such things.
You mention golang's crypto. Is it true that all that code is native to the go project or
are they mostly just wrapping other open source libraries which have been created by 3rd parties?
Any open source language could do the same without massive investment (many have).
Go's crypto libraries are all native, and a good example of why corporate backing is very useful. It's unlikely that you would get someone like agl to develop such excellent cryptography libraries in the first place without being sponsored to do so. Yes, there are some talented developers who will donate their skills, but I would wager that the majority of the most experienced developers are going to be busy with work, and large contributions are only going to happen as part of that work.
Lisp, and OCaml are about as close as I can get. I would argue Haskell (several of GHC's core team worked at MS though). I would also argue Python was popular before Guido worked at Google. Those 4 all came out of academia though so they had backing just not corporate backing.
> Maybe we overestimate how much corporate backing is required to make a language a success
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.
> Any open source language could do the same without massive investment (many have).
What I meant by this was wrapping other open source libraries like libsodium etc. rather than implementing crypto libraries from scratch. I, wrongly, assumed golang might also be doing that.
It is true I have no experience implementing cryptographic libraries.
Maybe we overestimate how much corporate backing is required to make a language a success. After all we had successful languages and ecosystems long before any corporations became interested in funding such things.
You mention golang's crypto. Is it true that all that code is native to the go project or are they mostly just wrapping other open source libraries which have been created by 3rd parties? Any open source language could do the same without massive investment (many have).