

The New Ruby Ecosystem - Jim_Neath
http://ducktypo.blogspot.com/2010/06/new-ruby-ecosystem.html

======
jamesbritt
"So, where did the once-vocal Ruby community go?"

Well, it turns out there are many Ruby communities, some vocal, some not.
Talking abut _the_ Ruby community is going to end up missing a lot of what is
going on.

Mostly, though when people talk about a singular Ruby community they mean
Rails.

"In a world where a standard can take years to be discussed, approved,
implemented and supported, Ruby standards such as Rack skip from conception to
widespread support at blazing speed."

Wish the same could be said for Ruby itself. Everyone who's completely moved
to 1.9, raise your hand.

Overall the points made are interesting, but much the same is happening in
other language communities. People building stuff in Haskell, Clojure,
JavaScript, Scala, etc. are more than happy to steal the best ideas from other
realms and make them their own.

So long as people don't start believing in The One True Framework or The One
True Languge, we're doing quit well.

~~~
manveru
Seems like there are now around 1/4 on 1.9:
<http://survey.hamptoncatlin.com/survey/stats> I expect that to increase a lot
once 1.9.2 is out and Rubinius, MacRuby, and JRuby match the spec. And I raise
my hand, I'm happily on 1.9 for over a year now.

~~~
jamesbritt
"Rubinius, MacRuby, and JRuby match the spec."

What specs do they all match right now? The implementation teams are doing
stunning work, but last I heard they were not all completely compatible and
complete.

"And I raise my hand, I'm happily on 1.9 for over a year now."

Sure, but you're part of one those quiet Ruby communities that gets ignored by
surveys such as Hampton's.

~~~
WALoeIII
Rubinius, MacRuby and JRuby are all 1.8 implementations now with 1.9 still on
the roadmap.

------
mark_l_watson
Paolo sounds a bit like a fanboy but he makes a lot of interesting points. I
work in a Clojure+Java shop yet I use Ruby whenever I can get away with it
because it is the fastest language (for me) for getting stuff done. The
article talks about Ruby's ecosystem, and that is key to Ruby productivity.
That said, I think that Clojure will be super-awesome in a few years as its
ecosystem continues to develop.

------
adbge
I do my dev on an archlinux box and the standard Ruby version in the repo
(1.9.1_p378-2, I think) was doing something screwy to Jekyll.

After reading this article, I checked out RVM and installed a couple different
Ruby versions to play with. If you're doing anything with Ruby, I'd definitely
suggest checking it out. Set up a 1.8.7-head install inside of RVM and fixed
all my Jekyll woes. It also gave me a chance to play with Rubinius and the
latest 1.9.3dev release.

I always enjoyed being able to use eselect to switch between Ruby versions on
Gentoo and RVM is able to duplicate this functionality and then some.

~~~
telemachos
To the best of my recollection, Jekyll itself plays nicely with 1.9.1. It's
Liquid that was a problem for me. The Gemcutter.org version of Liquid (2.0) is
not 1.9 safe. However, the version at Github (2.1) _is_.

<http://github.com/tobi/liquid>

Since the commit to fix Liquid for 1.9.1 was in April of 2009, I wonder why
it's not the version on Gemcutter? (Or some version of that version, if there
are other issues...)

 _Edit_ : Yup, just checked. Jekyll with Liquid 2.1 is fine on 1.9.1. (I'm on
OSX here, but the 1.9.1 I checked is also patch level 378.)

All of that said, rvm is outstanding.

------
donw
I will be happier when more Ruby coders take the time to actually document
their code; rolling through the Rails source has been an exercise in pain,
even with all the cleanups that have gone into Rails 3.

I recall an unhappy core contributor awhile back ranting about how people file
bug reports but not fixes; the reason is because it takes a significant time
investment to find and fix problems if you _aren't_ a core contributor and
have no interest in becoming one.

Sinatra and Sequel do it right -- solid documentation, both on the website,
and in the .rb files.

------
papertiger
I find the frequent major changes in the Ruby ecosystem to be quite
frustrating. That's not to say that I wish this progress wouldn't occur... I
just wish it would occur in a more controlled manner. Documentation seems to
suffer the most and I have definitely come across a few libraries that don't
"just work". I love Ruby and the Ruby community, but I long for the day when
things move at a less frenzied pace... I know it would put my managers at
ease, too.

------
angelbob
Much as I love Ruby and all the things he talks about, I worry that
publicizing all these self-congratulatory posts about the Ruby community will
create a lot more resistance to what we do. I get the impression that that's
how SmallTalk died.

~~~
aaronblohowiak
It is my impression that corporate drama around the smalltalk vendors helped
to quicken its demise. Image-based development (in the smalltalk, not
"rockstar" sense of image) also didn't sit well with a lot of people, though
there were projects to support exporting source to files.

~~~
stcredzero
_It is my impression that corporate drama around the smalltalk vendors helped
to quicken its demise._

Absolutely true! The merger-politics, the marketing missteps, and the cool
technology that got buried are all epic.

 _Image-based development also didn't sit well with a lot of people_

Not so true, for those who really "got it" and hit their stride, and anyone
who comments who didn't get to that point is commenting as a clueless newbie.
In image-based development, all of your programming meta-data are there as
live Objects, instantly scriptable, totally and instantly obedient to your
every whim. Ditto for runtime state -- everything available as live Objects
and instantly scriptable. Really, once you learn a suitable style, it's
heavenly, intoxicating and addictive. The same thing is true for Python and
Ruby, but only about half as much. For example, a lot of advanced IDE
functions require one to detect changes to files and _re-parse_ things to keep
programming metadata current. That problem just _vanishes_ with image-based
development. Literally hundreds of problems just vanish because everything is
an object and they're all instantly available.

On the other hand, image-based _deployment_ SUCKS. Sucks sucks sucks. Just
about every Smalltalker agrees. The big advantage of being file based is that
your development test environment resembles your deployment, or is at least
halfway to deployment by comparison. Image-based Smalltalk development is like
the ultimate monkey-patching uber-debugger. Very cool to develop in, but _you
do not want to give it to your users_!

~~~
cageface
Isn't it possible in image-based environments to have live objects but not the
code that created them? This idea makes me extremely uneasy. Being able to
derive everything in a running system from source code seems almost necessary
for maintainability and comprehensibility.

~~~
stcredzero
You have that in the Smalltalk environment in the Changes Log. It is -- wait
for it -- a text file! In fact, it gives you database-log like replay-ability
in your entire development environment. "Being able to derive everything in a
running system from source code," is exactly what it's for, and it's actually
more capable and powerful than what you can get from source files. All of that
scripting against the objects I was talking about? You can replay all that
stuff too! If you do something stupid-dangerous like, "Semaphore allInstances
do: [ :each | each release ]" then you can just exclude that last action when
you replay the Change Log. Combined with image save, it gives you the freedom
to live as dangerously as you like!

The classic demo -- have your students spend 1/2 hour writing some toy system.
Then have them _hard-reboot their machines without saving the image_. Show
them how they can restart the image, grab the Change List tool, and voila, all
their source code is back!

To answer your question: it's possible that the source can be absent, but you
have to execute an explicit command or do some sort of willful sabotage to
make it happen that way. Really, it isn't so different from having separate
source and executable files.

~~~
cageface
So why does image-based development suck for deployment? If you can regen an
environment from a simple text file what's the issue?

~~~
stcredzero
Because the environment that thing is designed to regen is the _development
environment_. That's not the environment you want to give to your users. This
isn't so big a deal with things like web application servers, but it is very
much a big deal with desktop applications.

It used to be, the way you deploy environments involved stripping out the
parts you didn't need for your application. This is doable, but it is a pain,
and if you do it wrong, your app blows up sometime when you don't expect.
ObjectStudio Smalltalk can bootstrap itself from source files, so you can
avoid stripping. VisualWorks tries to build itself up from components
(Parcels) on a base image as a deployment strategy. These are less painful
than stripping, but your app still blows up if you do them wrong.

Combine that with some vendors not being all that concerned about testing
deployment, and you have a potential mess.

Image-based deployment done right - have two images. Your devlopment tools go
in the second image. To deploy, you simply leave out the 2nd one.

------
cageface
Agreed. I was a little worried about the state of ruby a few years ago when
MRI was flaky and Rails deployment was a real hassle but now it's just such a
productive and pleasant environment to work in. There's still work to do, of
course, but I still reach for Ruby when I need to get something done quickly.

