Processes v. Threads - a fight to the death!
updated almost 7 years ago; latest suggestion about 7 years ago
This proposal has been withdrawn...
First, a question - when was the last time in the history of computing that a programmer gave a shit about efficiency?
As software devs we live a charmed life. For as long as languages have existed, we have written slow, inefficient software knowing that ever more capable hardware would bail us out eventually. Some people would say these days are coming to an end. Moore's law is running out of steam (clock speeds aren't getting significantly faster) and that the future is multi-core. But is it really?
In this talk I'll be looking at how we do things now vs a future vision of threads, concurrency, JRuby, torquebox and what it means for us as developers. In particular we'll look at the future of Ruby implementations, deployment options and how other languages are approaching this issue. On the way, we'll take in brief stops at Celluloid and EM-Synchrony to see alternative approaches to concurrency/parallelism in Ruby. We'll finish with a look at the economics and business choices involved in adopting a new programming style, and how that could affect the direction we take as an industry.
This is going to be an open-ended as opposed to dogmatic discussion. It's also a pretty epic subject matter to fit into a small talk so it won't have time to go into great detail.
I think open-ended presentations can be very interesting, but I find them most useful when they've equipped me with some concrete examples, and enough understanding that I can start to start playing with the questions myself.
Do you think it would be worthwhile to include one or more compelling-yet-simple examples of systems using concurrency (with code available online) to use as a basic for the comparison and discussion? This might help people before and after the presentation get a better grip of how such things work, maybe?
This is interesting as we are in a position where do have to process hundreds to thousands of complex requests every second and cannot keep throwing hardware at it.
The general consensus here is that we move away from Ruby entirely so I'd be interested in hearing why not and how not to.