5 ms·

I'm a longtime Ruby user (among a number of other languages). I feel very productive in Ruby right now, with Python being a close second. It's also vital to the

by jxf 12y ago

I'm a longtime Ruby user (among a number of other languages). I feel very productive in Ruby right now, with Python being a close second. It's also vital to the functioning of my current startup (along with Go). And yet -- I feel like Ruby is growing stagnant. Don't get me wrong: 2.x has brought lots of performance improvements, and some very smart people are constantly making it better, for which I'm eternally grateful. But I can't name a single 2.0-specific feature that I actually use. Refinements were the biggest thing I can think of, and in an informal survey of some other CTOs I know on Ruby stacks, nobody was directly using them. Additionally, for a lot of the features I've come to love in other languages (e.g. pattern matching), my impression is that no one's talking about them in the Ruby community. Much of Ruby's success came from making it one of the most enjoyable languages to develop in, and that's unquestionably still there. But I stare wistfully across the sea to some of alternative choices, and I wonder how much longer that will be true.

scoot 12y ago
It isn't so much that it's stagnated, but that it's so nice to start with that improvements are either going to be incremental in nature, or under-the-covers such as GC changes. What I long for from other languages (looking at you Python) is the vast array of library bindings.
- JonnieCache 12y ago
  >What I long for from other languages (looking at you Python) is the vast array of library bindings. I always seem to find what I need in this respect. What sort of stuff can you not find bindings for?
tcopeland 12y ago
I agree, although I do feel like runtime performance was the big problem with Ruby a few years ago. So fixing that was pretty huge.
- tburns 12y ago
  Fancy running into you here!
  - tcopeland 12y ago
    Small Ruby world!
gkop 12y ago
Ruby 2.0 introduced named parameters with default values and 2.1 introduced required named parameters. These are useful. For example, there are cases where you can replace options hashes with named parameters and get rid of guard clauses for key presence as well as lines that assign default values to keys in the options hash. And you don't have to index an options hash of course. The splat operator can be used to pass upstream options hashes to downstream methods taking named parameters so you can just refactor the downstream-most methods taking the options hash and get all these benefits.
- jxf 12y ago
  This is true, and is a good counterexample to my point since I do use these on an everyday basis.
cronin101 12y ago
If you have any idea how much of a clusterfuck parsing Ruby is, you might understand why special-sauce like pattern-matching is going to take a while... https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/ruby/ruby/blob/trunk/parse.y
rubiquity 12y ago
Languages don't need more features as they grow older. While Ruby isn't perfect, it does have the right "core" set of features in my opinion. What we're seeing happening to Ruby right now is fantastic. The language is getting some speed and memory enhancements. The next big face lift I expect to see Ruby get will involve better abstractions for concurrency in MRI.
- riffraff 12y ago
  > Languages don't need more features as they grow older I am not sure that is true. Many of the "old" languages that are still successful seem to have changed over time, while most of those that have stayed mostly unchanged seem to have lost mindshare (even if they had most things to begin with). It is probably a marketing problem.
  - rubiquity 12y ago
    One of the features of Ruby is simplicity. In that case, more features will usually mean less simple. The feature of Java and C++ is features, so the way for them to stay relevant is more features.
    - riffraff 12y ago
      I have used ruby for a long time so 99% of it makes sense to me, but it definitely is _not_ simple. Still, some increase in complexity may be acceptable: we have limited destructuring and case equality, pattern matching would be just a bit better. We have `Struct` which creates classes with positional arguments, but not a version that takes required parame even if it's a natural extension. We might have better composability for mixins etc.. And we can keep removing things (some more perlisms, for one).
      - rubiquity 12y ago
        I agree about removing Perlisms. I love pattern matching and don't think it would be more complex. I just don't think adding pattern matching would be easy or performant given Ruby's syntax.
petercooper 12y ago
I think the main reason for refinements not catching on is because of how poorly they were rolled out. I believe they were explicitly described as not for production use in 2.0 and how they worked changed in 2.1 (but I think they are now considered stable). The level of trust in the feature hasn't been high but may grow in time and especially once 2.1+ becomes the norm (after Rails 5 is released, I think).
djur 12y ago
As a longtime user of Ruby, improving performance is by far the primary thing I want out of the MRI team. Erlang-style pattern matching would be nice but I can't say I'm hurting for its absence. One of the topics that's been discussed for a long time is breaking the standard library into gems (installed by default), so they can be developed and improved separately from the core language. That's probably the #2 priority for me. One of Ruby's strengths (and sometimes one of its weaknesses, too) is that it has a fairly decentralized ecosystem. The standard library is small and has had few additions since Rubygems was added to the core distribution. Frankly, it could stand to have more taken out of it. Ruby is already a pretty big language (in terms of core features and syntactic complexity); I think the core team is well-advised to exercise caution in adding new features.
- riffraff 12y ago
  > Erlang-style pattern matching would be nice but I can't say I'm hurting for its absence. My memory is hazy, but doesn't Erlang have unification rather than pattern matching? If so that seems quite harder to get than "plain" pattern matching (i.e. copying the Scala model with user defined extractors) EDIT: it seems it's plain pattern matching.
dragonwriter 12y ago
> And yet -- I feel like Ruby is growing stagnant. I don't think that's really true. Its true that the releases since 1.9 (which, despite the wonky versioning, was in a sense the last thing that was really a major version bump for Ruby, similar to Python 3.0 -- and dealing, in a different way, with many of the same issues, particularly string encoding) have been less "big feature" releases, there've been significant but less-disruptive new features (both structural language features like named parameters and core / standard library enhancements) since then.

by jxf 12y ago

scoot 12y ago

It isn't so much that it's stagnated, but that it's so nice to start with that improvements are either going to be incremental in nature, or under-the-covers such as GC changes. What I long for from other languages (looking at you Python) is the vast array of library bindings.

JonnieCache 12y ago
>What I long for from other languages (looking at you Python) is the vast array of library bindings. I always seem to find what I need in this respect. What sort of stuff can you not find bindings for?

tcopeland 12y ago

I agree, although I do feel like runtime performance was the big problem with Ruby a few years ago. So fixing that was pretty huge.

tburns 12y ago
Fancy running into you here!
- tcopeland 12y ago
  Small Ruby world!

gkop 12y ago

Ruby 2.0 introduced named parameters with default values and 2.1 introduced required named parameters. These are useful. For example, there are cases where you can replace options hashes with named parameters and get rid of guard clauses for key presence as well as lines that assign default values to keys in the options hash. And you don't have to index an options hash of course. The splat operator can be used to pass upstream options hashes to downstream methods taking named parameters so you can just refactor the downstream-most methods taking the options hash and get all these benefits.

jxf 12y ago
This is true, and is a good counterexample to my point since I do use these on an everyday basis.

cronin101 12y ago

If you have any idea how much of a clusterfuck parsing Ruby is, you might understand why special-sauce like pattern-matching is going to take a while... https://github.com/ruby/ruby/blob/trunk/parse.y https://github.com/ruby/ruby/blob/trunk/parse.y

rubiquity 12y ago

Languages don't need more features as they grow older. While Ruby isn't perfect, it does have the right "core" set of features in my opinion. What we're seeing happening to Ruby right now is fantastic. The language is getting some speed and memory enhancements. The next big face lift I expect to see Ruby get will involve better abstractions for concurrency in MRI.

riffraff 12y ago
> Languages don't need more features as they grow older I am not sure that is true. Many of the "old" languages that are still successful seem to have changed over time, while most of those that have stayed mostly unchanged seem to have lost mindshare (even if they had most things to begin with). It is probably a marketing problem.
- rubiquity 12y ago
  One of the features of Ruby is simplicity. In that case, more features will usually mean less simple. The feature of Java and C++ is features, so the way for them to stay relevant is more features.
  - riffraff 12y ago
    I have used ruby for a long time so 99% of it makes sense to me, but it definitely is _not_ simple. Still, some increase in complexity may be acceptable: we have limited destructuring and case equality, pattern matching would be just a bit better. We have `Struct` which creates classes with positional arguments, but not a version that takes required parame even if it's a natural extension. We might have better composability for mixins etc.. And we can keep removing things (some more perlisms, for one).
    - rubiquity 12y ago
      I agree about removing Perlisms. I love pattern matching and don't think it would be more complex. I just don't think adding pattern matching would be easy or performant given Ruby's syntax.

petercooper 12y ago

I think the main reason for refinements not catching on is because of how poorly they were rolled out. I believe they were explicitly described as not for production use in 2.0 and how they worked changed in 2.1 (but I think they are now considered stable). The level of trust in the feature hasn't been high but may grow in time and especially once 2.1+ becomes the norm (after Rails 5 is released, I think).

djur 12y ago

As a longtime user of Ruby, improving performance is by far the primary thing I want out of the MRI team. Erlang-style pattern matching would be nice but I can't say I'm hurting for its absence. One of the topics that's been discussed for a long time is breaking the standard library into gems (installed by default), so they can be developed and improved separately from the core language. That's probably the #2 priority for me. One of Ruby's strengths (and sometimes one of its weaknesses, too) is that it has a fairly decentralized ecosystem. The standard library is small and has had few additions since Rubygems was added to the core distribution. Frankly, it could stand to have more taken out of it. Ruby is already a pretty big language (in terms of core features and syntactic complexity); I think the core team is well-advised to exercise caution in adding new features.

riffraff 12y ago
> Erlang-style pattern matching would be nice but I can't say I'm hurting for its absence. My memory is hazy, but doesn't Erlang have unification rather than pattern matching? If so that seems quite harder to get than "plain" pattern matching (i.e. copying the Scala model with user defined extractors) EDIT: it seems it's plain pattern matching.

dragonwriter 12y ago

> And yet -- I feel like Ruby is growing stagnant. I don't think that's really true. Its true that the releases since 1.9 (which, despite the wonky versioning, was in a sense the last thing that was really a major version bump for Ruby, similar to Python 3.0 -- and dealing, in a different way, with many of the same issues, particularly string encoding) have been less "big feature" releases, there've been significant but less-disruptive new features (both structural language features like named parameters and core / standard library enhancements) since then.