I disagree with this. Even if an application developer does not realize they are communicating with other machines, history has shown that providing tools for concurrency inside the language greatly enhances that experience. Even in rather nice abstractions like TPL, you still need to care about things that you probably don’t want to because of the substrate a Task runs on. It’s also going to be harder for languages to not provide concurrency as a first-class citizen given the success of Go, IMO.
I agree with you, not really for the concurrency that a language like Go provides and more along the line of what research languages like Bloom (http://www.bloom-lang.net) are moving towards.
I don’t think that Bloom’s model has much hope in the next 5 years–based on my experience in the enterprise, with fairly capable developers, the mere mention of “eventual consistency” (even when followed up w/ “but it’s optional!”) causes many to believe that eventual consistency = incorrect results. I think it will require more people than just those in compiler courses to become comfortable with semilattices early on in the career; however, I’m looking forward to that day.
I’m not sure I understand the argument. It seems to acknowledge that there is a need for constructs that support programming concurrently, and state a preference for the ones that prevent us from having to think concurrently, but not to include them in the language?
Does it matter where we make concurrency mechanisms available? Probably it’s more important that we understand concurrency models and apply them appropriately.
I think that you can trace this justification by looking at a system like Boehm or Ravenbrook MPS–in these systems, you need to write a lot of boilerplate to get the GC to work, and there’s still the possibility of mistakes. Compare this to writing reactive code in node.js or Java vs. using Erlang or Go, and the parallel should be more clear. Essentially, the reduced barrier to entry for these existing useful concurrency models is important for their future success.
This is in response to this other post, concurrency is the new memory management.