4 ms·
We don't know very much about what ruby 3 types will look like or what other information we'll have. Even a small subset of ruby being transpiled would be a us
by qop 8y ago
We don't know very much about what ruby 3 types will look like or what other information we'll have.
Even a small subset of ruby being transpiled would be a useful thing for some developers.
You're much more aware of some of the constraints here than I am, as Oracle doesn't pay me to hack ruby for a living.
With a typed AST, there'd be enough information there to build a foundation for a rb2cr tool. I didn't say the two languages are best friends and it'll be a breeze.
Most of the ruby code I want to rescue isn't littered with string-based define_method nonsense. Most of ruby I think worth saving at all is outside of rails and exists in various tools or maybe some metasploit modules or stuff like that. The pieces of code that utilize the grossest dynamic elements of ruby, like define method or objectspace, that stuff doesn't need to survive.
Even getting 50% of a codebase in ruby compiled to reasonable crystal is a much better foundation than previously purported successors (elixir, scala, swift) can do.
If ruby gets a typed ast, I'll try and write a simple transform tool for the simplest ruby.
- chrisseaton 8y ago> Most of the ruby code I want to rescue isn't littered with string-based define_method nonsense. I see what you are saying - but this is where the issue is I think. You may not write code that does sophisticated metaprogramming, but the gems you use are probably fundamentally based on it. Even just requiring some of the standard library uses a surprising amount of of metaprogramming. For example you can't load something as basic as 'fileutils' without doing a lot of metaprogramming. The entire Ruby ecosystem is built on metaprogramming.
- qop 8y agoThat's where the boundary for transpilation will lie then, but I don't consider that to be a good enough reason to justify not trying to write a tool like that. I really appreciate your thought on this! I look up to your work a lot. Sometimes I wish I had spent my career with compiler a instead of disassemblers... Yes, there will be a lot of ruby that can never by crystallized. Yes that kinda sucks. So yes it's very good to explore optional or gradual for incremental refactors and modernization. But if even 1% of ruby code CAN be crystallized, then it's worth it to do it. Maybe not for you, but my time isn't nearly as expensive as yours must be, so I understand your reasoning here I think. I don't mean to be adversarial here.
- chrisseaton 8y agoPart of the reason it might be coming across as a slightly negative reaction is that I'm passionate about implementing Ruby exactly as it is. If people want to write in Crystal that's great it can be fast. But if people want to write in Ruby, doing all sorts of metaprogramming, or that's the code they actually have today and need to run in order to keep their business going, then I want to make that just as fast for them automatically. Without telling them to use a subset, or not to use awkward features. I want people to bring me their insane code and I'll find a way to make it fast for them. That's the challenge I'm enjoying at the moment. If people are happy to use a subset of Ruby then yes it could be transpiled. But a simple subset of Ruby should work great in the new JIT compilers we're getting anyway, without using Crystal.
- qop 8y agoI used to be happy with Ruby, but learning Scala and then Crystal really changed my mind about where the line ought to be drawn wrt to expressiveness and safety. I don't and have never used the vast majority of Ruby's metaprogramming features, but I'm the odd duckling in an equation where probably 95% or more Ruby programmers are Rails programmers, and I am not. I mean, I can, but I don't. That factor makes less sympathetic to the majority of Ruby users who won't have any stake in a project like what I'm thinking about. And that's ok. And either way, if they want to make use of all those features then they will or maybe already have realized that Ruby already does what they want and Ruby3's care for backwards compat surely will cater to that majority in order to keep them on board. Metaprogramming I think is the primary style of Ruby, and that's OK. The Crystal team has essentially reprogrammed the way I think about how it should feel to write good OO code. Scala did the same thing for a time, but just the sheer pain of SBT drove me away. With Crystal, Having parametric modules is an incredible advantage. I can write mixins essentially like traits that specialize on some new type in my program. I have to consider how my methods end up typing out, and that changes the way I think about how I'm going to get from here to there. With Ruby, I really like that left-to-right idea of chaining until I arrive at the structure I want, and the more Crystal I write the more I realized how irritating it was to hunt down Ruby bugs by: whatever.tap{ |o| puts "#{o} is a: #{o.class} here" } or even deeper with responds_to? or whatever I'm trying to figure out. With crystal, all I have to do is look at the stacktrace, it is getting a nil where it shouldn't be at SomeClass#some_method on line 230842349, and I immediately can work on the bug at the source of it, instead of the tedious extra step of finding it. Being able to make Ruby do magic was never part of the equation that held me a romantic captive to Ruby, it was always the succinctness. Elixir came close, but Crystal gets me all the way there. If nothing else, maybe I will learn something new trying to find a subset of ruby3 that I can transpile. I haven't read much about the new JIT, but if you're happy about it, maybe I should stop procrastinating and find out about it.