A software engineer with over 10 years of experience, working as Tech Lead at Icelab. Active OSS contributor and maintainer of various projects for over 5 years. Former DataMapper core team member, creator of the popular Virtus gem, lead developer of Ruby Object Mapper project, and dryrb core developer.
On the eve of RailsClub 2017, on which Petr will be one of the speaks, we questioned him about his issues of Rails community and dry-* stack.
How do you think, what is the most important issue Ruby and RoR community faces right now?
The most important issue is for us to prove that Ruby is still a viable technology choice, with a strong, still growing and evolving, ecosystem of libraries, frameworks and various development tools. In order to do that we need to break our post-Rails habits though, so it’s a challenge and it’s going to take a while. A good example is the usage of ORMs, specifically Active Record pattern. It’s become a standard, and many people have serious trouble understanding how to use alternatives. It’s of course partly due to the lack of resources, and the fact alternative solutions are still relatively young, but I’m pretty sure even with good resources people will find it challenging, because of what they are used to. It’s a bit like with PHP back in the day when the community started embracing good design techniques, but it took a while to explain to everybody things like “look, don’t connect to the database and select rows in a view template, ok?”. We’re of course in a much better position than PHP was back then, but I see an analogy regardless. So yeah, breaking bad habits and to keep evolving the ecosystem is an issue that we’re facing. The fun fact here is that there are a lot of people who would completely disagree with me here, which is fine, Ruby community is big enough to have lots of different opinions. What’s important is to have a diverse ecosystem, so far we’ve been mostly a mono-culture gathered around Rails, and it’s especially visible when you look at the job market.
In your opinion, what is the most important task that have to be fixed/implemented in MRI to make Ruby much better than now?
I don’t have a unique answer to this question - better concurrency. I would also like to see some work done on unification of proc/lambda/method-object, as well as some new features, like support for composing procs. A first class concept of a function object would blow my mind too. In general, I think Ruby should expose its functional side more clearly, as personally I’ve found it to be extremely useful, but it’s hard to convince some people, as they are stuck within the OO paradigm.
How has dry-* stack changed from it's initial idea? What have changed during its development? Why that happened?
The initial idea was to create a set of small libraries that could be used to build bigger things, but eventually we ended up with a bigger variety of libraries, ranging from really tiny ones, to relatively big and complex gems. The reason why it happened is quite simple - certain proofs of concepts turned out to be pretty good ideas, and they still fit within the philosophy of dry-rb, which is first and foremost to have a set of non-intrusive, composable libraries. Some of these ideas turned into dry-rb gems, like dry-system or dry-validation, both are pretty big ones (assuming you consider 2kCLOC a big lib, I do).