RailsClub 2017. The answer to three main questions from Piotr Solnica
Until RailsClub 2017 quite a bit (by the way, even if you don’t go, do not forget to vote for Ruby Heroes ). Today we want to introduce one more guest to ours - Piotr Solnica, the author of rom-rb and dry-rb and, as Peter writes to himself, “all-around OSS contributor”.
What do you think is the biggest challenge the Ruby and RoR community is facing right now?
The most important task for us is to prove that it is worth choosing Ruby for new projects, that it is a viable technology, with a strong, growing and developing ecosystem of libraries, frameworks and various development tools. To do this, we need to overcome our “rail” habits, but it is not easy and will take some time. An example of such a rails syndrome is the use of ORM, in particular, Active Record. It has become such a rigid standard that many people have serious problems understanding how to use alternatives. This, of course, is partly due to lack of information and because alternative solutions are still relatively young. But I am sure that even if good resources appear, developers will consider alternative approaches difficult, because it will be unusual to use them. This is a bit like the situation in PHP, when the community began to apply good design patterns, but it took some time to explain things like “don't connect to the database and don't get records in view, ok?”. The situation with us, of course, is much better than that of PHP then, but I see an analogy. So yes, getting rid of bad habits and continuing the evolution of the ecosystem are exactly the tasks that we need to solve now. Interestingly, there are many people in the community who completely disagree with me, which is good: the Ruby community is large enough to have many different opinions. It is important to have a diverse ecosystem, so far we have been mostly monoculture gathered around Rails. This is especially noticeable if you look at the vacancies on the market.
In your opinion, what is the most important task that needs to be fixed / implemented in the MRI to make Ruby much better than it is now?
')
My answer is not original - improve concurrency. I would like to progress in the unification of proc / lambda / method-object, and also new features, for example, support for composite procs. If functions in Ruby were the main building blocks, that would be awesome. I think that Ruby should more clearly reveal its functional side, I find it extremely useful, but it is difficult to convince some people of its importance as they are stuck in the OO paradigm.
How did the stack dry- * change from its original ideas? What has changed during its development? Why did this happen?
The original idea was to create a set of small libraries that could be used to create large things, but in the end we had a large number of libraries, from the smallest to relatively large and complex gems. The reason this happened is quite simple - some concepts turned out to be good ideas, and they still fit into the dry-rb philosophy, which is primarily to have a set of easily composable libraries that do not impose a specific application structure. Some of these ideas have become dry-rb gems, such as the dry-system or dry-validation. Both of these hemes are quite large (assuming that you think that 2k CLOC is a large library, I think).
Come this Saturday at the RailsClub to meet Peter!
Traditionally, we thank the excellent companies that support the conference. Our general partner:
Toptal is a distributed global exchange that is already joined by the most talented developers from around the world. Toptal created by engineers to help companies accelerate and scale.
Stay up to date with our news by subscribing to the newsletter on the website railsclub.ru, and stay tuned for updates:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
What do you think is the biggest challenge the Ruby and RoR community is facing right now?
The most important task for us is to prove that it is worth choosing Ruby for new projects, that it is a viable technology, with a strong, growing and developing ecosystem of libraries, frameworks and various development tools. To do this, we need to overcome our “rail” habits, but it is not easy and will take some time. An example of such a rails syndrome is the use of ORM, in particular, Active Record. It has become such a rigid standard that many people have serious problems understanding how to use alternatives. This, of course, is partly due to lack of information and because alternative solutions are still relatively young. But I am sure that even if good resources appear, developers will consider alternative approaches difficult, because it will be unusual to use them. This is a bit like the situation in PHP, when the community began to apply good design patterns, but it took some time to explain things like “don't connect to the database and don't get records in view, ok?”. The situation with us, of course, is much better than that of PHP then, but I see an analogy. So yes, getting rid of bad habits and continuing the evolution of the ecosystem are exactly the tasks that we need to solve now. Interestingly, there are many people in the community who completely disagree with me, which is good: the Ruby community is large enough to have many different opinions. It is important to have a diverse ecosystem, so far we have been mostly monoculture gathered around Rails. This is especially noticeable if you look at the vacancies on the market.
In your opinion, what is the most important task that needs to be fixed / implemented in the MRI to make Ruby much better than it is now?
')
My answer is not original - improve concurrency. I would like to progress in the unification of proc / lambda / method-object, and also new features, for example, support for composite procs. If functions in Ruby were the main building blocks, that would be awesome. I think that Ruby should more clearly reveal its functional side, I find it extremely useful, but it is difficult to convince some people of its importance as they are stuck in the OO paradigm.
How did the stack dry- * change from its original ideas? What has changed during its development? Why did this happen?
The original idea was to create a set of small libraries that could be used to create large things, but in the end we had a large number of libraries, from the smallest to relatively large and complex gems. The reason this happened is quite simple - some concepts turned out to be good ideas, and they still fit into the dry-rb philosophy, which is primarily to have a set of easily composable libraries that do not impose a specific application structure. Some of these ideas have become dry-rb gems, such as the dry-system or dry-validation. Both of these hemes are quite large (assuming that you think that 2k CLOC is a large library, I think).
Come this Saturday at the RailsClub to meet Peter!
Traditionally, we thank the excellent companies that support the conference. Our general partner:
Toptal is a distributed global exchange that is already joined by the most talented developers from around the world. Toptal created by engineers to help companies accelerate and scale.
Stay up to date with our news by subscribing to the newsletter on the website railsclub.ru, and stay tuned for updates:
RailsClub.ru
twitter.com/railsclub_ru
facebook.com/railsclub
Source: https://habr.com/ru/post/338278/
All Articles