This is quite a startling position for a library author: don't supply convenient constructs that could be misused if they aren't absolutely necessary. Without any desire to be snarky about the hard work that went into POSIX, I'm glad as a discipline we've move on in the last 20 years.
Especially in synchronization it pays off to go with the simplest solution. Unless you know very well what you're doing (and wrote some formal verification that it can't break under any circumstances).
I'm right there with this "startling" (some would say "opinionated") position. And so is my C library, which complains at me every time I compile a program using getwd()
("my" as in the one I have installed here. I am making no ownership claim)
The Rails "kerfuffle" was about unnecessarily dangerous default settings affecting a widely-used (including in official tutorials) mechanism.
To even get a recursive mutex in POSIX, you have to explicitly ask for one, they're not even mentioned in most (any?) tutorials, they don't pose any direct security threat, and unlike Rails, POSIX threads are not a common thing for brand-new developers to be using, much less in anything exposed to the public Internet.
Irrespective of what the tutorials say, many developers will go reaching for a recursive lock the first time they get a recursive deadlock - especially if they come from a Java background - and tutorials or no, it's not as though the information is hard to find. Five minutes browsing Stack Overflow will quickly disabuse you of any perception that all the people writing POSIX threaded apps are in any way particularly gifted, even compared to Rails developers
And since you want to argue based on SO, I'll just leave you with two bits of data from SO:
http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions
http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions
But you're still reading things into my comment other than what I said.
(1) Rails had insecure defaults which encourage bad programming
(2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming.
(3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library.
That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.
Dear Google: please stop requiring authentication to read public google group messages.