Let me be the realist here : it isn't.
Go is just a very young language that, for the moment, only has developers that are curious and therefore either good or willing to learn. This has the additional consequence that for the moment the mailinglist is very helpful. History teaches us that both effects have nothing to do with the language and are temporary (unless the language never sees any "real" acceptance, like Haskell).
You can look messages from some years back showing the same sentiment for Delphi, Visual Basic, Java, Python (especially Python had lots of people making this argument), ... And when those messages were posted, they were true. It didn't last long for any of them.
> But people would struggle without Visual Studio debugging and a big run button.
Sadly this is being used as an excuse for making language with substandard (to put it mildly) debugging facilities and editors.
And of course, like for every other argument, the Go team itself is just being extremely arrogant about this. "Why do you want this ?" type responses, or just dead silence, or outright declaring the people asking the question to be substandard developers or some such.
That doesn't mean that idiomatic practices are always virtuous, but non-idiomatic code is only virtuous because it overcomes an inherent mismatch between what the user wants and what the language provides. With many languages (certainly js, java, c++) we see non-idiomatic practices guide changes to the language and then be replaced. Java gained functions to avoid the abuse of anonymous inner classes. ES6 is stealing from transpiled javascript languages left and right.
Making idiomatic code virtuous is the goal of creators and maintainers. Writing idiomatic code means that you have chosen languages, frameworks, and libraries that are closely aligned with the code you need to write and the style you want to write it in.
I can't say for sure, but I'm guessing it probably came from years of experience working on the sorts of projects that Go was designed to address. Go is really geared toward large distributed projects with a lot of contributors. In that context, it makes sense to value some sort of conformity. It may not always result in the most efficient code, but it makes the code much more maintainable and accessible to newcomers. Once you're familiar with idioms you don't need to spend so much time figuring out what a new piece of code is trying to accomplish.
You seem to argue that since old PHP and javascript code had terrible coding practices, therefore Go shouldn't try to enforce any particular type of practice. I don't see that your conclusion follows from that premise. Now if you're arguing that good coding practices arise from the community, that's well and good. Idioms can change and I expect that idiomatic Go code in 2020 will be different from idiomatic Go code today. That doesn't mean there isn't value to writing idiomatic Go code today.
I haven't actually seen any cargo cultists explicitly say that no one should be writing in other programming languages for any project. That would be a pretty stupid sentiment, although I shouldn't be too surprised if some people felt that way. Go's strength is really on server side code where storage is cheap and network and I/O latency is a bigger issue than CPU or memory utilization. If you're developing for that kind of environment, there's a lot to be said for using Go. And while you're at it, you'll save yourself and anyone else who's working with your code a lot of hassle if you follow best practices and write idiomatic code most of the time. If you're in a specific situation where you can get better performance or whatever by deviating from the standards, then go for it, but leave some comments explaining your choices to anyone else who has to maintain your code.
If I'm going to write a one-off script to process a million lines of text, I'm probably going to write it in Perl, not Go (and yeah I know it's 2015). My Perl code will follow TMTOWTDI whatever-the-heck-works practices. If I'm already writing Go for something, and others might want to peek at my code, then I will make an effort to make my code idiomatic.
Because being able to communicate is a virtue. That is all idioms are, a way to improve communication. By being well understood in a given community or sub-set of a community, they create a lot of value and a type of short-hand for understanding code.
Idioms are not static unchanging things -- they are flexible, adaptable, constantly changing tools that assist in understanding language (both spoken and programmed).
> Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co. It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged.
Seems like your problem is with bad idioms, you seem to be a fan of the Play style -- both are just idioms, a simple way to improve communication.
> The de-facto idiom of PHP before 2010 was messy code.
That isn't even an idiom. An idiom is a well understood part of a language and community. "Messy code" isn't an idiom, it is just messy code. There is no value gained from it, it has no short-hand value and it is not well understood across a community.
> It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose...
But well understood by those in the space, a Laravel person can see another Laravel persons code and "get it" very quickly because they speak in the same idioms. It might be ugly to you, but it is useful to the community. Rails has its idioms, Django as well...
> Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before.
Idioms are about communities more than languages, JS toolkits vary rather wildly in what they consider idiomatic.
> In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse.
Again, idioms are about what those native in the language or toolkit understand and can expect others to understand, they have never been (nor are intended to be) static, they are a reflection of what a community understands. They are shorthand.
> But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code.
Go has a very strong core set of idioms that Go developers understand and expect. Breaking them has a significant cost to all future readers of the code and should be done only if it adds value in some ways. But a lot of questions in Go are far from settled, error returns as interfaces, concrete types or strings. I would be interested in explicit examples rather than vague cargo cult claims.
> It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.
"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it. Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on. Of course, there are valid reasons, it is faster, it is lighter, it is X. But when you diverge from the norm, you better be willing to explain it in a comment, both the what and the why.
No, my problem, is with the pre-supposed and agreed upon set of idioms ("idiomatic Go", "idiomatic Java", "idiomatic Python").
I'm not even against what those idioms contain per se, as individual items.
>"different but convenient" can to be looked at in two different ways. The first is for you, the original developer. It is more convenient for you... but what about the next 5 (or 50) developers who are unfamiliar with the idioms in play, it will radically slow them down as they lack the shorthand to quickly understand it.
Well, the reverse can be true.
Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.
Someone coding unidiomatic Java (e.g. Play) and giving the project to them, they'd instantly understand what its going on -- even better than someone giving them an "idiomatic Java EE" monstrocity.
>Go is about programming at scale (in terms of people) and something that benefits one while slowing down all others is going to be looked down on
People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".
Programming at scale, like big 3D games, Photoshop, the Linux Kernel, Webkit etc, is still done in C/C++, with no sign of this changing.
Idioms have to be agreed upon (by the community) else they have no value at all. Shorthand only works if both people in the conversation understand what it means.
It seems like you are upset that the idioms came from the standard libraries (which is where I believe the initial idioms for Go, Java, and Python stemmed from), but you also have to give time.
Play was released in 2007 -- Java was released 1995. So it took a number of years for that change to take place. During the between time, idioms helped move java forward, make it understandable, make developers able to communicate via code.
Go was released in 2012 (v1), so of course a lot of the idioms are going to stem from the standard library -- we don't have two decades of Gophers moving the ball forward and agreeing as a community what the idioms are, they gotta start somewhere.
> Java programmers familiar with the circa-2004 idiomatic BS over-reliance of GoF patterns and deep class hierarchies created code that was "idiomatc Java EE" but difficult to undertand, overengineered, and inflexible.
Idioms are not static. Please stop using that as a strawman to tear down. Idioms rot. If they are not what the community currently uses, they are not idiomatic.
> People keep saying that, but most Go projects I've seen are made by only few of people, maybe even a couple. Plus, people complain about even single-developer Go projects being "unidiomatic".
Current use and design goals are not the same. Google developed Go to be used at (many-people) scale, even if it currently isn't (which I don't agree with: https://code.google.com/p/go-wiki/wiki/GoUsers). It isn't like Go can stop individuals from using it.
I'm not annoyed by idioms because they don't ever change -- but because while they exist in a certain form, they inhibit experimenting with different approaches.
Or to be more presize, I'm not annoyed by idioms themselves (as I also wrote above), as individual practices. I'm annoyed by people insisting on them, and criticizing everything diverting (unidiomatic) as something that's bad.
Nothing is static, except change. But for a specific period of time (which can be like aeons in the software industry) idioms are for all intends and purposes static.
E.g Java EE land, from say, 2000-ish to 2007. The idioms were fixed and agreed upon, and most people and groups, from Apache Struts to Java engineers and IBM played by them, but they neither helped the community "communicate via code" nor helped "make programs understandable".
Instead, they hindered both communication and understanding. Almost everybody agrees now that the adopted idioms at the time were bad, and inhibited progress and even slowed down projects.
It's not even like "it was good for it's time, but we eventually came up with something better". We always had the option to do the better thing (it doesn't take unique new research to not use a 20-levels deep hierarchy or to not think GoF patterns should be applied everywhere). And since we moved on, everybody seems to agree it wasn't "good for the time" either.
I see you all the time in these go threads, by the way. You would better spend your time forgetting about go and doing something else since you so clearly detest it for not having generics (obviously less convenient than a functional language, but clearly not required to do programming).
Idiomatic Java was the FactoryProxySingleton EE-wank fest from Apache, SUN, Spring and co.
It was by changing those idioms around (e.g. how the Play framework wrote Java), that saner alternatives emerged.
The de-facto idiom of PHP before 2010 was messy code.
It started getting more coherent after that, but the preffered idiom now (e.g. for Zend, Synmphony, Laravel) is still a tedious, verbose, copy of the Java circa 2006 style (large class hierarchies, singletons, "Facades", DI, etc).
Idiomatic JS pre-Cockford was ad-hoc BS. After Cockford it got a lot better, but then it changed again (can't say for the worse) with all sort of functional tricks and patterns that weren't in vogue before.
In all of those cases, if they have stuck to the same "idiomatic" way from the start, it would have been worse.
Within a single project, sure, enforce some idiomatic way of doing things.
But within a whole language people should be able to experiment and not be called upon for being "unidiomatic" all the time. This is exceptially disturbing and often in Go, where there's some cargo cult in many advocates that they have found the be-all end-all way to code.
It seems to me this push for "idiomatic" is also related to the Blub paradox. Blub programmers know a couple of ways of doing things (the "idioms" of their language) and cannot understand why someone might want to program with higher (or just different but convenient) concepts he learned in another language.