Summarized using AI

The State of Ruby Dev Tooling

Vinicius Stock • November 13, 2024 • Chicago, IL • Talk

The video titled "The state of Ruby dev tooling" presented by Vinicius Stock at RubyConf 2024 discusses the current state and challenges of developer tooling in the Ruby community. The primary focus is on the fragmentation of tools available for Ruby and how it compares to other programming ecosystems, particularly Rust.

Key Points:

  • The Complexity of Choice: Stock initiates his talk by highlighting that while having options seems beneficial, it can lead to 'choice overload', making it harder for developers to decide which tools to utilize.
  • Fragmentation: The main issue identified is fragmentation within Ruby's developer tools. New developers face numerous decisions, such as installation methods and testing frameworks, unlike more cohesive ecosystems like Rust, which offers a well-integrated experience.
  • Comparison with Rust: Stock contrasts the Rust developer experience where tools are developed in coordination with each other, reducing complexity for users. For example, installing Rust is straightforward with a single managed tool, while Ruby offers numerous diverse installation options.
  • Consequences of Fragmentation: This fragmentation in Ruby leads to increased learning curves, excessive configuration needs, and makes it difficult for tools to integrate seamlessly. Developers must often relearn tools when switching projects, impeding productivity.
  • Community Support and Usage Statistics: The Ruby community has a significantly smaller size compared to JavaScript's, impacting its ability to maintain a wide variety of tools effectively. Furthermore, the lack of adequate tooling for Windows deters a considerable number of potential Ruby developers.
  • Paths Forward: Stock suggests that the Ruby community can learn from Rust by adopting a more unified vision of developer experience that emphasizes integration and collaboration among tooling efforts. He advocates for the role of Language Server Protocol (LSP) as a means to consolidate various tools and enhance the developer experience.
  • The Role of Ruby LSP: The Ruby LSP is presented as an essential tool that could unite the ecosystem by allowing various gems to integrate easily with the editor, thus improving overall developer experience.

Overall, Vinicius Stock calls for the Ruby community to converge efforts, reduce fragmentation, and ultimately enhance the developer experience to attract and retain developers. The goal is to ensure that using Ruby is as compelling and effortless as possible for any new developer entering the field.

The State of Ruby Dev Tooling
Vinicius Stock • November 13, 2024 • Chicago, IL • Talk

During the last few years, the Ruby community invested significant effort into improving developer tooling. A lot of this effort has been divergent; trying out many solutions to find out what works best and fits Rubyists expectations.

So where are we at this point? How do we compare to other ecosystems? Is it time to converge, unite efforts and reduce fragmentation? And where are we going next? Let’s analyze the full picture of Ruby tooling and try to answer these questions together.

RubyConf 2024

00:00:15.480 hello
00:00:16.439 everybody Welcome to the state of Ruby
00:00:19.960 tooling as mentioned my name is Vinnie
00:00:22.680 I'm a part of the Ruby developer
00:00:24.720 experience team our team created the
00:00:27.279 Ruby LSP we contribute to s aspects of
00:00:30.960 gradual typing for Ruby and we also
00:00:33.600 contribute to projects like IRB uh Ruby
00:00:36.920 debug Ardo essentially anything related
00:00:39.920 to developer experience uh if you want
00:00:42.520 to know a little bit more about me you
00:00:43.719 can find me at Vino on those links over
00:00:48.120 there I want to start by asking a
00:00:50.520 question is having options a good thing
00:00:54.800 now it's tempting to believe that the
00:00:56.640 answer to this question is always
00:00:58.719 positive and that being able to choose
00:01:00.840 is going to lead to flexibility and a
00:01:03.600 sense of freedom and autonomy so it can
00:01:06.960 never be a negative thing to be able to
00:01:09.479 choose but in reality it is a little bit
00:01:12.080 more complicated than that this paper
00:01:14.799 from the year 2000 when choice is
00:01:17.000 demotivating wanted to understand what
00:01:19.240 would happen if they were to increase
00:01:21.840 the complexity and the number of options
00:01:24.759 related to a decision someone was making
00:01:27.439 would they still feel like they got this
00:01:30.200 sense of autonomy and freedom from being
00:01:32.600 able to choose and it turns out that's
00:01:35.040 not always the case you have a risk of
00:01:37.280 inducing something called Choice
00:01:39.240 overload which is essentially when the
00:01:41.439 effort to make the decision has become
00:01:43.680 so high that people are going to start
00:01:45.640 cutting Corners to make the decision
00:01:48.520 they might consider a smaller portion of
00:01:50.920 the information that's available because
00:01:53.040 processing everything requires too much
00:01:55.600 effort they might simplify their
00:01:57.759 decision- Mak process or they might try
00:02:00.280 to eliminate the effort completely by
00:02:03.039 just preferring whatever is the default
00:02:04.920 or making no choice
00:02:07.640 whatsoever today I would like to talk to
00:02:09.599 you about options in the context of
00:02:12.360 developer
00:02:13.519 experience and where are we in the Ruby
00:02:16.200 Community when it comes to developer
00:02:18.120 experience I want to address one point
00:02:20.440 which is that it's common to hear people
00:02:22.040 say that creating tooling for Ruby is
00:02:24.560 difficult because Ruby is a dynamic
00:02:26.519 language and of course there is truth to
00:02:28.920 that STC analysis is not as accurate in
00:02:32.120 Dynamic languages as we just saw Matt's
00:02:34.760 talking about uh
00:02:36.480 upstairs but I don't think that that's
00:02:38.400 the main thing holding us back today and
00:02:40.760 Ruby is not the only Dynamic language in
00:02:43.640 existence JavaScript is also Dynamic
00:02:46.640 python is also Dynamic and the answer
00:02:49.560 for more accurate static analysis is
00:02:52.000 gradual typing this in the case of
00:02:54.319 JavaScript typescript for python it was
00:02:57.000 type hints and we have our own gradual
00:02:59.239 typing solution ions like surve and
00:03:00.920 steep so I don't believe that today that
00:03:03.040 is the main source of difficulty we face
00:03:05.080 with our Tooling in my opinion the main
00:03:07.560 challenge for a modern developer
00:03:09.159 experience is the level of fragmentation
00:03:11.760 that we have in our
00:03:13.840 tooling let's follow the story of a new
00:03:16.280 developer so this is a junior developer
00:03:18.480 just starting out and they want to have
00:03:20.440 a complete developer experience with
00:03:22.040 everything they would expect today while
00:03:24.239 trying out rust and Ruby for the very
00:03:26.959 first
00:03:27.959 time the first thing they have to do is
00:03:30.879 install the language so they need to be
00:03:32.360 able to install rust and manage
00:03:34.319 different rust versions the official way
00:03:36.799 to do that is with rust
00:03:39.120 up if they wish to write automated tests
00:03:42.480 for their program they don't have to
00:03:44.480 configure anything the test framework is
00:03:46.840 built into the language and you can just
00:03:48.720 start writing your tests and executing
00:03:50.480 them straight away with no setup step
00:03:53.959 required if they want to adopt
00:03:56.159 formatting they can just use rust format
00:03:59.000 which is the official formatter for rust
00:04:01.319 maintained by the rust
00:04:03.319 team similarly if they want to adopt
00:04:05.799 linting they can use clippy which is the
00:04:08.439 official linter for the rust language
00:04:10.280 also maintained by the rust team and if
00:04:13.000 they want to integrate all of that into
00:04:14.760 the editor and have Rich features like
00:04:17.000 completion and goat definition then they
00:04:19.880 can use rust analyzer the official
00:04:22.280 language server for rust and uh also
00:04:25.199 maintained by the rust team which
00:04:27.199 integrates with all of the other default
00:04:28.960 tools with with zero configuration
00:04:31.720 required and if we keep keep taking a
00:04:33.960 look at any other category of tooling
00:04:35.720 for rust the story here is always the
00:04:38.440 same but this well integrated experience
00:04:41.840 didn't happen by accident rust has a
00:04:45.520 dedicated developer tooling team with
00:04:48.000 several different sub teams that are
00:04:49.600 each responsible for those individual
00:04:51.639 tools and the overarching team is
00:04:54.520 responsible for Designing this unified
00:04:56.960 cohesive experience and also for coordin
00:04:59.960 the efforts of all of the sub teams so
00:05:01.880 that they're all building towards that
00:05:03.840 same
00:05:05.600 direction what we have here is very
00:05:07.960 modern default tooling but also guidance
00:05:10.600 coming from the language itself about
00:05:12.680 what your developer experience should be
00:05:14.360 when you're interacting with rust which
00:05:17.400 leads to Consolidated tooling and in
00:05:19.720 turn has several benefits that the rust
00:05:22.000 Community gets to enjoy integration is
00:05:25.280 easy because the teams are explicitly
00:05:27.800 working towards that making sure that
00:05:29.199 they use invention over configuration so
00:05:31.680 all of the tools will integrate out of
00:05:34.000 the
00:05:34.720 box it minimizes the decisions for new
00:05:37.360 developers in fact you don't have to put
00:05:39.199 in any effort in evaluating options you
00:05:41.160 can just use the set of default tools
00:05:43.600 and have a great developer
00:05:46.120 experience it also minimizes the
00:05:48.400 configuration you need because you
00:05:50.319 rarely ever if if at any time need to
00:05:52.840 configure something in order to make the
00:05:54.759 tools work the tools already work out of
00:05:57.039 the box and you only configure things if
00:05:59.000 you want a custom imiz
00:06:00.960 Behavior you get a reduced learning
00:06:03.319 curve as well because the set of tools
00:06:05.160 that you learn how to use in one rust
00:06:07.360 project is the same sort of tools that
00:06:09.199 you're going to be using on other R
00:06:10.639 projects so your knowledge
00:06:13.000 transfers and finally you also get a
00:06:15.759 very high collaboration environment if
00:06:18.080 one developer contributes a new feature
00:06:19.880 to any rust tool then the entire
00:06:22.319 Community gets to
00:06:24.599 benefit when our Junior developer
00:06:27.039 switches to Ruby they're going to have a
00:06:29.639 a very different Journey at the very
00:06:32.400 first step they're already faced with a
00:06:34.639 decision how do I install Ruby there's
00:06:37.759 no official way on how to install Ruby
00:06:40.280 so they're going to have to evaluate
00:06:41.880 several different
00:06:43.360 options on how they can do that and here
00:06:46.479 on the slide we have 11 different
00:06:48.440 options some of which allow you to
00:06:50.759 install Ruby others allow you to switch
00:06:53.160 your Ruby version and a few of them
00:06:55.240 allow you to do both and in addition to
00:06:58.360 that many of these these options are
00:07:00.440 written as pure shell scripts which for
00:07:03.680 some of them make them shell specific
00:07:05.680 and operating system specific so in
00:07:08.680 reality only certain combinations are
00:07:11.080 actually available depending on your
00:07:14.240 setup if they decide to adopt automated
00:07:17.520 testing they have another decision to
00:07:19.360 make but in this case not because we
00:07:21.840 don't have a default test framework is
00:07:24.199 because we have
00:07:25.560 two both mini test and test unit are
00:07:28.759 included as a part of your Ruby
00:07:30.520 installation so it's not possible to
00:07:32.599 provide developers with a completely
00:07:34.960 zero testing zero configuration testing
00:07:38.240 experience at the very minimum you still
00:07:40.400 need to add the gem to your gem file
00:07:42.120 because we don't know which one of the
00:07:43.240 defaults you're going to
00:07:45.759 pick if they decide to adopt typing they
00:07:48.639 have another decision to make they can
00:07:50.599 adopt gradual type Checkers like Steep
00:07:52.800 and Survey but they also have uh at
00:07:55.800 their disposal more novel approaches
00:07:58.080 like typro which is a type profiler and
00:08:00.680 you can get varying levels of type
00:08:02.560 checking with other tools as
00:08:05.680 well for formatting and linting and here
00:08:08.879 I put both in the same category because
00:08:11.159 in the rubby Community they're it's not
00:08:13.120 so clearly separated you also have
00:08:16.159 multiple options that you can choose
00:08:17.720 from and different combinations that you
00:08:19.599 can make with all sorts of
00:08:22.039 linters and if you want to try to
00:08:24.120 integrate all of that into the editor
00:08:26.639 then uh they're going to be evaluating
00:08:28.599 families of Link servers you have the
00:08:31.400 type checking family which focus on
00:08:34.200 features where type checking is
00:08:35.640 particularly important like completion
00:08:37.959 and goats definition you have the
00:08:40.240 general family of language servers like
00:08:42.080 Ruby LSP and solar graph which try to
00:08:44.560 give you the best experience possible
00:08:46.920 even if no type system is present and
00:08:49.560 then you have the formatting family of
00:08:51.040 language servers that provide you with
00:08:54.279 formatting if we continue looking at any
00:08:56.880 other category of tooling for Ruby the
00:08:59.000 story here is the same we have a lot of
00:09:01.720 fragmentation at every single
00:09:04.120 level if we were to consider that our
00:09:06.959 developer wants to have a full
00:09:08.760 experience so if they want tools from
00:09:10.839 all of the all of the categories that we
00:09:12.839 saw and if we limit that they can only
00:09:15.519 pick one per category which is not the
00:09:17.959 case you can combine multiple linters
00:09:19.800 multiple language servers but for the
00:09:21.680 sake of the argument let's say they can
00:09:23.760 only pick one and keeping in mind that
00:09:26.440 the lists are not exhaustive there are
00:09:28.440 many tools that are not on those lists
00:09:30.959 but there are entire categories of tools
00:09:32.680 missing like debugging which I didn't
00:09:34.720 put
00:09:35.760 up with these constraints rust has one
00:09:39.600 possible combination of how you can
00:09:41.560 configure your environment the set of
00:09:44.000 default tools and Ruby has the very
00:09:47.000 conservative number of 11,000 ways which
00:09:50.040 you can configure your
00:09:52.079 environment if we were to visualize that
00:09:54.760 rust's visualization would be a straight
00:09:57.120 line where on each level you just pick
00:09:58.959 the next default tool and for Ruby you
00:10:03.160 can't quite put that on a slide because
00:10:05.000 there are simply way too many
00:10:06.480 combinations to
00:10:08.000 visualize it's no wonder that it's
00:10:10.959 extremely difficult to guarantee that
00:10:12.920 Integrations are going to work properly
00:10:15.040 for every possible combination of way
00:10:17.040 that you can configure your
00:10:19.959 environment if we take a look at
00:10:22.440 different projects that all use
00:10:24.720 different sets of tools you also
00:10:26.839 conclude that learning Ruby itself is is
00:10:29.440 not enough to be able to contribute to
00:10:31.000 all of those for example if you
00:10:33.000 contribute to project a and you're not
00:10:35.279 used to gradual typing but then you have
00:10:37.279 to work on Project B then you're going
00:10:39.600 to have to learn the specifics of steep
00:10:41.480 and RBS in order to be able to make a
00:10:43.600 successful contribution but if you then
00:10:46.079 want to contribute to open source
00:10:47.440 project C now you need to learn the
00:10:49.480 specifics of another gradual typing
00:10:51.279 system surve in order to be able to
00:10:53.480 contribute and this is not exclusive to
00:10:55.959 type Checkers it's the same thing for
00:10:57.320 test Frameworks linters or even
00:10:59.279 debuggers if they use a different
00:11:00.680 debugger you're going to have to learn
00:11:01.760 how to use it to debug your
00:11:04.160 code the essence here is that the set of
00:11:06.760 tools you learn how to use in one
00:11:08.200 project may not fully transfer to other
00:11:10.680 Ruby
00:11:12.519 projects what we have here is missing
00:11:14.800 defaults but also guidance from the
00:11:17.000 language Ruby is not prescriptive about
00:11:19.839 what your developer experience should be
00:11:22.680 and that in practice is delegating the
00:11:25.360 design of the overall developer
00:11:26.880 experience to the community which leads
00:11:29.079 to to fragmentation and in turn we see
00:11:32.120 all of the Opposites of what the rust
00:11:34.279 Community
00:11:35.360 enjoys integration is extremely
00:11:38.160 difficult because we have several
00:11:39.440 implementations of the same tools all of
00:11:42.120 which don't conform to any standardized
00:11:44.040 API so you need custom integration for
00:11:46.720 all of those tools you get an excessive
00:11:49.639 number of decisions for new developers
00:11:52.160 can we really expect that a junior
00:11:54.120 developer who's just starting out is
00:11:56.079 going to understand all of the
00:11:57.200 trade-offs they're making by picking
00:11:59.279 tools from all of those
00:12:01.480 categories because integration is
00:12:04.200 difficult it also increases the amount
00:12:06.120 of configuration required because the
00:12:08.240 easy way out is to ask users for more
00:12:10.320 and more configuration so that they are
00:12:12.360 responsible for ensuring that the tools
00:12:14.440 are going to integrade properly so it
00:12:16.360 degrades our ability to provide a nice
00:12:18.079 out-of-the-box
00:12:20.240 experience it increases the learning
00:12:22.360 curve because the set of tools you learn
00:12:24.040 how to use in one project will not
00:12:26.279 necessarily transfer to other Ruby
00:12:28.120 projects you may need to re learn the
00:12:29.959 same tools you already knew but just a
00:12:31.760 different
00:12:33.440 implementation and it spreads the
00:12:35.399 efforts of our
00:12:37.440 community if we take a look at
00:12:39.320 JavaScript which is another highly
00:12:41.160 fragmented ecosystem they have similar
00:12:44.360 issues they have dependency management
00:12:46.279 fragmentation runtime fragmentation in
00:12:49.160 that sense they're very similar to the
00:12:50.600 Ruby ecosystem but they do have an
00:12:53.959 advantage they have a much larger
00:12:56.360 Community if we take a look at the most
00:12:58.519 recent stack overflow results the number
00:13:01.279 of respondents for JavaScript was at 62%
00:13:04.160 it was the number one programming
00:13:05.480 language and Ruby was just a little over
00:13:09.240 5% so maybe JavaScript has enough people
00:13:12.880 in their community that they can afford
00:13:15.440 to have all of this richness and
00:13:17.199 diversity in tooling they can sustain
00:13:19.399 all of these different options but I
00:13:21.600 want to argue that a community our size
00:13:24.279 cannot afford to divide our efforts
00:13:26.240 maintaining several different
00:13:28.120 implementations of the same highly
00:13:30.160 complex
00:13:31.639 tools as another statistic if we take a
00:13:34.120 look at the number of non-unique
00:13:35.519 contributors for language servers as of
00:13:38.240 the time when I wrote the slide rust
00:13:40.199 analyzer had
00:13:42.040 874
00:13:43.600 contributors and if we sum up the number
00:13:45.959 of five actively maintained language
00:13:48.160 servers in our community serbet steep
00:13:50.959 solar graph Ruby LSP and typr and this
00:13:54.120 is non-unique so the pandabot is being
00:13:56.079 counted five times and I'm being counted
00:13:58.639 more than one too it's an inflated
00:14:00.759 number and even though it's inflated
00:14:03.199 we're not even close to the number of
00:14:04.800 contributors that rust analyzer has
00:14:07.480 which is a lot more impactful to the
00:14:09.120 quality of our tools than the fact that
00:14:10.680 Ruby is a dynamic
00:14:13.800 language and I want to say that building
00:14:16.279 new tools might make sense I am not
00:14:19.000 arguing that we should stop making new
00:14:21.000 tools the point that I'm trying to make
00:14:23.480 is that you don't automatically get a
00:14:25.000 better developer experience simply by
00:14:26.880 creating more tools not with without
00:14:29.320 considering how they're going to fit
00:14:30.720 into this General picture of developer
00:14:33.160 experience how they're going to
00:14:34.279 integrate with the rest of the
00:14:36.079 ecosystem because developer experience
00:14:38.040 is not about the tools in isolation it's
00:14:39.680 about how they combine to allow you to
00:14:41.959 interact with the
00:14:43.839 language if we go back to the article
00:14:46.360 that we were discussing at the very
00:14:47.639 beginning what we want to avoid is being
00:14:50.440 in the last option of making no choice
00:14:54.320 whatsoever that would mean that
00:14:56.000 evaluating all of the different options
00:14:57.800 requires so much effort it that in the
00:15:00.040 best possible case the developer might
00:15:01.600 be neglecting an entire category of
00:15:03.399 tooling by choice and in the worst
00:15:06.519 possible case they might decide to not
00:15:08.120 try out Ruby and go try some other
00:15:10.160 language that is easier to get
00:15:12.480 started we want to be where rust is
00:15:14.759 where the default option is so good that
00:15:17.680 they can just use the defaults and have
00:15:19.759 a great developer experience without
00:15:21.199 investing anything in the
00:15:23.480 decision after all using the tools is
00:15:26.399 not the developer final goal the
00:15:29.360 developer doesn't have it as it final
00:15:31.600 goal to use rails or to use the Ruby LSP
00:15:34.480 or to use
00:15:35.519 sorbet those are just stepping stones
00:15:38.199 and the goal is to build something so
00:15:40.720 setting up your development environment
00:15:42.240 should be absolutely effortless and it
00:15:44.399 should set you up for Success so that
00:15:46.279 you can focus on what it is that you're
00:15:48.399 trying to
00:15:50.720 build and perception matters right the
00:15:53.240 way that Ruby is perceived is important
00:15:55.560 for
00:15:57.000 us if you search online there's a lot of
00:15:59.560 research into how certain elements of
00:16:01.480 one thing can impact the perception of
00:16:03.759 that thing overall like certain elements
00:16:06.120 of Brands can impact how consumer feel
00:16:09.120 consumers feel about their products or
00:16:11.639 how certain aspects of a location can
00:16:13.880 impact tourism or how certain elements
00:16:16.480 of a restaurant can impact how people
00:16:18.120 feel about the
00:16:20.000 food this effect is called the halo
00:16:22.440 effect it is when one trait impacts the
00:16:25.560 overall perception of that thing I I do
00:16:29.120 not believe that Ruby is uh immune to
00:16:31.519 this effect I don't think that Ruby the
00:16:33.279 language is evaluated independently from
00:16:36.319 its developer experience so a new
00:16:38.440 developer wouldn't know where the
00:16:40.560 language ends and the tooling starts or
00:16:42.759 who maintains what so the developer
00:16:45.000 experience is important for a new
00:16:46.720 developer to evaluate how they feel
00:16:48.639 about ruby and what their first uh
00:16:51.680 contact with the language is how they
00:16:53.519 feel about that the question I want to
00:16:56.560 raise and the concern that I have is
00:16:58.639 could we be losing developers who are
00:17:00.440 genuinely interested in Ruby because
00:17:02.720 getting started may be a little bit more
00:17:04.600 difficult than it is in other languages
00:17:07.280 today let's take a look at another
00:17:10.160 situation if we take a look at Windows
00:17:12.880 setting up a modern development
00:17:14.520 environment on Windows is a little bit
00:17:16.520 more difficult than it is on Mac OS and
00:17:19.480 Linux and the reason for that is that
00:17:21.600 many of the tools that we use don't
00:17:23.400 support Windows in particular many of
00:17:25.919 the version managers don't support
00:17:27.640 Windows so doesn't support Windows but
00:17:30.320 also core methods of the Ruby API are
00:17:32.640 sometimes not implemented for Windows
00:17:36.640 let's take a look at some more
00:17:39.039 statistics in the latest stack Overflow
00:17:41.400 survey professional usage of Windows was
00:17:44.440 at
00:17:45.799 47% and the numbers here don't add up to
00:17:48.760 100 because you could select all of the
00:17:50.919 operating systems that you worked
00:17:53.440 with jetbrains which is a company that
00:17:56.120 makes uh developer tooling and
00:17:58.120 Commercial ID these they're very good if
00:18:00.240 you don't know them check them out they
00:18:02.240 have their own uh survey called the
00:18:04.559 stateof the developer ecosystem and in
00:18:07.200 their survey Windows usage was even
00:18:09.039 higher at
00:18:10.960 64% the rust Community survey reported
00:18:14.360 uh windows in the third place but still
00:18:17.600 with a healthy number of developers
00:18:19.600 about 32% which is roughly about a third
00:18:23.080 of the community it's a decent
00:18:25.320 number and the Ruby on Rails Community
00:18:27.760 survey reported reported about 4% of
00:18:30.600 rubyists using Windows and this number
00:18:34.440 is not actually just Windows it includes
00:18:37.200 WSL which is the Linux subsystem so the
00:18:40.840 number of people using just Windows
00:18:43.159 purely is even smaller than
00:18:45.120 that I think that when we see a number
00:18:47.679 this discrepant from the rest of the
00:18:49.360 programming Community we have to ask
00:18:51.760 ourselves what is happening exactly here
00:18:55.120 if the answer is that rubies just have a
00:18:57.440 predisposition to using EOS and maybe
00:19:00.320 there's no problem but the question I
00:19:02.440 want to raise is could we be losing
00:19:04.120 developers who are genuinely interested
00:19:06.440 in our community and maybe have a hard
00:19:08.240 time getting
00:19:11.000 started what can the future look like
00:19:13.880 for our tooling I want to be super Fair
00:19:16.960 here and mention that rust case is the
00:19:19.280 absolute exception if we take a look at
00:19:21.919 many other popular programming languages
00:19:24.000 like python JavaScript uh PHP most of
00:19:27.520 them are also frag M mented and don't
00:19:29.600 have this official cohesive story of
00:19:32.559 developer experience in fact the only
00:19:35.000 other language that I found to have a
00:19:37.240 somewhat similar experience as rust is
00:19:39.280 go which also has official tooling
00:19:41.320 that's quite
00:19:42.720 solid and there's a relationship here
00:19:45.000 between these lists the fragmented
00:19:47.679 languages are all much much older than
00:19:50.679 go and rust are which makes perfect
00:19:53.919 sense many of the techniques that we use
00:19:56.360 today didn't exist back when Ruby and
00:19:59.120 python were created so it's only natural
00:20:01.159 that the ecosystem of tooling evolved
00:20:03.559 organically and we ended up in a place
00:20:05.760 with more fragmentation whereas rust and
00:20:08.320 go had the opportunity to plan the path
00:20:11.159 ahead from the very beginning and were
00:20:13.080 able to create this compelling story for
00:20:15.039 developer
00:20:16.679 experience but there's nothing stopping
00:20:18.799 us from learning from all of the success
00:20:21.280 that rust has had and bringing that
00:20:23.400 learning to our community and in fact
00:20:25.760 there are other programming languages uh
00:20:27.760 that are catching up to this Elixir
00:20:30.559 recently announced their official
00:20:32.360 language server team which is going to
00:20:33.919 build uh Rich Integrations for the
00:20:36.400 editor for The Elixir
00:20:38.440 language and in the python land uh the
00:20:42.240 problem of having modern integrated by
00:20:44.679 default highly performing tooling was
00:20:47.039 deemed so valuable that there is a
00:20:48.520 company behind it Astro is a company for
00:20:51.440 which the mission is to create the full
00:20:53.520 Suite of next generation of python
00:20:57.159 tooling our tool buing is also becoming
00:20:59.520 more integrated but I do think that
00:21:01.000 there's still a ton of work to be done
00:21:02.600 if we want to match what we're seeing in
00:21:04.960 those communities especially in in
00:21:09.000 Rust however I do also believe that we
00:21:11.360 can have a more integrated experience
00:21:13.520 even
00:21:14.720 today and the answer for me comes from
00:21:17.159 outside of our community it comes from
00:21:19.320 the language server protocol language
00:21:22.080 servers are uniquely tailored to
00:21:24.279 integrate and aggregate with other tools
00:21:27.080 for example they can integrate with your
00:21:29.120 test framework your linter your type
00:21:31.000 Checker your formatter but today in our
00:21:33.720 community we are seeing language server
00:21:36.760 fragmentation and that of course has
00:21:38.760 consequences for the developer
00:21:40.039 experience as well if we take a look at
00:21:42.919 editors many of them have some sort of
00:21:45.679 extension hosts like a separate process
00:21:48.240 that will execute the code in your
00:21:50.039 extensions and is normally shared across
00:21:52.440 all of them if you have multiple
00:21:55.279 language servers connected in addition
00:21:57.640 to having to configure each one of them
00:21:59.520 and ensuring that they don't step on
00:22:00.960 each other's toes they're all going to
00:22:03.039 do duplicate work to index your codebase
00:22:05.679 figure out what is available and then
00:22:07.799 maintain an inmemory representation of
00:22:10.080 your entire code base which could be
00:22:12.039 several gigabytes in memory depending on
00:22:14.400 how large of a project you're working
00:22:16.600 on and then for every single operation
00:22:19.200 you do in the editor like opening
00:22:20.600 documents those operations are also
00:22:22.760 going to be replicated for each language
00:22:25.000 server which are also going to maintain
00:22:27.200 duplicate representations of all of the
00:22:29.520 documents you're interacting
00:22:31.720 with it's a lot of duplicate work for
00:22:34.760 maintainers who end up having to solve
00:22:36.679 the same problems over and over again
00:22:39.200 but it's also increased memory usage and
00:22:42.760 uh under certain conditions one language
00:22:44.919 server could potentially make the others
00:22:46.960 the other ones
00:22:49.400 slower if we could consolidate language
00:22:52.320 servers I think we could do a better job
00:22:54.559 at delivering a more integrated
00:22:56.279 out-of-the-box experience for Ruby
00:22:59.480 and of course I am incredibly biased but
00:23:02.919 the Ruby LSB may help
00:23:05.120 here we've been experimenting for a long
00:23:08.240 time now with what we're calling Ruby
00:23:10.279 LSP add-ons and this is a way for other
00:23:13.360 gems to deliver Integrations for the
00:23:15.559 editor through the Ruby LSP it's
00:23:17.919 essentially uh an API layer for the
00:23:20.320 language server so that other gems can
00:23:22.679 enhance the features that we
00:23:25.279 provide if one of your dependencies in
00:23:27.720 your project ports an add-on it will be
00:23:31.039 automatically detected and loaded so
00:23:33.360 that your experience gets more tailored
00:23:35.240 to the project that you're working on
00:23:37.240 for example uh standard the linter and
00:23:39.840 formatter recently shipped with an
00:23:42.760 add-on inside the gem if you have
00:23:45.080 standard in your gem file the Ruby LSB
00:23:47.320 will automatically pick that up and
00:23:49.480 integrate with it for
00:23:51.559 linting and alternatively addons can
00:23:54.760 also be distributed as an independent
00:23:57.039 gem which we are also have some examples
00:24:00.000 of
00:24:01.960 those there is no need to write a vs
00:24:04.559 code extension or editor plugin with
00:24:06.640 this approach there's no need to write a
00:24:09.320 brand new language server and decide how
00:24:11.640 you're going to represent documents or
00:24:14.200 how you're going to handle different
00:24:15.520 encodings coming from the editor and
00:24:18.080 there is no need to write your own
00:24:20.880 toolkit of static analysis tools to be
00:24:23.400 able to understand Ruby code all of that
00:24:25.640 is provided by the add-on API
00:24:30.159 in this scenario the Ruby LSP is a
00:24:31.840 little bit more than just a language
00:24:33.159 server but also a platform for editor
00:24:35.919 Integrations and through the add-on API
00:24:38.120 we can make the experience richer based
00:24:40.360 on what type of project the user is
00:24:42.960 currently working on we already have the
00:24:45.360 rails add-on which adds rails specific
00:24:47.960 features to the Ruby LSP we have the
00:24:50.960 rspec add-on adding support for rspec
00:24:53.559 tests as I mentioned we also have the
00:24:56.120 standard add-on which adds a link and uh
00:24:59.640 formatting for for standard if you're
00:25:02.559 using that but we can have add-ons for
00:25:05.480 any kind of tool or framework that could
00:25:08.240 benefit from providing their users with
00:25:10.679 a richer editor
00:25:12.559 experience and because everything's
00:25:14.640 going through the language
00:25:16.159 server and and the language server
00:25:18.240 connects to any editor that supports the
00:25:20.320 protocol then everything that gets
00:25:22.279 contributed by add-ons is also available
00:25:24.440 to any editor it doesn't have to be vs
00:25:27.080 code specific
00:25:29.440 and in the age of artificial
00:25:30.840 intelligence if your editor has an llm
00:25:34.240 and if it provides an API that the Ruby
00:25:36.679 LSP could use to provide extra
00:25:39.000 information to the llm then we could
00:25:41.399 make it so that the Ruby LSP will
00:25:43.640 provide extra information and extra
00:25:45.679 context based on where you're currently
00:25:47.760 editing but also based on everything
00:25:50.120 that was contributed by add-ons this
00:25:53.279 doesn't exist at the moment these apis
00:25:56.039 are not available but I'm hoping they
00:25:57.480 will be available
00:25:59.760 soon I think developer experience for
00:26:02.120 Ruby can be a lot more than just good in
00:26:05.320 fact I believe that we can lead the way
00:26:06.960 when it comes to developer experience in
00:26:08.840 highly Dynamic languages even when
00:26:11.200 there's no type system present and to me
00:26:14.320 there are two important things for us to
00:26:15.960 get there number one is considering a
00:26:18.880 unified vision for developer experience
00:26:21.760 to achieve the level of sophistication
00:26:23.760 that we're seeing in the rust Community
00:26:26.480 we need to be able to have the tools
00:26:28.559 integrate automatically and have the
00:26:30.360 tools create apis to talk to each other
00:26:33.000 building the tools in isolation will not
00:26:35.120 cut it and so to get there we also need
00:26:38.240 to coordinate our efforts join forces
00:26:41.640 and ensure that uh Ruby has a great
00:26:44.159 developer
00:26:45.559 experience thank you very much
Explore all talks recorded at RubyConf 2024
+64