> being a better Java for teams of mid-tier engineers.
That cuts me right to the bone.
That cuts me right to the bone.
IMO it is better said that Go is designed as being a good language for Senior and Junior developers, where mid-tiers will probably hate it.
I do like to dabble in F# still.
I think the ultimate goal of making a programming language is to cause the least friction for a programmer trying to get real work done, and in my experience Go's great from that point of view. Language bells and whistles may be exciting, but often don't pay their way in terms of real world productivity, IMHO.
Abstractions make large systems easier to understand, not harder. Each line of Go is easy to understand, but whole programs are not.
I raise you AbstractSingletonFactoryProxyBean.
Well, in the real world a lot of people have to work on teams where many of their co-workers never grow beyond beginner level. So anything that can be done to reduce the burden of having to deal with them is welcome. Not everyone gets to sit in the Silicon Valley ivory tower beside the greats.
> your career lasts 40 years
40 years is a peculiar number. If it is your passion, you should easily be able to see 60-70 years (assuming you live to an average age), and if you are only in it for the paycheque the comparatively high salary offers you retirement long before 40 years comes around.
It is this condescending attitude that I feel many golang advocates (online) share that makes me shiver.
What are you implying, that devs using other languages don't get "real work" done?
Let's wait until Go has the same history, maturity and reach of e.g. Java and then let's see how well it will hold up in comparison.
In the time you get everyone on the team to agree whether you should use Maven or Gradle, which testing framework to use, or figure out how to autoformat your code, your Go program will be done.
* everyone agrees to use Cargo
* everyone agrees to use `cargo test` (what even is a “testing framework”)?
* everyone agrees to use `cargo fmt`
What’s the advantage of go here?
By the way, the formatting situation is actually worse in Go because there are both gofmt and gofumpt used in the wild, at least gofmt has different behavior depending on different flags, and there are additional linters people use to e.g. ban long lines that for some reason the formatters don’t cover.
I don't know why we're talking about Rust in the first place, but an obvious advantage would be compilation time and iteration speed in general.
Let's wait another 15 year and then compare the new languages at that time against golang. Then let's see how golang is doing in comparison.
I used Go for most of my own projects and as I got deeper into it began to realize its warts, but the worst was that you can't get performance by "share memory with communicating"--channels are slow. Reading the non-idiomatic stdlib implementation shows the difference of who it's made by vs who it's for (which isn't the authors).
What's the difference? The opposite, so to speak, of system is script, and I don't think system management falls into the scripting category. A system management system is a system too. But that isn't what they were talking about anyway. They were talking in the context of building servers (think like a HTTP server). That was clearly spelt out.
I understand that the Rust crowd has reimagined system to mean something akin to kernel, much like they have reimagined enums to be akin to sum types. Taking established words and coming up with entirely new meanings for them is what they like to do. But that reimagining has no applicability outside of their little community. This is not how the industry in general considers it.
There was a sort of misunderstood dream in the early days of go that it would make fanning out and using your 24 cores easy as empowered by channels: this is still not easy in go, although it may be easier and less error prone than c.
In the intervening decade, python has made say a parallel for loop immensely easier.