[zik]

In the end it was a dumb comment by one of the Go devs which got jumped on by all the Go haters. Contrary to the popular meme, Go's not just for mid-tier programmers - it never was (and to be fair to Rob Pike, they've twisted what he said). But sure, it makes it easier for programmers at all levels to get started, and to get real work done. That includes advanced people as well as the inexperienced.

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.

[umanwizard]

I have never understood why go fans think “make it easier for beginners” is an important feature. I mean, sure, it’s nice to have, but not at the expense of anything else — your career lasts 40 years; why optimize for the first month experience?

[elvlysh]

Pretty much every reputable computer scientist has been saying for the last 70 years that the most important thing in the entire world is simplicity and ease of understanding.

[umanwizard]

First of all, that is not true. But even if it were, those are not the same thing as how easy something is for beginners.

Abstractions make large systems easier to understand, not harder. Each line of Go is easy to understand, but whole programs are not.

[elvlysh]

>Abstractions make large systems easier to understand, not harder.

I raise you AbstractSingletonFactoryProxyBean.

[umanwizard]

Sorry I meant good abstractions, not all abstractions.

[jay_kyburz]

I like that meme graph with the junior programmer liking the simplicity, then the mid level programmer liking the power, then the senior going back to liking the simplicity.

[9rx]

> I have never understood why go fans think “make it easier for beginners” is an important feature.

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.

[valenterry]

> But sure, it makes it easier for programmers at all levels to get started, and to get real work done.

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.

[Mawr]

Start a Java project and a Go one.

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.

[umanwizard]

Meanwhile, start a rust project, and:

* 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.

[Mawr]

Yes, Rust copied all those good ideas from Go, so this is an odd argument to use.

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.

[vessenes]

The rust team will be bikeshedding a borrow checker error and debating if using unsafe is appropriate for some time after this, though.

[valenterry]

Well, sure.

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.

[karmakaze]

It may have been a dumb comment, but there's some truth to it. Go was to solve a Google problem of devs that needed to write system management programs, not systems themselves. The choices of Python or C/C++ left a large gap that Go filled.

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).

[9rx]

> Go was to solve a Google problem of devs that needed to write system management programs, not systems themselves.

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.

[vessenes]

It’s funny you mention that: my on and off years with go have locked a couple (possibly wrong today) ‘rules’ for go; one is that channels are crazy slow, and another is that defer does not always work like you imagine it will.

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.