This is a frequent complaint I hear about Go: they made the language too simple in certain places. People also tend to cite Rich Hickey's distinction between "simple" and "easy".

So the question about Zig becomes one of what exactly was kept simple, and what was allowed to become complex?

I think the world would benefit from a Hyperpolyglot-style comparison here. Rosetta Code is too much of a mess; ideally, I want to see a thoughtful side by side comparison of the same program written in several languages, with commentary.

And with respect to discussion of boilerplate, you can, of course, always have a "Zig++" language that patches over Zig. By cutting out its own metaprogramming functionality, it's much more straightforward to generate useful Zig source. There are a lot of advantages to restraint in the design, and Go does share that, too.

You can use a style in D that is even simpler than Go if you want, but it's nice to have the extra features for the times that they're handy. Just because the features are there doesn't mean it's a good idea to use them - and D allows you to program that way.

Even in a two person project, one person using a language feature will inadvertently force the other person to learn how that feature works. And they will not even know if the feature was appropriate to use until they have learned it.

With this small amount of reasoning we are back to the tired old argument of "Which is better? Ease of expression or ease or learning?"

Even if true, so what? "Personal projects" don't count?

But honestly, this is one of the worst programming language arguments there is. Any feature can be misused. There has to be discipline - full stop. Restricting the language is not the answer because that just leads to worse code, not better. Decades of C code demonstrates that lack of features does not translate into good programming practice.

That's more or less the reason I too don't find "multiple people projects may have problems with discipline" to be a good argument for anything. That's a culture issue and pretty much orthogonal to any technical factor of your environment, including the choice of programming language.

True, but the same is true of Go, which may be surprising to people. Despite its claims, Go didn't solve this problem.

One reason is that larger projects typically start to invent their own abstractions on top of the base language and Go is no exception here, in fact, what with its lack of some common abstractions, built-in support for code generation, frequent use of external add-ons (like go vet etc.), Go very much encourages this. And so you're going to have to learn specifics of larger projects just like with "complex" languages. The solution to this problem is meticulous and somewhat restricted code style standard, but that's a solution that works with "complex" languages just as well, in fact, I'd argue that even better.

The other reason is that the Go language is not just the Go language. That is, what with the lack of abstractions for error handling, code re-use, etc., people end up following a bunch of conventions, styles, patterns and using external tools (like the already mentioned go vet). And so in effect the language becomes "the base" + "lore". This is of course true of any language. With Go and early Java, for example, this becomes more pronounced, since the base part is very small, larger parts need to be taken care of by the "lore". This is why Design Patterns become so popular in the Java world. And this why it's not good to have the base part too small, which is the problem of Go. Of course, the other extreme is equally bad - that is, when the base part is too large, which is the problem of C++, where now "lore" has to take care of deprecating/removing language features.

I feel like the authors of Go decided to do the opposite of what C++ does and thought that since C++ is horrendous, doing the opposite would yield a great result. But unfortunatelly that's not the way things work. You can't just negate someone's bad approach and expect great results.

Then again, you are perhaps making a decent argument for using simple languages in multi person projects!

So yeah. I love feature-rich languages, but caution is prudent, and I can understand why Perl or D or what have you might be too feature-rich.

Consider the Go vs D comparison. D has good support for templates. Occasionally, templates are a big help, so every once in a while you should use them. In those cases, if you're writing D, you add a templated function and everything is concise and readable. In Go, you do one of several things, none of which is concise and readable. Future you will thank you for using D and taking advantage of it's features.

Features support the writing of disciplined code. Lack of features forces hacks, duplication, and crazy workarounds. The latter is what you're seeing when you look at ugly Perl code.

That's not to say that C crypto libraries don't suck for other reasons (I've used OpenSSL, I can't really defend that) but the language itself limits what you can do, in the standard library or otherwise. I mean, look at the many flawed or error-prone interfaces in the C standard library itself, I don't think stdcrypto.h would be the panacea.

There's a ton in Java, C++ and C#. One example in C is the proton implementation of AMQP.