On Tue, November 20, 2012 10:28, m.roth@5-cent.us wrote:

Here, they use Ruby, the enterprise version - is that what you mean by RBENV or RVM? The next release of ruby? from RH? will be the 1.93 or some such, and include all the stuff in the enterprise version.

RNENV and RVM are Ruby language installers that create a custom programming environment by user. REE is simply a modified Ruby VM based on 1.8.7 which was produced by the same people who provide the Passenger gem. Support of REE is / will be discontinued as MRI (Matz Ruby Interpreter) version 1.9.3 addresses most of the issues with v 1.8 that REE attempted to correct.

Development tools on a production box are a very, VERY bad idea. I assume you can build the ruby app on your development box, and then move it as a package to test, then prod.

I am not sure that I can agree with this. All of our application servers are sealed. There are no local users other than administrators and application pseudo-users so the presence or absence of development tools is mostly moot. Anyone who penetrates a sealed server already knows enough that the absence of development tools is a negligible inconvenience. On the other hand, many RubyGems must be custom built on their target hosts. This is particularly true for DB adapters. To keep these gems up-to-date requires build tools.

I suppose that I could direct that all build tools be removed after a gem update and reinstalled as required but the illusionary security benefit is simply not worth the very real labour cost.

I've also seen an article or two about ruby not scaling up well. From my experience here, the apps seem to be *very* fragile, and

First, there are a lot of fragile COBOL applications that have been running in large corporations for decades. I know, I worked on some of them. On one system, run by a now defunct telecommunications giant, the corporate accounting staff had to calculate foreign currency adjustments off line and explicitly ADD the resulting figures to the production cost system as component items. This was necessary because the existing system did not handle foreign currencies and NO ONE was going to take the responsibility for breaking the entire cost accounting application just to add that feature. Just consider how fragile that is.

The reason that there are a lot of fragile Ruby (and a plethora of any other languages that you care to name) Apps is mostly due to the sudden popularity of the language generated by the creation of a 'cool' new framework (in this case Ruby on Rails). The result is attraction of swarms of people from other languages who throw up (in both senses of the term) hastily built, generally untested, toy applications that simply are not designed to handle growth; or simply not designed at all. That is likely the case with most of these supposed 'fragile' apps. Apps which no-one seems able to name however.

If one comes to Ruby from Python or PHP or MVB or dot.net or Java or C++ or C and just starts coding then one likely will end up with a Python, PHP, VB, dot.net, Java, C++ or C application. It will be written in Ruby but it will not be a Ruby app. The problem is succinctly put by the observation that one can write Fortran in any language. Of course, if you come from Smalltalk, then the case is somewhat altered. But, I digress.

it reminds me of python 10-12 years ago, where updating it one or two subreleases broke everything that had been working, including system tools.

I cannot speak to what happened with Python a dozen years ago but it seems to me irrelevant to what is happening with Ruby today.

ObStmt: No, I don't like ruby.

I would never have guessed.