8 ms·

Ruby Next: A Transpiler for Ruby

151 points by progapandist 6y ago

geraldbauer 6y ago
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 6y ago
  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.
drchopchop 6y ago
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?
- jaynetics 6y ago
  > The language and standard libraries are pretty narrow Compared to which other language?
  - drchopchop 6y ago
    > Compared to which other language? Java, for one, but obviously it's subjective
    - jtth 6y ago
      You can use JRuby and then have access to both library ecosystems.
  - vidugavia 6y ago
    Not JavaScript or Go, that's do sure...
- cageface 6y ago
  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.
  - thekingofh 6y ago
    In 5 years there'll be another shiny thing everyone will flock to. It's part of the fun, but there are some languages that just do that particular thing just right. Ruby/Rails is bittersweet to me. It does that thing just so right, but it feels like there's an evolution around the corner that could be an upgrade when it comes to the ecosystem. It certainly doesn't feel like Rust is a good replacement if you enjoy Ruby syntax and dynamic typing simplicity. Ruby reminds me a lot of how Perl 5 is a great language, yet finding jobs in Perl 5 is becoming more and more difficult. I'd love to think that Raku (formerly Perl 6) would be that language, but it doesn't seem like the trajectory is there.
    - cageface 6y ago
      Just because something is new and shiny doesn't mean it's not a step forward. People dismissed Rails with these same criticisms in the beginning. Sometimes new tech gives us a big step up in productivity and I think we can now do better than Ruby/PHP/Python.
  - jaredcwhite 6y ago
    Or you could become an open source contributor and improve the ecosystem by submitting PRs to existing gems or writing your own. The community is us. Ruby is what we make it. So let's make it better.
    - cageface 6y ago
      Rails has been very good to me over the years so I am tempted to try to help out but I think if I'm going to volunteer I'd prefer to help a more modern stack like KTOR.
- the8472 6y ago
  Does the dependency manager not enable fork + override dependency?
  - drchopchop 6y ago
    Yes, but you can easily get in a situation where say Github says "gem X is vulnerable, upgrade it", but can't generate it needs to update version of dependent gem Y, and that would break gem Z which is version locked because ruby versions etc...
    - lostapathy 6y ago
      This happens, but it's not really that common, and it's certainly not insurmountable. You can fork any gem in github, fix whatever issue it has, and point your Gemfile at your fork on github. Bundler treats it as the same package so it doesn't break your dependency tree either above or below it. I've used this to fix an incompatibility in the middle of my dep tree before. It's annoying, but it's not exactly a big deal.
- Trasmatta 6y ago
  Ruby is generally very backwards compatible, so I rarely run into an issue where an old gem requires that I run an old Ruby version.
- rubiquity 6y ago
  A lot of gems don’t need to be updated. Stable software is a thing, especially in more mature ecosystems such as Ruby.
- joshmn 6y ago
  I haven't had your same problem and I've been working with Ruby for the last 8 years. I've also deployed Go, Python, Elixir, and Javascript to production. Here are my thoughts on Ruby in 2020: Ruby, between versions, doesn't have many breaking changes, if any. They're more additive changes than they are subtractive. That obscure gem that has a last commit date of 2 years ago? Probably still works. Bundler complaining the Ruby version isn't supported in the gemspec? Fork, edit, push, bundle, success. When you say basic stuff, I think of "busy work that's already solved by someone else, probably in a more complete than my half-assed attempt would be just so I can focus on more domain-specific problems and implement business logic." That's a fine tradeoff. My clients don't pay me to implement things like authentication or design an ORM: They pay me to do business logic. `bundle add devise; rails g devise:install; rails g devise User; rake db:migrate` gets me rock-solid authentication and I didn't have to think twice about it. "Look at all the things I'm not doing" was something DHH said when he released Rails. A lot of Ruby is the same way. That's fine with me, and a lot of others. There's a lot to love with Ruby in 2020. I still find it to be the most hyper-productive ecosystem and it doesn't change daily (see: Javascript's ecosystem). It's a language that's expressive, enjoyable, and plain fun. And for the very vast majority of web applications — which are CRUD-centric — Rails is still an extremely valuable means to get up and running. Scale? 99% of us won't need to worry about scale, and when we do, that's a great problem. Speed? For 99% of us, our database will be the slowest part of our application — even when indexed and tuned. Sure, it may not be 2020 sexy. The socks you're wearing probably aren't either, but they still get the job done.
  - jaredcwhite 6y ago
    Ruby is plenty sexy to me! Been working in a large "modern" Typescript codebase for about a year now, and every chance I get to go back to writing Ruby, it's a breath of fresh air!
  - mostlysimilar 6y ago
    Ruby is a joy and I'm always a little confused by it getting so much negativity on internet forums. I guess we all have our preferences, but the Ruby ecosystem feels sane and stable to me.
- dragonwriter 6y ago
  > The language and standard libraries are pretty narrow, unless you add Rails Rails is neither the language nor the standard library, so the “unless” part seems superfluous. > 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? If it's open source, why would reinvention rather than forking and assuming maintenance (for one's own needs, not necessarily publicly) be an issue?
- vidugavia 6y ago
  Ruby is super backwards-compatible with new versions. Even to much. The core team almost made religion from it. So I don't really understand what the problem is - aside from using not maintained library. It will work, unless it was written for 1.8 or something.
- YorickPeterse 6y ago
  Just because something hasn't been updated for a while doesn't mean it's broken.
VWWHFSfQ 6y ago
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 6y ago
  looks more like bable form javascript (takes new code and re-writes it to work on an older interpreter version)
- jaynetics 6y ago
  Not really, and it is also for the opposite direction (newer to older). More like Babel.
braythwayt 6y ago
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 6y ago
  That was a lot of interesting work.
jarym 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      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.
jaynetics 6y ago
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 6y ago
  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-rails-is-compatible-with-which-ruby-version https://stackoverflow.com/questions/9087116/which-ruby-on-ra...
burlesona 6y ago
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.
SPBS 6y ago
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 6y ago
  "We can write a compiler as a set of macros." -- Peter Norvig
bilalq 6y ago
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.
georgianar 6y ago
This kind Man brought my Lover back In less than 3 days, i saw wonders, my Lover came back to me and my life got back just like a completed puzzle… am so happy.. thanks to Robinsonbucler@ { gmail }. com for saving my life. Mr Robinson is the best I’ve ever met! Thanks, thanks thanks_____________

151 points by progapandist 6y ago

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 6y ago
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.

drchopchop 6y ago

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?

jaynetics 6y ago
> The language and standard libraries are pretty narrow Compared to which other language?
- drchopchop 6y ago
  > Compared to which other language? Java, for one, but obviously it's subjective
  - jtth 6y ago
    You can use JRuby and then have access to both library ecosystems.
- vidugavia 6y ago
  Not JavaScript or Go, that's do sure...
cageface 6y ago
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.
- thekingofh 6y ago
  In 5 years there'll be another shiny thing everyone will flock to. It's part of the fun, but there are some languages that just do that particular thing just right. Ruby/Rails is bittersweet to me. It does that thing just so right, but it feels like there's an evolution around the corner that could be an upgrade when it comes to the ecosystem. It certainly doesn't feel like Rust is a good replacement if you enjoy Ruby syntax and dynamic typing simplicity. Ruby reminds me a lot of how Perl 5 is a great language, yet finding jobs in Perl 5 is becoming more and more difficult. I'd love to think that Raku (formerly Perl 6) would be that language, but it doesn't seem like the trajectory is there.
  - cageface 6y ago
    Just because something is new and shiny doesn't mean it's not a step forward. People dismissed Rails with these same criticisms in the beginning. Sometimes new tech gives us a big step up in productivity and I think we can now do better than Ruby/PHP/Python.
- jaredcwhite 6y ago
  Or you could become an open source contributor and improve the ecosystem by submitting PRs to existing gems or writing your own. The community is us. Ruby is what we make it. So let's make it better.
  - cageface 6y ago
    Rails has been very good to me over the years so I am tempted to try to help out but I think if I'm going to volunteer I'd prefer to help a more modern stack like KTOR.
the8472 6y ago
Does the dependency manager not enable fork + override dependency?
- drchopchop 6y ago
  Yes, but you can easily get in a situation where say Github says "gem X is vulnerable, upgrade it", but can't generate it needs to update version of dependent gem Y, and that would break gem Z which is version locked because ruby versions etc...
  - lostapathy 6y ago
    This happens, but it's not really that common, and it's certainly not insurmountable. You can fork any gem in github, fix whatever issue it has, and point your Gemfile at your fork on github. Bundler treats it as the same package so it doesn't break your dependency tree either above or below it. I've used this to fix an incompatibility in the middle of my dep tree before. It's annoying, but it's not exactly a big deal.
Trasmatta 6y ago
Ruby is generally very backwards compatible, so I rarely run into an issue where an old gem requires that I run an old Ruby version.
rubiquity 6y ago
A lot of gems don’t need to be updated. Stable software is a thing, especially in more mature ecosystems such as Ruby.
joshmn 6y ago
I haven't had your same problem and I've been working with Ruby for the last 8 years. I've also deployed Go, Python, Elixir, and Javascript to production. Here are my thoughts on Ruby in 2020: Ruby, between versions, doesn't have many breaking changes, if any. They're more additive changes than they are subtractive. That obscure gem that has a last commit date of 2 years ago? Probably still works. Bundler complaining the Ruby version isn't supported in the gemspec? Fork, edit, push, bundle, success. When you say basic stuff, I think of "busy work that's already solved by someone else, probably in a more complete than my half-assed attempt would be just so I can focus on more domain-specific problems and implement business logic." That's a fine tradeoff. My clients don't pay me to implement things like authentication or design an ORM: They pay me to do business logic. `bundle add devise; rails g devise:install; rails g devise User; rake db:migrate` gets me rock-solid authentication and I didn't have to think twice about it. "Look at all the things I'm not doing" was something DHH said when he released Rails. A lot of Ruby is the same way. That's fine with me, and a lot of others. There's a lot to love with Ruby in 2020. I still find it to be the most hyper-productive ecosystem and it doesn't change daily (see: Javascript's ecosystem). It's a language that's expressive, enjoyable, and plain fun. And for the very vast majority of web applications — which are CRUD-centric — Rails is still an extremely valuable means to get up and running. Scale? 99% of us won't need to worry about scale, and when we do, that's a great problem. Speed? For 99% of us, our database will be the slowest part of our application — even when indexed and tuned. Sure, it may not be 2020 sexy. The socks you're wearing probably aren't either, but they still get the job done.
- jaredcwhite 6y ago
  Ruby is plenty sexy to me! Been working in a large "modern" Typescript codebase for about a year now, and every chance I get to go back to writing Ruby, it's a breath of fresh air!
- mostlysimilar 6y ago
  Ruby is a joy and I'm always a little confused by it getting so much negativity on internet forums. I guess we all have our preferences, but the Ruby ecosystem feels sane and stable to me.
dragonwriter 6y ago
> The language and standard libraries are pretty narrow, unless you add Rails Rails is neither the language nor the standard library, so the “unless” part seems superfluous. > 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? If it's open source, why would reinvention rather than forking and assuming maintenance (for one's own needs, not necessarily publicly) be an issue?
vidugavia 6y ago
Ruby is super backwards-compatible with new versions. Even to much. The core team almost made religion from it. So I don't really understand what the problem is - aside from using not maintained library. It will work, unless it was written for 1.8 or something.
YorickPeterse 6y ago
Just because something hasn't been updated for a while doesn't mean it's broken.

VWWHFSfQ 6y ago

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 6y ago
looks more like bable form javascript (takes new code and re-writes it to work on an older interpreter version)
jaynetics 6y ago
Not really, and it is also for the opposite direction (newer to older). More like Babel.

braythwayt 6y ago

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 6y ago
That was a lot of interesting work.

jarym 6y ago

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 6y ago
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 6y ago
  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 6y ago
    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.

jaynetics 6y ago

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 6y ago
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-rails-is-compatible-with-which-ruby-version https://stackoverflow.com/questions/9087116/which-ruby-on-ra...

burlesona 6y ago

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.

SPBS 6y ago

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 6y ago
"We can write a compiler as a set of macros." -- Peter Norvig

bilalq 6y ago

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.

georgianar 6y ago

This kind Man brought my Lover back In less than 3 days, i saw wonders, my Lover came back to me and my life got back just like a completed puzzle… am so happy.. thanks to Robinsonbucler@ { gmail }. com for saving my life. Mr Robinson is the best I’ve ever met! Thanks, thanks thanks_____________