Go isn't designed to feel mature, it's designed to be boring and effective. It's designed to keep code complexity low even as the complexity of problems and solutions increases. It's designed to allow large teams of medium-skill programmers to consistently produce safe and effective solutions. The most precise description ive heard to date is: "Go is a get shit done language."
C# 1.0 was also boring and effective - modern versions are still effective, and I'd say they are more powerful.
Golang in 15 years will likely converge and embrace many of the missing features of mature languages (its happening now already), especially if it wants to reach broader adoption.
A reference like "Go is a get shit done language." very much reflects overall immaturity of the language that I see day to day.
>Golang in 15 years will likely converge and embrace many of the missing features of mature languages (its happening now already), especially if it wants to reach broader adoption.
Go is 10 years old already and picking new features at an extremely low rate, with no hints at a pace change.
I think error management and generics should be the only major changes to expect within the next 5 years.
C# is more complex by an order of magnitude...
And thus its evolution was and is still way faster.
Basically it is designed for writing boilerplate libraries and code generators to cover up lack of language features, which even well known projects are forced to make use of (k8s).
It is already there in some form as 'Go Cloud Development Kit' [1].
Though many claim it is not really enterprise scale until a petstore application can be created in it. And a flawless implementation of EJB 2.1 made enterprise fall in love J2EE. I am not sure Go can deliver anything remotely powerful as that.
Right now I'm using prometheus and grafana to monitor around 8k database servers (sql server too BTW).
We have pricing applications using influxdb. Docker. Openstack. Minio. We also have mattermost.
All of this in a conservative big bank. My friends in the banking sector tell the same story.
True there are lots of c# enterprisey web apps.
However given the amount of boilerplate you describe, I cannot understand how such useful and reliable tools can be delivered in Go.
A hint:just because a language is not to your liking, it does not mean that it is not useful, performant and reliable.
"However given the amount of boilerplate you describe, I cannot understand how such useful and reliable tools can be delivered in Go."
I don't follow your logic. Multitudes of useful and reliable tools were built with assembly languages - is that evidence that assembly code doesn't have a lot of boilerplate (relative to modern languages)?
AWS, Azure, actual hardware racks, plain old VMs, JEE containers, .NET packages, Ansible, Puppet, Chef, whatever scripting stack, but surely not one line of Go related code.
Here's a list of prominent Go infrastructure projects and by no means a complete list: Kubernetes, Docker, Etcd, Consul (and the rest of Hashicorp's projects), CockroachDB, Prometheus, TiDB. Maybe I'm just blind to C# but I don't remember coming across a single similar project that's written in C#.
None of this is relevent and or even close to be as popular as the previous tools mention in Go, just k8s and Docker crush your entire list. Another very popular one is Grafana also written in Go.
In correct English one would state fully, completely written in X.
Modern stacks are seldom pure blood language X, thus if 5% of it is written in Y, the product is written in a mix of X and Y.
Which I also mentioned on my comment, "Yep, they aren't pure C#", naturally overseen when one intends to champion its language as "Year of Desktop Linux" on IT infrastructures.
> It's designed to keep code complexity low even as the complexity of problems and solutions increases.
Honestly I think that's pretty wrong. Go is designed to let you get coding quickly. It's not designed to make your ultimate solution well designed are easily refactorable. In a few years there's going to be a ton of Go code that becomes almost as bad as C where it becomes untouchable because people quickly threw something together and didn't think about long term design.
I didn’t read the thesis for each implementation, but it would have been cool to see how long it took an engineer to write each network driver. I bet the Go version, while definitely not the fastest, was one of the fastest to finish.
