[throw1111221]

Well that's good, since Go was specifically designed for juniors.

From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical."

However, the main design goal was to reduce build times at Google. This is why unused dependencies are a compile time error.

https://go.dev/talks/2012/splash.article#TOC_6.

[the_gipsy]

> This is why unused dependencies are a compile time error.

https://go.dev/doc/faq?utm_source=chatgpt.com#unused_variabl...

> There are two reasons for having no warnings. First, if it’s worth complaining about, it’s worth fixing in the code. (Conversely, if it’s not worth fixing, it’s not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.

I believe this was a mistake (one that sadly Zig also follows). In practice there are too many things that wouldn't make sense being compiler errors, so you need to run a linter. When you need to comment out or remove some code temporarily, it won't even build, and then you have to remove a chain of unused vars/imports until it let's you, it's just annoying.

Meanwhile, unlinted go programs are full of little bugs, e.g. unchecked errors or bugs in err-var misuse. If there only were warnings...

[Mawr]

Yeah, but just going back to warnings would be a regression.

I believe the correct approach is to offer two build modes: release and debug.

Debug compiles super fast and allows unused variables etc, but the resulting binary runs super slowly, maybe with extra safety checks too, like the race detector.

Release is the default, is strict and runs fast.

That way you can mess about in development all you want, but need to clean up before releasing. It would also take the pressure off having release builds compile fast, allowing for more optimisation passes.

[pa7ch]

I feel like people always take the designed for juniors thing the wrong way by implying that beneficial (to general software engineering) features or ideas were left out as a trade off to make the language easier to learn at the cost of what the language could be to a senior. I don't think the go designers see these as opposing trade offs.

Whats good for the junior can be good for the senior. I think PL values have leaned a little too hard towards valuing complexity and abstract 'purity' while go was a break away from that that has proved successful but controversial.

[ErroneousBosh]

> This is why unused dependencies are a compile time error.

I think my favourite bit of Go opinionatedness is the code formatting.

K&R or GTFO.

Oh you don't like your opening bracket on the same line? Tough shit, syntax error.

[benjiro]

But it also has a advantages that you can literally read a lot of code from other devs without twisting your eyes sideways because everybody has their own style.

[pkaye]

Doesn't Google use mostly C++?

[throw1111221]

Just because it was a design goal doesn't mean it succeeded ;)

From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby."

https://research.swtch.com/gotour

[dpe82]

It really depends on product area.

[allset_]

No.