
Ruby Next: A Transpiler for Ruby - progapandist
https://evilmartians.com/chronicles/ruby-next-make-all-rubies-quack-alike
======
burlesona
This is interesting. I’ve maintained a dozen or so production ruby apps and
have found language updates are generally painless and quick. In most cases my
test suite will issue a few deprecation warnings after an upgrade, but those
have always been easy to fix and are also safe to ignore for a little while.

I do see the author’s point with regards to writing gems, though. Just because
it’s easy to upgrade to 2.7 doesn’t mean I rush to do it. Usually the new
language features added are nice, but not mind-blowing. It’s a mature
language.

One thing that has been great is steady performance improvement every year. We
usually see a few percent reduction in compute after a ruby bump, which is
good for a smile. I’ve heard and am hoping that the 3.0 bump will be a little
bigger.

------
jarym
I have mixed feelings about this as I do JavaScript transpilers.

I’m totally in favour of using transpilers to support older platforms.

What has happened though in JS land is developers started using them in
reverse - writing to future standards that are not supported by the current
underlying interpreter.

Hoping here the same thing does not happen in Ruby

~~~
chris_st
I think I see what you're saying, and I agree about supporting older
platforms.

But wow, when the ES6 features hit, and I could use them NOW, in spite of
having to support IE? That was huge, and made the code so much nicer in so
many ways.

I was _really_ glad that I could, as the snaky folks say, "import from
future".

~~~
freedomben
Likewise. We have a big important codebase that was started a little before
all the ES6 features hit. Had it been written in ES5 at the time it would be a
pain to work in. However it's still a pleasure because it is ES6 with snippets
from ES7. We no longer use the transpiler, and were disciplined about only
using features that were definitely coming. I'm glad we did.

~~~
earthboundkid
Yeah, there's no way to convince people to write ES5 once they've seen ES6+.
:-) But the problem was that the JS ecosystem never totally got a consistent
story about how to stop transpiling. They were transpiling in Node, which
makes no damn sense. They were shipping transpiled bundles without the code
needed to turn the transpilation off in the future. It was and is a big mess
where now that ES6 is supported everywhere, you can't actually use it because
even though everything is written in ES6, it's shipped as ES5 and you're
saddled with this polyfilled crap even if you don't want it.

It's not the worst problem for an ecosystem to have, but as someone who wants
to ship smaller JS bundles, I find it annoying.

~~~
lioeters
> even though everything is written in ES6, it's shipped as ES5 and you're
> saddled with this polyfilled crap

This is somewhat mitigated by the use of babel-preset-env and browserslist.

[https://github.com/browserslist/browserslist](https://github.com/browserslist/browserslist)

Where I work, our build tool uses a list that's (very slowly) getting reduced
to evergreen browsers. On some projects, a simpler list can be used for little
to no polyfills.

> transpiling in Node, which makes no damn sense

A legitimate use case would be for server-rendered apps, where it's
advantageous to share code with client-side, namely transpiling module
import/export (rather than CommonJS) and JSX. I do enjoy how recent versions
of Node.js are embracing modern language features, even pipeline operator.
Still, there are situations where transpiling server-side code makes sense.

Another maybe more relevant reason is using TypeScript, which arguably
provides a leap in developer experience and code quality, beyond what browsers
(or the V8 engine) would implement in the foreseeable future.

------
geraldbauer
Love it a great way for encouraging more syntax experimentation in the wild. A
less functional and more conceptional library is the pragma gem [1] - that
lets you turn on the future today or add your own ideas for easy (re)use for
everyone - let's evolve the ruby language together by experimenting in the
wild in a pragma(tic) way.

[1]: [https://github.com/s6ruby/pragmas](https://github.com/s6ruby/pragmas)

~~~
ksec
Yes. It is hard to actually know whether the new Syntax is good or not by just
"looking" at it. It will needs to be put in the wild and see how it works out.
But you also dont want to support a syntax indefinitely for compatibility
reason.

------
jaynetics
Great project!

A bit shocking to see how much ancient Ruby is in use. It is not like they
massively change the language with every release like e.g. Swift. Probably
breaking changes in Rails are a bigger blocker for updating to a new Ruby than
Ruby itself?

~~~
skunkworker
New rails major and minor versions commonly lock the ruby version to a mature
recent release, though this is not always intuitive.

I can see a number of companies sticking on Ruby 2.2 because you can happily
upgrade Rails from 3.2 to 5.2 while only changing to a minor bugfix release of
2.2.10.

Rails 6 locks in at 2.5.0 which was over a year old at the time of the Rails 6
release.

[https://stackoverflow.com/questions/9087116/which-ruby-on-
ra...](https://stackoverflow.com/questions/9087116/which-ruby-on-rails-is-
compatible-with-which-ruby-version)

------
SPBS
you know, it just occurred to me that transpilers are basically lisp like
macros for programming languages that don't support it. i.e. Rewriting your
preferred syntax into a syntax that is supported by the programming language.

~~~
ken
"We can write a compiler as a set of macros." \-- Peter Norvig

------
drchopchop
I've had to deal with Ruby for the last 2 years, and one of the main problem
is the gem ecosystem. The language and standard libraries are pretty narrow,
unless you add Rails (which adds a new variety of breaking upgrade headaches).

Thus, there's always the desire to use third-party gems to achieve pretty
basic stuff (localization, decent networking/REST, database drivers, etc).
These then tend to go out of date. It's pretty common to find well-used gems
that haven't been updated in 5, even 10 years. This puts the developer in a
tough spot - reinvent the gem/wheel? Or be forced to stay on an EOL version of
Ruby?

~~~
cageface
This is because the next generation of hot coders is working on JS or
something more exotic like Rust. This is why I think that even though Rails is
still a good platform for building a certain class of webapps the writing is
on the wall and I'm planning to transition away from it over the next few
years.

~~~
shiny
I'm in the same spot. I still use & love Rails, but having adopted TypeScript
& VS Code (w/ React) for the front-end, I find myself missing those luxuries
when I switch back to Ruby/Rails/Vim.

I'm leaning towards a full TypeScript stack for my next project. The idea of
sharing types & code between client & server is incredibly seductive. But
there's no Rails for TS/Node, so I know it's going to be a shit show
assembling all of my chosen libraries into a cohesive whole.

Although looking at your previous comment, perhaps I should give Kotlin / Ktor
a try?

~~~
davidwf
FYI I think Redwood is trying hard to be Rails for TS/Node...

([https://news.ycombinator.com/item?id=22537944](https://news.ycombinator.com/item?id=22537944))

~~~
cageface
Redwood looks really interesting. I'd like to try it on a small project. The
emphasis on serverless seems like a bit of a different direction than Rails
though.

------
bilalq
Love seeing this. This let's people avoid the pains of forced migrations or
forking when a new version of a library has critical changes but drops older
Ruby support.

Also, I found this statement hilarious:

> Unlike front-end developers, we, Rubyists, usually do not need to “build”
> code (unless you’re using mruby, Opal, etc.).

It wasn't that long ago that front-end developers used to say the reverse.

------
braythwayt
I wish this had existed a decade ago. I would have saved myself a lot of
trouble by using it instead of trying to invent it!

[https://github.com/raganwald-
deprecated/rewrite_rails](https://github.com/raganwald-
deprecated/rewrite_rails)

~~~
grumple
That was a lot of interesting work.

------
VWWHFSfQ
Is this similar to Python's 2to3 [0] tool?

[0]
[https://docs.python.org/3/library/2to3.html](https://docs.python.org/3/library/2to3.html)

~~~
tingletech
looks more like bable form javascript (takes new code and re-writes it to work
on an older interpreter version)

