> This is mostly because applications and libraries are so hard to reason about and understand due to inheritance, packaging, OOP, build tools ect compared to Go.
You are just at the early phase of the project.
> Go is simple. It's easy to understand, read, and maintain
My opinion is that Go is too simple, to the point that it hinders understanding and readability. 4 nested loops with random mutability is much worse than a clear Stream api "pipeline". The 31st if err check will not be actually handling the underlying problem, while you can't forget about Exceptions -- even if they do bubble up to the main app, you will clearly get an actionable stacktrace.
> The tooling is built into the language
This has benefits, I will give you that. At the same time, I think all these new build tools are anemic and can't be used for anything more complex than interacting with the same language's standard dependencies. Gradle is not sexy, but is actually capable of doing any kind of build.
Go is a complete and simple language, and this is a fairly objective claim.
Unless by "incomplete" you mean it could have more features. But C++ and Rust (and Java) have been piling on features for years, with no signs that they will ever slow down or stop, proving that they're also "incomplete" by this definition. IMO this is really just a result of there being too many cooks in the kitchen, and a lack of leadership committed to saying "no" to feature requests.
This is also why using Rust or C++ requires every organization to agree on a subset of the language they will utilize. Rust isn't as far along this path, but it's heading in the same direction as C++.
But with Go, every organization can use the complete language. That's how simple it is.
Go has been used by many organizations to build stable, large, and scalable systems that have been operating successfully in production for many years now. That's how complete it is.
I wonder if replacing the type system in Go with the one in Rust and adding native Actor model support would be doable. Or if GC and compile time would regress too much. Modern languages without good sum types just seems like such a lost opportunity to me.
That what I often wonder, if one is going to start using a new language why go? Rust at least it gave one memory safety and not having to use GC make it more stable usage of resource as the discord article have already pointed out. Seem like go is just google's .NET, every big corp need to have their own language.
99% of the code written out there doesn't need layers of indirection, responsibility tossing around, Code splitting across classes, design patterns, inheritance and the class jungle that is common in Java.
Rise of languages like Go is simply majority of the people realising when they want X, they are better of writing just X. You don't have to write a generic version of X that needs to work in a dozen situations. This is for a simple reason. Most of the times, there are no dozen situations. Most, not all the times.
Most of the code I write, doesn't change all that much. If you are writing code that needs to run for decades in an industry where grifting and job hunting is a daily affair you are doing it wrong.
Lately, I am seeing very few codebases getting supported more than 3 years in companies offering software products. Every 2-4 years services are getting rewritten, what's the point of having tool intended for 15 years, when services are deprecated in 4 years
You're doing it wrong if you think programming for work is about the code being a means of expressing your inner soul. The most successful professional programmers derive their enjoyment from achieving business objectives, like making products that users love and improve the world.
If you want to express your soul in your code, do that on the weekend using whatever language you want. Trying to mix these motivations is a recipe for disaster.
> The most successful professional programmers derive their enjoyment from achieving business objectives, like making products that users love and improve the world.
Successful by what metric? Achieving business objectives? I don't necessarily disagree with the point, but this seems like a truism.
You are just at the early phase of the project.
> Go is simple. It's easy to understand, read, and maintain
My opinion is that Go is too simple, to the point that it hinders understanding and readability. 4 nested loops with random mutability is much worse than a clear Stream api "pipeline". The 31st if err check will not be actually handling the underlying problem, while you can't forget about Exceptions -- even if they do bubble up to the main app, you will clearly get an actionable stacktrace.
> The tooling is built into the language
This has benefits, I will give you that. At the same time, I think all these new build tools are anemic and can't be used for anything more complex than interacting with the same language's standard dependencies. Gradle is not sexy, but is actually capable of doing any kind of build.