L. Guidi: "The strongest part of Rails is solidity"

Family man, software engineer, Open Source indie developer, speaker,  author of Hanami, a full stack web framework for Ruby
13 September 2017   1895

Luca Guidi
Luca Guidi

Software engineer, Open Source indie developer, speaker. Author of Hanami, a full stack web framework for Ruby.

On the eve of RailsClub 2017, on which Luca will be one of the speaks, we questioned him about his job and his views on Ruby development. 

What’s your programming background? It looks like you should have some programing experience before Ruby. How did you come to Ruby universe?

I started doing programming when I was teenager at high school. Then I’ve started my professional career about 15 years ago. I was a webdev, writing in Java which was horrible for me. I did that just for a couple of years and it was painful. Then I switched to Ruby because of rails. It was revolution at that time. It made web development less painful. since then, the Rails pre-1.0 era, my main language is Ruby. I also learnt Go and few drops of Elixir which is interesting for me whereas Go is what I use in production at work.

Do you think Ruby is a better OO language than the others?

If we look at OO way of the things, in Ruby it sounds more natural for developers and it is better object oriented language. In my opinion, Java is like an unenhanced version of C. In Ruby, for me, at the beginning, the mind-blowing fact was that everything is an object. Even numbers. It takes some time to understand at the beginning, but then it makes sense and then it unleashes a lot of tricks regarding polymorphism — like passing around the objects that “quack like” an Integer, for instance. It provides a lot of flexibility for method signatures you are designing and also the implementation you can be focused on. On the other hand I think that ruby missed an opportunity of having the interfaces. Because you can’t define which behavior you want to accept for the method. It could be really useful for you as a library maintainer. That is a missing part. I hope someday it will be fixed. Also, I don’t think the libraries implementing “the missing parts” will determine the real future of Ruby. These new features will work once they are a part of the language core. And of course it must be done right.

What in your opinion are the strongest or the weakest parts of Ruby? Is there life in Ruby besides the Rails?

The strongest part historically is the solidity of Rails. The fact that Rails had become huge platform. It is important not just in Ruby ecosystem but also for web development as a whole.
You may notice that when Rails came in, you may notice the huge level of adoption for the language. It gave Ruby the credibility. But the worst part is that Rails took over Ruby entirely. That created a monoculture in my opinion. There are programmers, that only know Rails, but not Ruby as a language. There are gems that assume that you use only Rails platform. It is something that can damage the language. You should expect problems when you try to work outside Rails with, say,  Hanami or systems automation. So Rails in my opinion is major good and bad for a Ruby community.
Now more about goods and bads. I think it is the greatest time for a Ruby ecosystem. Look at good parts. If you have a 5-8 y.o. rails app, good news for you — apart from some upgrading rails problems, you’ve got covered because original recipes of the framework stay unchanged for more than a decade. But at same time I think that ecosystem and language that does not evolve and knows only one way of doing things will eventually fade. But there are good things about it that happening now. Think of Hanami which riches 1.0 this year, more and more apps running in production. Think of ROM which riches, I think, 4.0. Think of Dry-rb, the set of tiny libraries for things like data manipulation et cetera. That is basically the good news. If Rails is good for you as a developer — Rails has the solidity that you need. If Rails doesn’t suit you — you have alternatives.

You wrote Hanami. Why do we need yet another web framework?

There are a lot of web frameworks in Ruby ecosystem, but in general, they are just the clones of Sinatra. Hanami is different in a sense it doesn’t repeat Sinatra. It adopts ideas that are good in Rails along with others we have to adjust. My point is, even if you stay with Rails forever, take a good look on Hanami or other ruby frameworks and learn from them.

What would you point out as the most useful gems/ideas in ruby?

I still have to mention “rom” and “dry-rb” because it is interesting blend between FP and OOP. Especially for “dry” libraries. They are really interesting and I think everyone has to look at them. Not just for hype but because it helps a lot to understand about immutability and deterministic objects. It’s important to make the things in a way so for the given input you have the expected output.   

What in FP in your opinion is worthy of an object-oriented rubyist attention?

Immutability and composition. Not necessarily in pure functions. You can have a look how things are done in Elixir. My idea is to blend together FP and OOP. I’ll give one example of that, Function Objects. It’s an object that accepts an input and returns output as a function but also have some kind of state or has a way to call it in a way that doesn’t require all that state and dependencies to be passed around. And at the same time by definition a function object does one thing and does it well — that’s for single responsibility. Thus combining composition and immutability, it is always predictable. Those are the concepts still open to discussion and experimentation. This is something that I want to present at RailsClub. It’s about the future — the new way of doing webapps with Hanami.

So, what your talk at RailsClub will be about?

I will speak about the blending of OOP and FP. How has it been an intuition in Hanami 1.0 series. For instance, Actions. Actions are objects which expose just one method that takes input and returns output, the HTTP response serialized with Rack specification. We have validators that act similarly. The idea is to take a look of what we have right now and standardize it as behavior for 2.0. Trying to build a webapp for each use case, for each feature that you have in your webapp — it’s like a pipeline of functions combined together. Where you take an input, you validate, coerce, manipulate, process and then return something to the user. That is something I what to present. I want to standardize the set of objects that we have. It goes beyond MVC. Because in MVC you get a request for a controller, you do bla bla bla, you don’t know what goes inside. Everyone wants to define their own workflow there and then return a response. Inside of that layer, our goal is to have a pipeline of data transformation. If you want to describe what webapp does, it basically takes data input, eventually process it in the database and returns data output. If you think about those data transformations, you have it step by step. If previous step was successful, you continue. Otherwise, you handle the exception or an error the previous step returned. It has to be standardized in my opinion.

What resources would you suggest to both newcomers and experienced rubyists?

I suggest Sandi Metz book “Practical Object-Oriented Design in Ruby”. Because if even she doesn’t speak about functional programming, it is important to understand the object oriented part. It’s not natural to just turn Ruby into a functional language, you have still to take all the good parts of Ruby well described in that book. Another book is “Exceptional Ruby” by Avdi Grimm. It’s a short book, basically questioning why in Ruby ecosystem we use exceptions to signal errors. Exceptions should be for exceptional events like “database is gone”. But not for other stuff like database check violation. For example, in new programming languages like Go and Elixir, you never see exceptions, only errors. That makes virtual machine less heavy if you use errors not exceptions. Also, it keeps your code more natural. It is short but solid book about one concept that changed my mind. I also invite readers to check how things work in functional programming and what we can borrow from there. I don't have any book suggestion for that, I just learn Еlixir via their guide. It is good to get a sense what’s going on outside the ruby community.

How would you encourage developers to join Open Source?

It is matter of giving back. For example, Rails, which is open source project, is free in terms that it costs nothing but it helps people earn money. It’s just a matter of recognize the value that it has for you as a developer, for you as a company and give back. It doesn’t mean that you have to spend whole week working on open source. Just help others from time to time. For example, I started the hanami with 30 minutes a day. I’m a big fan of baby steps. Open source doesn’t have to be second job for you. Be open source oriented rather than just a contributor. For instance, you can add some worlds to outdated documentation. It will take 5 mins, but it is very precious for the community. If you find a bug, open a github issue. Also, speaking of the selfish part, contributing to popular projects is great for your CV. You learn to work asynchronously, it is the future of our job, in my opinion. You learn to be patient, you learn the philosophy, you learn how to fit in different setups and visions. It will help you to adapt to the next job and will help you to know Ruby better. You will learn how to read someone else’s code. Long story short — you will learn a lot of skills that makes you really good candidate for your current company. Or, it with help you to find better job if you are bored with the current. It not only helps you to be a good programmer but also gives you a set of skills around programming that helps a lot.

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   2417

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.