Nikita Shylnikov is an experienced Ruby developer, member of Dry-rb and Rom-rb Core team.
On the eve of RailsClub 2017, on which Nikita will be one of the speakers, we questioned him about his way to Rails and future of Ruby.
How did you start programming in Ruby?
Everything was simple. I hadn't programmed for money before. At first I was a manager, and I was offered to work as a programmer. I've agreed. On that project, there were Ruby and Oracle (they are there now). Since then, I've been working in the same place for 7 years now, switching between tasks.
Do you have any "professional education" or did you study yourself?
Did you immediately get involved in web development, or was there something else before it?
Now you are working in the web development?
In fact, yes.
And how did you come to the open source?
At one conference - I do not remember exactly - maybe DevConf, there was a section about Ruby. There, Kirill Mokevnin told about DDD, and I realized that everything we do at work is Domain Driven Design. Kirill said that there are problems in ActiveRecord with mapping the entities of the domain to the relational database, that there are guys who make the ROM, and they already released the DataMapper. This interested me, and since that time (2012) I started to follow the ROM. In 2015, version 1.0 was released. I just came up with a new project - I used Rails, because I already worked with them. I threw out ActiveRecord from there, inserted the ROM and started to struggle with it. In the course of this struggle, I came to the commits in the open source project ROM and dry-rb.
ROM and dry-rb are known for borrowing from FP. How do you think - is it important to add functional programming techniques to Ruby?
I'm not a fan of any particular programming language. I am for choosing the right tool for each task. There are general-purpose languages that can solve different problems, and they have both strong and weak sides. Ruby itself, which appeared more than 20 years ago, was originally object-oriented. However, it was strongly influenced by LISP. Even Matz said that he wanted to make a mixture of Perl and LISP. And LISP is the first functional language. It turns out that if you look deeper, Ruby has functional ancestors. It seems to me that we are so focused on the OOP that we did not develop other sides of Ruby. I believe that you need to look at other programming languages and take something that is applicable to Ruby. Can we combine FP and OOP? We'll try.
And why dry gems are called DRY?
In general, it's just a trademark. The essence of gems is to solve individual problems. For example, dry-types describes types, types can be re-used in different ways in different places. This is one of the meanings of the name.
In which direction will Ruby will evolve in general and the Rails in particular?
The standard question. Mats, for example, is afraid what happened to the Python: Python 2 and Python 3 was too big jump, I would not want such a repetition in Ruby. But the transition from Ruby 1.8 to 1.9 was palpable, but not painful. I do not think that Ruby will have major changes that will break back compatibility. I can not say anything specific about Rails.
What, in your opinion, is not enough in Ruby?
I can say quite definitely what Ruby doesn't have: pattern matching. In addition to applications, I'm writing a library code - there it would be great to use pattern matching. From the application point of view, you can add multithreaded programming primitives, get rid of GIL. There are still not enough non-commensurate structures: the idea of non-profitability allows you to think about the code much easier, and this would be useful for beginners. In dry-struct, for example, we emulated the profitability. Probably, it would be great if such tools were in the language from the box.
In your opinion, the most notable phenomena in the Ruby ecosystem except dry and rom?
Hanami is a very interesting project. This is the right tool with good documentation, which is understandable where and how to use it. It's very cool that we have an alternative to Rails, and it does not consist in creating a home-grown framework.
Why do we need the next Rails?
I've seen a lot of things by working on one big project. Started by dropping SQL from templates. In Rails, there are many unanswered questions about how to develop a large and long project. We have learned to work with this but have not reached standards, so it would be cool to have a framework where everything that is needed is standardized. A serious problem in Rails is ActiveRecord, a controversial pattern with certain flaws. For example, it's difficult to get off from. And, the more you "hide" the business logic from it, the better it works.
What could you recommend sites / courses / books for beginners and experienced Rubists?
I would advise newcomers to work with complex books like this: read for first time to put something in your head, and return to it as a directory as you work. An excellent example is Martin Fowler's "Patterns of Enterprise Application Architecture" The book was written in 2002 and is still relevant, many classes in the Rails took some patterns from it. Personally, I've got another book for experienced programmers - Martin Kleppmann, "Designing Data-Intensive Applications". This is not a very deep, but well-written book, with a bunch of links on topics of interest. The author mainly deals with the study of distributed systems, he was writing this book for 4 years, and it is devoted to working with data in various systems. There is given a clear, good description of many aspects of working with data, and it is not tied to a particular language. If you want to raise your level as a developer, that's it.
What is the biggest problem of the Ruby community?
We need to show that we have'nt yet uncovered the full potential of the language, and even if it is already over 20 years old, we can apply new approaches both in old problems and in new, developing areas!