Asp Forum - Re: If you are unhappy with the direction of Ruby 1.8.7+, respond

Yukihiro Matsumoto

2/13/2009 8:10:00 AM

Hi,

In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, respond"
on Fri, 13 Feb 2009 16:41:25 +0900, Michal Suchanek <hramrach@centrum.cz> writes:

|I'm sorry if I personally added to this kind of view. Unlike earlier
|releases I had some minor problem with code not running after upgrade
|to 1.8.7, and it seemed many other people have similar experience.
|While acceptable for your own code it is not good for code you
|distribute to somebody else.
|
I expect you to be more concrete and specific about minor problems.
As far as I know:

* Rails had problem from method name conflict. This was
unfortunate, caused by Rails' fragile monkey patching and our bad
for lack of thorough Rails test before 1.8.7. It is fixed now.

* erb also had a bug in 1.8.7 initial release. It is fixed now.

* two other problems are reported (SWIG and hash order), and as far
as I understand, they both contain bugs that haven't disclosed for
1.8.6 by accident.

I consider them minor and not being worse than previous releases.
Most of them are addressed already. Am I missing something?

|Back then nobody stepped up and said that if code working on 1.8.6
|broke it is a bug so I just left it at that - the compatibility seemed
|to be not so great.

If compatibility of 1.8.7 is really "not so great":

* if it is fixable, we can fix.

* if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
as we did in the past.

* if upgrading is not affordable for enterprisey people (yes, I
understand them; upgrading is costly even when incompatibility is
minor), they can keep using 1.8.6, which is maintained right now.
As EngineYard raised their hands, the maintenance of 1.8.6 will be
kept, even after 1.8.8.

If more evidence of great incompatibility is not shown, I will
consider it FUD, or FUD-like at most, even though I see no bad
intention from anyone.

matz.

5 Answers

Michal Suchanek

2/13/2009 8:50:00 AM

On 13/02/2009, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
> Hi,
>
> In message "Re: If you are unhappy with the direction of Ruby 1.8.7+, respond"
>
> on Fri, 13 Feb 2009 16:41:25 +0900, Michal Suchanek <hramrach@centrum.cz> writes:
>
> |I'm sorry if I personally added to this kind of view. Unlike earlier
> |releases I had some minor problem with code not running after upgrade
> |to 1.8.7, and it seemed many other people have similar experience.
> |While acceptable for your own code it is not good for code you
> |distribute to somebody else.
> |
>
> I expect you to be more concrete and specific about minor problems.

Yes, I would like to be more concrete. Unfortunately, it's some time
since 1.8.7 was released and I do not have any of the code at hand.

> As far as I know:
>
> * Rails had problem from method name conflict. This was
> unfortunate, caused by Rails' fragile monkey patching and our bad
> for lack of thorough Rails test before 1.8.7. It is fixed now.

This was well understood from the start, and easy enough to fix.

Again, if the many methods added were optional such situations could be avoided.

>
> * erb also had a bug in 1.8.7 initial release. It is fixed now.
>
> * two other problems are reported (SWIG and hash order), and as far
> as I understand, they both contain bugs that haven't disclosed for
> 1.8.6 by accident.

The SWIG problem was until recently described as something like "many
C extensions fail". I personally don't care as I don't use them but I
would not upgrade to 1.8.7 a package in a system distriution be cause
of this.

It's obviously a change of expectations on which many C extensions
rely. While this might be a step towards making the GC "more correct"
the old behaviour was "safe enough" and the fix is not localized into
replacing a single bit - many C extensions will have to change so this
might not be considered minor.

>
> I consider them minor and not being worse than previous releases.
> Most of them are addressed already. Am I missing something?
>
>
> |Back then nobody stepped up and said that if code working on 1.8.6
> |broke it is a bug so I just left it at that - the compatibility seemed
> |to be not so great.
>
>
> If compatibility of 1.8.7 is really "not so great":
>
> * if it is fixable, we can fix.

I guess saying this is exactly what the 1.8.7 release was missing at the start.

There were people saying it breaks things, and no obvious progress
towards fixing the issues. When I got 1.8.7 in an overall system
upgrade I also had to modify code which I believed to work on 1.8.6.

>
> * if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
> as we did in the past.
>
> * if upgrading is not affordable for enterprisey people (yes, I
> understand them; upgrading is costly even when incompatibility is
> minor), they can keep using 1.8.6, which is maintained right now.
> As EngineYard raised their hands, the maintenance of 1.8.6 will be
> kept, even after 1.8.8.
>
> If more evidence of great incompatibility is not shown, I will
> consider it FUD, or FUD-like at most, even though I see no bad
> intention from anyone.
>

Yes, the attitude towards 1.8.7 evolved in an unfortunate way.

And I think some of the uncertainty resulted from lack of
communication on part of the core team.

Thanks

Michal

Rick DeNatale

2/13/2009 4:11:00 PM

[Note: parts of this message were removed to make it a legal post.]

Hi Matz, I'm glad to see that you've entered this fray.

I trust that you know me well enough to know, that while I have strong
opinions, I have no ill-will, particularly to you or your language.

On Fri, Feb 13, 2009 at 3:10 AM, Yukihiro Matsumoto <matz@ruby-lang.org>wrote:

> Hi,
>
>
> * Rails had problem from method name conflict. This was
> unfortunate, caused by Rails' fragile monkey patching and our bad
> for lack of thorough Rails test before 1.8.7. It is fixed now.
>
> * erb also had a bug in 1.8.7 initial release. It is fixed now.
>
> * two other problems are reported (SWIG and hash order), and as far
> as I understand, they both contain bugs that haven't disclosed for
> 1.8.6 by accident.
>
> I consider them minor and not being worse than previous releases.
> Most of them are addressed already. Am I missing something?

First, the next comment is directed to a subset of the Ruby community,
which doesn't include you Matz,

I know that Rails isn't liked by everyone in the Ruby community, but for
better or worse, it's an important factor to the health of a significant
portion of 'our' community. Those who don't use Rails or other large Ruby
frameworks over time haven't experienced how we got to the point where these
problems have been addressed.

At this point, it's a little hard to recover the history, but, although
Rails 2.2 is now compatible with Ruby 1.8.7 it has taken work, and new
releases, from both the Ruby team and the Rails team.

Rails users faced with upgrades, need to deal with the evolution of both
Ruby and Rails. To a large extent Rails over the last year to 18 months has
been even more volatile than Ruby. Porting a Rails app from Rails 1.2.x to
Rails 2.0 (There was no Rails 1.3) was, as the change in major version
number indicates a fairly significant jump. And Rails made changes in Rails
2.2 which, for applications doing certain complex things with ActiveRecord,
VERY difficult to port. That's not Ruby's fault, it's just a fact of life.

So there are quite a few Rails Apps, which need to stay on a version of
Rails which is compatible with Ruby 1.8.6, but won't work with Ruby 1.8.7.

|Back then nobody stepped up and said that if code working on 1.8.6
> |broke it is a bug so I just left it at that - the compatibility seemed
> |to be not so great.
>

Of course, none of us is perfect, particularly without the benefit of
hindsight.

As a practitioner and advocate of agile techniques, I like to have a
comprehensive test suite to expose compatibility issues when changes are
made.

Unfortunately in the case of a language like Ruby, it's impossible to have
such a test suite, It would need to draw from a significant portion of the
applications implemented in Ruby, and applications implemented on frameworks
like Rails which are implemented on Ruby, etc. etc. Not really practical.

If compatibility of 1.8.7 is really "not so great":
>
> * if it is fixable, we can fix.
>
> * if it is minor, we can upgrade 1.8.7 (or later) whenever we want,
> as we did in the past.
>
> * if upgrading is not affordable for enterprisey people (yes, I
> understand them; upgrading is costly even when incompatibility is
> minor),

I'm not sure who you are calling enterprisey people here. I know that you
have no intent to disparage, but that term does carry a certain meaning of
"the other guys" with some of the Rubyists, (and others) I run into.

To me "enterprisey" means someone working in a large corporate enterprise,
who is following strategies, architectures and standards, promulgated by
enterprise vendors, like Microsoft, and IBM (to the extent IBM still has the
influence to do this), probably because of edicts handed down from on high
from the executives who play golf with sales reps from those vendors.

I'm pretty sure that such "enterprisey" types make up a very small subset of
the Ruby/Rails community. We don't have many sales reps who play golf with
corporate executives.

The vast majority of those using Rails are fairly small companies trying to
leverage the almost unique advantages of Ruby and Rails to be able to
quickly deploy into production, and incrementally improve core business
applications. And the vast majority of Rails developers are either working
for those small companies, or for a small Rails consultancy, or as
independent freelance contractors.

> they can keep using 1.8.6, which is maintained right now.
>
>
Very true, I've got no argument with that, but it's important to understand
that those who are using packaged distributions of Ruby from debian
(including Ubuntu), RedHat, macports etc. have more trouble keeping 1.8.6
because normal system administration has a nasty tendency to replace 1.8.6
with 1.8.x where x > 6 because they don't differentiate versions with
differences in teeny version numbers as backwards incompatible. While 1.8.7
is backwards compatible with 1.8.6 in theory. Whether or not it really is,
depends on whether or not all of the ancillary ruby code on the particular
system, like Rails, Gems, and local applications have been kept, or brought
up to date.

Savvy developers get around this by eschewing packaged versions and
installing the components of the Rails stack, including Ruby, from source.
But there are a lot of developers who trust the package maintainers, and run
into these issues, and end up blaming Ruby. We could say "well that's their
problem," if we don't care about the impact on the overall perception of
Ruby. Perhaps that's the right attitude, but I'm not so sure.

Would it have been better for those with these problems had Ruby 1.8.7 not
included the changes from 1.9 which broke apps and frameworks? I think that
the answer is clearly yes.

But, for better or worse, it did, and we have to live with the consequences,
that doesn't mean we need to be happy about it.

As EngineYard raised their hands, the maintenance of 1.8.6 will be
> kept, even after 1.8.8.

If more evidence of great incompatibility is not shown, I will
> consider it FUD, or FUD-like at most, even though I see no bad
> intention from anyone.
>

I hope that this doesn't come across as FUD, or even FUD-like, I'm just
trying to put a bit more context on why compatibility isn't a black or white
thing, and the sources of real FUD.

The real FUD doesn't come from discussions like this, it comes from those
who either have run into these problems and blame Ruby. We have no control
over what they say, we can only try to consider the effects of decisions on
the broader community, within the bounds of our human lack of complete
knowledge.

--
Rick DeNatale

Blog: http://talklikeaduck.denh...
Twitter: http://twitter.com/Ri...

znmeb

2/13/2009 5:19:00 PM

On Fri, Feb 13, 2009 at 8:11 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:
> I'm not sure who you are calling enterprisey people here. I know that you
> have no intent to disparage, but that term does carry a certain meaning of
> "the other guys" with some of the Rubyists, (and others) I run into.
>
> To me "enterprisey" means someone working in a large corporate enterprise,
> who is following strategies, architectures and standards, promulgated by
> enterprise vendors, like Microsoft, and IBM (to the extent IBM still has the
> influence to do this), probably because of edicts handed down from on high
> from the executives who play golf with sales reps from those vendors.
>
> I'm pretty sure that such "enterprisey" types make up a very small subset of
> the Ruby/Rails community. We don't have many sales reps who play golf with
> corporate executives.

I saw a (fairly boring) panel discussion on "The Future of Enterprise
Software" by some of these "enterprisey" folks last night, including
the President of Oracle, who gave the keynote address. Yes, there is a
*big* difference between the 5-million ton gorilla Oracle (did you
know there are five million Oracle developers, all connected by Oracle
software?) and a typical Rails development team.

> Very true, I've got no argument with that, but it's important to understand
> that those who are using packaged distributions of Ruby from debian
> (including Ubuntu), RedHat, macports etc. have more trouble keeping 1.8.6
> because normal system administration has a nasty tendency to replace 1.8.6
> with 1.8.x where x > 6 because they don't differentiate versions with
> differences in teeny version numbers as backwards incompatible. While 1.8.7
> is backwards compatible with 1.8.6 in theory. Whether or not it really is,
> depends on whether or not all of the ancillary ruby code on the particular
> system, like Rails, Gems, and local applications have been kept, or brought
> up to date.

It's not just the users ... the *packagers* need to be in the loop
too. There are two main package formats -- Debian/Ubuntu and RPM (Red
Hat / SuSE / Mandriva). And there are three major "community" Linux
distros as well as a few "Corporate" Linux entities. Sure, there are
differences in the details of how a Linux distro is packaged and
administered, but the tasks, issues and use cases are the same: first
of all it has to *work*, security holes need to be fixed ASAP,
preferably *before* exploits appear in the wild, and capacity planning
tools need to exist so that a supplier can be sure his service level
agreements are being met. The distinction here is not one of scale --
Oracle vs. a "typical Rails app". The distinction is between a
production, deployed IT environment and a chaotic, risky experimental
venture.

I think we have to start thinking in terms of weeding out some of the
chaos. For example, I would expect openSUSE, Fedora and Ubuntu to be
all shipping a Ruby with *identical* syntax and semantics. I would
expect them all to be shipping a Rails with *identical* behavior. I
would expect to be able to walk up to a Ubuntu, openSUSE or Fedora
server console and type a *distro* install command to bring in any
Gem, *not* "sudo gem install <gem-name>" because *some* gems are in
the package repository but others aren't. In short, I would expect
that there would be *one* Ruby and *one* Rails, differing only in
whether I said "sudo apt-get install rails", "sudo zypper install
rails", or "sudo yum install rails". It should *just work*.

This requires communication. This requires "marketing". This requires
the kind of discussion we are having in this thread within the Ruby
community, but it also requires communication between the Ruby / Rails
communities and the distros. I haven't done much in terms of syncing
up with the openSUSE community on Ruby, but I did get a sense of the
frustration with Ruby in the Gentoo community when I was a Gentoo
user.
--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

Trans

2/13/2009 7:42:00 PM

On Feb 13, 11:11=A0am, Rick DeNatale <rick.denat...@gmail.com> wrote:
> Hi Matz, I'm glad to see that you've entered this fray.
>
> I trust that you know me well enough to know, that while I have strong
> opinions, I have no ill-will, particularly to you or your language.
>
> On Fri, Feb 13, 2009 at 3:10 AM, Yukihiro Matsumoto <m...@ruby-lang.org>w=
rote:
>
> > Hi,
>
> > =A0* Rails had problem from method name conflict. =A0This was
> > =A0 =A0unfortunate, caused by Rails' fragile monkey patching and our ba=
d
> > =A0 =A0for lack of thorough Rails test before 1.8.7. =A0It is fixed now=

Robert Dober

2/13/2009 9:07:00 PM

On Fri, Feb 13, 2009 at 8:41 PM, Trans <transfire@gmail.com> wrote:

> I think 1.8.7 was a mistake. It has taken us too long to get to 1.9
> and now we are being forced to deal with a unwanted stop-gap measure,
> holding it all up yet again.

It indeed was, though technically fine! It seems that it killed its sibling. :(
R.

--
It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be ... ~ Isaac Asimov

comp.lang.ruby