Interview with Godfrey Chan, RubyRussia Conference Speaker

    Hello! October 6 in Moscow will host a conference RubyRussia - the good old RailsClub, but with a new name. Speakers of this year: Aaron Patterson, Charles Nutter, Godfrey Chan, Maciej Mensfeld, Markus Schirp and more. And of course, 600 participants, the best companies with stands in the lobby and fiery afterparty.

    Traditionally, before the conference, we talk about the most relevant topics in Ruby and Rails. Today we introduce you to the Godfrey Chan - ex-Rails core team, working at Tilde, where it is torn between creating a smart Rails profiler Skylight , working on Ember.js and developing JavaScript on TC39. Evrone Tim Lead Dmitry Matveyev asked our guest important questions.


    Let's start with a couple of questions about your RubyRussia report?

    I do not want to reveal all the secrets! My report is called “Dropping down to the metal”. I'll tell you how to write rather strange Rub code using metaprogramming to do something similar to JavaScript. Of course, we won't be able to write a full-fledged JavaScript parser and runtime, but I will show some magic that will cause a piece of JavaScript-like code to run in Ruby using the native Ruby runtime. It's fun, at least, I really like it. This is the same technique with which you can write things like rspec, rake or other DSLs in Ruby. I'll show the audience how Ruby parses and runs your code, and what hooks you can use. I think that the report will not only be fun, but also teach some useful things about Ruby metaprogramming.

    Cool! That is, there will be practical advice, right?

    I am not sure that it will be possible to focus on them, but I believe that from these 30 minutes you will take out something useful for yourself.

    Fine! I think the report will be interesting for both experienced programmers and beginners. True?

    I hope that it will be like that. At least I will try.

    By the way, yesterday I read your article on Medium about rethinking education in computer science. The article is very interesting, and I agree with the thoughts about the differences between classical university education and modern courses for programmers. By the way, why did you decide to become a programmer?

    Just a fluke, I never planned to work as a programmer, for me it was a bit of a hobby. I really liked messing around with computers, it was easy to think of an occupation there — accidentally deleting system files or digging into the Windows registry. Then I wanted something more. After school, I started going to web site development courses. I was delighted with the opportunity to create something new on the computer. But I soon realized that this was not enough for me. I could create a kind of computer game in HTML, but this toolkit was rather limited. One day, my teacher gave me a book on PHP. I read it all and, unexpectedly for myself, opened up a whole new world of possibilities, which gives much more than HTML and CSS. It was very cool, after that I began to read more and more books on this topic. The next language I learned became java. I once read about Ruby in Linux Magazine (not really about Ruby, but about Rails, of course), and thought it would be great to study it. From there it all started, and, like a snowball, is rolling to this day.

    And so you switched to Ruby, right?

    I discovered Ruby around the time I started to study Computer Science in college, so at the same time I also studied Java, C ++, Haskell and more, I studied many programming languages ​​at once. As part of our studies, we didn’t have Ruby assignments, and I really liked it, so I always tried to use it in those classes where I could choose the technology myself. Well, in their third-party projects, too. When I graduated from college, I decided to look for a job related to Ruby. It was easy, because Rails was at the peak of popularity: a lot of startups used this technology. So interest became my work.

    Do you use Ruby as your main tool now? Or working with something else?

    In my current job at Tilde, I don’t write as much in Ruby as before. I would say that my work is a cocktail from JavaScript / TypeScript, Rust, Ruby and sometimes Java. But, anyway, all the work I do is related to Ruby.

    The main product in Tilde is Skylight. Not all the components in it are written in Ruby: the frontend is in JavaScript and Ember, the backend on Rails, but all the processing of incoming data is Java and Rust. But Skylight itself is a performance monitoring tool for Rails applications. In this sense, all the work I do is still related to Ruby.

    Super! I registered with Skylight a few days ago for one of the projects, now I'm testing it. It looks interesting, and from the very beginning it is clear how everything works. I haven’t gone deep yet, but I plan to start using it very tight next week. I hope I can fix some problems with it.

    Well, it would be great to hear feedback!

    It is interesting to compare Ruby with other languages. For example, with Rust. Ruby is very expressive, and created to make the code readable. If you compare it with Python or with C ++, C #, Java, they, in my opinion, are not as easy to read as Ruby. What do you think about it?

    I will agree. There are two ways to “learn” a new language. The first one is rather superficial: I study the basics of syntax, play with examples, and then immediately forget about it. I had it with Go. I worked on them at the weekend, then I wrote small projects on it for a couple of weeks. But then I had no reason to continue programming on Go. I just studied it for curiosity, and quickly forgot.

    On the other hand, there are JavaScript / TypeScript, Rust and Ruby that I use all the time. Each of these languages ​​has opened up new opportunities for me, which is great motivating.

    For example, when I started working with Ruby, I was attracted to expressiveness. No other language was allowed to do such crazy things as method_missing. Metaprogramming, expressiveness, and code readability are key things I love about Ruby. It would be cool if other languages ​​could do that.

    But you can do things that are impossible in Ruby. For example, javascript. With him everything was completely different from Ruby, which I fell in love with at first sight. I started using javascript as needed, I needed to write browser code. Whether we like it or not, there's no getting away from JS. If you want to write an interactive browser application, such as Skylight (just what I was interested in at the time), then JavaScript is the only way out.

    I wanted to transfer the ideas that I liked to Ruby, to JavaScript, so, in the end, I started working with Ember. This in turn led me to TypeScript. When writing a huge framework, such as Ember, in JavaScript, having types and a compiler for error checking really helps. JavaScript and TypeScript helped me understand this.

    The ideas that Rust taught me are very similar to TypeScript. It's nice to be able to compile the whole program, and be sure that it works. As for me, it's just awesome. I worked with compiled languages ​​before: with Java and C. In them, you also have to wait until the code is compiled, but this is not so useful because the type system in these languages ​​does not catch errors very well. But in Rust, the compiler can guarantee that the program will not cause memory problems, and that during its execution there will be no segmentation errors (segfault). One of the most difficult things in C programming is memory problems that are very difficult to avoid. The main feature of Rust for me is the opportunity to engage in low-level programming, without worrying about it.

    By the way, my interest in Rust was associated with Ruby. I just started working at Tilde, and I knew that the Skylight gem was written in Rust. I thought it would be great to learn how to write native Ruby extensions in the same way. I wanted to learn how to write in Rust so that I don’t worry about how to break user ruby ​​processes, as happens if the pointers in C are incorrectly dereferenced. Therefore, the main purpose of studying Rust for me was actually writing native extensions for Ruby.

    Just this morning, I worked on a project with Peter Wagenet from Tilde, and Sean Griffin from the Shopify team and the core Rails team. Sean is working on a new version of Active Record, written in Rust, to speed up the slow parts. And right before this interview, I was working on a project on Rust called libcruby-sys, which allows you to write native extensions for Ruby on Rust.

    In the end, we can say that all languages ​​are connected. The languages ​​that I study and in which I program are simply tools that allow me to create what I have in mind.

    Very interesting! It's cool that ActiveRecord will be much faster. As far as I understand, the very idea of ​​ActiveRecord will not change. I mean, will it be the same ActiveRecord, and not something like a Data Mapper?

    Active Record on Ruby, of course, is not going anywhere, it is actively developed, it is used. In the case of JRuby, this is the first choice. Sean's implementation is 100% compatible with the native API. The insides are rewritten to Rust, so everything works faster, but for the end user, the API will not change.

    Same with the project I've been working on for the last couple of years. It is called Helix , and is associated with my experiments with Rust to create native extensions for Ruby. It was very difficult to start, because of the heaps of memory safety issues that had to be solved. Helix allows you to simply focus on writing code on Rust, he himself takes care of compiling it in a Ruby-extension.

    I think many people used JSON gem in Ruby. In fact, there are two different implementations of this heme. There is a pure Ruby implementation and a C extension that implements the same API. This is not noticeable, but if you write `require json`, then most likely the C version will be loaded. If the current platform is not supported, then it will be a ruby ​​version. But, again, the API in both cases is used exactly the same. The only difference is that the internal components for one of them are implemented in C, so it works faster. In addition to higher performance, there are no differences. This is the goal of all such projects - to be able to use Ruby, which we love, but to get the performance benefits of native code when necessary.

    It's great that Ruby will be faster. Although it is believed that the speed of execution is not too important for programs in Ruby, but I am sure everyone will be happy if productivity increases.

    For the most part agree. In general, it is. But, seriously increasing productivity, we will be able to do things that were previously simply impossible on this platform. As I said, I studied JavaScript because I wanted to write browser programs, but this cannot be done otherwise. I think the same is true for performance. I don't care if the code runs 20% faster. This is good, but it is not so important. But when the code runs 10 times faster, it opens up completely new possibilities.

    For example, if you are engaged in machine learning, you have to do a lot of complex calculations. Most likely, you will not be able to implement this in Ruby, because Ruby is too slow. But if there is an interface for easily interacting with native machine learning libraries, then you can work with ML even on Ruby. You can write code to orchestrate all processes with calculations on Ruby, with all its expressiveness and an ecosystem of gems. For me, productivity is a tool for bringing new features.

    This is absolutely true! I have struggled many times with the poor performance of Ruby programs. I had to write a lot of code in SQL to speed things up, transfer part of the logic to the database side, because it works hundreds of times faster.

    That's right, but I would rather move the problem code into native extensions, rather than rewriting it as microservice on Go or Haskell. I think it's good to be able to write as much Ruby code as possible, and move the performance-critical parts to somewhere that you can easily interact with in Ruby. The opportunity itself is beautiful.

    Yes, it should be faster and simpler, more efficient in terms of business objectives. No need to hire programmers with different skills and stacks, since everything can be written in Ruby. That sounds promising. What do you think about the future of Rails? Every year there are rumors that Rails is dying ...

    I am biased because I work for a company whose main product is a performance monitoring tool in Rails. Personally, I don't think they are dying, but Rails has definitely become more mature, “matured”. For many people in the community, this is something fundamentally new. Many of us joined the Rails and Ruby community when Rails was a hype. There was a lot of enthusiasm, a lot of innovations. Although many of our “innovations” were common things in other, more adult, ecosystems. Much was impossible then, because the ecosystem was still immature.

    It was a very exciting time. Every Monday I was looking forward to a new episode of RailsCasts. New hem every week. For example, this week we are creating PDF files, uploading a file next week, and then something fundamentally new, such as a bundler, for example, appears. It was a time of fresh ideas, exciting, everyone had a lot of energy. Many believe that Rails or Ruby is dying because these emotions are gone.

    And in my opinion, the ecosystem has simply matured and become more stable. We have already conducted experiments with 5 completely different ways of downloading files and we simply do not need to do this every week. In terms of emotions, I definitely miss those times. But I do not think that now it has become worse. You can say this: “OK, we went through all these adventures, tried different approaches, got lessons. And now we have chosen the best option that everyone will use. ” I think it's great.

    Part of me definitely misses the drive, the constant sense of change and progress that was in the Ruby community at that time. Now I see it in the Rust community. There I can experience the same emotions. Yes, in Ruby, the passions subsided. But in terms of performance and real work, everything is quite good. I understand that a person who likes to constantly learn new things, there is a need for such emotions. I search and find them in other ecosystems. The community is maturing, and there are fewer changes. But personally it suits me.

    I think this is a natural order of things, and Rails is still beautiful. All that happens is for the benefit of the real business that develops commercial applications. I like the fact that Rails allows you to use different approaches. For example, you can use trailblazer or dry-rb gems, while remaining in the context of Rails. You can use different types of abstractions in your code, but in the end it will still be a Rails application. This is what I like.

    I definitely agree with you. I think the whole ecosystem is growing up. At that time, which we now call the "peak" of Rails, many new startups appeared. No one worried about stability and stability. Then you get a constant influx of new emotions and energy. Now many of these companies have become large corporations, such as Github or Shopify, and have begun to take care of stability. This is true for many.

    As a community, we collectively decided to prefer stability to experiments. From a language point of view, there is still plenty of room for experimentation, because Ruby remains the same. The reason Ruby was great for experimenting has gone nowhere. However, the community decided to focus on creating things that run on Rails, because Rails has been actively used for a long time. When you write gems, you will probably support multiple versions of Rails, because there are many companies that use them. As a result, Rails themselves also become more cautious, not breaking their API unnecessarily. Personally, I am happy to be part of this process.

    From a business point of view, stability is very important. Especially for high load systems. The stability of the framework interfaces facilitates the work. I remember a time when it was very difficult to switch from one version of Rails to another. For example, at that moment, when the application began to throw out a bunch of errors due to incompatibility of encodings (encoding incompatible).

    Trailblazer is a great example that shows the current state of a community and ecosystem. On the one hand, the fact that it exists is pretty good proof that there is still plenty of room for experimentation in the Ruby community. But I think that if it came out 5 years ago, it would be much more popular, because now we have built a much larger ecosystem around Rails, with a lot of gems.

    After all, you care more about what you can do with a familiar stack. When you just need to write an application that can bill, make PDF files and use web sockets, many people will prefer to use what others are already using - in this case, you can share gems, discussions, find answers to StackOverflow, etc.

    In In this sense, we can say that part of the Ruby community has died. 5-10 years ago you constantly did new things, didn’t worry too much about compatibility, used new and coolest gems, because there was no “baggage” behind your back. Now most of the projects in the “baggage” community have accumulated decently. And those who love experimentation and innovation have moved into other communities and ecosystems.

    I think this is normal.

    I don't mind either. It looks like growing up, another stage of life.

    What do you think about static typing? Is there a prospect to get the benefits of this approach in Ruby?

    I look forward to it because I have already experienced the benefits of this thing in a JavaScript ecosystem with TypeScript. JavaScript is very similar to Ruby. It is a dynamic language with free typing, so it has a lot of flexibility, but even more runtime errors. TypeScript is an attempt to build a JavaScript type system, a superset of JavaScript syntax. When you compile code, the compiler checks the types, checks that everything is correct, and then simply erases them. When you remove all types from TypeScript files, you are returned to pure JavaScript.

    I see that this approach works surprisingly well. People have already built a whole ecosystem around TypeScript. I would really like to see the same story in Ruby. The genius of the idea is that TypeScript is a superset of JavaScript syntax, this is a new layer, it does not prohibit the use of anything from the JavaScript ecosystem. The programmer of the old formation can simply interact with the untyped version of the code. Other developers can get all the advantages of typing, just by looking at the typed version. But, ultimately, everyone will be able to call libraries in the usual way. Even if you use only standard JavaScript, you can benefit from the types, for example, using autocompletion, because someone has already done the job of adding types to the used JavaScript libraries. In my opinion,

    There is probably a way to do this in Ruby, without forcing anyone to do anything. People who like typing will do their job, and everyone will benefit from it, be it autocompletion in the editor, or simply knowing that the entire infrastructure, for example, Rails, contains fewer bugs, because inside it uses types, and that helps catch errors at compile time, not at runtime. I would really like to make this possible in Ruby.

    I totally agree. I think this will be a big step towards application stability. And it will make life easier for the juniors: they will have less chance to make mistakes. Now you need to be very careful with the name of the variables to make it clear what is stored inside them. When I write code, I have to very clearly express what type of value is expected in a variable, so that the person who reads my code will understand me correctly. If we have types, it will be easier.

    People who like types actually use them to document the code. If done correctly, TypeScript does an excellent job with this. It is read almost like self-documenting code. Even if you do not want to look at the typed code, you can see the JavaScript version. But due to the fact that someone has done the work on adding types, you can generate documentation for untyped code.

    I believe that the key point here is the separation of layers of abstraction. Some people are very enthusiastic about types, while others strongly dislike them. The TypeScript history shows that there is a way of coexisting and sharing these approaches. I'm a little worried about the direction in which types are moving in Ruby. I personally would prefer to find a way by which we can impose types on top of Ruby and allow two opinions to coexist with each other, rather than go for a bunch of compromises.

    A few years ago, Matts came to us at RailsClub. We, of course, talked to him about typing. I had a feeling that he was not too optimistic. Although, everything could change.

    I think that if Matts does not like types, I would prefer a way where Matts would never have to see them in the code, instead of trying to write them so that it is tolerable for him, for example, something like comments.

    I could be wrong, but I think that the idea of ​​the Matz is that it is easier to program with no types than with them.

    It really is easier for most, and in many cases for me personally. But in some types of programs, like in Rails, you are crossing the line. Without types, you have to store a lot of information in your head or in the documentation. At some point, this becomes too hard, especially for a project as large as Rails. I think that even for JavaScript there are applications where the advantages of types are not worth all their complexity. But there are huge projects, such as Ember, that have greatly benefited from using TypeScript. As I said, the beauty of the layering is that in the end, you still get JavaScript code. You can choose one way or another without affecting the other half of the community that does not share your ideas. At least my experience is exactly like that.

    What advice can you give to newbies? What will be the main direction in programming in the next 5 years?

    This is a huge topic, it can be discussed for a very long time. But I have 2 tips.

    First, instead of chasing the "mainstream", go for what interests you. Maybe I was just lucky, but it really helped. When I plunged into Ruby, I started looking for a job that would allow me to write on it. Since I was very motivated to learn more about Ruby, I started making commits in open source, and this helped my career later. This is the first tip. Follow what interests you. If you are motivated, the likelihood that you will do your job well is much higher.

    I described the second tip in detail in that article on Medium. You need a thorough approach to the learning process, because no matter what you do, learning is a key part of the job. I recommend finding good ways to learn more than you already know, move to those territories that you do not know, and figure out how to create and change thinking patterns for different concepts. Training is one of the key skills you must possess in order to develop in programming.

    I think higher education is important today. It gives people a deep understanding and basics that have not changed too much. The basic principles of a computer or database almost do not change. At higher levels, a lot of new things appear, but the basics are the same for decades. I think higher education is valuable. And you?

    I agree, universities are still important. I personally received a lot from higher education. At the same time I do not like the term "fundamentals". There is always something beyond the "basics" that you can learn. The main thing is to understand that there is always something deeper than what you know, and it is waiting to be discovered. And if you start digging it will probably help you wonderfully.

    For example, at university I studied many operating systems, compilers, etc. But I almost did not use this knowledge, because I worked mainly with Ruby. Most recently, I had to remember all this, because I started working on utilities that allow compiling Rust code into native Ruby extensions. It made me re-learn all these things. I should have known this already, but I forgot almost all the details. But I remembered the key concepts and knew that I needed to google. And, more importantly, the fact that I have already studied this material earlier has given me confidence that I can understand this topic. This is very valuable for motivation.

    In your opinion, how useful is it for a developer to engage in training and mentoring?

    I really like this topic and this is an important part of my work. Training, mentoring is an integral part of any organization, the basis of its culture. In programming, this is especially important because there is always something to learn.

    We in the company try to help people learn what they are interested in. For example, I am currently teaching a couple of colleagues Rust programming in the context of current projects. We want to rewrite more backend from Java to Rust. For the company, it is important that we have more people with experience in Rust. This is an investment, so we are making efforts for this. When a person in a company is interested in Rust - we are trying to figure out how to give him the resources and time necessary for studies.

    I believe that mentoring is a good way to learn. When you teach someone, you yourself learn to do it much better.

    I give Rust lessons every week, and every time I understand how much I don’t know about him. When I try to explain things that I thought I know, there is always something that I had no idea about. I spend a lot of time after each lesson to learn the material that I thought I already know. Excellent source of experience.

    By the way, I would like to thank you for posting "This Week in Rails" .

    Thank! I myself have no more time to write these letters, so now I don’t need to thank me. The guys who write them now know their stuff. And now, as a reader of the newsletter, I also really appreciate their work.

    I have received these letters for at least the past 2 years. It's interesting on Mondays to read what happened last week in the Rails community!

    It was very funny! I'm glad I started this project.

    Thank! Let's lastly talk about the conference. Stayed just a month before RubyRussia . What do you expect from a trip to Russia?

    I have not been to Russia and, frankly, I have no idea what to expect. But I think it will be very fun. I am very glad that I will come and I am sure that everything will be fine. What should I expect? Is there anything I need to be prepared for?

    Haha, among other things, we will have a great afterparty, last year's all remembered. A lot of things: conference, tours, and not only. It will be fun! The people here are friendly, and I am sure that we will have many interesting topics for discussion.

    I look forward to and very grateful for the invitation! I somehow never thought about visiting Russia. But now I realized that I should have done it before. I think I'll have a great time!

    I hope to talk in person at the conference.

    I look forward to!

    It was very interesting to talk! Thank you for your time! Have a nice day! See you in Moscow!

    We are also waiting for you at the conference! Ask your questions in person (and on the legendary afterparty :) will be October 6th. The program is here , and before the price increase remains about a week. Now the ticket costs 8,000 rubles.

    You can read the original in English at .

    And here is a place to thank the excellent companies that support the main Ruby event in Russia:

    General Partner - Toptal
    Gold Partner - Gett
    Silver Partners - Instamart , , JetBrains
    Bronze Partners - Bookmate and InSales

    Also popular now: