Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
My first chance to do serious concurrent programming was using C++ on Windows in the 90s, on NT, where async programming was done with IOCompletionPorts. It was pretty interesting, but as is the case with most things C++, it was like ‘here‘s the keystone, you can build the rest of the doorway now.‘ C++ got a bad wrap. Sure you could blow the whole machine up with an errant pointer, but there were also outstanding tools that could find all those things in a large codebase in a matter of minutes. The real reason C++ went from top of the heap to the ash bin was a decade of producing a standard mostly chewed up the oxygen debating the String class. Java sprinted in the other direction and decided to put shacks up to cover the whole waterfront. 15 years later, how many of those things are super useful? Not that many. By far, the best case study of APIs in Java, AFAIC, is the concurrency library, which was abysmal and stupid when it first came out but was then redone by Doug Lea et al. Not long after using the concurrency package (in prerelease), I came to the conclusion that it kind of fit the billing that Doestoevsky gave to Don Quixote: the first and last word on western thought (substitute concurrency). Sadly, the next decade was spent inside anemic containers that told people not to worry about asynchronicity. That is breaking open now with the advent of things like Play and Akka.
However, yesterday I saw a tweet from Bill Pugh saying that using iOS after java concurrent, he feels so crippled he might have to implement util.concurrent in iOS. I am not so sure of this. I find that iOS and GCD is probably a step ahead of Java in a very typical Apple way: it‘s simpler, so it makes the 80% cases much easier and cleaner, but I have also read cogent arguments from concurrency cats who think that ultimately a scheduler model makes the most sense. One thing is for sure, they are both smarter than an EE container, which would have you put up a JMS queue to get simple async abilities.
In a related Twitter tangent, I was following some of the TypeSafe guys for a while after doing my first Akka project. They are a pretty boring lot, filling up the airwaves with cutesy little nudges to each other on inane matters. But one day, one of the Akka guys was mocking Future (from the concurrency library) for not having an onComplete() method. So I went a couple rounds with the two of them. The main impression that I was left with was that this was a case of Freud‘s narcissism of small differences . I also had occasion to get my Goetz book off the shelf, and was reminded at what a serious tome that is. Shit talking util.concurrent doesn't make you look like Gary Cooper in High Noon; more like Eddy Murphy in 48 Hours.
Read an article a week or so ago saying the EE market was TypeSafe‘s to lose. I am betting that‘s just what their cocktail of bluster and hubris will end up doing (maybe they should get a PR person who has studied the Romney Campaign).
Published at DZone with permission of Rob Williams , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.