The state of Ruby tooling

This talk analyzes the current state of developer experience in Ruby. Currently, there's a high level of fragmentation for Ruby tooling and no official default experience that new developers can expect. The presentation compares that scenario with Rust, an example of a highly consolidated ecosystem and what we could do to deliver a better developer experience for Ruby out of the box.

In addition to that, the presentation also aims to foster more collaboration and coordination between tool maintainers, so that all tools that compose our ecosystem can build towards a highly integrated experience in the future.

Transcript

1. Vinicius Stock The state of Ruby tooling
2. Vinicius Stock Sta ff dev Ruby DX team @ Shopify X / GitHub: @vinistock https://vinistock.com
3. Is having options a good thing?
4. Flexibility, freedom, autonomy
5. Sources: When Choice is Demotivating: Can One Desire Too Much of a Good Thing? - Sheena S. Iyengar, Mark R. Lepper 2000 Journal of Personality and Social Psychology, 2000, Vol. 79, No. 6, 995-1006 • consider smaller portion of the available information • simplify their decision making • prefer the default option • make no choice at all When Choice is Demotivating: Can One Desire Too Much of a Good Thing? Complexity Options choice overload
6. Today, I want to talk about options in the context of developer experience
7. Where is the Ruby community currently at in terms of developer experience (DX)?
8. It’s common to hear that tooling for Ruby is di ff i cult to make because it is too dynamic
9. I don’t believe that’s the main source of di ff i culty with tooling
10. The main challenge for a modern developer fragmentation experience in Ruby is
11. Story of a new developer
12. They want a complete developer experience while trying Rust and Ruby
13. How to manage Rust? Rustup
14. Tests? Built-in
15. Formatting? Rustfmt
16. Linting? Clippy
17. Language server? Rust analyzer And so on
18. Rust’s well integrated experience didn’t happen by accident Source: https://www.rust-lang.org/governance/teams/dev-tools Rust has a dedicated developer tooling team Responsible for designing a cohesive experience and coordinating e ff orts
19. Modern default tools + guidance Consolidated tooling Easy integration Minimal decisions Reduced learning curve Minimal con fi guration High collaboration
20. Direnv RubyInstaller Shadowenv Mise asdf chruby Frum rbenv rvm Homebrew How to manage my Ruby install? ruby-install
21. Tests? Test Unit Minitest RSpec Sus Cucumber
22. Types? TypeProf Steep RDL YARD Sorbet
23. Formatting /linting? Syntax Tree Standard Rubyfmt Rufo RuboCop Reek
24. Language server? TypeProf Steep Ruby LSP Solargraph Sorbet RuboCop LSP Standard LSP Syntax Tree LSP Continues…
25. Rust: 1 combination Ruby: 13200 combinations Considering: • Full experience • Single choice • Lists not exhaustive
28. Project A Project B Open source project C asdf No typing RuboCop RSpec rbenv Steep / RBS Standard Test Unit Mise Sorbet Rubyfmt Minitest
29. Missing defaults and guidance Dif fi cult integration Excessive decisions for new developers Tooling fragmentation Too much con fi guration Spreading our efforts Steeper learning curve Community driven tools DX design is delegated
30. JavaScript is another fragmented ecosystem Source: https://survey.stackover fl ow.co/2023/#technology-most-popular-technologies But they have a much larger community JavaScript: 63.61% Rust: 13.05 % Ruby: 6.23% We can’t a ff ord to divide our e ff orts
31. Contributors (not unique) Sorbet + Steep + Solargraph + Ruby LSP + TypeProf = Rust Analyzer = 816 603
32. Building new tools might make sense More tools != Better experience We need to consider the big picture of DX DX is not about any one tool. It’s about the combination of them
33. Sources: When Choice is Demotivating: Can One Desire Too Much of a Good Thing? - Sheena S. Iyengar, Mark R. Lepper 2000 Journal of Personality and Social Psychology, 2000, Vol. 79, No. 6, 995-1006 • make no choice at all When Choice is Demotivating: Can One Desire Too Much of a Good Thing? • consider smaller portion of the available information • simplify their decision making • prefer the default option
34. • make no choice at all Evaluating the alternatives requires too much e ff ort
 
 Best case: having a worse developer experience Worse case: deciding to not try Ruby
35. • prefer the default option Our defaults are so good they don’t have to choose
36. Using the tools is not the final goal Tools are a stepping stone. The goal is to build things Setting up your development environment should be e ff ortless So that developers can fully focus on what they want to build
37. Tools as project dependencies
38. In Ruby, it’s common to add tools as project dependencies But why? # Gemfile group :development do gem “formatter” gem “debug” end
39. Version consistency in the same project But not much else
40. Rust components rustup component add rustfmt clippy rust-analyzer
41. Tools installed globally Version consistency in any project Auto-updates Global installation already in the PATH Reduced maintenance Tools can easily integrate with the project’s dependencies
42. Could we do the same?
43. What can the future look like for tooling?
44. Rust’s case is the exception Fragmented • Ruby • Python • JavaScript • C / C++ • Java • PHP Consolidated • Rust • Go 1995 1991 1995 1970s / 1985 1996 1995 2015 2009
45. Nothing stops us from learning from Rust’s success
46. There’s already a move towards consolidation Prism is unifying all static analysis e ff orts
47. Prism Prism::Index Code mods Ruby LSP Linter Type checker Formatter RDoc Deprecation framework
48. This is very long term, but we can achieve it The challenges for a modern developer experience are not technical So what’s missing?
49. • Is it coordination? • Is it collaboration? • Is it governance? Do any of these look like a problem we can’t solve?
50. How to have a more integrated experience right now?
51. Language server protocol But now we have language server fragmentation
52. Language server 3 Code index Language server 2 Code index Language server 1 Code index Extension host Document 1 Document 1 Document 1 Open document 1 Open document 1 Open document 1 Editor Indexing…
53. • Duplicate work • Increased memory usage • Each language server can potentially make the other slower
54. If we consolidate language servers, we can do a better job at integrating the rest of the ecosystem
55. The Ruby LSP can help
56. Ruby LSP addons Source: https://github.com/Shopify/ruby-lsp/blob/main/ADDONS.md A way for other gems to deliver integrations in the editor
57. Ruby LSP addons • No need to write a VS Code/editor extension • No need to write a brand new language server Source: https://github.com/Shopify/ruby-lsp/blob/main/ADDONS.md • No need to build your own static analysis tools
58. Encoding helpers Ruby LSP Codebase index Addon Static tools Response builders Type resolver
59. Language server Code index Extension host Document 1 Editor Rails addon Test addon Linter addon Type checker addon
60. Ruby LSP addons • Ruby LSP Rails https://github.com/Shopify/ruby-lsp-rails • Ruby LSP RSpec https://github.com/st0012/ruby-lsp-rspec • Internal integrations with RuboCop, Syntax Tree, Minitest and Test Unit Source: https://github.com/Shopify/ruby-lsp/blob/main/ADDONS.md
61. The most important steps to advance Ruby developer experience: • Consider the big picture • Coordinate our e ff orts
62. Thank you