Ruby developers need to stop using EventMachine. It's the wrong direction.
...
Ruby developers need to stop using EventMachine. It's the wrong direction.
Lost in the "Threads vs Event Driven vs Process Spawning" debate is that you can combine them! Learn how Celluloid is improving thread programming by abstracting them using a higher level framework called Celluloid, how you can use Celluloid::IO to throw a reactor pattern into a thread. Using this approach, you can take advantage of threading and use all CPU power on a machine with JRuby or Rubinius. I also discuss the future of distributed objects and computing, and where I think things are going.
Ara Howard, Owner and Founder at owner at dojo4.com, llc.i really can't tell all you young kids how much of my life i've spent debugging shitty threaded code and writing libraries to make is less error prone. it can't be done. give up. move on.7 months ago
Are you sure you want to
Your message goes here
Brendten Eickstaedt, CTO / VP Engineering at Mavizon@bdicasa I certainly agree that detecting bugs caused by non-threadsafe code can be very difficult, my core thesis remains strong and I stick to it. If you focus on making your code threadsafe when you design and build it initially, then you don't NEED to worry about finding bugs due to threading issues. When thread safety is written into every object from the start (which really isn't all that hard, really) then you won't have to address threading bugs, because they won't exist.7 months ago
Are you sure you want to
Your message goes here
bdicasa@Brendten I'm not arguing the fact that knowing how to write thread-safe code is an absolute for any software developer. I'm also not arguing the fact that learning how to write thread safe code is hard. However issues with threading can be hard to detect, so why not use concurrency patterns that help you to avoid race conditions and deadlocks?7 months ago
Are you sure you want to
Your message goes here
Brendten Eickstaedt, CTO / VP Engineering at Mavizon@peterashford9 So true, Peter. I love Ruby, but I'm not a 'Rubyist'. A problem I've always had with a large group of 'rubyists' out there is that they seem to think being a Ruby dev absolves them from learning CS fundamentals in any way. You can't be a ruby developer without being a developer. Just because you started out as a Web designer/developer and found Ruby by way of Rails doesn't mean you can just ignore and/or not learn and practice the skills that are required fundamentals for software engineers using other languages. I would never even considering hiring a Java dev who couldn't write threadsafe code. Why should I consider hiring a 'rubyist' who can't, either? I hire developers who have the skills and knowledge that form the foundations of CS. If you have that, you can learn Java, or Ruby, or Python, or Objective C, or (*gack*) C# (or even more esoteric languages and frameworks we might use from time to time like Erlang, or OCaml, or Haskell, or whatever).7 months ago
Are you sure you want to
Your message goes here
Brendten Eickstaedt, CTO / VP Engineering at Mavizon@bdicasa Let's be clear: threads don't introduce problems, programmers who don't know how to use them, or who use them carelessly, introduce the problems. My argument here is that as a developer living and working in a multi-processor, multi-core world, you MUST understand threads and how to write threadsafe code. This should be a core part of everything you do when you design your software. Think about this: Tony has done a really nice job with Celluloid (and I have used it myself on occasion), but what if he gets hit by a bus, or if he suddenly decides to stop open-sourcing the code? Or what if you're not using Celluloid, and developing with MRI in mind, but along comes another developer 5 years after you've moved on to greener pastures, and decides to run your code on JRuby? What will happen to all of this code? It will be broken, and it will be your fault. Why? Because you chose to ignore the 'difficult' problems of multi-threaded concurrency when you originally designed and wrote your code. So, contrary to your assertion that 'it helps to understand how threading works,' I assert that you MUST understand how threading works (and as a corollary, how to write threadsafe code) in order to be even a competent software engineer in the world today.7 months ago
Are you sure you want to
Your message goes here
Peter AshfordAgree with Brendten: I'm always bemused with the programmer fashionistas going about how threading is *so hard*. It's not really. Yes, there are a few pitfalls you can fall in to, but there's a lot of information out there about how to do this stuff and in the end, the amount of code that's actually *doing* any threading is a tiny part of any application. I wonder if the whole 'threads are hard' manta is really just an excuse for the fact that a lot of 'cool' languages don't support them?7 months ago
bdicasaAbsolutely it helps to understand how threading works and it will make you a better developer. But many problems can be solved by these higher levels of abstractions which help avoid problems that threading can introduce.7 months ago
Are you sure you want to
Your message goes here
Brendten Eickstaedt, CTO / VP Engineering at MavizonOh, and by the way, Scala and Go absolutely DO NOT do away with threading. They merely hide it from programmers so they can't 'screw it up' and so they 'don't have to be bothered' with them. That's fine when appropriate, but to ignore that threads exist, and that we must know how to use them correctly, is simply irresponsible.7 months ago
Are you sure you want to
Your message goes here
Brendten Eickstaedt, CTO / VP Engineering at MavizonOf course they are, because people refuse to learn how to use threads properly. It's not hard, it just takes effort and precise thinking. Alternative concurrency models have been around for a very long time (Scala didn't invent Actors), but it seems that no matter what, we always come back to the basics: learn how to properly use threads. An analogy can be drawn from mathematics: to be a mathematician, you must be able to solve differential equations with nothing more than a pencil and a piece of paper, even though you often time will probably choose to use Matlab, or Mathematica, or something like that. You don't go right to the tool that abstracts away the complexity because you don't understand how to do it by hand, you go to it once you know how to do it by hand, and need something to make it more efficient for you to solve. And you only do this when it is appropriate to do so, rather than relying on it as the only way to do it.7 months ago
Threads and Events inHarmony with Celluloid Kyle Drake
Hi, I’m Kyle Drake. Iwork at Geoloqi Esri.We built a geofencing Textand real-time location streaming platform.
Last year, IText a didtalk at KRTConf.
I was really intopure event-driven Text(reactor patternbased) architecture.
EventMachine, Twisted, Node.js• Event-driven Text• No threads• One CPU core• Process Spawning
I releasedsinatra-synchrony,so I could use TextEventMachinewithout callbacks.
Since then, I’ve Textchanged my mind.
I’m really not a fanof EventMachine Textanymore.
EventMachine is• A frankenstein - guts the ruby internals• Not in active development Text• Makes non-blocking IO block• Requires special code from Ruby libraries• Hard to use in an OOP way• Is really difficult to work with• Poorly documented
Ruby developersneed to stop usingEventMachine. It’s Textthe wrongdirection.
Ruby MRI:Global Interpreter Lock (single CPU core) Rubinius and JRuby: Full threading (multiple CPU cores)~20KB per thread
We’re not finding a lot of thread safety issues in Ruby.
“Threading is hard”
Threading is not an intention!
Let’s fix it by abstractingthreads into how humans think!
http://celluloid.io• Developed by Tony Arcieri• Actor Pattern for Ruby• Lots of inspiration from Erlang
Each actor is aconcurrent objectrunning in its own thread
First “Killer App”: Sidekiq Mike Perham
Don’t get mewrong. Event-driven is still awesome.
“..seasoned engineers areusing a mix of threaded,event-based, andalternative concurrencyapproaches like Actors” - Alex Payne
What if we couldcombine threads and reactor patterns.. and actors?!
https://github.com/celluloid/celluloid-io• One reactor pattern per Celluloid object• Multiple reactors? No problem!• Doesn’t mess with code outside of actor• Utilizes all CPU cores (using JRuby and Rubinius)• Websockets, messaging systems, your hugelysuccessful blog
You dont have tochoose between threaded and evented IO!
Let’s getdistributed.
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages" - Alan Kay
Guess who was really into distributed network objects?
NeXT experimented with distributedobjects in the mid 90s.NeXT was way ahead of its time.
"Objects can message objects transparentlythat live on other machines over the network, and you dont have to worry about thenetworking gunk, and you dont have to worry about finding them, and you dont have to worry about anything. Its just as if you messaged an object thats right next door." - Steve Jobs
“Portable Distributed Objects”
https://github.com/celluloid/dcell • Objects talk over networks! • Uses 0MQ • Aware of eachothers’ existence • Distributed gossip protocol • Web UI • In the early stages, very promising
CODEEXAMPLES!
Help UsBuild This!
Thanks! @kyledrakekyledrake.net
Let LinkedIn power your SlideShare experience
+
Let LinkedIn power your SlideShare experience
Customize SlideShare content based on your interests
We will import your LinkedIn profile and you will be visible on SlideShare.
Keep up to date when your LinkedIn contacts post on SlideShare
Régis Gaidot
1–10 of 12 previous next Post a comment
1–10 of 12 previous next