This attitude is fine for personal projects, but it does not scale when working with other people.

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?"

> This attitude is fine for personal projects, but it does not scale when working with other people.

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.

C has clearly other issues than just a lack of features.

You could very well argue, however, that many of the issues with C are symptoms of a lack of some specific features. To work around that, you need just as much discipline (to avoid, for example, buffer overflows) as you would need not to misuse the features that aren't there.

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.

> This attitude is fine for personal projects, but it does not scale when working with other people.

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.

Are you not doing code reviews in your organisation?

You're assuming the multi person project has no coding standards.

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

Perl is another language with a lot of features. I tend to appreciate those features, since once you know how to use them they're a huge timesaver and productivity boost. However, the more obscure/clever the feature (or application thereof), the less likely another programmer (your future self included) is going to understand it. And if you're tasked with maintaining old code written by someone (your past self included) who knew/used a different subset of the language's features than what you currently use, you're suddenly going to need to learn that subset.

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.

This is actually exactly what I'm arguing. If you have a language with lots of features, you don't write clever or obscure code. The stuff people do with Perl is because the language allows it, but doesn't include features to do it for you. That's a sign that something is missing from the language.

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.