

Rubyspec is dead, long live Rubyspec - nateberkopec
https://gist.github.com/nateberkopec/11dbcf0ee7f2c08450ea

======
grandalf
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
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
_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
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
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.

------
whistlerbrk
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
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.

~~~
whistlerbrk
We're on the same page here, especially re #2. And I think it's high time I
give JRuby a real shot.

As for #4, I'm all for those mentioned, low-level (and fascinating) projects.
And for projects surrounding programming paradigms e.g. Celluloid, EM... I was
really referring to libraries, but on second thought #4 isn't that a big of an
issue in Ruby-land, it's mostly a JS world problem.

I suppose my particular fear is that instead of re-organizing code within
Rails as an example, the community will opt to make another new framework
instead, increasing fragmentation.

~~~
cheald
This is somewhat off topic, but since you mention wanting to try JRuby, I'll
give you my spiel. :) I'm a recent JRuby convert (I've only started using it
heavily in the last year), but I can't say enough good about it. It's mature,
reliable, and really easy to work with. The Java code is extremely easy to
read (especially compared to MRI), and integrating Java libraries with your
Ruby code is trivial - you don't even have to write bindings, you just require
a jar and then start referencing constants.

This _really_ shines in places where CRuby has lagged behind - places like
numeric computing and natural language processing. The library support is iffy
at best, and usually the answer is "use python", but when you can just drop in
a Java library and call it a day, stuff gets really fun.

Profiling a live JRuby app with JMX and jvisualvm is _amazing_ \- I can attach
to a live, remote production instance and perform heap dumps, start sample
profiling, or even execute Ruby code! Going to back to fix our MRI apps has
left me very discontent with the state equivalent tooling :)

My primary complaint with Java is that it's verbose and lends itself to
overcomplex design, but I absolutely _love_ that I can write high-performance
code in Java and then write all my business logic in Ruby - it's the best of
both worlds. To illustrate, I wrote Manticore
([https://github.com/cheald/manticore](https://github.com/cheald/manticore))
to solve my persistent discontent with the state of HTTP clients in Ruby; the
Apache Commons HTTP components are extremely comprehensive, fast, powerful,
etc, but the API is horrific. I spent a bit of time wrapping them up in a nice
idiomatic Ruby interface, and ended up with an HTTP client that destroys the
pure Ruby clients for features and performance, and even beats out even
Typhoeus (which is really just a set of libcurl bindings) - and all in only
700 lines of code!

Finally, the JRuby community is _so_ welcoming and inclusive. #jruby on
Freenode is populated with all the project core members, and they are very
willing to answer questions and help out. headius (Charles Nutter) has turned
around bugfixes for issues in _minutes_ (in addition to being extremely
friendly and helpful), and they as a group have made it very easy for me to
contribute to the project. I've gotten a few dozen pull requests accepted into
master in the last few months, and thoroughly enjoy working on it. It has
easily been one of my best experiences in open source.

------
matzsayzno
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.

