RubyConf 2019 – Sorbet: A type checker for Ruby 3… by Jake Zimmerman & Dmitry Petrashko

RubyConf 2019 – Sorbet: A type checker for Ruby 3…  by Jake Zimmerman & Dmitry Petrashko

>>Hello, everybody. Welcome to RubyConf. This
is a talk about sorbet, the type checker for Ruby 3 that you can use today. I’m Dmitry
Petrashko.>>I’m Jake Zimmerman.
>>First we will run through some of the background. Which problems that exist to solve and why we believe
this is the right solution for them. We are followed by discussing the today reality of
this, about how the community is using it today, how other companies are benefitting,
and what is waiting for us in Ruby 3. >>DMITRY: So we’re coming from Stripe, which
is a company that is helping other people run businesses online, helping them focus
on building their products by making it easier for them to facilitate payments on the internet. Stripe
has more than 2,000 employees. We have engineering hubs in San Francisco, Seattle, Dublin. We’re
hiring and we’re also hiring remotes. Go online and see what positions are there. 
We, more specifically, are members of Stripe developer productivity team. We’re the teaming
helping engineers have the most productive life of their career at Stripe. We help them
focus on building the product rather than overcoming obstacles which are specific to
development.  And Stripe, more specifically, uses Ruby a
lot. Ruby is our main product language, and thus as developer productivity team is helping
Stripe engineers be more productive, we mostly end up working in Ruby and building Ruby abstractions
for Stripe. Thus, our customers, customers of mine, are internal Stripe engineers. There
are hundreds of them writing millions of lines of code in a single repo. That’s intentional. We
want it to be easier to make changes, to make swapping changes around the entire code base
so we have a single codebase with so many lines of code. 
In order to figure out what do we do to make our engineers more productive, one of the
ways we learn is by asking them. We run developer productivity survey. Before Sorbet existed,
a common feedback that we heard is that for engineers, it was taking a long amount of
time to get feedback for existing systems on whether their code is correct. It took
too long to grasp the unfamiliar code, to read the code of other teams or previous people
who were on the team. And it was ‑‑ the codebase was pretty fragile. It was easy
to break things and a lot of assumptions were unspoken. It was possible to break the things
without noticing it.  So, we went to assess what were our options
to improve the situation. The first option is do nothing. Ignore the feedback and let
the engineers cope with the situation. The downside here is engineers will be less productive. They
will continue facing this complexity of the code base, the brittleness, and increasing
iteration cycle. The alternative was treat the symptoms. We could find the biggest offenders
and fix them. But as the company is growing, we believe it would be increasingly harder
for us as a single team to do this manually. So, we didn’t choose this option, either. 
Another option was declare bankruptcy and rewrite the thing. Rewrite it and make it
perfect from the start. This was a high risk. We’ll have to have hundreds of engineers rewriting
our product. During that, we’ll have to maintain both of them. And maybe it will succeed or
fail, and it’s all or nothing. It’s either entirely successful or entirely failing. It’s
a high risk.  Another option was to write some things. Take
ten engineers and take the horrendous offenders and rewrite the things that matters, but it’s
hard to agree what matters long term. It might be wrong. Some things that used to
matter no longer matter and some things matter more now. You might be launching new products
or changing priorities, and maybe there are pressures that make the area that used to
be not important more important. So, it’s a hard decision. And it requires substantial
amount of engineering. And finally the one that we chose. We chose to write a type checker. This
is a tool. This is not a process that you need to do. This is a tool that you do, and
the tool works on everything.  So what we did is started a team with three
engineers. The smallest investment in between all of those, which was able to deliver incremental
value in a month. Every improvement was possible on a file by file basis. Improvements came
every day rather than requiring a leap of faith, and a lot of engineers committed to
the leap of faith. So, that’s why we built the type checker. 
Here is the timeline. In October 2017, the project was kicked off. Originally we have
been evaluating a few other alternatives. Most notably, the type checker built for GitHub,
we took the parser for it. And it’s pretty good. We evaluated RDL, which was built by
Jeff Foster. Unfortunately, it was too slow to work on our code base. It would have taken
literally hours to do a single type checking. It would be slower than our test. So, because
of this, we decided to implement our own thing.  In February 2018, we typed first production
code in real world. We ourselves, as developers of the tool, were verifying whether our tool
actually is useful by taking real code and trying to type exit seeing that error messages
made sense. And to be honest, at first they didn’t. They were complaining too much in
some cases where the code is correct, but it doesn’t like it. It wants to follow some
scheme that you may disagree with, and you are probably right. Why is it forcing this
on me? And in other cases it was permitting things that we didn’t want. This is a moment
that we believe contributed the most to the experience of using Sorbet. We have been
intentionally building on a balance of allowing users to write the code that they want and
checking the things that are there. We want the users to feel like this is a helper rather
than prohibiting them from something.  And the manifestation of this was in June
2018, where we made this required for every engineer at Stripe. At that moment when it
became enforced on everybody, this with us a moment where we were very careful to make
sure that we’re here for every engineer. If somebody doesn’t like it, we want to make
sure they hear heard.  Fortunately, it worked really well. A majority
of people liked it. Some people were neutral for quite a time, but as we were developing
more and more features that they cared about, they got on board. And a year later in 2019,
after extensive beta with more than 40 companies, it was open sourced and now it’s available
for everybody to use.  So, I want to dive deeper in what problems
did we want Sorbet to solve and how does this solve them? Jake? 
>>JAKE: Thank you, Dmitry. All right. So, we’re going to dive into what problems Sorbet
actually solves in a real code base. So, going back, Dmitry mentioned the developer
productivity survey that we run at Stripe, and there were three repeated complaints or
concerns that people raised over multiple iterations. It took too long to grasp unfamiliar
code, it took too long to get feedback. And then, you know, having changed it and gotten
the initial feedback, it was still too easy to accidentally break things. Well‑meaning
developers, people get paged, and that’s something that we try to minimize so that we can make
them more productive, focusing on actual product, not fixing broken product. 
So, as an example, diving into that first point of what I mean by it took too long to
grasp unfamiliar code, I pulled this snippet from Stripe’s codebase. I shortened some
variable names. Consider that we’re trying to debug something. Maybe we saw a reference
to something in a stack trace and we’re like why is there a problem here? So it’s our
task to understand it. But we have no tools to figure out what’s going on. The first
question is that merchant argument, is that a string ID of a merchant’s unique ID? Or
is that an actual object that is some model instance? And we can’t actually tell, because
it’s just being passed on to two other functions. We’re not interacting with it, so it could
be one of either. If we wanted to change this code and we wanted to access some property
on a merchant, we don’t know whether we first have to load the thing from the database or
whether we already have it from the database and we can just access its fields directly. 
Another question that we might want to ask here is okay, we can see that the result of
this similarity fetch call is returning data, but the previous programmer thought that it
might be null. Is it actually going to be null? What does it mean for the result to
be null? We’re coding defensively and sticking an or= an empty array, but is that something
we should handle completely different? We have no knowledge into what this code should
be doing.  We have taken a simple example. Maybe it’s
kind of trivial, but it happens all the time, especially when you’re working with an engineering
organization the size of Stripes where you have so many changes a day. The chance is
inevitable. Every day you’re looking at code that is unfamiliar. 
So that second point that came up in the survey was it took too long to get feedback. Here
are some numbers. If Stripe very, very strongly believes in test‑driven development, so
we write tons and tons of tests because Stripe is involved with actually moving people’s
money around, so we want to make sure we’re doing that correctly. Over the years we have
written so many tests that if you tried to run every test that Stripe has on a single
laptop end‑to‑end, it would take days of wall clock time. So, of course we have
done a lot of work to make these tests run in parallel with really powerful CI so you
can get results really fast. So, those tests, you know, take anywhere from 10 to 20 minutes
and recently we have done really impressive minutes to get it down to 8 or 6 or 5 minutes,
but that’s still 5 minutes where you’re just waiting to see if the changes you made is
the right change. And we really want to measure ourselves based on how fast people can actually
change the code. People can type a single key inside their editor and see it render
on the screen in milliseconds. So, we aspire to give them feedback that quickly. So, that’s
kind of what we’re trying to get to in terms of too long to get feedback about the code. 
And the third is it’s too easy to accidentally break things. So, going back to the snippet
from before, let’s say we identified, okay. It actually is a string but I need it to be a
merchant. So, let’s change it. What are the places that I need to update? Maybe this
method, it has a particularly unique name like find card similarity probably doesn’t
show up in a lot of places, but that’s not always the case. Sometimes these methods,
you can’t descrip for them. Maybe you can run the tests and see what tests fail, but
that doesn’t catch everything. Is it enough if the tests pass? Is it enough if you make
the change and then deploy the code and see that production says that there is no errors? At
what point can we be confident that the change we did make was safe? Those are the kind
of problems that we’re trying to use Sorbet to solve. So, at this point we built Sorbet,
every Stripe engineer is using it. Looking back on the year or two years of using Sorbet
at Stripe, has it fixed these things? Rather than answering that question directly, I would
rather go to a demo. You can almost follow along. You won’t have the starter code that
I have, but we have built an online sandbox for Sorbet called, and anybody
can go there on your browser and mess around with it. Because it’s running in a browser,
I can embed it in an iframe, so I can mess around with it right here. 
The first question that we were thinking about is it took too long to grasp unfamiliar code. We
were not sure what this function was doing. All we have to do with sorbet is point and click ‑‑
not even click, just point. >>DMITRY: You should be pointing on the other
screen. >>JAKE: You’re right. Thank you, Dmitry. Hover. Cool! So
the first thing that you can do is you can hover over the name of a method and immediately
see the type for this method. You can see also the documentation for this method. You
can see, like, the question we were trying to figure out before was merchant a string
or was it an object? We can see directly there, it’s a string. If there wasn’t, you
know ‑‑ sometimes there’s documentation and sometimes there isn’t. If there wasn’t
documentation and we wanted to check the implementation out, we can right click and go to check definition
and we jump down to the definition. This is a little demo, so I unimplemented it. In
Stripe’s code base, it is implemented. That is immediate. That feedback is point and
click and people can figure out this code that’s unfamiliar to them and get grounded
in the reality and move on and think about the problem they were actually trying to solve. 
Oops. My cursor is over here. The next question we had was having changed the code, what is
the fastest feedback that we can give people as to whether they have done it correctly
or not. So, I’m going to go over here and introduce an error for the sake of making
an error. The red squiggles update as soon as I type something, so Sorbet can point directly
to the parts of your program that are wrong as you’re typing it. You don’t have to wait
for the test run to see that you typo’d the name. And again, as you type things, not
only can Sorbet tell you what’s wrong, but it can suggest to you how to fix it. Here
I type the name of this method, and Sorbet immediately pops up a completion item that
says maybe you meant this, and not only will it say ‑‑ it’s kind of small. But it’s
suggesting the fetch method that’s on this object. Not only is it suggesting the name
of the method, if I ask for the documentation, it will show it to me. It tells me the type
of this method and what the documentation is for it. If we press tab, it will let us
fill in the blanks for all the information that it needs. So, we can go over here for
merchant and it will suggest merchant and so on and so forth. This demo, again, running
on an iframe in a reveal js presentation. But that’s how fast it is in Stripe’s multi‑million
line Ruby codebase, partly due to interesting architectural decisions. Sorbet can see that
it’s only editing inside of a method so it only needs to analyze that method. We have
done interesting things to be able to give this feedback to developers as quickly as
we can.  The last thing is we want to make it harder ‑‑
not impossible, but hard tore accidentally break the code. So, the way that Sorbet does
this is by giving people one more tool to analyze their correctness. So, having grappled
with unfamiliar code as a developer, now we want to go in and leave our understanding
behind for future engineers so when they come in next time, they won’t have to know whether
this thing is a merchant ID or a merchant object. They can just see it. So, the easiest
way to do that is by leaving behind a type annotation for this method. We can write
a type annotation by typing sig, which is like method signature. So, if we start typing
that inside this editor, not only will Sorbet show us that sig is a method we could call
but it will also show us a suggested sig. Just by typing out the start of a type annotation,
Sorbet says it looks like you can add this, and it’s right in this case. The parameters
that says it’s a method that will take a merchant, which is a string and it returns a similarly
record object. And all we have to do is press tab and that signature pops into the code. That
gives us a great starting point if we want to change the code. Now Sorbet will update
its knowledge of the world and say it must be the case that this signature is true. If
we wanted to change it, maybe the change we wanted to make was to change this from a string
to a merchant object, as soon as we finish typing that signature, Sorbet then updated
its knowledge and said okay, it must be the case that this is a merchant object. If you
were ever using, you know, this local variable in a way that was incompatible with that,
it will show you all the errors. I can’t show you, because it’s in the browser. But
in VSCode, there would be a separate tab where it would list the errors and you could jump
to dev and fix the error. Expected string found merchant object. Now we can go through,
and again, this is one more way to be, you know, a little bit more confident that the
change that you have made doesn’t silently break something. Tests help, deploying the
code helps, and also, type checking the code helps, so that’s kind of one more way. 
So let’s click out of here. Those are the three benefits that we talked about where
the types make the code easier to grasp. Sorbet is as fast as you can type. So, you get feedback
much more quickly than other alternative methods and Sorbet ends up being one more tool to
help developers and analyze whether the thing that they have written is actually the thing
that they wanted.  Cool. So, that’s the demo of the problems
that Sorbet was trying to address and whether or not it solved them. Now I will hand it
back to Dmitry to talk about the community since we have open sourced Sorbet. 
>>DMITRY: It has been slightly less than a year since we open sourced Sorbet. We had
an ongoing discussion with Ruby core team about what should be happening with this. As
Matz announced at Ruby kaigi2019, Ruby 3 standard library will ship with type definitions. 
There are active discussions about how do we evolve
the Ruby usage of types, how to make it be Ruby and get the benefits that type languages
normally get. It’s been a great collaboration and a pleasure. Thank you, Matz. All of
the work has been done by the creator of the type checker called Steep. He has created
the syntax for type signatures that Ruby 3 will ship with. So, thank you. 
Since we have open sourced, we have had in the open source, in the new repo, more than
800 pull requests, and a lot of them are coming from not Stripe. We have 135 contributors
who contributed to it. 10 are on the Sorbet team, and 30 are stripe, and 85 are coming
from Shopify, Heroku, a great collaboration. Companies are helping make it easier for people to adopt
Sorbet and making it discover more errors, errors that those companies care about. At
this moment, we believe that tooling behind Sorbet, the tooling that those companies created
together can make it easier for you and pretty easy to adopt Sorbet. Shopify will talk more
about this, about what are the steps that they took and how did they benefit from it
and what are the problems and what were the solutions for them. So, it’s the next talk
in this slot. So, please follow us.  I wanted to specifically also pinpoint a few
contributors. Alex snaps has contributed with the details about how to make it work
correctly and in tricky cases where parser for Ruby doesn’t do what you expect it to,
Sorbet now does it for you. They are substantial contributions. Univerio has built a way to
automatically add documentation that comes from stdlib. Hover was coming from your codebase. But
similarly now, the information for hover can be coming from stdlib. You will now have
documentation on arrays, on hashes, on maps, all of those. This is awesome. Thank you. 
And we also have gem support. Not every company does it. Coinbase doesn’t. As an early user
of Sorbet, they have ‑‑ since we open‑sourced, 117 gems have been added additionally to the
ones that were added in bulk. A majority of the gems that people use now have types
now, and those types are Either auto‑generated with tools that are part of the repo or part
of a similar tool that Shopify will present. We have automatic ways to gather type signatures
to be shared. And then you can modify them and make them more precise to specify specific
types.  And majority of the contributions are from
the community. This is a very active project that helps better integrate Sorbet into the
gems. If you’re a library author, please join.
If you’re a library user, please join. There are also entire projects that are extending
and building the ecosystem to make it easier for you to adopt. The most important one is
sorbet‑rails. This is started by CZI. An interesting thing about Stripe, Stripe uses
Ruby but we don’t use Rails. A majority of projects do use Rails. So, CZI created an
external extension that makes Sorbet play really well with Rails. There’s another extension
called Sword. So, you have a codebase where you use to describe a majority of your arguments,
you can convert them to sorbet types in order for them to be checked. And Parlour is a
plug‑in ecosystem for writing plugins so you can teach sorbet about the internal coding
conventions, internal magic that is adding additional benefit to your company, and you
would benefit from adding types to it, despite it not being used by other people. 
And finally, this has been us presenting our project as people who are working on it. So,
we can make it look fancy. So, we also want to add some direct feedback from the users
of it. So, here is one. I’ll just let you read it through. 
So a very common thing that happens in a big codebase is in order to make a change, in
order to feel good about the change, you need to refactor some code around it and as you
are refactoring the code, you need to make sure you don’t break stuff. And iteration
can be painful, and can make it so that you don’t end up and you don’t want to change
things. And thus you end up piling hacks and hacks. So, here the person is saying
that sorbet is making it easier for them to have faster iteration loop and thus to do
the refactorings.  Here, similarly. Stripe has a bunch of smaller
code bases that do not have sorbet. And it’s very hard for people to compare their experience
pre‑sorbet and after, because we’re gradually rolling it out. If you ever go to the other
code bases that do not have the benefits, people see a striking difference between the
two. We actually saw one of them start adopting it in smaller projects simply because they’re
used to it and they enjoy the benefits.  So yep. Even smaller projects than Stripe
are getting types. And then, yep. >>JAKE: This was the e‑mail that we sent
out the first day that we released go to definition. It’s completely changed the way many people write
Ruby code because they don’t wait for figuring out where something is defined. They just
click and click and click and suddenly they understand the code. 
>>DMITRY: Yes. This changes the iteration speed. This changes. It empowers engineers
to be more productive, to be more brave, to do more experimentation. They feel that they
have better ways to check that they are still safe. This allows them to build more features,
to change existing features, and do this in the code base that they now like. They like
the abstractions that they introduce. They like that they can change them or eliminate
the abstractions they no longer like. What’s next? The major push is investing into the
editorials. We’re investing in auto‑complete and finding references. We’re moving to things
which rather than asking questions about your codebase, we’ll be changing it like refactorings.
Doing refactorings automatically like renaming a class or a method or reordering local variables.
Maybe promoting a positional argument to a keyword argument or back. This is the majority
of our investment. The second one is we want to make it even faster. Sorbet ‑‑ Stripe
codebase is growing. And we want our users to continue having fast iteration cycle. From
our experience, a majority of the code bases similar to Stripe grow exponentially over
time, which means we need to continue to make sorbet faster. 
And finally, we’re hearing feedback from internal and external users, which one do we hear most
commonly? Which ones will be the most useful for our users to invest?? We now have interfaces. You
can specify that a module describes a set of functions and you’re required to always
override them to implement them. You can have final methods and final classes and exhaustiveness
checks and sealed classes. A lot of the features that you would normally provide you guarantees
are now possible and are being asked for by users and we’re prioritizing them by demand. There
is going to be an awesome talk about how to adopt sorbet presented by Shopify. If you
stay in this room, you will see it. They will describe what problems did sorbet solve
at Shopify. They will describe what was the progress around solving them and what were
the problems that they ran into and how did they solve them so you can learn from their
experiences.  Thank you for following our talks. We would
love you to share your questions and feedback. If you haven’t tried sorbet, try it. If you
have, please let us know how did it go. We would love to make it better. Thank you for
coming. As always, we are hiring. We’ll be around. Thank you. 
>>JAKE: Also, I have stickers.  [ Applause ]>>[ Inaudible Question ]>>DMITRY: So the question was we have this
sig. The way you annotate the method with a signature and it comes before the method. And
the question was how do we implement it. Jake do you want to take this one? 
>>JAKE: Our syntax has gone through multiple iterations of design and redesign. The actual
concrete syntax is sig is just a method name. And it’s kind of hidden. I tricked you for the
purpose of this demo, but there’s actually a module down here at the bottom called tsig. And
if you include it, you can monkeypatch every module. Alternatively, you can put extend
tsig any place you would like to use that annotation. We did that for a long time. We
required every Stripe developer to have this extension in every class that they wanted
to use types in, and we realized wait a second, 80%of our classes have this in there and it’s
just noise so let’s just get it and put it everywhere. 
>>DMITRY: It runs in standard Ruby. It doesn’t require any custom modifications. You just
mix in what you mix in and now you have type signatures. Thank you for a great question. 
>>[ Inaudible Question ]>>DMITRY: So the question is what do we use
for VS code? Microsoft is popularizing it. It works in other editors. We know it works in
VI. We know that people have integrated it in emacs. This is just language integration. And
yep, it works. Thank you for a great question. Yes, please. 
>>[ Off mic ].>>DMITRY: So the question is if you are already
using Ruby mine what are the benefits of using this? Ruby mine tries to understand your
code base as written and to provide you some information, but it cannot do as much. It
does not have the types. It tries to get something, sometimes opportunistically. The
difference here is when you’re describing the sig, you’re describing the intent. You’re
describing not what this method happens to do now, but what I want it to do. You’re
describing that I want it to actually do this rather than anything else. So, it provides
guarantees. If you’re using IDE, like you can still have auto complete to some degree. Much
lesser case and frequently will be slower. But if you have a small code base, at the same
time, the question is how much of this can you trust? With sorbet, all of the signatures
are 100%trust worthy. They are checked in production at Stripe. They are checked in
tests at Stripe. They’re fast enough for us to be able to run in production so they
provide guarantees rather than hope. Hope is not a strategy. Thank you for a great
question. Yes, please. >>[ Inaudible Question ]>>
>>JAKE: I don’t remember if Matz covered it here, but in April or May, he basically
talked about these three tiers of type checkers. So, there’s the Ruby core tier, and then there
are things that are built right on top of core, and then the third tier of third‑party
checkers. What they plan to ship for Ruby 3 release is type signatures for the Ruby
stdlib. When those are available, we will flip a switch. On top of that, Yusuke will
be giving a talk in this room after Shopify. He’s going to talk about his progress about trying
to come up with types for untyped programs. And the third one, which is third‑party checkers
like sorbet and RDL are these kind of like things that will, you know, in their own way,
analyze the type signatures. So, there will always be a place for sorbet. It’s just that
we will be using either our own source of truth for the stdlib or the Ruby source of
truth, and sorbet will work the same way.>>DMITRY: Thank you for a great question. 
>>[ Inaudible Question ]>>DMITRY: Could you repeat again? 
>>[ Inaudible Question ]>>DMITRY: So the question was can you support
polymorphic interfaces, I guess? So if you specify a type and rather than taking a merchant,
you want to take something. So, we have union types. So Jake is showing ‑‑ I’m intending
to take either a string or a merchant and we will check it correctly. And also you
can use mix‑ins as interfaces in your types. We not only have classes in the type system,
but also modules. Combining the two is the most common way we see people model the question
that you’re asking. >>[ Inaudible Question ]>>JAKE: That’s a nice question to pass off. I
think that the key design principle is the same design principle that makes it easy to
adopt. Everything starts out in a codebase without types so everything is untyped. And
then over time you add type annotations to it, so they are added one by one. If there
is a place where you realize, like, there is nothing currently in sorbet’s type system
that will let me 100%accurately annotate this type, which does happen. Sometimes there
is something that is doing really wonky things. Either the first parameter is this or the first parameter
is this and the second is this and the types change all over the place. Sometimes you have
to say okay, I can’t type this and leave it at that. The thing that we have seen at Stripe
and the thing that Shopify will touch on is you don’t actually need to type literally
everything to get tons of benefit. You can be okay typing the most common and important
things and having those things checked. If there is a conflict, they’re rare enough that
you can say I’m just not going to worry about this. 
>>DMITRY: Thank you for a great question. Question in the back? 
>>[ Inaudible Question ]>>DMITRY: One downside that I saw from this
is some people get super excited and they end up mostly writing the types rather than
the programs. [ Laughter ]
We internally don’t encourage this, and we discourage it. Types are there to help you. Types
are not there to prove that you are smart. Types are not there to introduce complexity. Types
are there to make it easier for other engineers. If you’re writing a complex type that makes it
harder for other engineers, that’s not what they are there for. 
>>JAKE: Another thing that I have seen that gets people into a little bit of a trap is
they trust Sorbet maybe too much. As you are incrementally adopting sorbet in a code
base, it will never be at 100%coverage. If you assume that the only thing you need to
ensure correctness is the type check, you might get bit. You might be dealing with
a gem that doesn’t have type annotations yet or an older part of your code base that doesn’t
have type annotations. If you assume the only thing you need is types and not rely
on tests as strongly or on careful monitoring as strongly, sorbet is one more tool, not
a replacement for existing tools. >>DMITRY: Yes, please. 
>>[ Inaudible Question ]>>DMITRY: The question was so far we’re using
nominal types. Do we see a future where we will do structural types. As this has been
progressing, this is one of the questions we are looking to answer. A lot of research
that happened before us, most notably by Jeff Foster shows that structural types, the error
messages are by people. If you expect to have an integer and you got a float, the structural
types will describe this as here is 55 methods on integer, but I expected 55 methods on floats
and they look similar. Why are you complaining at me? They seem the same. 
So, we chose nominal type system because of the user experience, because by having classes,
having modules, you are building a shared language between you and the type checker. The
question was can we type check Ruby code in this world? Yes. There are rare cases where
somebody is asking for those. But most commonly we have seen this create more problems than
solve it. If you are doing this, you also most likely have a method that has a short
name. So, from our experience, we believe that it would be, at this point, potentially
harmful to add it. It’s additional work. It makes it easier to adopt in some cases, but
at this point our suggestion is use untyped. This seems to be doing wonky things. So, our suggestion
is just go with untyped. Thank you for a great question. 
>>JAKE: I think we are at time, but I have nothing else to do but talk about types. So,
if you have any other questions for me or Dmitry, we will be around pretty much the
rest of today and all of tomorrow. >>DMITRY: Thank you for coming. 
[ Applause ]

1 thought on “RubyConf 2019 – Sorbet: A type checker for Ruby 3… by Jake Zimmerman & Dmitry Petrashko”

Leave a Reply

Your email address will not be published. Required fields are marked *