Interview with Godfrey Chan, RubyRussia Conference Speaker
Hello! On October 6, the RubyRussia conference will be held in Moscow - 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. This is 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'm 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 something 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 some 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 was 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 began, 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 job.
Do you use Ruby as your main tool now? Or work 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 of 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 really 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 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 quite 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 the sake of 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, this is great motivating.
For example, when I started working with Ruby, I was attracted to expressiveness. No other language is 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 they 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 do 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 chop processes, as happens if the pointers in C are mislabeled. Therefore, the main purpose of learning Rust for me was actually writing native Ruby extensions.
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 learn and program in are simply tools that allow me to create what I have in mind.
Very interesting! It's cool that ActiveRecord will become 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 heap of memory safety issues that had to be solved. Helix allows you to simply concentrate on writing code on Rust, he himself takes care of compiling it in a Ruby-extension.
I think many 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 Ruby programs, but I’m 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 parts that are critical for performance 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 Rails performance monitoring tool. 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 experimented with 5 completely different ways of downloading files and we just 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 has a need for such emotions. I look for 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 a 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, staying 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 over 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 experimentation 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 the 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 the 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.
In the end, 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 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 the 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 the JavaScript JavaScript ecosystem with TypeScript. JavaScript is very similar to Ruby. , , . TypeScript — JavaScript , JavaScript . , , , , . TypeScript, JavaScript.
, . TypeScript. Ruby. , TypeScript JavaScript, , JavaScript . . , . , , . JavaScript, , , , - JavaScript. , TypeScript JavaScript, , .
, Ruby, . , , , , , , , , Rails, , , , . , Ruby .
. , . : . , , . , , , , . , .
, , . , TypeScript . . , JavaScript . , - , .
, — . , . TypeScript , . , Ruby. , Ruby , .
, RailsClub . , , . , . , .
, , , , , , , , - .
, , , , .
, . , , Rails, . . - , , Rails. , JavaScript , . , Ember, TypeScript. , , JavaScript . , , . , .
? 5 ?
, . 2 .
-, , «», , . , , . Ruby, , . , Ruby , open source, . . , . , , , .
Medium. , , , — . , , , , , . — , , .
, . , . . , . , . ?
, . . «». - «», . , - , , . , , .
, , . . , Ruby. , , Rust Ruby. . , . , . , , , , , . — .
, ?
, . , — , . , .
, . , Rust . Java Rust. , Rust. , . Rust — , .
, — . -, .
Rust, , . , , , , -, . , , , , . .
, «This Week in Rails» .
Thank! , , . , , . , , .
, , 2 . , Rails!
! , .
Thank! . RubyRussia . ?
, , , . , . , , . ? -, ?
-, , , . : , , . ! , , .
! - , . , . , !
.
!
! ! ! !
! ( :) 6 . , . 8000 .
hype.codes .
, Ruby- :
— Toptal
— Gett
— Instamart , UCHi.ru , JetBrains
— Bookmate InSales
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. This is 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'm 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 something 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 some 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 was 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 began, 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 job.
Do you use Ruby as your main tool now? Or work 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 of 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 really 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 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 quite 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 the sake of 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, this is great motivating.
For example, when I started working with Ruby, I was attracted to expressiveness. No other language is 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 they 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 do 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 chop processes, as happens if the pointers in C are mislabeled. Therefore, the main purpose of learning Rust for me was actually writing native Ruby extensions.
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 learn and program in are simply tools that allow me to create what I have in mind.
Very interesting! It's cool that ActiveRecord will become 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 heap of memory safety issues that had to be solved. Helix allows you to simply concentrate on writing code on Rust, he himself takes care of compiling it in a Ruby-extension.
I think many 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 Ruby programs, but I’m 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 parts that are critical for performance 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 Rails performance monitoring tool. 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 experimented with 5 completely different ways of downloading files and we just 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 has a need for such emotions. I look for 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 a 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, staying 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 over 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 experimentation 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 the 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 the 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.
In the end, 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 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 the 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 the JavaScript JavaScript ecosystem with TypeScript. JavaScript is very similar to Ruby. , , . TypeScript — JavaScript , JavaScript . , , , , . TypeScript, JavaScript.
, . TypeScript. Ruby. , TypeScript JavaScript, , JavaScript . . , . , , . JavaScript, , , , - JavaScript. , TypeScript JavaScript, , .
, Ruby, . , , , , , , , , Rails, , , , . , Ruby .
. , . : . , , . , , , , . , .
, , . , TypeScript . . , JavaScript . , - , .
, — . , . TypeScript , . , Ruby. , Ruby , .
, RailsClub . , , . , . , .
, , , , , , , , - .
, , , , .
, . , , Rails, . . - , , Rails. , JavaScript , . , Ember, TypeScript. , , JavaScript . , , . , .
? 5 ?
, . 2 .
-, , «», , . , , . Ruby, , . , Ruby , open source, . . , . , , , .
Medium. , , , — . , , , , , . — , , .
, . , . . , . , . ?
, . . «». - «», . , - , , . , , .
, , . . , Ruby. , , Rust Ruby. . , . , . , , , , , . — .
, ?
, . , — , . , .
, . , Rust . Java Rust. , Rust. , . Rust — , .
, — . -, .
Rust, , . , , , , -, . , , , , . .
, «This Week in Rails» .
Thank! , , . , , . , , .
, , 2 . , Rails!
! , .
Thank! . RubyRussia . ?
, , , . , . , , . ? -, ?
-, , , . : , , . ! , , .
! - , . , . , !
.
!
! ! ! !
! ( :) 6 . , . 8000 .
hype.codes .
, Ruby- :
— Toptal
— Gett
— Instamart , UCHi.ru , JetBrains
— Bookmate InSales
Source: https://habr.com/ru/post/422925/
All Articles