What would your own version of Ruby look like? (RubyKaigi)
- 1. What would your own version of Ruby look like? Stan Lo
- 2. About Me • GitHub: st0012 • Twitter: @_st0012 • Work at Ticketsolve
- 3. I have my own version of Ruby
- 5. Today I want to share my visions of Goby
- 6. And how do they make Goby different from Ruby
- 7. Outline • Introduction about my language - Goby • How does it feel to have my own language • My visions and plans for Goby • Extensibility • Productivity
- 8. What’s Goby
- 9. What’s Goby • It’s an object-oriented scripting language • It’s written in Go • It’s largely inspired by Ruby, from syntax to internal designs
- 10. Project Status • It’s one year old now • Version 0.1.9 just released last month (0.1.10 is coming) • It has built-in libraries required for writing web applications • You can already write simple web applications
- 11. How does it feel to have my own language
- 12. It’s a very good opportunity for learning
- 13. I had a deeper understanding about • The model language - Ruby • The host language - Go
- 14. Also good for broadening my knowledge
- 15. Parser, Exception handling Concurrency and Thread-safety …etc.
- 16. Writing Documents, Managing Tasks, Fixing Issues, Reviewing PRs, Preparing Talks
- 18. Visions • It should make users as productive as possible • I want it to have great concurrency support • It can be extended with “existing” resources
- 19. Core Values • Productivity • Concurrency • Extensibility
- 20. But Goby is just one year old
- 21. We don’t have enough statistics about its concurrency performance
- 22. We’re still looking forward to optimize its concurrency
- 24. Core Values • Productivity • Extensibility
- 25. Extensibility
- 26. Ruby and Go both have mature communities and a lot of resources (libraries)
- 28. 870k + 285k > 1m
- 29. I believe it would be great if we can use those resources in an easy way
- 30. • Plugin Library • Ruby-like Syntax and Internal Design
- 31. Plugin Library
- 32. We can call Go’s packages using 100% Goby, and it’s very easy
- 33. Using go packages to ping a database
- 35. Importing packages and linking functions
- 36. Calling function on a plugin
- 37. Calling function on a Go’s pointer (or object)
- 38. This feature is now supported on both macOS and Linux
- 39. But why being able to call Go libraries is important for Goby?
- 40. Go is one of the most popular languages for writing high-traffic web applications
- 41. I thought Goby should include Go's concurrency support and libraries for helping build high-traffic apps
- 42. With Goby, you will be able to write high-traffic applications using Ruby-like syntax and object system
- 43. Ruby Compatible Syntax and Internal Design
- 45. (from my personal experience on Ruby) 80% of our code are • Defining classes • Defining modules • Defining methods • Calling methods
- 46. So theoretically, if we can provide same syntax and mechanism for doing above things
- 47. Users can easily port most of the Ruby gems to Goby with a few modifications
- 48. Why don't we support Rubygem directly?
- 49. We will introduce a library management tool for Goby’s library in next release
- 50. And integrate Go’s dependency management tool in the future
- 51. Productivity
- 52. 1. Readability 2. Consistency 3. Predictability
- 53. 1. Readability
- 54. How semantical a language is
- 55. I think Ruby’s syntax is perfectly semantical
- 56. This is why Goby has Ruby compatible syntax 😄
- 57. 2. Consistency
- 58. How many ways can a developer write the same program
- 59. In Ruby, there usually are several ways
- 60. Because Ruby is very flexible
- 61. But for Goby, I want to let it be less flexible
- 62. Because I’m sick of “best practices” or “style guides”
- 63. It takes time for community to create them
- 64. For individual developers, it also takes time to learn those practices
- 65. Most importantly, developers including me still need to adjust Rubocop settings by projects!
- 66. Let’s take a look at two Ruby “best practice” examples
- 67. Those examples are all from https://github.com/bbatsov/ruby-style-guide
- 70. Obviously, those two bad practices can be forbidden on language level
- 71. Here’s our feature and plan to make Goby programs consistent
- 72. Having Strict Syntax Rules
- 73. Let’s use ‘if’ statement as our example
- 74. • No unless keyword • No inline condition • Only one way to go
- 75. Let’s take a look at our second example
- 77. Why does this matter?
- 79. So in Goby, you need to define different types of parameters in certain order
- 80. 1. normal parameters 2. normal parameters with default value 3. keyword parameters 4. keyword parameters with default value 5. splat parameters １ 2 3 4 5
- 81. This keeps method definitions consistent
- 82. And prevents unexpected behaviors
- 83. These two examples explain about how Goby’s syntax rules are designed
- 84. Plan: Official Coding Style and Practices
- 85. • Coding Style (indentation, code alignment...etc.) • Coding Practices (naming conventions, doc comment formation...etc.)
- 86. We will have these guidances once the community grows bigger
- 87. Plan: Providing Official Formatter and Linter
- 88. Because we know programmers are lazy
- 89. So we will let users format their code with only one command
- 90. Our goal is to eliminate Rubocop settings and reduce arguments
- 92. I want to make Goby follow the “Principle of Least Astonishment”
- 93. “In general engineering design contexts, the principle means that a component of a system should behave in a way that users expect it to behave; that is, users should not be astonished by its behavior” https://en.wikipedia.org/wiki/Principle_of_least_astonishment
- 94. In Ruby, some features can sometimes make it hard to predict the code’s behaviors
- 96. Limiting the Affected Scope
- 97. I think Ruby is already using this strategy to make some features more predictable
- 104. “Refinements are designed to reduce the impact of monkey patching on other users of the monkey-patched class. Refinements provide a way to extend a class locally.” From: http://ruby-doc.org
- 105. “Refinements are designed to reduce the impact of monkey patching on other users of the monkey-patched class. Refinements provide a way to extend a class locally.” From: http://ruby-doc.org
- 106. Ruby uses refinements to limit the scope of monkey-patching
- 107. And I want to experiment the same idea on method_missing
- 108. So I made method_missing non-inheritable by default
- 109. If you don’t explicitly say you want to use method_missing, you won’t get unexpected behaviors
- 110. Bar#method_missing Foo#method_missing Method Missing In Ruby Bar.new.foo Bar#method_missing Foo#method_missing Bar.new.foo
- 111. Method Missing In Goby Bar#method_missing Foo#method_missing Bar.new.foo
- 112. In this way, we can prevent unexpected method_missing behaviors from ancestor classes or included modules
- 113. However
- 114. Sometimes we still need method_missing to be inheritable. E.g. When ‘Foo’ is an abstract class
- 115. Then you can explicitly enable it in every children classes
- 116. And now the method_missing is inherited
- 117. Because you need to explicitly enable inheritance of method_missing
- 118. You can always see what class will trigger method_missing just by looking at its definition
- 119. Exception Handling
- 121. Imagine you have your own language
- 122. Will you give it Ruby’s exception handling mechanism? Why?
- 123. How will your language handle errors?
- 124. We tend to not support exception handling in Goby
- 126. Also because it creates hidden control-flow paths
- 134. How should we deal with error if we don’t use exception handling?
- 135. We can use error object
- 139. It forces you deal with the error from the nearest place
- 140. So what’s our plan?
- 147. This feature is still work in progress, so we’re looking forward to receive any feedback
- 148. And if I had a chance, I’d be glad to share the result with you in next year’s Kaigi
- 149. To Summarize
- 150. We tend to make Goby have strict syntax rules, and provide official coding guidance
- 151. This way, developers can collaborate with each other more easily and reduce arguments
- 152. • To limit the method_missing’s affecting scope • But can be enabled explicitly Forbidding method_missing’s inheritance by default
- 153. • Treat errors as values • Avoid checking error with ‘if’ statement Developing a new class to help handling errors
- 154. • Treat errors as values • Avoid checking error with ‘if’ statement Developing a new class to help handling errors
- 155. Useful resources • “Writing An Interpreter In Go” - https://interpreterbook.com • “From NAND to Tetris - part 2” - http://nand2tetris.org • “Ruby Under a Microscope” - http://patshaughnessy.net/ruby- under-a-microscope
- 156. We are looking for more people to join us
- 157. Join us plz • GitHub: https://github.com/goby-lang/goby • Slack: https://goby-lang- slackin.herokuapp.com • Official Site: http://goby-lang.org • Twitter: https://twitter.com/goby_lang
- 158. Thanks for you listening