Vladimir Dementyev: there's no need to write competitive programs by Ruby

Skilled coder shared his thoughts about Action Cable and usage of different languages for different projects
16 June 2017   2212

vladimir dementyev

Vladimir Dementyev

Evil Martians developer

At RailsClub 2016 he spoke about Active Cable.

We've managed to talk with Vladimir after his speech.

Please, tell us a little about yourself.

I came to Ruby not so long ago. About 4 years ago, I tried the Rails for the first time. I liked it, but the project I was working on did not use them. Therefore, I had a pause until the next reincarnation of the Teachbase, our startup. Teachbase is a SaaS system for study management, it allows you to create your own Coursera within a company or project. When I came, it was a terrible PHP project, and I hadn't a lot of experience. I was coding what they said. Then I got acquainted with the Rails and from the moment I became the CTO, I started to conceive the idea to write a new cool version of the system on advanced technology. This opportunity introduced itself in 2014, and then we completely switched to the rail stack in the part of the web application. Since then, I started to use Rails actively.

Rails Club

Biggest Russian Ruby on Rails event

How could you convinced ​​​the client to choose Rails? 

It is very easy - I am the client myself. I am one the founders of this startup, other two of my partners hadn't enough tech skills, so they trusted me. I hope they don't regret it. The choice of technology was on me. The only question was to find the time to swap technologies. Well, and money, of course. When the time has come, we have copied everything onto the Rails, and this third (or fourth) version of the system worked quickly, clearly, everyone was happy - both we and the customers.

Is it still online?

Yes, it's still running. We brought the project to a very good state, when making a new version makes sense not for technological reasons, but rather ideological. I don't know what guys plans for now. While they are engaged in supporting this system, selling. Everything is going well, the project is alive, working.

Teachbase is a pretty big project on the Rails. And it was Rails 4.1, we haven't migrated to Rails 4.2, although we planned. A year ago, the release of the 5th rail in the fall of 2015 announced, so we decided to move to Rails 5. Everybody knows what happened next. Another year has passed, the fifth Rails have already left, but now it is probably dangerous to migrate to it. It is necessary to wait for at least 5.0.1, and better 5.1, then you can go. We relied on the release plans of the rail development team, they didn't work, so our project is still hanging on 4.1. And there are no special problems with this.

You mean that project is finished on the tech side? And you only add something new when you understand that business needs it? 

Yes. There are plans to redo a large part of logic, and this is likely to be a new project on new Rails, and maybe not on Rails. We always had Erlang on our stack, since we were engaged in videoconferencing, accordingly, we needed a streaming service that would work with the RTMP protocol. It is necessary that people using flash technology (which everyone hates) can communicate in the browser, conduct webinars on a large number of people and so on. Backend for all this served as an erlang service, which budded off from a fairly well-known project Erlyvideo.

You took an open-source fork? 

Yes, it was open source, version 2.18. It happened in 2011. First, we just used it, then we began to open bugs and edit them, adapt everything to our history. And then Max Lapshin "closed" the code and began to develop paid version Flussonic. It wasn't a problem for us. So we had experience in Erlang, and we started doing some other minor services for the Erlang system. Our stack has found the second main language.

It's not easy to find good Erlang developer. That only Erlangist, who we had, came as a student, he knew C and knew mathematics well, he had an olympiadic past and he wanted to work. As an Erlangist, we brought him up from scratch. By the way, he still works in this project.

But wasn't able to find more Elixir coders, so earlier this year, when I was still working for Teachbase, we started a program of acquaintance with Elixir (both for those who programmed in Ruby, and for those who programmed for Erlang). There was a separate subproject, in which there were 2 developers: the Rubist and the Erlangist. They had to learn technology together, using each of their strengths. One better knows Ruby and its paradigm, knows Rails, which are similar to Phoenix in the MVC part. And the second person who knows Erlang, can handle Elixir too. The project has not been completed yet, but it is very interesting. We began to move onto this stack, rather because of its popularity, so it was easier to hire new employees.

Maybe you would like to migrate to Phoenix? Get rid of Ruby, and install Phoenix over Elixir? 

When we were thinking about the migration to Rails, there was an alternative option to switch immediately to Erlang. I was ready to do it. Probably we would have started longer, but probably it would be better in terms of efficiency. It's good that we hadn't done this: our loads doesn't require any creepy optimizations, and the Rails is quite manageable, and the development speed is much higher. Now I don't think that Phoenix can replace the Rails completely from the point of building business logic, the layer of working with data.

As far as queries are concerned, sockets (this is a separate conversation we will return to it) - with this in Phoenix everything is fine. But Active Record (or its alternatives) and the ecosystem around it is so much more convenient than anything Elixir has. It's logical, there's another paradigm, it's not so easy to make a tool that's easy to use. Therefore, in my opinion, Elixir and others, with Phoenix or without, are more likely technologies for the ideology of microservices. It is necessary to use them in some heavy part, in which many customers are "knocking" with some tasks and requests. Such parts can be written by Elixir, they can be solved by several different services. And the basic logic should, I think, remain in the Rails, if it was originally written on them. But even if I was starting the project from scratch, I would not do everything on Elixir anyway.

You talk about Teachbase and your role as CTO in it, as a past story. Now, as far as I know, you work for Evil Martians as a developer. Why did you move from management to development? More often people want to grow from developer to manager. Do you think this is a step back, or is it an intermediate stage?

First, for a long time I was in Teachbase the only developer. I started to recruit the team only in the last couple of years, when we had such an opportunity. The problem for me, as for the developer, was that I tried a lot, learned a lot, but mostly from my own experience. I've never worked in a team led by someone who was more experienced than me and had some knowledge that I didn't have. This was one of the reasons: I was bored, I realized that my own growth in Teachbase will go hard. Especially when the project stabilized, there were no super interesting tasks, only fluidity such as adding features, there was creativity.

I looked at the Martians in the first place, because I was familiar with some guys, I was on the Brainwashing course, since then I had the most pleasant feeling about this team. I really wanted to work with such people, share experiences, share my ideas. When I worked in Teachbase, I had no one to discuss any technical ideas, there were no people who would understand technical aspects. So I wanted to get into a strong team.

The fact that I had "power" in Teachbase, and now I'm an ordinary employee doesn't scare me. Probably. Although my wife says that after I stopped being a "boss", I try to manage houses a little more often. Compensate.

I like the lack of a hierarchy, you can talk to everyone calmly, argue, swear sometimes. I'm glad to be in this environment.

We've started to talk about Rails and long-awaited 5th version. For example, Action Cable, that you will discuss at the conference. What does Rails miss? 

I would ask another question - what is excess in Rails.

Great question. So, what would you throw away? 

The front part and assembly of assets using Sprockets, in my opinion, is an outdated scheme. The front is now being written with bundlers, there is a very developed ecosystem. This works, in my experience, much nicer than Sprockets. It's fast, convenient, lots of extra features, fine tuning and so on ... The same autoprefixer can be inserted into Sprockets. But if you add another 20 similar plug-ins, then Assets, most likely, will be assembled for a very long time.

I used the rail, mostly non-classical, with server-side rendering, using javascript templates and similar things to update the page. I mostly used the API mode, only JSON. HTML-pages were also driven by Rails, but there was an idea to get rid of this too, in order to load the statics separately, since there was at least minimum dynamic rendering, for example: inserting the logo "on the fly". All the features like Turbolinks should be separate gadgets to the Rails. If you like it - feel free to add.

At one time, Sprockets was a real breakthrough. Perhaps, now this technology is outdated, because the front-end is developing at crazy pace.

Because only Grunt was popular in front-end, awful and monstrous. For a long time it pushed me away from using all of this until a more pleasant alternative appeared. Let's talk about the current situation: if I've just started a new project and took Rails as a backend i would separate the development process for back-end and for front-end coders. It is very convenient from the development point of view. There is no need for a front-end coder to "lift" the server. Let him do frontal work on specification, which backend coders gave.

What technology would you use instead Rails? 

It all depends on a kind of project, of course.

Let's take Teachbase as an example. API, interaction on JSON. We throw out the Action View, throw out something else. Maybe you should use alternatives of Ruby, but not Rails. Or even another language?

Good question. If the question is like "anything else on Ruby" - then no. Firstly, I do not have enough experience. I tried micro-frameworks like Cuba, Sinatra. Just experimented and watched what's happen. I'm not interested in big alternatives, such as Trailblazer or Hanami. I still do not understand why I need it. Yes, I saw benchmarks, everything is cool, fast. But the Rails and rubies are chosen not in order to be fast, but in order to be convenient. Therefore, this argument is not the most important for me.

Yes, Hanami has one very big disadvantage: no one uses it.

Exactly! It is difficult to "fight" with Rails, which everyone uses, with it many begin their journey in Ruby. The real competitors to the Rails are now not inside Ruby. It's Elixir and Phoenix, which are gaining popularity. In my opinion, this is partly because Elixir has a good PR. It is being sold to the team. Even in Russia there are people already who use a hybrid stack - part of the Rails, part of the elixir. Everyone wants to try it. And most importantly, everyone wants to sell the development on Elixir to the customer. As a commercial project, Elixir is a very cool thing. It is simpler than Erlang, although personally I would still prefer Erlang. Yes, it will be a little painful, there will be more code in places, although it can be optimized.

If you answer the question "what if not Rails." I would choose Erlang, but only if I was given a couple of developers and a little more time. Basically, everything depends on the availability of coders: there are few. Elixir's problem: many who began to study it and wrote something on it, immediately feel that they know Erlang. It's about the same story as when people "poking" into Rails, then they say they know Ruby. Most likely, the market will suffer from this. Finding a good erlang developer will be even more difficult, because there will be a lot of "trash". There are similar problems now: people who have learned Angular, but don't understand what JavaScript is. Such problem is everywhere now.

We started talking about Ruby alternatives. You have a lot of experience with Erlang, you wrote in PHP, as far as I know, you still write on Go. What other languages ​​have you tried and which do you want to try?

Let's speak chronologically. In schools and university there were Pascal, C, Basic, Assembler. But at the university I missed programming, I really did not like it. I still wonder how I accidentally became a programmer. I started with ActionScript.

Is that flash?

Yes. I started with the second ActionScript, it was terrible. But in the third there were a lot of changes: normal classes, proxy objects, which are all so waited in JavaScript now (but so far there is no good support). A lot of everything is cool, comfortable. As a language he was funny. Main disadvantage is difficult compilation. If you don't have Adobe Flash Builder, you have to cast a lot of magic. I had a very large project in the framework of Teachbase, when we began to make our decision for webinars. It consists of two parts: client and server. In the server we used Erlang, and in the client - a large ActionScript application. This was my first big project, I was creating it from scratch, with a serious architecture, there were a lot of cool ideas. This application is still working. There are no bugs in it, I've checked it two years ago! Since then it works great. And it's very good, because I don't even know how to build it, run it and so on. I do not have any build systems, and I do not remember how everything works there.

Wait, the third ActionScript came out a long time ago, it's old. About 10 years. Is it developing at all?

Yes, he is very old, but still alive. Especially in the gaming industry, they made a lot of optimizations in terms of graphics, rendering, using GPU and so on. You can write great games using it. It seems that some of the popular online games, such as Tanks, was originally on flash. Now I do not know, maybe until now.

There was a period when these technologies were everywhere, when, for example, it was used to create all video chats, flash was everywhere. Now it is not enough. Flash used to implement what is now in the Web RTC, peer-to-peer. In the end, this project was abandoned. Initially it was called Stratus, we even did a side project on it - a portal for psychologists with the possibility of consulting online. It worked time to time. Now those webinars that work in the browser uses Web RTC, but in most cases it's not. flash, rtmp are still used for streaming.

I knew ActionScript very well, but now I wouldn't say that I'm an expert. And I do not plan to go back to it.

And now back to our question: what happened after ActionScript?

Then there was php. I don't remember what version there was, there were some issues with it.

And how did you get to know Rails?

It all happened by chance. There is such a wonderful Coursera playground. When it first appeared, there were about five courses, one of them was about SaaS development. This course, in fact, was such an introduction to Rails, then another 3. I can't say that I learned the Rails for this course. It was a very simple course, output of one page and the search from the database. But it was well told about testing, about all its levels. After that, I wrote a micro service for our system. Very scary, ugly, it was even launched through Rails s in development mode. But he worked, almost did not fall.

It's hard to say at what point I started studying and doing something. A strong impetus was the visit to Brainwashing. When I went there, I practically did not know anything about Rails. And on the course got a kick, let's just say. Sat down and began to develop.

Can you say that Ravil and Gazai had a big influence on you?

Yes, they did. If we continue to talk about languages, next was Erlang. Sometimes now I use Golang for different things. The language is quite simple, you can choose it if you need to "sketch" something quickly. It is compiled into an executable and can be used. I also did a lot of front work, now less.

You don't want to do the front-end? Go to the dark side.

Good question. Probably not. I'm not very good fronetend dev, because I'm not very strong in everything that concerns styles, layout and other things. Especially with the new muddies: some CSS modules, CSS 4, everything changes very quickly, I do not have time to follow it. I've never liked it, I always thought the layout was work for someone else.

Almost always we gave it to outsourcing. We've got a code, we integrated it.

Once I suggested not to suffer, and do it yourself. Thanks to Andrew Sitnik, who gave some vector. And I started to do a lot of frontend coding. As a result, in Teachbase, the main logic on the client is the framework I've wrote. We started before React became popular, Angular was not very popular yet, but it already existed. I decided that I could write faster myself. I knew how JavaScript works, and did not want to spend time figuring out how Angular works. I never regret it, because Angular worked horribly in the first version.

How do you participate in open source? Are there any projects that you would like the guys to pay attention to?

Again, I've advertised Brainwashing. Open source for me started there, I made my first commit on the OS. As part of the course, the guys came across a bug in pry-byebug, which was extensible in C. I found it, fixed it, sent it and got my first pull request, got pleasure from it and got a bit hooked. I started doing this.

If we talk about other projects: I worked a lot on Rubocop, this is Bozhidar Batsov's project. I really like this project and the whole idea that the code should be stylized. I propagandize it everywhere.

But you don't use the default rubocop's configuration?

Of course, I always have something right there.

Do you have the existing settings that you always use or each time you need to negotiate with other developers in the project?

Differently. Now I, for example, came to the project with a large code base and we screwed the mandatory check by rubocop, but we had there very minimal config that checks for very bad things, such as a forgotten debug in the code or focuses in the specs and so on. And we also have several optimization cops. Things like the length of a string, the number of lines in a method, and so on, we don't check in this project.

And are you a fan of 80 characters, 120 or just turn off this check?

I support this topic, usually I put 100. This number was obtained by experience: I worked for a long time on a 21-inch iMac and developed with splitscreen. I did so that all parts of the screen included all the lines. That's about 100 characters. The logic of choosing the length of the line was such because the horizontal scroll is very inconvenient.

About the length of methods or the length of the class ... no.

The comment at the beginning of the line, enter at the end ...

I always put an empty string at the end. I do this because it's so convenient to go to the end of the file. There is some indentation from below, you do not need to get to the border of the display. I read somewhere, what historical limitations this rule was caused, in some old systems. I do not exactly remember what was there. And now the GitHab constantly highlights this in the diff, "swears" when you do not have an empty line - it's not very pleasant.
In my default config on the zero project much is included, but these parameters of complexity are a little increased. Sometimes I just disable this cop locally, and that's it. But in all the hems that I deal with, or in which I actively contributed, I introduced this matter.

What other projects should I pay attention to? Which ones did you take part in?

I worked a lot on projects from the InfluxDB ecosystem. This is a database for time series. It's an interesting project, now it's grown in InfluxData, they have their own stack. It's something like a stack from Elasticsearch, where you have a log collector, a visualizer, the base itself, but it's for some time metrics. I started using it in Teachbase, it was not very well known then, it was about a year and a half ago. Their story is very similar to the story with Rails 5: there was version 0.8, they promised to release next month, more stable and with bugfixes. It was rather risky to use a not ready story, a couple of times everything was very scary. But in the end, the promised version came out, like Rails, only at the beginning of this year. We lived a year on an unstable version, we had to work with it after all.

One of my big open source projects is known to those who worked with this database. I wrote an adapter for this database in the style of Active Record. The project is called Influxer. It is very similar to ActiveRecord: you define a certain class, tell what attributes it has (these are the attributes of these labels in the database), and it allows you to make queries, such "syntactic sugar". InfluxDB supports a SQL-like language, and instead of writing on it you can use this wrapper. It's convenient, there are some fiches, links to models and so on. It was actively used in Teachbase, for which it was done. I still continue to support it, in connection with the release of new versions of the database and the changes in API, it is more or less relevant. The project someone uses, there are several tens of stars.

In addition to Influxer, I was involved in other projects for this ecosystem. Until some time, all the code was open, the base itself and all the secondary services that were used there. This year they introduced a commercial option.

Part of the code, of course, is no longer in open source, especially as far as clustering is concerned. All the rest is open. Everything is written on Go, it was my first go experience. I did a couple of patches in a project called Telegraf: it's a log collector, something like Logstash or new beats from Elasticsearch. The project is very actively developing, to a stable version far. If you want to try go and participate in open source, know that it's pretty easy to do pull request.

Tell me more about Thinknetica. You are a mentor there, what does it mean? What kind of experience did you take from there? How many people was taught?

Yes, I like the word mentor. Earlier we called each other mentors, but it somehow is not in Russian. I have been working there for 1.5 years, but with interruptions. We take a group, we teach them, then we take a break and so on. I taught like 50 students, maybe a little more. 20 percent of them are very classy guys who have been well employed after the course. Many of the graduates are then arranged for profile positions, but I do not really follow it. When you teach fairly simple things (we do not teach anything complicated), it broadens the horizon, prevents the eyes from getting soapy. You see different code of very different people. You see different mistakes, first of all. It doesn't allow you to dry out.

Tell me about what you will report at RailsClub?

Let's go back to the spring of 2015. Some time before the conference was held, at which DHH announced this wonderful feature.

Is this really a great feature for you or such a "great feature", in quotes?

I have an ambivalent attitude towards it. In any case, this is a great feature.

In Teachbase we used websockets. Naturally, they were supported by the Erlang, because it was our stack. We had plans for tight integration of the service, which processed data from web sockets, with a rail. We had our own idea (it is implemented, laid out in open source and works), how to make Rails with sockets. And now, in March or April, Action Cable comes out. I watched the video, watched the examples. The first impression was: "Wow, wow! It's cool, it looks very cool, convenient, beautiful - just what I would like to use. " This was an additional argument to not migrate to 4.2, but wait for Rails 5 to make something new using the Cable.

I really liked how everything was done. But there was a second thought - what technology it will use? I had this thought when the repository of the cable in the source code was separately placed on the Githab. Then it worked on Celluloid, if I remember correctly. That was implemented in Ruby, which is not cool. I have an opinion that there's no need to write competitive programs by Ruby. This is not what this language was designed for, especially when it comes to scalability and efficiency.

Then I had an idea to take good from Action Cable and good from implemented in the service on Erlang. And there was already a lot of things: horizontal scalability, various authorizations and so on. Then I did not know about Phoenix yet. As it later turned out, it was very similar to Phoenix. But only done on a live Erlang. Although in fact inside all use the same Cowboy as the Erlang web server.

For the year in the cable, of course, there have been a lot of changes. All of them, perhaps, are positive. First, we got rid of Celluloid in favor of nio4r. Many different synchronization possibilities, adapters and others were added. But the basic problems didn't go away quickly. Just recently there was a sensational bug with leaking memory, non-closing connections. Oddly enough, it arose after the 5.0 release. Still hangs a few bugs related to performance. All this shows that Action Cable is not suitable for production in any large system. This is not the tool that can solve the problem.

What kind of problems can Action Cable solve?
We all know that all the innovations in Rails appear for the a single well-known project with the letter B. I checked that Action Cable is actually used there.

Or maybe it's not Action Cable at all?

Maybe. At least, the protocol of the web sockets is signed as ActionCable. The protocol is very similar. Unfortunately, there is no insider information. But I would not be surprised if there is actually some server running there that just works on the same protocol, it can communicate with the rail, although in fact for what they do, it's necessary. It literally does two scenarios: sends changes that occurred on the page (someone wrote a comment, sent a task, and so on). This is a Broadcast, the first scenario. Second which sends information to the server from the client about what the person is doing on the page. It is transmitted in encrypted form, but there is roughly the following: moved to the page or closed the tab, some activity tracking.

They have all this not very loaded?

Yes. And in this case Action Cable is enough. And on the other hand, the question arises: why is there a Rails? I see the only point that is exactly used there, it's authentication. We need to somehow confirm the right person is connected to the socket, subscribed to a specific channel and so on. Here they probably interact with the application. Everything else has little to do with business logic. I did something similar, I just had web sockets used for tracking activity. All these data weren't written to the main application. They were written in a separate system, they were already processed and then stretched out when needed. In this context, it's not very clear: do you need Action Cable there or not? Is it used or not? But if it looks like Action Cable, maybe it is it. I don't know any more real examples. And I think, there are no known projects that use Action Cable. Probably, many people want to use it, but the question is in scope. It is very good at what Rails are good - quick MVP assemble, to show someone the first version of the project. Everything is boxed, sketched realtime and works. But when business grows, and there are customers, load and so on - what to do with Action Cable? You can, in principle, produce instances, it is rendered separately, as some background Sidekiq and other side services that we have in the application. But I do not know how effective this is, as long as I have big doubts on this score.

So you would ask Matts a few questions?

Honestly, I have no questions for him. I would listen that he will answer the questions of others, usually I do so, I rarely ask myself. At the last conference, I talked with you, after a report on microservices (by Andrei Deryabin, a leading podcast). And talked a little with Claudio. Even on the last RailsClub, I learned about Crystal, it's quite interesting, I'm now following this project. I'm thinking about how to apply it somewhere, write on it some extension for Ruby, there is such an opportunity. Any bottleneck, maybe even in the project that I'm currently working on. Waiting for a free day to figure out and play around with this affair. Let's see what awaits us.

RailsClub conference on which we managed to communicate with Vladimir will take place this year in Moscow 23th of September.

Get your ticket here.

G. Chan: "Ruby Ecosystem Has Stabilized & Matured"

Interview with Godfrey Chan, Rails core team alumni, developer at Tilde Inc. and speaker at RubyRussia 2018
06 September 2018   2716

Godfrey Chan is a Rails core team alumni. He currently works at Tilde as an in-house Canadian, splitting his time between building Skylight, Ember.js and evolving the JavaScript language at TC39. In his previous life, he was also an award-winning WordPress plugin author. He will be one of the speakers at Ruby Russia 2018 conference, which will take place in Moscow on 6th of October.

Godfrey Chan
Godfrey Chan

Meeting the speakers before the Rails conf has already become a good tradition. This year the conference name has changed, from now on it is called RubyRussia. As always we are preparing the interviews with the speakers to give our attendants the idea who the speakers are and what to expect from the event.

That's very cool. I'm very happy to be here.

I've prepared some questions as I’d like to know more about your speech and your presentation. Let’s get started!

I don't want to give too much away. The title of my speech is ‘Dropping down to the metal’. It's basically about writing some weird code in Ruby using metaprogramming to make something that looks like JavaScript run in Ruby. Of сourse, we won’t be able to write a full-fledged JavaScript parser and executive environment, but you will see some tricks (as in magic tricks/illusions) that makes a block of JavaScript-like code run in Ruby, using the native Ruby runtime. It's fun to do that, at least for me it was fun writing that. It is also the same techniques you use to write something like rspec, rake or other DSLs in Ruby. You will also get a good understanding on how Ruby parses your code and also how Ruby runs your code, and what hooks are available. I think it will be pretty entertaining but also it can teach you something useful about metaprogramming and Ruby.

Ok, so, there's gonna be some practical advice, right?

I don't know if I would spell them out explicitly in the talk, but I do believe you will walk away with something useful in that half an hour.

Alright, great! I think it will be interesting both for the experienced Ruby programmers and the newcomers.

I certainly hope it will. I will try hard to do that.

Great! By the way, yesterday I’ve read your article on Medium. It is from your keynotes, rethinking computer science education. It was very interesting, and I basically agree with your thoughts about the difference between the classic university education and the modern coding courses. So.. why did you decide to become a programmer?

I was in a fortunate situation, I didn't really decide to become one, it was always a kind of interest, a hobby for me. I really liked tinkering with computer stuff at young age and, at some point, there were only so much you can mess around with by deleting random system files and modifying the Windows registry. At some point, the natural progression was to realize that I wanted to teach the computer to do more things for me. The way things  started was when I took an after-school class for making websites in elementary school. That was pretty cool, you could create things on the computer. But soon I realized that it was pretty limited. You could create a choose-your-own-adventure game with hyperlinks and stuff, but I wanted to do something more interesting. My teacher gave me a PHP book. I read the whole book and, wow, suddenly that opened up a whole new world of possibilities on top of what you can do with just HTML and CSS. That was pretty cool and from there I started reading more and more books as a teenager. Next language I learned was Java. Eventually, I saw Rails in a Linux magazine. I thought it would be cool to learn it. It kind of snowballed from there.

So, you’ve moved to Ruby, right?

I discovered Rails around the time I started my Computer Science degree in college,  so at the same time I was also doing Java, C++, Haskell, etc. I was exploring a lot of languages. I never got to do any Ruby at school and I really enjoyed my time writing Ruby, so I kept trying to sneak Ruby into the more open-ended assignments at school, especially in the upper-division classes where they don’t really care what languages you choose. So yea, those were my chances to write Ruby during school, other than my side projects. Since I didn’t have much opportunities to do that at school, as soon as I finished school I decided to look for jobs where I could do more Ruby. It was a good time for that anyway because Rails was at its peak. A lot of startups were using Ruby and Rails, so it wasn’t difficult to align my interest with work.

Do you use Ruby as your main language now? Or do you work with other languages on a daily basis?

With my current job at Tilde I actually don’t write as much Ruby as I used to. I would say my job is a mix of JavaScript/TypeScript, Rust, Ruby and occasionally some Java, but all the work I am doing is related to Ruby in some ways.

For example, our main product at Tilde is Skylight. Not all components in Skylight are written in Ruby. For example, the frontend is written in JavaScript with Ember, the backend is written in Rails but the data-processing pipeline is Java and Rust. Even though not all the code I write is in Ruby per-se, Skylight itself is intrinsically about Ruby, since it is a performance monitoring tool for Rails apps. So in that sense, all the work I'm doing are still related to Ruby.

I see. Actually, I've registered in Skylight a few days ago for one of my projects, so I am testing it now. It looks interesting and it’s quite clear from the beginning. I haven’t digged too much in, I hope to do it next week. I hope it will help me to fix some issues.

If you have any feedback, it would be great to hear it!

One of the most interesting questions is how you would compare Ruby with the other languages. For example with Rust. Ruby is very expressive. It is created to make the program readable. If you compare it with Python or with C++, C# or Java, they’re not so easily readable as Ruby, in my opinion. What do you think?

I would agree with that. There are two ways I “learn” new languages. The first way is pretty superficial, where I look at the language, learn the syntax, play with the examples and then I pretty much forget about it. That’s what I did with Go. It took a weekend and then I spent another week or two writing different projects. But it never stuck, I didn’t have many reasons to keep programming in Go. I was just learning it for curiosity sake.

On the other hand there are those languages that stuck around for me, like JavaScript/TypeScript, Rust and Ruby. It's really about unlocking some possibilities that I didn't have before and that’s the intrinsically exciting and motivating thing for me.
For example, when I’ve first found Ruby, the thing that really attracted me was the expressiveness. No other languages gave me the possibility to do such crazy things as method_missing. I think that metaprogramming, expressiveness and code readability are really the key things that drew me to the language. I wish that other languages that I'm using are more like that.

At the same time, the other languages I use added some new possibilities for me that were impossible with Ruby. JavaScript is a pretty obvious example. I did not intrinsically like JavaScript that much, it’s not like Ruby where I fell in love at first sight. JavaScript came on my radar by necessity, because I needed to write code that runs in the browser. For better or worse, JavaScript is the language you have to use for browser programming. If you want to write an interactive browser app like Skylight, and that was something I was interested in doing at the time, then JavaScript is really the only way.

So my focus with JavaScript is to bring some of the ideas I liked in Ruby into this environment which is why I ended up working on things like Ember. That, in turns, brought me to TypeScript, because when you are writing a huge framework like Ember in JavaScript, having types and a compiler to check your mistakes actually helps a lot. That's what JavaScript and TypeScript unlocked for me.

Finally, the things Rust unlocked for me were quite similar to TypeScript. It is very satisfying to be able to compile the whole program and have the compiler assure you that things are correct. That’s fascinating for me. I’ve used other compiled languages before, like Java and C. You have to go through the process of compiling your code but you don’t really get much out of it, because the type system in those languages are just not very good at catching mistakes. But in Rust, the compiler can guarantee your program is memory-safe and you can be sure that you won’t get a segfault in runtime, and that’s a powerful thing. One of the trickiest things about programming in C is this kind of memory-safety issues, which is very difficult to avoid. The main thing Rust unlocked for me was the ability to do low-level programming without having to worry a lot about memory-safety.

Interestingly, the way I got into Rust was actually related to Ruby. At the time I just started working at Tilde and I knew the Skylight gem was written in Rust, so I was thinking that it would be cool for me to learn how to write a native extension for Ruby. I wanted to learn Rust and not have to worry about crushing peoples’ Ruby processes because I didn’t dereference a pointer correctly in C. So the main purpose for me to learn Rust was actually to write native extensions for Ruby.

That has been a main line of work I’m doing with Rust. Just this morning I was working on a project with Peter Wagenet, who works at Tilde and Sean Griffin from Shopify and the Rails team. Sean is working on a drop-in replacement for Active Record that’s written in Rust to speed up some of the slower parts. So just before this interview, I was working a Rust project called libcruby-sys that allows you to write those kind of Ruby native extensions in Rust.

So, in the end, they are all connected. At the end of the day, the languages I learn and program in are just tools that allowed and enabled me to build things I wanted at the time.

It is very interesting. Especially because it seems that the ActiveRecord will be much faster in the future! As far as I understand, the idea behind the new ActiveRecord is the same. I mean it will still be an ActiveRecord. Not something like a Data Mapper.

To be clear, Active Record, the Ruby implementation, is not going anywhere. That’s still the main implementation that’s being actively developed. That’s still useful. If you are using JRuby that’s still the way to go. What Sean implemented is 100% API-compatible;  it’s just re-implementing the guts in Rust, which does the same things faster internally but keeping the same API from the end user’s perspective.

This is connected with a project I’ve been working on for the last couple of years. It is called Helix and it traces back to my journey of learning Rust to build Ruby native extensions when I first joined Tilde. It was really difficult to get started, and there were a lot of safety issues to consider. Helix allows you to just focus on writing your Rust code and Helix will take care of compiling that into a Ruby extension for you.

You’ve probably used json gem in Ruby. There are actually two different implementations of this gem. There’s the pure Ruby implementation and the C extension version which implements exactly the same API. You may have not noticed this, but when you say require json in your code, you’re probably using the C extension version, unless you are on an unsupported platform, in which case the pure Ruby implementation is used. But again, the way you use its API is exactly the same. The only difference is that the internals for one of them is implemented in C, so it runs faster. You get the higher performance. But otherwise, as a user, you don’t really notice the difference. That’s the goal of all these projects – to be able to use the same Ruby we all love to write on, but get the performance benefits of native code when you need it.

It sounds great! Ruby’s going to be faster. But I think that the speed of execution is not too important for the developers who use Ruby. But although everybody tells that it doesn't matter too much, they will be happy to have the better performance of their programs.

I totally agree with you for the most part. You don’t care and you shouldn’t care. My angle on performance is enabling use cases which were not possible before. Like I said, I learned JavaScript because I wanted to program the browser and that wasn’t possible without JavaScript. I think the same thing is true for performance. I don't really care that your code runs 20% faster. That’s nice, but that’s not intrinsically what I care about. What I really do care about is if your code now runs 10 times faster, that enables you to build things that were not previously not possible.

For example, if you’re interested in machine learning, that involves a lot of heavy number crunching and you might not be able to implement that in Ruby because Ruby is just too slow. However, if you have a way to easily interface with a machine learning library written in native code, then you are able to explore machine learning in Ruby, because when you make those calls you are actually running native code that is very fast. You can still write the code that orchestrates all the machine learning processes with Ruby, with all of its expressiveness and the RubyGems ecosystem. For me, it's really about enabling things that were not previously possible to do in Ruby before.

That's absolutely true! I’ve been struggling with the issues when Ruby programs worked very slowly many times. So I found myself writing a lot of SQL code to speed them up. I’ve moved some logic to database queries because they work, like, 100 times faster.

Right, I would much rather move the hot code into a native extension than to reimplementing it as a microservice in Go or Haskell. I think that it's good to be able to keep as much of your code as possible in Ruby, only move the performance critical parts somewhere else where you can still easily interface with in Ruby. That’s the beauty of that.

Yes, it should be faster and easier. It should be more productive in terms of business. You do not need to hire programmers with different skills and languages since everything can be written in Ruby. That sounds promising. What do you think about the future of Rails? Every year there’s a lot of rumours about that Rails is dying...

I am probably biased because I work for a company whose main product is a Rails performance monitoring tool. I personally don't think that it is dying, but it's definitely maturing. For a lot of people in the Rails community that’s an unfamiliar thing. A lot of us joined Rails and Ruby community when the Rails was the new hot thing. There were a lot of excitement and innovations going on there. Though, a lot of the “innovations” were just us trying to figure out how to do certain things in Ruby and Rails that were pretty common in other ecosystems. We weren’t able to do it because the ecosystem was so immature at that time.

That was definitely very exciting time to be around. Every monday I would be super looking forward to watching the latest episode of RailsCasts. You learn about a new gem every week. For example, one week there is this new gem for generating PDFs, next week there is yet another new gem for handling file uploads, and then there are even big paradigm shifts like bundler coming into the scene. Those were great innovations and there were a lot of excitement and energy, and a big part of the sense that Rails or Ruby is dying is that we just don’t have a lot of that anymore.

In my opinion, that is because the ecosystem has stabilized and matured. We already did the experiments of having 5 completely different ways of handling file uploads, maybe we just don’t need to do that every week anymore. Emotionally, I definitely miss those times. At the same time, I don't think this is a bad place to be in. It's good to be able to say: ok, we have been on those journey, tried different approaches, learned the lessons. And now we’ve chosen the best option that everyone uses. I think that’s great.

A part of me definitely misses that energy and excitement and constant feeling of change and progress at that time in the Ruby community. Personally, I’m finding a lot of that in the Rust community. That’s where I'm getting the excitement. I agree that the Ruby community is dying in terms of excitement. But in terms of productivity and real work - that’s not a bad thing at all. I understand that for a person who likes to be learning new things constantly there is a need for that. As for me, I am doing exploratory work in other ecosystems instead of Ruby. The community is maturing and things are not changing so much anymore. But personally, I’m ok with that.

I think it's a natural way of things and Rails is still great. It’s very useful for real business that develops commercial applications. Actually, one thing about Rails I like  is that you still can use different approaches if you want to. For example, you can use trailblazer or dry-rb gems. You can use different kinds of abstractions in your program but still stick with Rails. That’s the thing I like about it.

I definitely agree with you. I think that the whole maturity thing comes for the whole ecosystem. At the time that we would call “the peak” of Rails, a lot of users were starting to build new startups and new projects. No one really cared about stability. That’s when you get constant influx of excitement and energy. Now a lot of those companies have turned into big companies like Github or Shopify, and now we care about stability a lot. That’s true for a lot of us in the community.

As a community, we just collectively decided to favor stability over experimentation. From the language’s perspective, there’s still just as much space for experimentation, because Ruby is still the same language. The reason that Ruby was great for experimentation back then is still true now. However, the community have decided to focus more around building things that work for Rails, because Rails is heavily used already. When you write a gem, you would probably support a few Rails versions, because there are a lot of companies which use them. As a result Rails itself also becomes more conscious about not breaking its API unnecessarily. Personally I'm happy to be a part of that process.

That’s very nice in terms of business to have stability rather than experimentation. Especially, for high loaded programs. The stability of interfaces and frameworks is very important. I remember the times when it was extremely hard to move from one version of Rails to another. For example, it was like that with an issue with encoding incompatible exceptions.

I think trailblazer is a good case study for the current state of the community and ecosystem. On one hand, the fact that it exists is pretty good evidence that there’s still a lot of space for experimentation in the Ruby community. However, I do think that if trailblazer came out 5 years ago, it could have been much more popular, because now we’ve already built a much bigger ecosystem around Rails with a lot of gems.

At the end of the day, you care more about what you can do with a programming stack. What you need to do is to write that app that knows how to do invoicing, PDFs, websocket. A lot of people in that part of ecosystem just prefer to work with something that is maximally compatible and on the same path as other people, so you can share gems and conventions, find answers on StackOverflow, etc.

Maybe in that sense, a part of the Ruby community has died. The part of the ecosystem from 5-10 years ago where you are building new stuff all the time and not have to worry too much about compatibility, and just wanted to use the latest and greatest gems because you did not have too much baggage. Now as a community, we just have a lot more baggage. That part of the ecosystem that likes a lot of experimentation and innovation may have moved to other communities.

I think it's ok.

I'm ok with that too. It’s like growing old, it's like a different stage of life.

What do you think about static typing in Ruby? Like a possibility to gain advantages of that approach in the Ruby?

I'm very excited about that because I have experienced the benefits in the JavaScript ecosystem with TypeScript. For those who are not familiar with JavaScript it is very much like Ruby. It is dynamically and loosely typed so you have a lot of flexibility but also a lot of runtime errors. TypeScript is an attempt to give JavaScript a type system in a way that basically just exists as a layer on the top. So it’s basically a superset of JavaScript syntax. When you compile your code, you compiler checks the types to make sure that everything is correct, then it just erases all the type. When you delete all the types from TypeScript files, you’re back to pure JavaScript.

I think that approach works surprisingly well with JavaScript. Now people have built a whole ecosystem around TypeScript. I would love to see the same story happen for Ruby. The genius of that is because TypeScript is a superset of JavaScript syntax, a layer on top of JavaScript, it didn’t take anything away from the JavaScript ecosystem. If you are a JS programmer, you can just interact with untyped version of the code. People who work on projects that will benefit from having the type can look at the typed version. But ultimately,  everyone will be able to call the libraries in the same way. Even if you’re using JavaScript you get some nice things like autocompletion because someone did the work to produce the typings for those JavaScript files. So in my opinion, the whole TypeScript thing is a big win for everyone in the JavaScript community whether you use it directly or not.

I think there is probably a way to make it happen in Ruby too, where no one is forced to do anything. The people who are enthusiastic about types will do the work and everyone will benefit from it, whether it is about getting better autocompletion in the editor or just knowing that your framework like Rails is less buggy because internally it uses types, which helps you catch bugs in the compiler rather than at runtime. I would very much like to see that layering made possible in Ruby.

I completely agree. I think It will be a big step to the stability of applications. Actually, it will be easier for juniors. They will have less chance to make errors. Now we need to be very careful about the variable naming to provide the idea of what is stored inside the variable. When I write a code I have to be very expressive about what type of a value is expected in this or that variable to give an idea for the next person who will read my code. If we’ll have the types, it will be easier

I think that for people who like types, they are basically executable documentation. If it’s done correctly, TypeScript does a very good job of that. It reads naturally as a self-documenting code. However, even if you don't want to look at the type code, you can look at JavaScript version of the same code which is again, in the case of TypeScript, exactly the same code, just without the types. But thanks to someone who actually did the work and put annotations there, you can actually use those annotations and generate documentation for the untyped code as well.

So, I think that the layering there is really important. Some people are very enthusiastic about types and some strongly dislike them. The TypeScript story shows that there’s really a way for those different approaches to co-exist and benefit from each other. I'm slightly nervous about  the direction that the types in Ruby is going. I personally would rather find a way where we can layer types on top on Ruby and let two opinions co-exist with each other rather than making a lot of compromises.

We had Matz couple of years ago at RailsClub in Moscow and we obviously talked with him about the typization. But I had a feeling that he was not too optimistic about that. But certainly his mind could change some day.

I think if Matz dislike types, I would much rather find a way that Matz would never have to see the types, rather than trying to writing them in a way that he would tolerate, like in doc comments. If that makes sense.

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

That’s totally true for some people, and I think that’s even true for me most of the time. But in some types of the programs, such as a big framework like Rails, at some point you cross the line. Without types, you have to keep that information in your head or in documentation. At some point, that’s too lousy for big codebase like Rails. I definitely think even for JavaScript there are code bases where the benefits of types are not worth it. On the other hand, there’re also big code bases like Ember that really benefited from having TypeScript. As I have already said, the beauty of the layering is that in the end of the day you are all still writing JavaScript, you can choose one or another without affecting the other half of the community that doesn’t like types a lot. At least that’s my experience.

Thank you. Let’s change the topic a bit. It is just a month until the RubyRussia conference starts. So what do you expect from coming to Russia? Have you ever been here before?

I haven’t been to Russia and, honestly, I have no idea what to expect. But I think it's gonna be really fun. I'm really excited to visit Russia for the first time. I'm sure it's gonna be good. What should I expect? Is there anything I should have prepared?

Haha, at least, we will have a great afterparty! Everybody have really enjoyed it the last year. There will be some activities during the day, an excursion and so on. You will have a lot of fun. The people are friendly here, and I’m sure we will have a lot of interesting topics to discuss.

I definitely look forward to all that. I'm very thankful to you for inviting me to your conference. It wasn't really on my mind to visit Russia. Now I’ve realized that I should have done it earlier. I think I will have great time! I am looking forward to it.

You're welcome!  What advice can you give for newbies? What will be the mainstream in the programming in the next 5 years?

This topic is really huge and requires much more time to discuss. But I have 2 advices.

First, instead of chasing after the “mainstream”, chase what interests you. Maybe I was just lucky, but that worked very well for me. When I was into Ruby I started looking for a job that allowed me to do a lot of Ruby. Because I was really motivated to learn more about Ruby, I eventually learned to make open source contributions, and that helped my career after. That’s the first advice. Chase your interest. If you are motivated, the chances that you will do a good job is much higher.

The other thing is basically what I said in the medium article you mentioned. It is to be more conscious about how you learn, because no matter what you do, learning is really the key part of the job. I recommend finding good ways to learn beyond what you already know, going into territories that you’re not familiar with, and figuring out how to build and correct mental models for different concepts. Being conscious of the layers you are building on is really one of the key skills you should have in terms of navigating the programming career.

I think that the higher education is very important even now. It gives people deep understanding and the basics which haven’t changed too much. The basic principles of how the computer or database works are not changing much. There are a lot of things happening on higher levels. But the basics are still the same for decades. I think the higher education is valuable.

I would agree that university still has a place and is still very valuable. I personally benefited a lot from it. Though I do not like the term ‘basics’. There is always something more ‘basic’ that you can learn. The key thing is to realize that, that there’re always more things sitting underneath what you know, waiting to be discovered. If you do learn it, it will probably help you in surprising ways.

For example I've learned a lot of operation system, compilers and such at university, and I did not use it too much since I graduated because I was working primarily with Ruby. Until recently, when I had to remember all of that, because I was working on a toolchain that lets you compile Rust code into Ruby native extensions. That forced me to re-learn those things on the spot. Even though I supposedly learned those things in school, I already forgot all the details. However, I roughly remembered the key concepts and knew what to google. And what was more important, is the fact that I already learned this stuff in school gave me the confidence that the topic is approachable and learnable. That part is super valuable. It gives me a motivation that I need to solve the problem.

In your opinion, is it a good idea to do more mentoring while you are a programmer?

That’s the topic that I'm quite enthusiastic about. Teaching and mentoring is intrinsic part of any organization. In programming, it’s especially important because there’s always so much to learn. It is a part of my job now to learn how to be more effective at teaching and mentoring. Like everyone else I’m still learning to do that myself. It’s important to get it right. I appreciate it. The culture of learning on the job is very important.

At my company we try to make it easy for people to learn things they are interested in. For example, I'm currently mentoring some people at the work to help them to learn Rust, in the context of what we do as a company. We want to move more backend stuff from Java into Rust. It is an important goal for the company to have more people who are skilled with Rust. It is an investment; we are definitely making an effort to do it. When a person in a company is interested in Rust, we try to figure out how to give them the resources and time that is needed to learn those kind of things.

I think mentoring is a good way to learn things yourself. It is a great instrument for learning. When you teach someone to do something you learn how to do it much better.

I do weekly mentoring sessions on Rust, and every time I realize how much I don't know about Rust. When I try to explain things I thought I knew, it always uncover parts that I don’t know anything about. I spend a lot of time after each session to learn stuff I thought I already knew. That definitely enhances the experience.

By the way, I would like to say thank you for the ‘This Week in Rails’ newsletter email.

Thanks! I don't have time to write that anymore, so I can’t take credit for it, but the people who write it nowadays do a very good job. As a reader of the newsletter now, I appreciate their work a lot.

I’ve been receiving it for the past 2 years at least.

It was a lot of fun! I'm glad I've started this project.

It is very interesting to read on Monday what has happened last week in the Rails community! I think it's time to finish. Hope to talk with you personally at the conference. We’ll definitely have time at the after party.

Looking for it as well!

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

Meet Godfrey and ask a question in person at Ruby Russia 2018!

Questions were asked by Dmitry Matveyev, project manager and developer from Evrone.