RubyRussia 2019. Nikita Shilnikov on algebraic effects
There is very little time left before the RubyRussia conference. Those who did not manage to get their ticket still have a chance to pick up one of the last on the site . Nikita Shilnikov at the conference will talk about algebraic effects, but for now you can read the interview on the topic of the report.
Tell me what you do and how it relates to Ruby?
I work for two companies whose projects are written in Ruby. In one we do billing, we can say that this is such a semi-enterprise, and in another we create a SaaS service. It so happened that I do a lot of open source. Four years ago, I became interested in one project, found a lack of functionality in it, decided to fix it and off and on. Now I am a core developer of two organizations and the community. Everything can be seen on my github . One part of the work deals with rom-rb databases, and the other dry-rb is a set of libraries for different occasions.
Your report on algebraic effects, tell me what benefits they give developers.
Here you need a small interview. The dry-rb ecosystem is inspired by functional programming. But during its development, something haunted. For example, you are developing a SaaS service and there is a simple task of isolating data. Everything seems to be clear, there is some kind of service, companies are registered in it, and they should not have access to each other's data. You can solve in many ways. But from a purely functional point of view, I could not find an answer to how to do this, except for the explicit transfer of arguments throughout the code. He came up with his “non-functional” solution and lived with him.
At the end of 2018, hooks appeared in React. When I first saw their API, I thought that it’s impossible to do such things so simply. I have a good idea of how JavaScript works and decided that everything is obviously not clean here, global variables are used or something else. In my idea of how the program works, it was either impossible, or some kind of dirty hack was used. I decided to study the issue.
It turned out that I was not the only person who was interested in this topic. I found information that there is such a way of formalization, that is, writing programs that seem to use global variables or some general state. However, they will still be clean. The problem was relevant and I began to dig deeper. As a result, the very algebraic effects became the answer. I wrote a small prototype in Ruby, and, to my surprise, it worked. Implemented in production, launched and drove for several months, then made a decision for everyone.
You intrigued me directly with React hooks. I thought there was something very simple like call stack, closure, current scope.
It really is. The problem is that you have some kind of article that describes semantics and how, from a scientific point of view, this should work. If you follow the specifications, then it appears you can make a library. In the case of React, this is also a library or, say, a framework that provides some kind of API. If you use it correctly, then everything works fine. But if you go left or right, it can end badly. In React, they simply prohibited the use of hooks in conditions. They had to do so. This is one of the limitations.
Is this somehow related to the mathematical proof of the correctness of the code?
Not really. There is no question that you need to prove something, the question is more towards verifying programs. What algebraic effects are all about is just a description of semantics. Nothing is proved there, but it is shown how it should work. If this library, which implements algebraic effects, does not contain errors in itself, then by describing the semantics, you guarantee that your code will work as intended.
How do you feel about types and statically typed programming languages?
Very positive. For example, we have a backend on Ruby, and a front end on such a thing as ReasonML. This is OCaml, but with a different syntax. Other things being equal, I make a choice in the direction of this type system. It is quite simple and there are a number of languages in which a similar or similar implementation. The more types, the better. However, I am writing a backend in Ruby and everything is fine with me. I am the developer of the tools with which I work and they have always been about types: dry-types , dry-struct , dry-schema , dry-validation , dry-monads . They are about describing types that come from the database, from the user, from external systems. So you always know what your Ruby code works with. Even if he himself is not typed, you can be sure of the type of variable with which you work.
There are rumors that there will be types in Ruby 3. What do you say about this?
I have experience with Python. When the types were brought there, the tuling was not very developed and I was not impressed. Now the situation is better there. There you can go in and describe everything with types and apply some kind of tuning, which will check that your program is correct. It's about some kind of replacement for the compiler, about what sorbet is doing now. This took several years for Python. I always welcome the movement towards types, but I have no illusions.
Looking for a new syntax that you plan to implement in terms of Ruby code?
Especially not played, went into the chat, looked. But I have no opinion on how this is worth implementing. The syntax can be improved, changes in the language and so on. Now they have made the usual Ruby-compatible syntax. I don’t think that syntax is a stumbling block here, a stumbling block is tuning and, as I said, this is a very long road.
What else would you like to see in Ruby, how do you see its development?
I would be interested in cooperative multitasking. We already have cooperative multitasking in the form of fiber. We still lack the ability to run them on multiple threads. There are options for how this will be done and it is not clear in what form. Given that Ruby, the C implementation has a pretty solid legacy, Matz doesn't want to break backward compatibility. I am inclined to a combination of fibers and several threads running simultaneously. Maybe something like Guild will work.
This year, Yukihiro Matsumoto, the author of Ruby, comes to the conference. What would you be interested to discuss with him over a cup of coffee or a glass of sake at the afterparty?
The best thing we can do in communicating with the authors of languages or even libraries is to show them how we use this product in real life. Moreover, even as the authors did not expect. This will give the author the opportunity to take into account such experience and apply it in further development. I would like to show the whole story with algebraic effects. I would say - look, what a thing can be done in the miracle language that you created. And maybe after that he will come up with something else for us.
See you at RubyRussia!
Recall that the conference is already this Saturday, registration is still open.
There will be not only reports, but also stands of the best companies:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - Valarm , JetBrains , Bookmate, and Cashwagon
Bronze Partner - InSales
Tell me what you do and how it relates to Ruby?
I work for two companies whose projects are written in Ruby. In one we do billing, we can say that this is such a semi-enterprise, and in another we create a SaaS service. It so happened that I do a lot of open source. Four years ago, I became interested in one project, found a lack of functionality in it, decided to fix it and off and on. Now I am a core developer of two organizations and the community. Everything can be seen on my github . One part of the work deals with rom-rb databases, and the other dry-rb is a set of libraries for different occasions.
Your report on algebraic effects, tell me what benefits they give developers.
Here you need a small interview. The dry-rb ecosystem is inspired by functional programming. But during its development, something haunted. For example, you are developing a SaaS service and there is a simple task of isolating data. Everything seems to be clear, there is some kind of service, companies are registered in it, and they should not have access to each other's data. You can solve in many ways. But from a purely functional point of view, I could not find an answer to how to do this, except for the explicit transfer of arguments throughout the code. He came up with his “non-functional” solution and lived with him.
At the end of 2018, hooks appeared in React. When I first saw their API, I thought that it’s impossible to do such things so simply. I have a good idea of how JavaScript works and decided that everything is obviously not clean here, global variables are used or something else. In my idea of how the program works, it was either impossible, or some kind of dirty hack was used. I decided to study the issue.
It turned out that I was not the only person who was interested in this topic. I found information that there is such a way of formalization, that is, writing programs that seem to use global variables or some general state. However, they will still be clean. The problem was relevant and I began to dig deeper. As a result, the very algebraic effects became the answer. I wrote a small prototype in Ruby, and, to my surprise, it worked. Implemented in production, launched and drove for several months, then made a decision for everyone.
You intrigued me directly with React hooks. I thought there was something very simple like call stack, closure, current scope.
It really is. The problem is that you have some kind of article that describes semantics and how, from a scientific point of view, this should work. If you follow the specifications, then it appears you can make a library. In the case of React, this is also a library or, say, a framework that provides some kind of API. If you use it correctly, then everything works fine. But if you go left or right, it can end badly. In React, they simply prohibited the use of hooks in conditions. They had to do so. This is one of the limitations.
Is this somehow related to the mathematical proof of the correctness of the code?
Not really. There is no question that you need to prove something, the question is more towards verifying programs. What algebraic effects are all about is just a description of semantics. Nothing is proved there, but it is shown how it should work. If this library, which implements algebraic effects, does not contain errors in itself, then by describing the semantics, you guarantee that your code will work as intended.
How do you feel about types and statically typed programming languages?
Very positive. For example, we have a backend on Ruby, and a front end on such a thing as ReasonML. This is OCaml, but with a different syntax. Other things being equal, I make a choice in the direction of this type system. It is quite simple and there are a number of languages in which a similar or similar implementation. The more types, the better. However, I am writing a backend in Ruby and everything is fine with me. I am the developer of the tools with which I work and they have always been about types: dry-types , dry-struct , dry-schema , dry-validation , dry-monads . They are about describing types that come from the database, from the user, from external systems. So you always know what your Ruby code works with. Even if he himself is not typed, you can be sure of the type of variable with which you work.
There are rumors that there will be types in Ruby 3. What do you say about this?
I have experience with Python. When the types were brought there, the tuling was not very developed and I was not impressed. Now the situation is better there. There you can go in and describe everything with types and apply some kind of tuning, which will check that your program is correct. It's about some kind of replacement for the compiler, about what sorbet is doing now. This took several years for Python. I always welcome the movement towards types, but I have no illusions.
Looking for a new syntax that you plan to implement in terms of Ruby code?
Especially not played, went into the chat, looked. But I have no opinion on how this is worth implementing. The syntax can be improved, changes in the language and so on. Now they have made the usual Ruby-compatible syntax. I don’t think that syntax is a stumbling block here, a stumbling block is tuning and, as I said, this is a very long road.
What else would you like to see in Ruby, how do you see its development?
I would be interested in cooperative multitasking. We already have cooperative multitasking in the form of fiber. We still lack the ability to run them on multiple threads. There are options for how this will be done and it is not clear in what form. Given that Ruby, the C implementation has a pretty solid legacy, Matz doesn't want to break backward compatibility. I am inclined to a combination of fibers and several threads running simultaneously. Maybe something like Guild will work.
This year, Yukihiro Matsumoto, the author of Ruby, comes to the conference. What would you be interested to discuss with him over a cup of coffee or a glass of sake at the afterparty?
The best thing we can do in communicating with the authors of languages or even libraries is to show them how we use this product in real life. Moreover, even as the authors did not expect. This will give the author the opportunity to take into account such experience and apply it in further development. I would like to show the whole story with algebraic effects. I would say - look, what a thing can be done in the miracle language that you created. And maybe after that he will come up with something else for us.
See you at RubyRussia!
Recall that the conference is already this Saturday, registration is still open.
There will be not only reports, but also stands of the best companies:
Organizer - Evrone
General Partner - Toptal
Gold Partner - Gett
Silver Partners - Valarm , JetBrains , Bookmate, and Cashwagon
Bronze Partner - InSales
All Articles