Hacker News new | past | comments | ask | show | jobs | submit login

Well no, all I'm saying is that they indeed were breaking changes, but not "obscure design decisions".

All of them were made for a reason and the reasons were public. Some of them had easy workarounds (like a commandline switch) Most of them happened at the transition of a major release and made the introduction of major features possible. Ruby 1.8.6/7 was supported for years after the transition for people that had code that's hard to change or adapt. Hey, one of the examples the OP posted is "we had code relying on an obvious parser bug, and it breaks since they fixed it." So well, call it "dismiss" if you want. I call it "evolving a language"

I've been working with ruby at the point when 1.8 moved to 1.9 and it was quite a change. Pretty much every library that handled strings broke, but I don't see any way around that and still get encoding support. Many people actually forget that ruby 1.9 is actually what should have become 2.0.

I've been affected and patched several libs to work properly with 1.9.[1] There's absolutely no reason to become snarky.

[1] most of the changes required were trivial, still it's breaking and annoying.




Fair enough, I apologize for the snark, but then everything you've said hinges on your interpretation of the word "obscure".


Looking at the sibling comment, I'll happily take back the word "obscure" if it sounds too negative and subjective. But I stand by my opinion that Ruby is unstable because most of the above changes could have been handled in a backwards compatible way (for non-pathological cases). That should-be 2.0 was turned into 1.9 does not help :)

Not that stability is always the right choice, I wish C++0x would have been more radical, for example. It does matter for long-lived codebases though.


Well, 1.9 was the "unstable" branch leading up to 2.0, that's why that actually matters. And that's why most of those changes were made at that point - they were intended to land in 2.0. Later the decision was made to roll 1.9 as a stable release since 2.0 would take another couple of years and encoding support was an important feature that people wanted to ship. So a lot of changes that could not be handled in a BW-Compatible way landed in 1.9 since encoding support required those changes. String all of sudden was not enumerable any more since there was now String#each_byte and String#each_char which did something different. Require was changed because loadable encodings were an attack vector, ... But for people that needed the old behavior 1.8 was supported until lately and REE (1.8 patched) is still supported.

The breakage in 1.8.6/1.8.7 was widely regarded as a massive failure on the maintainer side - a bugfix for a security vulnerability that had other changes land in the release (and subsequently segfaulted, sigh). That's however not a design change. Something like that has never happened ever since.

I actually agree with you up to a certain point: The ruby ecosystem is was and still is pretty unstable. Things have settled a little lately, but gems still appear and disappear, are superseeded by newer versions or other gems that do things differently. That's good in some ways, since stuff evolves and improves, bad in other ways - the lib you depend on just disappears or falls out of maintenance. However, none of this is the core-languages fault. Behavior of ruby as a language has been pretty stable during the last couple of years.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: