
155 RR Why Ruby Sucks
The Rogues have a friendly discussion about why Ruby sucks and what the language could do to improve.
Show Notes
The Rogues have a friendly discussion about why Ruby sucks and what the language could do to improve.
Transcript
JAMES:
Whereâs David? Did he fall into the water trough?
CHUCK:
How did you know he has a water trough?
[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. Thatâs $50 per month at RubyRogues.com/Rackspace.]
[DevMynd is a software design and development studio in Chicago with expertise in Ruby, JavaScript, and Clojure. We believe that well-crafted software makes life better. And our team of designers and engineers is dedicated to that pursuit. We love our customers, we love our team, and we spend a lot of time and effort making sure that we fit the right projects with the right people. Get in touch at DevMynd.com.]
[This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.]
CHUCK:
Hey everybody and welcome to episode 155 of the J- [Chuckles] JavaScript J-.
JAMES:
Ouch. Ouch. [Laughter]
DAVID:
Keep going. Keep going. [Laughter]
DAVID:
Youâve made this mistake so many times, Chuck, Mandy, that the episode is on. Just pick it up.
JAMES:
Weâre going with it. [Chuckles]
DAVID:
Keep going. Keep going.
CHUCK:
Hey everybody and welcome to episode 155 of the Ruby Rogues Podcast. [Chuckles] This week on our panel, we have Avdi Grimm.
AVDI:
Hey, I thought this a C++ show?
CHUCK:
James Edward Gray.
JAMES:
Iâm only staying if weâre talking about Lua.
CHUCK:
David Brady.
DAVID:
Iâm David Brady and this episode really grinds my gears.
CHUCK:
Iâm Charles Max Wood from DevChat.TV. And this week weâre going to talk about why Ruby is not the Promised Land, or maybe why there are other Promised Lands.
JAMES:
That does it. Iâm hanging up. [Laughter]
DAVID:
Yeah.
CHUCK:
Whose idea was this?
DAVID:
Weâre going to take some sacred cows and make some delicious, delicious hamburger.
JAMES:
It was Avdiâs idea. Heâs the resident curmudgeon. [Laughter]
CHUCK:
Yeah, we got him complaining about Erlang in the Rogues channel.
AVDI:
Come on. You all know this language sucks.
JAMES:
[Chuckles] Thatâs right. Ruby sucks.
DAVID:
Itâs true. Itâs true.
JAMES:
So, weâre going to talk about specific problem points and where they might be better, kind of a grass is greener sort of approach. So, whatâs a problem point? Throw one out there. DAVID: So, should I start with the really big one that had the disclaimer that we talked about in the preshow?
JAMES:
Disclaimer. Oh, nice.
CHUCK:
I didnât see a disclaimer.
DAVID:
Okay, so my biggest axe to grind right now with Ruby requires a disclaimer. And the disclaimer is this: thereâs a rule in open source that says donât complain, only fix. And I want to be careful with that rule. Sometimes I want to build cathedrals, not make bricks. And if I bash on about the lack of a particular type of brick, I donât mean to disparage those of us out there toiling away making bricks. Keep up the great work, guys. The one exception Iâll make to this disclaimer is that I want to talk about version mismatches between Ruby 1.9 and Ruby 2. And thereâs no other way to say it than I want our gems to work on both versions of Ruby and sometimes they donât. And I donât have time to fix the entire Ruby ecosystem so Iâm just going to complain instead.
JAMES:
[Chuckles]
CHUCK:
Isnât this the point that, I think it was Avdi made a few weeks ago about debuggers?
JAMES:
Yeah. The debugger, itâs probably the penultimate example because it seems to break with everyâŠ
AVDI:
[Laughs]
JAMES:
Every single version of Ruby?
DAVID:
Yeah. Ultimately what it comes down to is in my opinion there is currently no stable version of Ruby that also has a robust ecosystem. There are widely used tools like MetricFu that arenât ready for Ruby 2. As of a month ago, Ripper still wouldnât rip Ruby 2 syntax. I think thatâs changed. But there are other widely used tools like guard that have amputated their Ruby 1.9 support. They just donât run. Rb-readline wonât work on Ruby 1.2. And Guard has switched to use rb-readline instead of the rb-notify and the different types of readline support that it had. So, in some languages, you want to change things. And you have this trailing edge of really old legacy stuff and then you have this stable platform where everybody gets along great. And then you have this sloping forward bleeding, leading edge of the language. And right now, I feel like Ruby 2 is bleeding edge and not work-y. And we have amputated the tail of 1.9 support in some areas. But weâve amputated so close to the bleeding edge that there is no stable platform in the middle.
AVDI:
So, what language has a stable platform?
DAVID:
Iâm going to go ahead and eat my own words on this one. I have publically derided Python for freezing core for two years. Guido stopped development on core. He basically stopped development on the reference language so that everyone else could catch up. And that was right at the time that Ruby was saying, âHey letâs go from 1.8.7 to 1.9 and letâs not be backwardscompatible. Letâs jump headlong into the future.â And Python at that same time literally was freezing for two years. And I mocked Python ridiculously and this just totally showed how Python were a bunch of stick in the mud backwards fear of progress people. And boy, those words are really hard to chew. But boy golly, Iâm going to have to eat them because weâre now reaping a little bit of the dark side of having jumped forward so fast and cut ties with our past so quickly.
CHUCK:
So, is there a way to solve this problem?
JAMES:
Let me say this, because this is interesting. I have not felt this particular pain with Ruby 2. I definitely felt it in the 1.8/1.9 era and I assume thatâs no⊠when we were making that transition Iâm pretty sure the whole world felt it. I thought Ruby 2 was fairly smooth. There were some changes. I had one particularly large app that began to segfault on it which was really unfortunate and caused some problems. And then the Ruby 2 to Ruby 2.1, to me that was almost a plug and play. It seemed perfect. So, I find it interesting that you run into that a lot lately and I havenât. You mentioned Ripper. Ripper is included in Ruby. And I wasnât aware that there was any point that it couldnât parse its own syntax. Itâs actually really interesting if you look at how itâs implemented. They cover it a little bit in Rum because the parser basically now has if-elseâs at almost every node that it parses. So, the if is, am I parsing this for Ruby itself in which case I do this thing to get it ready to go to Ruby, or am I parsing it for Ripper? And so, that, it didnât do that. So, I feel like the Ripper integration is really amazingly good. But I havenât seen theâŠ
DAVID:
I may be fingering the wrong gem. I think itâs Ripper. But a month agoâŠ
JAMES:
But Ripperâs not a gem. Itâs included.
DAVID:
Sorry, yeah. Wow. I may be actually having a beef with Ruby itself then. All I know is I wrote a program that had keyword arguments. And I want to say optional keyword arguments, so weâre talking 2.1 stuff here. And it just blew up. MetricFu, one of its gems, like Saikuro I think uses⊠and you know what might have been happening is that Saikuro might have been using an older version. Iâm not sure how thatâs even possible. But it might have been using an older version Ripper to parse the Ruby syntax. And yeah, I lost all my complexity metrics because the language couldnât be parsed anymore.
JAMES:
Thatâs interesting. I havenât run into that problem but I admit I havenât used MetricFu in a while. And Guard I think was the other one you named with readline. I havenât hit that particular problem either. I do use Guard, but I donât think Iâve used it very recently. So, I may have just dodged that bullet. I donât know. Avdi, Chuck, have you run into trouble with the Ruby 2 transition?
AVDI:
Itâs been smoother than previous ones.
DAVID:
Iâm just the lone voice crying in the wilderness. [Laughs]
CHUCK:
Iâve run into things occasionally that donât⊠For example, I move ahead when thereâs a new version of Ruby out. So, Iâm writing code on Ruby 2.1. And occasionally Iâll run into something that doesnât play real nice. Thereâs some little gotcha between 2.0 and 2.1 or 1.9 and 2.1. But itâs pretty rare. And most of the time I can find a way around it without too much hassle.
JAMES:
One of the issues Dave brought up is really good I think, and thatâs keyword arguments. In my opinion, keyword arguments didnât really become fully-baked production-ready this is a go until Ruby 2.1, which was kind of unfortunate. I almost wish they could have shipped in that state originally because itâs this weird thing now when Iâm using Ruby 2. We have an application at work thatâs tied to Ruby 2 and itâs like, âIâll use keyword arguments,â and then I forget, âOh they still have that one major disadvantage here.â
DAVID:
Yeah.
CHUCK:
Yeah.
DAVID:
Last week we talked about games with Megan Fox and I mentioned that I might go off and do Ludum Dare with Ruby Gosu. And I was going to explore the Releasy gem to ship to Windows. And for anybody whoâs interested, I did actually chicken out largely because the Saturday of Ludum Dare turned out to be my wifeâs birthday, which I as an ignorant standard bone-headed husband forgot. So, through no fault of Rubyâs, that didnât happen. But I did take a minute to install Releasy. And it requires, if you want to build on Linux which I do and you want to ship to Windows which I did, you have to use Ruby 1.9.2. And all sorts of things fell apart. MiniTest was available as a gem in 1.9, wouldnât run. And what happens is Bundler just gives up. It says, âI canât give you the version you need.â Even though that version, a version that satisfies the Ruby version number requirement, even though a version of that gem might exist somewhere, Bundler canât find it. It just gives up. And so, youâre at that point. Youâre literally going out to GitHub and digging through the commit history of the gem to find which commit message to clone and build manually and install. I will admit that 95% of the time, Ruby and Bundler are great and they work fantastic and theyâre seamless. But the other 5% of the time, we have no package management. And our pants are down on the internet.
CHUCK:
So, I have to ask this. At what point is it appropriate to drop support for 1.9 or 1.8?
DAVID:
Never.
JAMES:
Well, 1.8 is dropped.
CHUCK:
So, you drop support when the core team drops support?
DAVID:
My code still runs on 1.8.4.
JAMES:
Wow. That would be awesome.
DAVID:
Not really. Not really. I actually have code that doesnât run. So, Iâm a hypocrite here. TourBus doesnât run. We dragged it kick and screaming to Ruby 2. But Migratrix wonât run on Ruby 1.8. It just wonât. So, this is hard.
JAMES:
I think the core team is usually fairly conservative in Ruby Land as far as support. Ruby 1.8 was only, 1.8.7 was only end-of-lifed was it last year or the year before?
CHUCK:
I think it was last year.
JAMES:
It hasnât been very long, yeah. And to me, that was really conservative. I was long past it then. And I felt like the gems had caught up. I donât know. Itâs an interesting problem. I do agree that Ruby tends to push forward and occasionally there will be a release that breaks a lot of things. I feel like theyâre slowing that some since the Ruby 1.9 transition which was brutal, in a word. I donât know. Itâs an interesting point. There are definitely languages that are more stable, move slower, stuff like that. But I think we should stress, there can be downsides to stuff like that. For example, when did Erlang get Unicode? [Chuckles]
DAVID:
Does it?
JAMES:
Wasnât that also fairly recently?
DAVID:
Does it have it? [Chuckles]
JAMES:
Iâm just saying. You can go too slow, right?
AVDI:
Yeah. Itâs also nice to have more explicit constructs in the language for saying I am going to use something from the future or I swear that I am totally compatible with the past.
JAMES:
Ooh, what languages do that?
AVDI:
Well, we talked a little about Python. Python has the import from future thing where you can import language features that are not, I guess, itâs been a while since Iâve done Python but basically import language features from the future that arenât part of this current release but theyâre in there experimentally.
CHUCK:
JavaScript does this as well.
AVDI:
And then you can see that in the file. An analyzer can see that in the file and say, âOh okay. This file probably isnât going to work on a version that doesnât even have that in its future libraries.â
DAVID:
Yeah.
CHUCK:
JavaScript solves it in a different way. They actually have transpilers. So, ECMAScript 6 for example is not in current browsers. But the Angular core team is writing Angular 2 in ECMAScript 6 and then transpiling it to ECMAScript 5.
AVDI:
Which is cool. And that kind of thing is incredibly difficult in Ruby.
CHUCK:
Yeah.
DAVID:
Yeah.
JAMES:
Yeah.
AVDI:
Which brings me to one of my complaints.
JAMES:
Bring it.
DAVID:
Wait. Before you do that Avdi, I wanted to give a specific shout-out. Miah Johnson, she is the reason that TourBus runs on Ruby 2. As much as I complain about gems that donât run on two versions, I didnât want to maintain my own gem. And she was the one who kept after me and pushed and helped. And we got it running over v2. So, thank you Miah.
JAMES:
It is super cool when people go and take old libraries and fix them.
DAVID:
Yes, yes.
JAMES:
So, thatâs awesome. Alright Avdi, you were going to tell us.
AVDI:
Or like when Erik Michaels-Ober took my Naught gem and said, âHey I want to use this in my gem.
But for that, I need it to be 1.8-compatible.â
JAMES:
Yeah.
AVDI:
And moved mountains, did things that amazed me, to make it. There were things in there I didnât think was possible to port, but he managed to make it happen.
JAMES:
Wow.
DAVID:
Yes.
AVDI:
And now it supports 1.8. So, yes Ruby is incredibly difficult to parse. The parser code is a nightmare for anybody, for implementers. And the reason itâs incredibly difficult to parse is because it tries to be super friendly to programmers who like writing really expressive code, which is nice. Itâs one of the reasons that I use it. But here is the thing. You have your static languages. You have your C++ and your Java. And you have your nicer static languages like Haskell, et cetera. And those, theyâre static so they get compiled. And compilers and other tools that are smart enough can learn a great deal about the code. They can make all kinds of interesting predictions about it. And they can be certain about things at certain points in the code just by analyzing it statically, because theyâre made to be analyzed statically, which means that you can build really cool refactoring tools for them. You can have tools that can very easily go through and do things like, âOh hey. You want to extract that method out? Well, Iâve found three different places that Iâve determined without a shadow of a doubt are exactly identical to that code. Would you like me to replace those with calls to your new method?â And you have a lot of neat stuff like that. You can do a lot of really advanced refactorings automatically. And an automatic refactoring is nice because it means you can think in terms of domain and semantics. You can say, âOh I want a new thing,â rather than, âI need to type, I need to make 15 different changes in order to have a new thing.â And then you have your dynamic languages. And one of the biggest influences on Ruby in this regard is both Smalltalk and Lisp. And they have none of these guarantees. Everythingâs only known at runtime. An object could have methods added to it at any time. So, you canât make any of these predictions. But they make up for that because in Smalltalk there is only runtime. There is no such thing as not runtime. So, it makes up for the fact that you canât make any static predictions about it by the fact that the system is always running.
DAVID:
[Chuckles]
AVDI:
You can always ask the system, what methods does this object respond to? You can do neat things Smalltalk like given this message send here, this abstract message send. I donât have a receiver, just the message send, what would respond to that in my entire system? And you can ask the system that because the system is running at all times. And Lisp systems, maybe not all of them, but some Lisp systems were very similar where you have a running image and you could ask the image things about its dynamic nature. And so, that took care of the things on the dynamic front. Ruby is in this gutter in between the two.
DAVID:
[Chuckles]
AVDI:
It is in the worst possible position between the two. It is impossible to statically analyze. Yes, people try but thereâs just a hard limit on what you can do with it. And itâs very hard.
JAMES:
Come on, Avdi. Thatâs what regex is for.
AVDI:
[Laughs] Most of itâs just heuristics. Itâs heuristics like in this case, âI think probably you have access to the following methods, but I can never actually be sure.â But at the same time, thereâs no image. Itâs very difficult to just have a running Ruby image and develop inside a running Ruby image where you can just ask the image, âOkay. Give me all the things that might respond to this message.â And you have things like itâs difficult to have an image that reloads things, because reloading things in Ruby is messy and often leaves stuff lying around. Or you have things like, âOh you canât reload that class because now it has a different superclass and thatâs just a no-no.â And so, reloading is a problem for images. A lot of things make it difficult or impossible to have just a long-running image that you develop in, in Ruby.
DAVID:
Yeah.
AVDI:
So, itâs just an awful position to be in. And Iâve done some, I did a Ruby Tapas episode recently where I was demonstrating how I sometimes flip over to RubyMine and the RubyMine team has gone to great lengths to try to do some nice automated refactorings for Ruby. Theyâre incredibly primitive compared to the ones that are available in Java. But theyâre there. And they even do a little bit of duplicate code detection and stuff like that. But itâs really barely there. You have to handhold it a lot of the time. It doesnât always get things right. And thereâs just no way out, the way things are set up right now. And if you want to see an example of how things are different, check out either of those two sides. Check out the amazing refactorings that are available in IDEs for Java. I think some similar things exist for some of the static functional languages. Or checkout the stuff that you can do in Smalltalk refactor-wise. So, thatâs my rant.
JAMES:
I have no response to that. [Laughter]
DAVID:
I love it. I love it. You were going down the Smalltalk thing and Iâm like, âOh dude. Ruby has ObjectSpace. We could walk all of the objects and we could say, do you respond to this? Oh except for we canât really query the arity of a method.â We canât know how many arguments itâs supposed to take. And then you really nailed it, which is ObjectSpace has no response for objects that are lazily loaded and the file hasnât been loaded into memory yet.
AVDI:
Yeah. Itâs really honestly been pushing me towards using other languages lately because Iâve, okay when Iâm gluing stuff together, when Iâm writing system automation scripts and stuff like that, Iâm gluing stuff together, a language like Ruby is fantastic. When I want to think in more domain terms, I want to think in more domain terms. I donât want to have to do all the work of refactoring, moving things around. A lot of design is moving things around. And I donât want to have to think about that.
I want to be able to work at a higher level.
JAMES:
One thing I was thinking about when I was listening to you talk is Light Table. Have you seen that? The editor thatâŠ
DAVID:
Oh, yes.
JAMES:
Yeah. That would be really hard to, I donât know if it has Ruby support yet. I havenât really looked at it. But if it does, Iâm sure it canât be as thorough as some of the things Iâve seen in it. And thatâs largely due to everything Avdi just said. So yeah, itâs an interesting point. Ruby almost forces you down to dealing with classes at the characters in a text file level.
DAVID:
Yeah.
AVDI:
Yeah.
JAMES:
So yeah. Oh, I think youâre dead on. [Chuckles] Alright.
CHUCK:
So, why else do we hate, hate, hate Ruby?
JAMES:
Thatâs right. While weâre getting it all out of our system I have a complaint. My complaint is the Ruby standard library, which I will go ahead and admit is one of my favorite and least favorite things of Ruby at the same time. The reason I say that is that I love having everything and the kitchen sink. I love being able to say I can count on something and know that I can require it and it will be there. And that lets me write Ruby programs that I just know will run and do these things and stuff like that. So, I love that aspect of it. And for the most part, the standard library includes a lot of the things I think are really, really critical with maybe a couple of exceptions like Nokogiri or something, though it does have REXML in defense. But that is the crux of it for me. The standard library I think, and this isnât really a fault of the core team or anything like that, itâs that once a library is pulled into the standard library, itâs slowed way down in its development cycle. Itâs expected that it will be very stable and not jump around a lot. And it will always be there and it will always be the same. And so, some of those libraries are great but we have much more modern versions that are leaps ahead. So, it would be great if we could rotate those in and rotate the old ones out, because obviously we donât want six xml parsers in there. Or if we could somehow keep progressing and building toward the future with the libraries that are in there. Sometimes, requiring REXML and using that on XML versus the current state of Nokogiri feels like a major step backwards. Or, WEBrick. WEBrick is awesome and cool and neat. But what about Rack? Rack is a similar. I realize theyâre not exactly the same thing, but how come WEBrick is in the standard library but Rackâs not? Is Rack still evolving too heavily so it canât be moved in? Or whatever. But I think my problem is that they get in there and they just stagnate. And then that makes it difficult to go forward. Thatâs my complaint.
AVDI:
So, whatâs a language that handles this better?
JAMES:
So, we were talking about this actually a little bit before the show. And I think the consensus was that Java is probably the gold standard here. It has a cultivation process where things start outside the language and get a certain level of fame and then they go through an improvement, a touch-up process. And then get imported into the language proper. So, I guess by the time they get there theyâre still pretty good. And then Iâm not super familiar. Itâs been so long since Iâve been in the Java world. Iâm not familiar with how well they do going forward from there. Maybe itâs just that they were so good by the time they get in that theyâre a lot better and itâs okay to make them the standard. And I think in Rubyâs defense, a lot of these things were probably imported at a younger time in Rubyâs life. So, we need an XML parser. Okay, REXMLâs the best we got. Letâs go with that, and great. And REXML doesnât require LibXML which Nokogiri does. So, they went forward with that because it was the best choice at the time. But itâs not the best choice at this time anymore. And I pretty much never see code parsing XML with REXML anymore. Am I alone in that?
CHUCK:
Iâm going to have to write some.
JAMES:
[Chuckles] Yeah. New goal.
DAVID:
My opinion on XML is that itâs a four letter word. The second jokeâŠ
JAMES:
No, itâs just three.
DAVID:
No, XMLâs a four letter word. The F is silent. [Laughter]
DAVID:
And the follow-on joke is the F stands for verbose. [Chuckles]
JAMES:
Yeah. No, thatâs cool. I love the standard library. I canât count the number of times Iâve required PStore or something and just blown somebodyâs mind and gotten ridiculous amounts of work done. I love things like that. But I do wish we could find a way to keep it moving forward and maybe find a good process for rotating things in, rotating things out, still developing in parallel. And I think this is on the core teamâs radar. Thereâs been talk of gemifying the entire standard library and then just having it be when Ruby installs, certain gems install. But then you could still easily upgrade to newer versions of that gem or whatever if you wanted to. So, it seems like that could maybe mitigate the problem a little bit of things stagnating in there and maybe free their development cycle from being tied to Rubyâs development cycle. But I donât know. To me itâs a great thing and a bad thing at the same time.
AVDI:
Yeah, agreed.
CHUCK:
So, Iâm going to throw one out there. And my experience with this has not been super recent except for some of my coaching clients. Sometimes we run into stuff. And that is Ruby on Windows. The Windows support I have to say has gotten a whole lot better than it used to be. I started programming in Ruby professionally in 2006. And yeah, it was kind of a pain on Windows. And by kind of a pain, it mostly worked but if you had to compile C extensions or anything like that, it just really didnât work. And today, itâs gotten a lot better. And so, you can use a lot of the gems that are out there with it. But for some of these you still donât have a great option for some of the things that they require. So for example, they have to rely on DLLs and stuff like that. And if itâs not there, then itâs not there. And thereâs not really anything you can do. But we do tend to keep up a little bit. Itâs just a little bit behind now. But I have to say, RailsInstaller and RubyInstaller have come a long way to making that possible.
JAMES:
I think one of the complaints I heard recently with Windows was that Win32 API was deprecated. Is that right? I think. Youâre not supposed to use it anymore. Youâre supposed to use Fiddle I think instead as an acceptable alternative. But I think thatâs significantly harder. And I may be wrong on all that. This is just what Iâve heard. But it does seem like the Windows solutions lag a little bit behind the Unix support.
CHUCK:
Yeah. I also remember going back and finding the mwin32 blah, blah, blah version of the gem.
AVDI:
Alright, now I often hear an objection whenever this comes up. âWell, why does it matter? Why do we need support on Windows?â
JAMES:
No, thatâs not a cool objection. [Laughter]
DAVID:
Itâs really not, because Windows still dominates the business marketplace. There is so much, when you start talking big data, youâre either talking Java or youâre talking .NET.
JAMES:
Schools use Windows.
DAVID:
Schools use Windows.
CHUCK:
Well, most of personal computing is still done on Windows as well, not just business.
DAVID:
Absolutely, absolutely. I spent a couple of years writing device drivers for Windows. So, guess what operating system I had to live on the entire time I was at work?
CHUCK:
[Inaudible]
JAMES:
Yeah. Plus, I just donât think, as those of us probably who listen to this podcast, thereâs probably a lot of that favor things like Linux and stuff like that. But surely, we havenât liked that attitude of, âOh we donât have to support Linux.â So, we donât ever want to be doing that to any other platform.
CHUCK:
Yeah.
AVDI:
For the record, I learned Ruby primarily on Windows because thatâs what I had available to me at the time.
JAMES:
How did you feel it was, pain-point-wise?
AVDI:
To be honest, with the stuff that I was doing back then it wasnât really that painful. I wasnât employing a lot of gems. I was actually using it for some Windows automation. Actually, one of the cool things about Ruby is that very early on it shipped with Win32OLE module which enabled you to do things like automate Excel from Ruby which was a lot of fun.
JAMES:
I believe thatâs the one they recently deprecated. I may be wrong on that.
AVDI:
If you prefer to do that over using Visual Basic for it, for the stuff that I was doing, and I was doing stuff with a lot of core Ruby and YAML and stuff like that and just not a lot of stuff from the ecosystem. So, it wasnât a huge problem. And I certainly wasnât serving web pages, doing a lot of concurrency with it. I think that if I had been doing less automation tasks and more application tasks, I probably would have been frustrated faster.
CHUCK:
Yeah. I have two things that I want to bring up with this as well. One thing is that most of the people that I see at the new Rubyist workshops, they show up with a Dell or an HP machine or something like that.
DAVID:
Yup, yup.
CHUCK:
And theyâre running Windows. And if you canât get them set up and you canât do it quickly and easily, we lose them right there, right at the doorstep.
DAVID:
Yeah.
CHUCK:
And itâs really kind of sad.
AVDI:
Some people at this point will say, âWell, get them to load up a Linux VM.â No. CHUCK: Yeah.
JAMES:
[Laughs]
DAVID:
Right, exactly.
AVDI:
Let me try and revise that. No.
CHUCK:
Well, thatâs hassle. And if you donât do that then you wind up using one of the bash emulators. And those arenât great too.
AVDI:
Because what youâre saying is number one youâre saying you have to bring in a Windows machine with sufficient horsepower to run a VM, which somebody might not have. And what youâre also saying it, âOh to learn this new programming language, you have to learn an entire new operating system.â
JAMES:
[Chuckles]
DAVID:
Yes.
CHUCK:
Yeah.
AVDI:
This argument [inaudible] me out a little bit.
JAMES:
Itâs so easy. [Chuckles]
DAVID:
That actually segs well into my next gripe. I canât write a program, compile it, and give it to my mom in Ruby. In theory, it can be done. RubyMotion, I can build an iOS app. But that really just lets me release to the entire world via the app store, not give a program to a friend without giving them a temporary beta license. Thereâs the LLVM. There are compilers. Thereâs the Releasy gem that weâve already talked about and weâve talked about it having problems. And ultimately if you are writing in Ruby, your consumers are either people who use websites or other Rubyists. Weâre not building solutions in Ruby for people outside of Ruby. That bugs me.
CHUCK:
Yeah. Mac ships with Ruby so technically you can hand something over to them and they can, if they figure out how to run it, then you can.
DAVID:
Technically, you can.
JAMES:
As long as you target the version thatâs on their Mac.
DAVID:
Exactly.
JAMES:
And that version changes every single release, so youâd probably be locking yourself to a certain Mac OS and higher.
DAVID:
Right.
CHUCK:
Case in point, I had a neighbor email me and he said, âDo you know a good program that will download the list of my Twitter followers into a text file?â And I emailed him back and I said, âNot off the top of my head, but I could probably write one in 20 minutes.â And then heâs like, âOh that would be cool.â And I emailed him back and I said, âWhat kind of machine do you have?â And he emailed me back and told me, âWindows.â And so Iâd have to have him install Ruby on his machine in order to make it run. And yeah, itâs hassle. Itâs hassle city to give somebody non-technical something like that to run.
JAMES:
And in that case, itâs actually a one-liner with the t gem.
CHUCK:
Yeah.
JAMES:
Which is yeah, itâs cool. We have all these tools. We want to give them to everybody but when, and this is true and I see this every time I teach somebody Ruby, they get to the point where theyâre like, âOh how do I write a program that I can run on my computer at work?â And Iâm like, âYeah, we donât really do that. We build a web app and we hit it through the browser.â [Chuckles]
CHUCK:
Yup.
JAMES:
Because thatâs our best choice.
DAVID:
Yeah.
CHUCK:
Well, and itâs a whole added level of complexity that you donât need for something like, âGive me a
list of my Twitter followers,â right?
DAVID:
Right, right. And again, there do exist tools. Why the lucky stiff wrote that weird wacky thing that was justâŠ
CHUCK:
Shoes?
DAVID:
Not Shoes. It was a different thing. But it would take, maybe it was shoes, but it would take an entire Ruby script and the entire Ruby interpreter and it would stick them into a, he just laid them down in a binary file. And on Linux he laid them down in the ELF format. And on Windows he laid down the data segment and the code segment in an EXE. And on Mac OS X he laid down the right segments of a DMG file. And when you ran the program, it ran Ruby that it had contained with itself and then it loaded out of the data segment your script. So, this stuff is there.
JAMES:
Thatâs kind of scary awesome. [Chuckles]
DAVID:
Itâs really scary. I cannot believe for a minute that that wouldnât trip most virus scanners today, especially if youâre trying to write data back to the file to store it. But also on Windows, we have the one-click installer which honestly I donât know where itâs at because I havenât touched Windows. I mean no disrespect to the guys that maintain it. The OCI fell out of favor for a while. It was unmaintained for a long time. And then it was maintained again. And OCI is great because it also includes Rails. So, you can give somebody a Ruby and a Rails and they can get up and they can get going.
CHUCK:
I tell people to use RailsInstaller now.
DAVID:
Oh, okay.
CHUCK:
And it works seamlessly. Even if they just need Ruby, because it puts Ruby on there and it works.
DAVID:
Right.
JAMES:
So, in a similar vein, letâs talk about GUI support.
CHUCK:
Eww. [Chuckles]
JAMES:
Ruby has shipped with a GUI toolkit for forever, Ruby Tk. And my hatâs off to the Ruby Tk maintainers because they have had to go above and beyond and then some to maintain things over the years because of things like mismatches between Ruby using its own threading system and Tk expecting real operating system threads and stuff.
DAVID:
Right.
JAMES:
So, I canât even imagine how theyâve done so well with that. But itâs generally not, when we talk GUI, Tk is nice but probably not our first thought when we think of making a good, fits in everywhere kind of GUI.
DAVID:
My programming background was years and years in Visual Basic and then Visual C++ in Windows. Then Visual C++ in Windows, so .NET and MFC and all that good stuff. And so, I naturally think, when I want to give somebody a utility to work on something, I naturally think in terms of a dialog application that opens up a dialog box, gives you some control, so you can click on them. And Ruby will let you do that by packing things using the Tk libraries. And there are people out there right now going, âWhat about FOX windows, what about wxWindows?â And my answer is [pbbbt].
CHUCK:
[Laughs]
DAVID:
They all stink. Theyâre all lousy.
JAMES:
The poor transcriptionist.
DAVID:
Yeah.
JAMES:
Thatâs all you got to feel sorry for.
DAVID:
Yup. Using wxWindows and using Tk from the programmerâs side of things, basically no different. Youâre still playing games with packing widgets from source code. So, you have to read basically a document and then compile it in your head to try and figure out what this dialog box is going to look like. We had a thread on Parley months ago where somebody said I wish we had the Visual Basic rad tool where you could just drag dialog boxes and drag buttons on and drag list controls and then double click on things to go right to a code editor and write the handler for on click and that sort of thing. And it was funny that one person actually responded and I believe it was out of just a vehement hatred of all things Microsoft, but they actually responded with, âI donât want this tool to ever exist in Ruby.â And I love you Parley members. I love all of you like my children, but whichever child you were that said that, youâre wrong. [Laughter]
JAMES:
And go to your room.
DAVID:
And go to your room. I still love you, but go to your room.
CHUCK:
Well, build it in a gem and if you donât want it, donât install it.
DAVID:
Yeah. And I donât know. I have thought long and hard about building a rad tool for Ruby that all it does is, because I can, in Developer Studio it spits out this, I canât remember what the name of the file is, but it spits out basically an XML document or a binary document that describes what the layout of the window is after youâre done drawing it. And I really just donât see any reason why we couldnât build a graphical environment, drag and drag stuff into Ruby, and have it spit out this data blob. And then have a Ruby gem that reads that data blob or loads it from file and throws it over to Tk or wxWindows or whatever. Actually, I see a whole bunch of reasons why we couldnât do it. One is integrating with Tk and wxWindows and FOX or whatever window library means you need different adapters. And the other one is, again I want to build cathedrals, not make bricks. And so, Iâm bemoaning the lack of bricks here. Iâm not complaining, this is one of those cases where donât complain, fix it. Well, I donât want to fix it because this would be an epic project, right?
JAMES:
Those rapid development tools, theyâre cool any time you see them. Iâve even seen one in Ruby. Ryan Davis had a thing, Iâm pretty sure it was zenspider, had a thing that using OmniGraffle Pro, he could use the UML stuff included with OmniGraffle Pro and UML design some classes. And then he integrated that. It had some API or something. And he integrated that where it would pop out the Ruby classes and the methods would already be in them and stuff that was said would be there. And it was neat. Not a, this is going to change how you program forever, but it was still very cool. And you see this in lots of places like Unity and stuff weâve talked about, have lots of tools, Unreal Engine, where some decisions in programming donât have to be thought out from, letâs start assigning some variables and write some code and blah, blah, blah. And you can start at higher levels, which is actually what Avdi was sort of talking about before, that in game stuff where you can connect certain environments just by manipulating these graphic nodes and then drop into the code when you want to change something. Or if you use something like Blender for 3D imaging or something, similar thing, graphic environment. You drag these nodules around and you create procedural textures for your 3D objects. Or we talked to Jacqui a while back at The New York Times and they have that Streamtools, which is designed for streaming information in to various systems. And they were literally using a visual drag and drop system for that, to set that up. Itâs amazing stuff.
DAVID:
Yeah.
JAMES:
Itâs like programming in the future.
DAVID:
Almost, except that it started in 1996 and weâve lost it. [Laughs]
JAMES:
[Laughs] So, now itâs like programming in the past.
DAVID:
Yeah.
AVDI:
I will say thereâs a good version of that and thereâs a bad version of that. And I think what some of the pain points, what some of the remembered pain might come from is the bad version of that, which manifested back in the day in tools that would write a whole lot of code for you.
JAMES:
Yes.
AVDI:
And it was usually one of two things. Either there were these huge sections of code that you werenât allowed to touch, hands off. If you touch things here things will break, and the tool would maintain that. Or, they would go a little further. They would try to do the round-tripping thing where you could modify the code and then it would be reflected back in the tool. And that was an interesting kettle of fish. And the flipside of this is tools that donât actually write code for you. So, my understanding is that most modern GUI frameworks have some sort of GUI definition language as far as I know, like Qt has a GUI builder which is really independent of any programming language. You build a UI in it and itâs basically building up some sort of, I donât know, XML representation or something along those lines, something standardized. And then the various language bindings to that GUI framework, they can all load up one of these definitions and that gives you at runtime, that gives you something that you could hook your events into regardless of what language youâre in. So, yeah I agree with people that have been burned by tools that tried to generate a lot of code. But there are other ways of handling it. And that might actually be an option in Ruby. I havenât really played with this. But I understand the Qt support is pretty decent these days. And building up a UI using their GUI builder and then hooking Ruby into it might be workable.
JAMES:
The prags had a short book on it one time, Qt. And I read it back then but it seems to have passed, I donât know, that phase. People didnât get into GUI development in Ruby for some reason Iâm not totally clear on.
DAVID:
Well, Ruby started out as a peer to Perl almost, even more than to Python. Ruby and Python came out at the same time as noble successors to Perl.
AVDI:
Right.
DAVID:
And Perl was this text graphic language that could do anything because everything was text. And so, Perl even had the Tk bindings to give you crappy looking windows from the get go. And so, Ruby has Ruby Tk to give you crappy looking windows right from the get go. And then Python got some cleaner windowing tools and Ruby got some cleaner windowing tools. Ruby seems to have not been as interested, I guess, as an ecosystem. We as developers just havenât been as concerned. Like with Python, very clear that game developers wanted to move forward. So, Pygame and those things are a lot more robust and a lot more stable and a lot more solid. And here Iâm using games as an extension of graphics and windowing support. But in Ruby, I think we, thereâs a few of us that really, really want it but everyone else is kind of happy either writing Rails apps or the occasional transformation script that just munges files on the disk system.
JAMES:
So, letâs talk about one more before we call it a day because itâs interesting. Dave, you had problems with concurrency, right?
CHUCK:
Heâs the only one.
DAVID:
Yeah, this is one that I mentioned in the preshow and you said you wanted to argue about it. Iâm excited about this one. So yeah, Iâm glad weâve saved this one for last because it is the sacred cow with Ruby, the biggest number one sacred cow. Standard MRI Ruby is slow, single-threaded, and uses a lot of memory. There, I said it. Itâs out on the table.
JAMES:
[Laughs]
DAVID:
We can get around all of these problems.
JAMES:
No! [Chuckles]
CHUCK:
Ruby canât scale.
DAVID:
Ruby canât scale. Itâs true. We can get around all of these problems. James, you gave a great talk at LoneStar years ago about Ruby is not slow. It can be as fast as you want and here is why, and you showed all of the things that we had available in Ruby. And single-threading, you can go to JRuby, you can go to EventMachine. Here is my beef with this. Going to something like JRuby or EventMachine, surmounting these problems requires introducing an inordinate amount of technical hassle, like deploying. We have an entire book by Joe Kutner called âDeploying JRubyâ because if you switch to JRuby now you have to know which version of Java to use, Java 6 or Java 7. You have to know. Java tools are going to creep in. now, youâre going to be making your project with Ant instead of Rake. Even knowing which version of the JDK or the JRE to install, do I install OpenJDK? Do I install the default Linux Java 7 JDK? Do I go to Oracleâs website and download their JDK installer or RPM, Debian file, whatever? These technical hassles. EventMachine is a great gem for Ruby that lets us write evented Ruby. But EventMachine also has a lot of problems of its own. And more importantly, writing evented Ruby looks wildly different than writing a regular Ruby script and just adding in concurrency where you need it. Itâs like you have to turn your whole program on its head. And I feel like Ruby, yeah, itâs slow, single-threaded, and uses a ton of resources. And surmounting these problems introduces a whole bunch of other problems that are annoying and a hassle.
CHUCK:
Can I pile on for a second? Because even if youâre writing evented codeâŠ
JAMES:
No, theyâre all against me.
DAVID:
[Laughs]
CHUCK:
Even if youâre writing evented code youâre still blocked by the GIL. The threads donât go to other processors, or the cores on your processor. So yeah, it will switch threads and work on something else but only if the other thread has given up the Global Interpreter Lock so that the other one can do its thing.
JAMES:
Avdi, you want to get in a few slaps? [Laughter]
AVDI:
I think they covered it pretty well. The concurrency story on Ruby sucks.
CHUCK:
We didnât talk about memory.
JAMES:
[Chuckles] Well, he said resources, uses an inordinate amount of resources.
CHUCK:
Yeah.
JAMES:
Alright. So, since I feel like Iâm the lone defender here, I will make my best attempt at defending some of these things. But yeah, I think itâs not like I can save it. Slow, I kind of disagree with in that I do believe in the past Ruby has been almost criminally slow. I really feel like theyâve made massive headway once YARV was integrated.
DAVID:
I have to give you that one because I got beat up regularly at my day job that Ruby was slower than PHP. And in 1.9.1 or 1.9.2, YARV is now faster than PHP. And all the PHP guys now no longer care about comparative benchmarks.
CHUCK:
[Laughs]
JAMES:
Yeah, I did feel Rubyâs speed in some areas. Dave mentioned that talk. I basically went through and showed a lot of cheats to get Ruby to go faster. And there are a lot of cheats. Iâll put the link to the slides into the show notes. Using things like NArrays so that you can manipulate a whole bunch of C integers in tandem and stuff, you can go crazy fast on things like graphic manipulation and stuff like that. So, there have been cheats to get around it in the past. I got to tell you, Iâm feeling that need a lot less these days now that Ruby 2âs really come of age. And I feel like itâs pretty smoking fast on a lot of things. There have been the occasional stumbling blocks like how Ruby gems would basically file stack everything when it was trying to require stuff. And that was a big slowdown. There have definitely been bumps in the road. But as far as, the way Iâm seeing speed improve, all I can say is thumbs up core team, looks awesome. Looks great to me.
AVDI:
Thatâs definitely true. But you canât get around the fact that if you want to do something thatâs mathheavy, in other words just engages the processor a lot in Ruby, even though it uses native threads nowadays, MRI still is not going to parallelize that math-heavy processing because anything thatâs actually in native Ruby itself is going to take the GIL.
JAMES:
So, yes. That is basically Daveâs second point, single-threaded. So, letâs talk about that one because I think itâs the biggie.
CHUCK:
Can I say something on speed really quickly?
JAMES:
Yeah, sure.
CHUCK:
Because speed is two concerns for me. One is does it tell me the answer fast enough? And I think thatâs what weâre talking about here where the NArrays or these other tricks, or not having to use them anymore, yeah it tells me the answer fast enough. But the other thing that comes up is that itâs also in some ways a measure of how much work it had to do to get the answer. And so, there are other systems out there that could take advantage of, C is an example of this, where itâs just really wicked fast. And it doesnât take as much processing to get the answer because itâs a little bit lower level language. And so, thereâs that as well where when you scale it up, you have to scale it up to handle a little bit more work.
JAMES:
Yeah, I think thatâs true. To some extent, thatâs impossible to mitigate. Calling a Ruby method will always be more expensive than calling a C function because thereâs so much context involved and stuff like that.
DAVID:
Yeah.
CHUCK:
Yeah. But for the most part, you could scale it. Itâs not terribly painful to do it. But at the same time, I just wanted to point that out, that there are processes out there that are a little bit more efficient than Ruby is.
DAVID:
Yeah. Well, and to be fair, if youâre worrying about speed in an interpreted, byte compiled, garbage collected language, you are already in a state of sin. [Laughter]
AVDI:
Eh, I donât know. There have been so much⊠first of all, itâs not, okay itâs either interpreted or itâs byte compiled but not really both.
DAVID:
Right, right.
AVDI:
And thereâs been so much work to speed up byte compiled code these days. Youâve got V8. The Smalltalk people put loads and loads of effort into making that very, very fast. And a lot of that got rolled into Java. A lot of that research got rolled into Java, which is, okay granted itâs a static language. But itâs pretty freaking fast these days.
JAMES:
Iâm surprised at all this because right now it seems like weâre complaining about garbage collectors and stuff. Am I the only one that realized Ruby just got generational garbage collecting?
AVDI:
Woo!
JAMES:
Weâre catching up. [Laughter]
CHUCK:
Yay.
JAMES:
Weâre getting faster. We have a real garbage collector. We have bitmap generational garbage collecting. So, itâs friendly with copy-on-write. I feel like theyâre making massive strides in these areas recently.
DAVID:
Yeah.
CHUCK:
Oh, totally props to the team.
DAVID:
Absolutely.
AVDI:
I think thereâs an elephant in the room though, with this concurrency stuff.
JAMES:
Okay. Whatâs that?
AVDI:
Which is that because Ruby has not had a concurrency focus for basically its entire life, nobody has been thinking about writing thread-safe or otherwise concurrency-safe code in the gem ecosystem.
DAVID:
Right.
AVDI:
And that to me is one of the biggest elephants in the room, is that there is a ton of code in the Ruby ecosystem that is not thread-safe. I donât know. It might not even be EventMachine safe.
JAMES:
Yeah, so letâs talk about that a sec, because actually some of what Chuck said about EventMachine is confusing, I think. Letâs address that. So, in something like Node where the entire thing is evented, period, from the bottom up, everything people write is evented-friendly. And in Ruby, thatâs not the case. We have lots of gems, like Avdi said, that do things that just canât be used in that kind of environment. So, you can totally use EventMachine on a single thread. Thatâs actually the point. And to do that, you need to make sure that any libraries you use are event type approach. So, you switch which database driver youâre using and stuff like that so that you get something thatâs evented layer, meaning that theyâll take their little slices of time as they come available and return in a reasonable amount of time and not do something that just brings everything to a screeching halt.
DAVID:
Right.
JAMES:
So, I believe EventMachine can be used in situations like that. But as Avdi said, youâre going to have to be careful which things you have to grab and stuff like that. Itâs a good point, that we havenât been aware of the threading thing in the past so we havenât done a good job prepping for that. So, getting back to the single-threaded thing which seems to be our primary complaint. MRI is no longer single-threaded but because it evokes a GIL to make C extensions work smoothly, and again that had to be done because otherwise they would have broken almost every single C extension out there because we havenât prepared like Avdi said, itâs effectively still single-threaded because you can only be in one at the same time. That said, I see people get this wrong all the time about Ruby and it makes me mad. [Chuckles]
JAMES:
So, Iâm going to go up on my soapbox here.
DAVID:
James smash!
JAMES:
Yeah, smash. So, Iâve seen people say forever that that means you canât do two things in Ruby at once. And oh, that just makes me so mad. So, first of all, at least back when I started Ruby, in Ruby 1.8.2-ish or something like that, from that time forward, Ruby has always been super smart about switching thread context or releasing the GIL when you do something thatâs going to pause. So, make a slow system call, I/O is the biggest one, you have always been able to in a loop make a bunch of Ruby threads, even when they were green threads, have all of them fetch some webpage, and that would work in parallel, all the way back to Ruby 1.8.2. And the reason is that most of that time was spent waiting on [inaudible] from the other side. And when Ruby sees a thread is about to go into waiting mode, it would suspend it, put it to sleep, jump context to the other thread. So, they would all do that. If you did it in a loop and you fetch ten websites, you would have some big amount of time if you did it in a loop and put them all on threads, even back on Ruby 1.8.2. You would have noticed a huge drop in time.
DAVID:
Yes.
JAMES:
That has worked as long as Iâve been in Ruby. So, Avdi has the right example. Anything thatâs processor-intensive is where youâre going to get into trouble because you canât pause the thread and then [inaudible] on the CPU. Well, you can but then work wonât be done. Ruby has another solution for that, and thatâs fork. Thatâs been, in my opinion, the core teamâs idea of how we should go forward. Obviously, there are plusses and minuses about that. But youâve been able to fork another process. Two processes will be scheduled by the operating system, not by the Ruby interpreter. Therefore at that point you can easily chew on multiple CPUs or whatever, cores even. So, I would say thatâs the Ruby answer. Itâs definitely not a perfect answer. And I think this was primarily Daveâs complaint of one, we start forking processes, you have to worry about a lot of things like how are they going to communicate to each other? How are they going to pass data back and forth? What are you going to do to reap the zombie processes so that they donât build up? All of these things.
DAVID:
Or the fact that each process is 64 megabytes in size.
JAMES:
Only if youâre forking Rails. Thatâs notâŠ
DAVID:
Oh, fair point, fair point.
JAMES:
But yeah, I agree.
CHUCK:
Fork Rails.
AVDI:
Itâs still a huge amount of resources compared to shared resource threads.
DAVID:
Right.
JAMES:
Compared just with threads, sure.
AVDI:
And hereâs the thing about that. Itâs not just strictly a resource consideration. You have to structure your entire architecture around that decision. You have to figure out, hopefully fairly early on, where is a good place to chop, to divide the system into separate processes? And you have to make it high enough level that you donât later find yourself wishing that you could start up 10,000 of these fork processes. And I compare this in my mind to something like the Erlang process model where an application is basically built of many, many Erlang processes. And theyâre scheduled independently, and theyâre very, very, very lightweight. And you donât have to think about, oh, does it makes sense to fork this off as a process or should I try to combine it into another process because we donât want to have too many processes? And of course, Erlang takes it to the next level where you can even decide, should this be even part of the same system basically, or do we want to push it out off somewhere else? But the process model forces you to make really, really big architectural decisions. And that also comes out in Ruby doesnât have a really great way of communicating between processes either, at least not baked in, not like this is the accepted way.
DAVID:
Right.
AVDI:
and so, you also have to spend a lot of time thinking about, okay now that Iâve decided Iâve got a good seam where Iâm going to split it into a few different processes, now how do I make them talk? Again, in a language like Erlang, all of thatâs already wired up for you. Youâre just sending message around always.
JAMES:
Yeah, thatâs a good point. I think when I finally got into Linux and learning how the process model works there, I really internalized a lot of that and went down a lot of those rabbit holes. To me, itâs totally natural to pull a pipe, do a fork, close one end on both sides and communicate across that. I do recognize it takes a little code and then you have to decide what protocol youâre talking over that socket or pipe or whatever youâre using. So, to me thatâs always felt not too unnatural, kind of the Unix-y way. But I recognize that youâre right and things like Erlang where they just have operators for sending messages to other processes and stuff. Iâm not sure I totally agree with, even with a language that does it better, even JRuby which gets rid of the GIL, then you have to think about different things in my opinion that potentially two threads could be in this code at the same time. Is that okay? And I feel like that makes me make different structural changes and decisions. So, I donât know. I think planning for concurrency to me always seems like planning for concurrency. Then itâs something you have to do and think about the problems that are going to be involved and itâs complicated. I will give you that I agree that Erlang is probably the lightest, itâs so ready for you, weâre trying to make this as painless as humanly possible thing.
DAVID:
Yeah.
JAMES:
There are other problems to fork by the way. I didnât cover them all, Windows being one of them. I
donât believe fork is implemented in Ruby on Windows.
AVDI:
Nope.
JAMES:
Which is probably one of the reasons that people arenât super big on it. But man, itâs amazing [inaudible].
DAVID:
Well, thatâs not Rubyâs fault though, right? The Win32 or, okay that shows my age doesnât it, but the Windows operating system doesnât have a fork, does it?
JAMES:
Not in the Unix sense of the word. You can obviously start up other processes and you can emulate some behaviors. So, hats off to the Perl team on this one. Perl fork works on Windows and it does it through emulation using Pthreads and them arranging for the two processes [inaudible]. Itâs the most epic hack I think Iâve ever seen. And Iâm sure it was hard. But it does, it is possible to build things like that, I think, on Windows. But Ruby doesnât go that far. But I would say that traditionally processes have been the Ruby way to achieve real concurrency. And itâs not without its faults. Iâm not saying that it is. But you can make some stuff go really fast. Resources is maybe the last point Dave had that we should touch on a little. Iâm not sure how much of that to actually pin on Ruby. Ruby I guess uses a fair bit of resources. I think a Ruby process is fairly small if you just fire it up and chunk it out. I seem to remember, 2 meg sticks in my head. Maybe itâs 4, which I guess is big-ish but not gargantuan. Rails is different. If you fire up Rails and then you check in the process table, itâs much, much bigger. But theyâve made lots of progress there. I know in the hash, they made it ordered in Ruby 1.9 I think. And so, that required hash to get bigger. But they made so many memory improvements in the move to the new architecture that hash was awash or got smaller. So, it didnât really hurt it. So, I think theyâve done, again made some pretty amazing improvements there. And I think it has a lot to do with how you use it. I think people tend to think Ruby leaks memory and things like that, which I think Ruby Under the Microscope, RUM again covered so well, just showing how the way we use it and passing blocks around can caused this context to be saved on the heap, that it looks like it sticks around for a long time and thatâs what makes you think things like that, I think.
DAVID:
With every language, there are things that you can learn and go, okay Iâm going to close the door on this and never think about it again. And then there are other things that you have to, itâs the minefield. You have to learn, oh I have to remember I canât take a hash in from the Rails controller that is the URL parameters that came from user land, I canât call symbolized keys on that because users can put in any keys they want on that string and Iâve just created a symbol that wonât ever go away. Although I hear a rumor now that symbols can be garbage collected.
JAMES:
No, they canât.
DAVID:
They canât? Oh.
JAMES:
Itâs been talked about but they donât.
DAVID:
Was that an April Foolâs Day hoax, then?
JAMES:
[Laughs] Itâs been talked about, making them garbage collectable. But there are lots of⊠the VM uses symbols internally for its symbol table. So, there are issues with that. Iâm pretty sure theyâre still not garbage collected. That said, I would encourage us in this discussion to separate Ruby and Rails as much as possible.
DAVID:
Yeah.
JAMES:
Rails does a lot of things. You just mentioned having a hash that doesnât know the difference between symbols and keys. While that may seem really cool from a programming standpoint, it has performance implications that I donât think were properly considered. Rails is just heavyweight with all it includes. And if you have your Rails process and you at some point do a moderately big query forcing a lot of objects into Rubyâs memory, thatâs going to balloon up your process and then itâs never going to go back down. So, thatâs I think where people come from when they see these leaks and ballooning processes and stuff like that.
DAVID:
Yup.
JAMES:
And Ruby has given us some tools to combat things like that, even recently with the lazy operators and stuff that let us chew over data in a lazy fashion and things like that. So, I donât know. I feel like massive thread inroads have been made here. The threading is definitely an issue and still is. But processes can be an answer sometimes.
DAVID:
Yeah. I guess weâre nearing the point to wrap up. And I want to take all of the kvetching that Iâve done in this episode and turn it into the biggest compliment that I can give Ruby, which is I see all the warts in Ruby and I see all the things that weâve complained about, and Ruby is still hands down orders of magnitude my favorite language over every other language. No other language makes me happy when I program in it.
JAMES:
I am just thrilled nobody brought up m17. I thought for sure Iâd have to defend that with my dying breath. [Chuckles]
AVDI:
Well said, Dave.
CHUCK:
Yup.
JAMES:
Yeah, I think itâs cool. Theyâve done lots of awesome things. Theyâve made lots of progress. And these things that weâre complaining about are largely first world problems, right?
DAVID:
Yeah.
CHUCK:
Yeah.
DAVID:
Yeah, they totally are.
CHUCK:
Yeah, so the moral of the story is go use Python, Java, Node, Erlang.
JAMES:
Erlang. Yup, thatâs it. Weâre switching.
DAVID:
And then come back. Yeah, weâre switching to everything else.
CHUCK:
Yeah. [Laughter]
AVDI:
Smalltalk.
CHUCK:
Smalltalk.
DAVID:
Smalltalk.
AVDI:
Haskell.
CHUCK:
Yeah. Mash them all up and you get everything that you ever wanted and everything you didnât want.
JAMES:
From here on we will be the non-Ruby Rogues.
CHUCK:
There you go.
DAVID:
Yup, the Everything-But-Ruby Rogues. [Chuckles]
CHUCK:
The Polyglot, something else.
JAMES:
Polyglot Rogues.
DAVID:
Well, Polyglot minus one.
CHUCK:
Yeah.
DAVID:
[Laughs]
JAMES:
But I tell you what, if Avdi does one episode on Smalltalk, thatâs it. Iâm going.
AVDI:
[Laughs]
CHUCK:
Do Elixir instead.
JAMES:
Yeah. Thatâs close, right?
AVDI:
Have that one already.
JAMES:
You did?
CHUCK:
Alright, cool. Well, should we do the picks?
JAMES:
Letâs do it.
CHUCK:
Alright, David Iâm going to make you start.
DAVID:
Okay, alright. So, last week we talked video games with Megan and I apologize that I havenât had any really seriously in-depth picks. And I have no intention of changing that today. So, last week we talked about games. I want to start by picking Meganâs game, Glass Bottom Games, Jones On Fire. This is a silly, stupid, itâs Canabalt with a firefighter where you rescue kitties. Itâs just a run and jump game. Thatâs all it is. And she talks in the last episode, she talks about Juice It or Lose It. And just the little twitches that they add to the game make this game. You can play it, how to say this delicately, you can play it in the room that people prefer that I not talk about me using my phone while Iâm in that room. [Laughter]
DAVID:
It echoes in there. People hate it when I call. But in the time it takes you to use that room, the library if you will, you can play a game of Jones On Fire. And itâs fun. And you rescue some kitties and itâs just fun. It is incredibly simple. Youâll look at it and youâll go, âI canât believe this game is going to suck me in.â But it absolutely is. Itâs absolutely worth the 99 cents it is. Thereâs a light version that you can play for free. Donât even waste your time. Just give Megan the dollar and get the full game. Youâll get your moneyâs worth out of it. The second game had me crying laughing. I installed it last night. Itâs called Inflation RPG. Have you ever played an RPG where you grind? Where you just try to get more, one more hit-point, try to get one more level, just 50,000 more experience points until I get one more point of charisma or whatever. Inflation RPG is a little mobile game that lampoons grinding. So, you start off and you walk around in this field. And the first thing you fight is a chicken. And you gain so much experience after killing the chicken that you are now 22nd level. [Laughter]
DAVID:
And so, you have to immediately leave the home area because now thereâs nothing worth fighting. Youâve just added, your attack score has gone from 100 to 300 after one battle. So, you move to the next area and you fight something. And my first game of Inflation RPG, I ended. Youâre limited to 25 battles. And I ended the game with, I was 749th level. And then itâs over at that point. And itâs just hilarious.
JAMES:
Thatâs awesome.
DAVID:
To just see, they use the JRPG style, Japanese Anime style. When you win a battle you just see this level up, level up, level up, level up, level up, over your character. Iâve gained 70 levels in one battle at one point. Itâs just absolutely insane. Itâs hilarious. Itâs fun. Itâs well-made. And itâs silly and stupid. You can put it down and walk away from it. There is a little bit of longevity to it which is that you can buy equipment. And anything you purchase you get to keep forever so that your next character starts with things that boost attributes and that sort of thing. So, you can go even further in your next game. And so, thatâs Inflation RPG. I know itâs out on Android. I donât know what other platforms itâs on. I know Jones on Fire is on, in Meganâs own word, on every mobile device ever. Inflation RPG, Iâm not sure on. But I recommend them both. They are lots of fun. And thatâs my picks.
CHUCK:
Avdi, what are your picks?
AVDI:
Iâm just going to pick a bunch of blog posts and talks that Iâve liked recently. So, letâs see, doing down the list. Oh, thereâs a talk called âOOP: Youâre Doing It Completely Wrongâ about how youâre doing object-oriented programming wrong by Kevin Berridge. I enjoyed that one a lot. There is, oh speaking of Smalltalk Noel Rappin did a talk at MountainWest RubyConf about why you should really check out Smalltalk. And he uses the Pharo Smalltalk in some live demonstrations. And incidentally, Pharo Smalltalk just dropped their 3.0 release. So, that was a really enjoyable talk. And it gives you a nice quick glimpse into what youâre missing out on when you donât write code within an image. And letâs see. Thereâs an article that I got a huge kick out of recently called âProgramming Sucksâ. And thatâs exactly what itâs about. And itâs just one of the better rants that Iâve read recently. So, I think Iâll just leave it at that, some talks and articles.
CHUCK:
Awesome. James, what are your picks?
JAMES:
Iâve got two. For a programming related one, I didnât know that there were other ways to monitor a file other than tail -f, but it turns out there is. You can use less +F. And the advantage of doing this is it does the tail thing. And then when you want to stop it to look at whatâs going by and examine that, you can. You can hit Ctrl+C.
AVDI:
Cool.
JAMES:
And it takes you into the normal less interface. So then, you can move around or search using that. Itâs pretty cool. So, itâs like tail but you can pause it and go into a less environment and poke around and then restart it if you need to. Itâs pretty cool. And then, I just saw this for fun tweeted the other day, 33 Amazingly Useful Websites. And I was surprised by how many of them I wasnât familiar with. And there are all kinds of things in here. Sites that will tell you what to eat or what to watch or how everybodyâs flipping their name upside down on Twitter, this site will do that for you. You can type in some text and it will give you the characters flipped upside down. Just lots of random things like that. I think one of my favorites is âCan I Stream It?â was on there, which you can go in and, oh I want to watch movie X, Y, Z and you just type it in there. And itâs like, oh you can stream it from Netflix or Amazon or Hulu or whatever. It tells you where you can go find it on the internet. Lots of cool sites in there and then some that are just silly, [inaudible] fun, but cool stuff. Thatâs it.
CHUCK:
Awesome. Iâve only got one pick today. It is âSmart Money, Smart Kidsâ by Dave Ramsey and Rachel Cruze. And itâs a terrific book about teaching your kids how to handle money. And you can start them at age three and it gives you guidelines all the way up. So, just a terrific book, really enjoying it. So, thatâs my pick. We are coming up on our episode with Rebecca Wirfs-Brock. Weâre going to be talking about âObject Designâ. And so, if you havenât had a chance to pick up the book, go get it. And weâll catch you all next week.
[This episode is sponsored by Codeship. Codeship is a hosted continuous deployment service that just works. Set up continuous integration in a few steps and automatically deploy when all your tests have passed. Codeship has great support for a lot of languages and test frameworks. It integrates with GitHub and Bitbucket and lets you deploy cloud services like Heroku, AWS, Nodejitsu, Google App Engine, or your own servers. Start with their free plan. Setup only takes three minutes. Codeship, continuous deployment made simple.]
[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]
[Bandwidth for this segment is provided by CacheFly, the worldâs fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.]
[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]

155 RR Why Ruby Sucks
0:00
Playback Speed: