I find that there are some disturbing similarities between the Java community and the Go community when it comes to features and culture. There seems to be an unwritten assumption that the language is perfect in its current form and any additional features are a source of evil (up until the day when they are added, in which case they are suddenly evidence of the language's superiority).

> the language is perfect in its current form

It works really well in its current form, that is probably the general consensous.

> additional features are a source of evil

Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

> up until the day when they are added, in which case they are suddenly evidence of the language's superiority

That sounded very much like flamebait. Could you name an example of a feature added to Go that was previously considered evil and then as evidence of Go's superiority?

Thescrewdriver is absolutely correct about Java. Many years ago, I participated in several Java user groups here in Silicon Valley. We frequently had members of the Java team from Sun as guest speakers. It always went roughly the same: we professional Java devs would ask them for a few language features that most of us wanted, and they would explain to us that they knew better than we did what a programming language should have and suggest that we should get over it.

Then a representative from Microsoft started attending a couple of the biggest Java SIGs, and he would ask us how we would change Java if we could. We were happy to answer. A few of the suggestions were broadly desired by the groups.

He took lots of notes, and a year or so later C# was announced. It included several of those features. My impression is that most of us considered it a better Java, as a language design. (The Achilles Heel of its relationship to Microsoft was a huge, but separate, issue from the design of the language itself.)

The Java Team suddenly had a whole new attitude about their fossilized masterpiece, and features we had been told for years were bad ideas were touted as evidence of Java's ongoing spirit of innovation with each new version of Java.

The first two apply to Go and Java, the last only to Java since Go hasn't added major features recently.

>> additional features are a source of evil

> Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

We've walked down that path and have been very happy and productive with Scala. Each to his own I guess.

> I disagree, especially in the presence of syntax highlighting editors.

Every syntax highlighter in an editor I've seen for Ruby handle highlighting string interpolation just fine.

You're probably right. Also, I obviously should've said, "Except the first one is much more readable to me."

I definitely don't have a problem with the Go developers keeping out random syntax additions unless they think its a really good idea.

Along the same lines, I really miss not having `map`, `reduce`, and `filter` in Go. However, it doesn't seem like those would be efficient in Go, or that they fit in with as well with systems programming, which Go was designed for. So I can't hate them for not including these.

For what it's worth, I do think it's more readable, but it's just not a good idea. It's too easy for people to inject variables into their strings and get your code to print out data that's in memory.

map, reduce, filter, etc will be easy to code up once there are generics. There will almost certainly be generics in Go at some point, that point is just not right now (and almost certainly not before 2.0).

What? There's absolutely no way for a user string to get scanned for format instructions unless you 'eval' or something like that. The proposed syntax is only for string literals in source code.

Ahh, oops, that was pointed out below as well. Sorry, I assumed a string was a string, not that this only works in string literals. That's certainly better than letter user-supplied strings work this way.