as one of those folks who's been attending Defcon since the 90's, and find the odd bit of pseudo-military gear damn useful for being on their feet for extended hours during a four day conference (only a small part of me finds it cool any more, and I never thought it funny), I'd be happy as hell to talk with you, and introduce you to many of the other folks that I know wear the same - because I think we'd all agree that we have an obligation to you as a fellow attendee to make you feel welcome and safe, and we welcome your input on how to do that. True, it's your problem, but that doesn't mean that other folks can't accommodate you if you give them a chance to do so - I think most of us would be more than glad to have the opportunity - you're part of our community and we have a responsibility to look out for the interests of one of our own. This is of course, the exact opposite of what happened with the censorship of the talk at BSidesSF. Sure, we don't *have* to change to to satisfy you, but many of us might /want/ to, given the chance. Discourse and cooperation are the best tools here.

Calcium isn't a stone now? he said literally, he meant literally.

Bingo.. and as many other folks have pointed out, 90% of of threading is purely to decrease latency and bypass blocking operations - very few applications out there today are heavily dependent on concurrency to achieve any kind of raw horsepower... This does just seem like, if it were to become mainstream, would just become a crutch for developers to ignore threading and blocking I/O issues entirely, because "The compiler will sort that out".. In theory, this isn't necessarily a bad thing. In theory, all things work in practice too.

Or, gawd forbid.. we could teach programmers how to use threading? I am a casual developer, with no formal training beyond writing practical code and reading as much as I can from the keyboards of real developers. I've run into my fair share of "real", "professional" developers who've been tasked to work on my code and thrown their hands up in defeat - not, as I feared, because of the awfulness of my coding style, but "This uses threading, I don't know this!".. Of course, looking at their resumes, a long list of single threaded webapps where the actual threading is handled for them by the webserver itself.. I give up. Even some basic native GUI client development should teach developers simple threading and asynchronous callbacks? alas, yet another talent abandoned in the age of the webapp. Is it any wonder the security issues (my actual realm of supposed 'expertise') in their code often make the architectural issues look trivial in comparison?

An interesting development, and much needed I fear, but yet another layer of abstraction to allow lazy developers to not have to really bother about knowing what their code is actually doing (that's for the poor SoB who has to maintain it is for...)