5 ms·

Rubyspec is dead, long live Rubyspec

51 points by nateberkopec 12y ago

matzsayzno 12y ago
Matz doesn't do threading, so we don't do threading. Matz doesn't do performance, so we don't do performance. Matz doesn't do rubyspec, so we don't do rubyspec.
grandalf 12y ago
As cool as Ruby is as a language, the politics are very strange. As Javascript VM performance starts to become orders of magnitude faster than any Ruby VM, there is less and less reason to invest time writing code in Ruby, particularly with superb syntax options like coffee and cljs, and better and better systems level alternatives (Rust, Swift, Go, etc... ) Ruby/Sinatra used to be my favorite combo, but since Rails started going off in a weird direction (anti-js, asset pipeline, choosing AR over DM, insecure defaults pre rails 4) there has been less good stuff written in Ruby to draw from to augment Sinatra... Rails has become a rapidly changing but rarely improving API. That Ruby 2.2 breaks Rails 3.2 is just one more reason to look elsewhere. I question why anyone would start a new project using Ruby at all. This is not a troll, I really don't think there are significant benefits anymore.
- thothamon 12y ago
  Of course it's very much a subject for debate, but I personally don't know a web development platform that is as fast to get off the ground and as complete as Rails. Some people are certainly trying, but I don't think anyone beats Rails in these two areas yet. You specifically mentioned starting a new project. I think that's where Ruby and Rails are the strongest. Maintaining a large system might be better done using some other language and framework.
  - grandalf 12y ago
    I personally don't know a web development platform that is as fast to get off the ground and as complete as Rails I think this is an aesthetic preference. I personally think that the simplest and cleanest design is a combination of something like Sinatra/Express to implement a simple API and React on the client to do component-ized UI. Much of the "completeness" of rails is simply not needed when client side components can keep a bit of state around for housekeeping and make the occasional API call when data actually needs to move between client and server.
    - bonif 12y ago
      Not every new project is a SPA. It's completely possible to start a new project in 2015, which basically is a WEB SITE (with mobile views and everything, but basically a poor old website), in this case Rails is still the best option.
      - grandalf 12y ago
        You mean with server rendered HTML? IMHO the component abstraction provided by something like react leads to much cleaner separation of concerns, better boundaries between parts of the system, and easier to change/understand code.
- nateberkopec 12y ago
  You make it sound like speed is the only purpose of a programming language. If that was true. we'd all be writing C. Ruby optimizes for programmer happiness - that was Matz's explicit goal when writing the language. If that doesn't matter to you as much as speed on microbenchmarks, or if writing Ruby doesn't make you happy (it makes me happy!) then Ruby isn't for you.
  - grandalf 12y ago
    I really like Ruby syntax, but lately others are catching up. Swift and Coffee are both (IMHO) strongly Ruby inspired and in some ways better. Consider how many heroku dynos are dedicated to running slow, non-concurrent Ruby web processes, and how many Kilowatt Hours are burned waiting for Rails to apps to start. These are just not problems people need to deal with anymore. So while I am a big fan of Ruby (I still think it's the closest to my brain's own pseudocode of any language I've used) the ecosystem is lagging significantly these days, not because it's not improving, but because js is improving at a must faster clip.
    - robertjpayne 12y ago
      I think there's a huge misconception that to scale your programming language must be concurrent and also extremely fast. I can't see how you can assert that the JS ecosystem is "better". It is rapidly changing which is partially detrimental. What worked or was considered a good choice at the start of 2014 is now mostly obsolete or abandoned by the end of 2014. As so many companies have shown it really does not matter what programming language you use as there are plenty of options to make it work, it's more about choosing the language that will provide the best fit for your business.
      - grandalf 12y ago
        > It is rapidly changing which is partially detrimental. What worked or was considered a good choice at the start of 2014 is now mostly obsolete or abandoned by the end of 2014. This is happening to supposedly mature, nearly decade-old Rails!
- ilikepi 12y ago
  > I question why anyone would start a new project using Ruby at all. This is not a troll, I really don't think there are significant benefits anymore. One might start a new project with Ruby if it were one's primary language, and there was a desire to build something without the overhead of working in another language in which one is less proficient. How about this analogy: there are many different ways to cook a meal, but often my goal is to prepare food easily and quickly so I can eat and move on. Thus, I usually stick to the relatively few methods with which I am comfortable. Sometimes I do experiment with the goal of learning something new. But in those cases, the primary goal is expanding my skills, not building the "product" as it were. edit: clarification
  - grandalf 12y ago
    Quite true, but over time that erodes as a good reason. For people for whom the learning curve of a new framework/language is minimal there are fewer reasons to use anything in the Ruby ecosystem these days (I think).
- ciconia 12y ago
  > ...there is less and less reason to invest time writing code in Ruby... It seems to me that Ruby is doing just fine - the community is thriving, MRI is advancing quite rapidly. In reality people find Ruby to be a good solution. > I question why anyone would start a new project using Ruby at all. Actually there's a whole Ruby world out there besides Rails, even for web apps/services. I've been tempted numerous times to start new projects using alternatives such as Erlang, node.js or Go, only to find myself finally going back to Ruby. The reasons: it's versatile, convenient, familiar, and to be honest, for much of the stuff that Ruby does, and for many different uses, it performs just fine, and it continues to improve at a steady pace. > This is not a troll, I really don't think there are significant benefits anymore. A sweeping statement like this, how can it not be taken as trolling?
  - grandalf 12y ago
    > A sweeping statement like this, how can it not be taken as trolling? Note that I said significant benefits. There are still some benefits but I can't currently think of any reason to use Sinatra over Express, and I love Sinatra.
whistlerbrk 12y ago
My feelings of late have been: 1. Ruby is not built from the ground up for concurrency and eventing. You can use a number of great tools to effect that, but it isn't built for that from the ground up. 2. Rails continues to forge ahead with weird JS and asset management at the Ruby community's peril. We need to be taking a very serious look at tools like: http://scorchedrb.com/ http://scorchedrb.com/ - which provides a (more) correct pattern for routing and things like https://github.com/apotonick/trailblazer https://github.com/apotonick/trailblazer which provides an alternative code organization method which might make more sense. Most of our web apps are essentially state machines and the only framework which acknowledges it is: https://github.com/seancribbs/webmachine-ruby https://github.com/seancribbs/webmachine-ruby 3. Ruby needs to be faster. The community needs to get library support for 2.2 ASAP. We need to use Fibers and we need to use Celluloid. https://github.com/celluloid/celluloid/ https://github.com/celluloid/celluloid/ 4. I'd love to see in 2015 less new projects (fragmentation?), but more forking and more collaboration. That goes for the JS world as well.
- cheald 12y ago
  1. JRuby's definitely built for concurrency, though I suspect you're kind of leaning towards Node with this comment. It's certainly true that Ruby doesn't comprehensively do reactor-pattern stuff as well as Node, but threading on JRuby works wonderfully well. 2. I definitely agree about Rails and the asset pipeline. It feels awkward and kludgey and particularly in relation to JS I'd like to see code organization and tooling stepped up; many of the apps we're writing today are heavily Javascript, and it's a lot of work to maintain a large JS app on top of a Rails app right now. That's not to say that it's prohibitive, but Rails built a name for itself by making the drudgery less painful, and this is an open pain point. 3. Agreed, though JRuby is again a trailblazer here; boot-up time sucks (I'm working on that over Christmas break!), but 9k and the Truffle+Graal projects are huge leaps forward, and once JIT kicks in, JRuby's long-term performance is really excellent. MRI continues to make strong advances here, as well; the discussions around MRI 3.0 have hinted at some really good stuff coming down the pipe. 4. Can you elaborate on what specifically you mean? Ruby as a whole is absolutely stronger for the "new projects" (RBX, JRuby, Topaz); while issues like this can become divisive, I'll argue that RBX has been a net positive to the Ruby community, both because of RubySpec (a different perspective is valuable, even if it doesn't become the official spec) and because a new approach to a problem generally ends up leaking improvements all over the ecosystem.

51 points by nateberkopec 12y ago

Matz doesn't do threading, so we don't do threading. Matz doesn't do performance, so we don't do performance. Matz doesn't do rubyspec, so we don't do rubyspec.

grandalf 12y ago

As cool as Ruby is as a language, the politics are very strange. As Javascript VM performance starts to become orders of magnitude faster than any Ruby VM, there is less and less reason to invest time writing code in Ruby, particularly with superb syntax options like coffee and cljs, and better and better systems level alternatives (Rust, Swift, Go, etc... ) Ruby/Sinatra used to be my favorite combo, but since Rails started going off in a weird direction (anti-js, asset pipeline, choosing AR over DM, insecure defaults pre rails 4) there has been less good stuff written in Ruby to draw from to augment Sinatra... Rails has become a rapidly changing but rarely improving API. That Ruby 2.2 breaks Rails 3.2 is just one more reason to look elsewhere. I question why anyone would start a new project using Ruby at all. This is not a troll, I really don't think there are significant benefits anymore.

thothamon 12y ago
Of course it's very much a subject for debate, but I personally don't know a web development platform that is as fast to get off the ground and as complete as Rails. Some people are certainly trying, but I don't think anyone beats Rails in these two areas yet. You specifically mentioned starting a new project. I think that's where Ruby and Rails are the strongest. Maintaining a large system might be better done using some other language and framework.
- grandalf 12y ago
  I personally don't know a web development platform that is as fast to get off the ground and as complete as Rails I think this is an aesthetic preference. I personally think that the simplest and cleanest design is a combination of something like Sinatra/Express to implement a simple API and React on the client to do component-ized UI. Much of the "completeness" of rails is simply not needed when client side components can keep a bit of state around for housekeeping and make the occasional API call when data actually needs to move between client and server.
  - bonif 12y ago
    Not every new project is a SPA. It's completely possible to start a new project in 2015, which basically is a WEB SITE (with mobile views and everything, but basically a poor old website), in this case Rails is still the best option.
    - grandalf 12y ago
      You mean with server rendered HTML? IMHO the component abstraction provided by something like react leads to much cleaner separation of concerns, better boundaries between parts of the system, and easier to change/understand code.
nateberkopec 12y ago
You make it sound like speed is the only purpose of a programming language. If that was true. we'd all be writing C. Ruby optimizes for programmer happiness - that was Matz's explicit goal when writing the language. If that doesn't matter to you as much as speed on microbenchmarks, or if writing Ruby doesn't make you happy (it makes me happy!) then Ruby isn't for you.
- grandalf 12y ago
  I really like Ruby syntax, but lately others are catching up. Swift and Coffee are both (IMHO) strongly Ruby inspired and in some ways better. Consider how many heroku dynos are dedicated to running slow, non-concurrent Ruby web processes, and how many Kilowatt Hours are burned waiting for Rails to apps to start. These are just not problems people need to deal with anymore. So while I am a big fan of Ruby (I still think it's the closest to my brain's own pseudocode of any language I've used) the ecosystem is lagging significantly these days, not because it's not improving, but because js is improving at a must faster clip.
  - robertjpayne 12y ago
    I think there's a huge misconception that to scale your programming language must be concurrent and also extremely fast. I can't see how you can assert that the JS ecosystem is "better". It is rapidly changing which is partially detrimental. What worked or was considered a good choice at the start of 2014 is now mostly obsolete or abandoned by the end of 2014. As so many companies have shown it really does not matter what programming language you use as there are plenty of options to make it work, it's more about choosing the language that will provide the best fit for your business.
    - grandalf 12y ago
      > It is rapidly changing which is partially detrimental. What worked or was considered a good choice at the start of 2014 is now mostly obsolete or abandoned by the end of 2014. This is happening to supposedly mature, nearly decade-old Rails!
ilikepi 12y ago
> I question why anyone would start a new project using Ruby at all. This is not a troll, I really don't think there are significant benefits anymore. One might start a new project with Ruby if it were one's primary language, and there was a desire to build something without the overhead of working in another language in which one is less proficient. How about this analogy: there are many different ways to cook a meal, but often my goal is to prepare food easily and quickly so I can eat and move on. Thus, I usually stick to the relatively few methods with which I am comfortable. Sometimes I do experiment with the goal of learning something new. But in those cases, the primary goal is expanding my skills, not building the "product" as it were. edit: clarification
- grandalf 12y ago
  Quite true, but over time that erodes as a good reason. For people for whom the learning curve of a new framework/language is minimal there are fewer reasons to use anything in the Ruby ecosystem these days (I think).
ciconia 12y ago
> ...there is less and less reason to invest time writing code in Ruby... It seems to me that Ruby is doing just fine - the community is thriving, MRI is advancing quite rapidly. In reality people find Ruby to be a good solution. > I question why anyone would start a new project using Ruby at all. Actually there's a whole Ruby world out there besides Rails, even for web apps/services. I've been tempted numerous times to start new projects using alternatives such as Erlang, node.js or Go, only to find myself finally going back to Ruby. The reasons: it's versatile, convenient, familiar, and to be honest, for much of the stuff that Ruby does, and for many different uses, it performs just fine, and it continues to improve at a steady pace. > This is not a troll, I really don't think there are significant benefits anymore. A sweeping statement like this, how can it not be taken as trolling?
- grandalf 12y ago
  > A sweeping statement like this, how can it not be taken as trolling? Note that I said significant benefits. There are still some benefits but I can't currently think of any reason to use Sinatra over Express, and I love Sinatra.

whistlerbrk 12y ago

My feelings of late have been: 1. Ruby is not built from the ground up for concurrency and eventing. You can use a number of great tools to effect that, but it isn't built for that from the ground up. 2. Rails continues to forge ahead with weird JS and asset management at the Ruby community's peril. We need to be taking a very serious look at tools like: http://scorchedrb.com/ http://scorchedrb.com/ - which provides a (more) correct pattern for routing and things like https://github.com/apotonick/trailblazer https://github.com/apotonick/trailblazer which provides an alternative code organization method which might make more sense. Most of our web apps are essentially state machines and the only framework which acknowledges it is: https://github.com/seancribbs/webmachine-ruby https://github.com/seancribbs/webmachine-ruby 3. Ruby needs to be faster. The community needs to get library support for 2.2 ASAP. We need to use Fibers and we need to use Celluloid. https://github.com/celluloid/celluloid/ https://github.com/celluloid/celluloid/ 4. I'd love to see in 2015 less new projects (fragmentation?), but more forking and more collaboration. That goes for the JS world as well.

cheald 12y ago
1. JRuby's definitely built for concurrency, though I suspect you're kind of leaning towards Node with this comment. It's certainly true that Ruby doesn't comprehensively do reactor-pattern stuff as well as Node, but threading on JRuby works wonderfully well. 2. I definitely agree about Rails and the asset pipeline. It feels awkward and kludgey and particularly in relation to JS I'd like to see code organization and tooling stepped up; many of the apps we're writing today are heavily Javascript, and it's a lot of work to maintain a large JS app on top of a Rails app right now. That's not to say that it's prohibitive, but Rails built a name for itself by making the drudgery less painful, and this is an open pain point. 3. Agreed, though JRuby is again a trailblazer here; boot-up time sucks (I'm working on that over Christmas break!), but 9k and the Truffle+Graal projects are huge leaps forward, and once JIT kicks in, JRuby's long-term performance is really excellent. MRI continues to make strong advances here, as well; the discussions around MRI 3.0 have hinted at some really good stuff coming down the pipe. 4. Can you elaborate on what specifically you mean? Ruby as a whole is absolutely stronger for the "new projects" (RBX, JRuby, Topaz); while issues like this can become divisive, I'll argue that RBX has been a net positive to the Ruby community, both because of RubySpec (a different perspective is valuable, even if it doesn't become the official spec) and because a new approach to a problem generally ends up leaking improvements all over the ecosystem.