What would your own version of Ruby look like?
- 1. What would your own version of Ruby look like? Stan Lo
- 2. About Me • GitHub: st0012 • Twitter: @_st0012 • Work at Ticketsolve
- 5. I have my own version of Ruby
- 7. Today I want to share my visions of Goby
- 8. And how do they make Goby different from Ruby
- 9. Outline • Introduction about my language - Goby • How does it feel to have my own language • My visions and plans for Goby • Extensibility • Productivity
- 10. What’s Goby
- 11. 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
- 12. Project Status • It’s one year old now • Version 0.1.9 just released last month • It has built-in libraries required for writing web applications • You can already write simple web applications
- 13. Project Status • More than 2600 stars • 4~6 regular contributors • 40+ slack members • https://goby-lang-slackin.herokuapp.com
- 16. Editor Plugins
- 17. How does it feel to have my own language
- 18. It feels quite heavy
- 19. I have lots things to learn
- 21. I also have lots things to plan
- 22. Next release, Next 3 months, Next year
- 23. Besides these, I have more things to do
- 24. Writing Documents, Managing Tasks, Fixing Issues, Reviewing PRs, Preparing Talks
- 26. But on the other hand, I also gained a lot from developing Goby
- 27. I can meet some brilliant engineers
- 28. It feels great when people recognize your work
- 29. I can apply my ideas on the language
- 30. Visions • It should make users as productive as possible • I want it to have great concurrency support • It can be extended with “existing” resources
- 31. Core Values • Productivity • Concurrency • Extensibility
- 32. But Goby is just one year old
- 33. We don’t have enough statistics about its concurrency performance
- 34. We’re still looking forward to optimize its concurrency
- 35. Core Values • Productivity • Extensibility
- 36. Core Values • Productivity • Extensibility
- 37. Extensibility
- 38. Ruby and Go both have mature communities and a lot of resources (libraries)
- 40. 870k + 285k > 1m
- 41. I believe it would be great if we can use those resources in an easy way
- 42. • Plugin Library • Ruby-like Syntax and Internal Design
- 43. Plugin Library
- 44. We can call Go’s packages using 100% Goby, and it’s very easy
- 45. Using go packages to ping a database
- 47. Importing packages and linking functions
- 48. Calling function on a plugin
- 49. Calling function on a Go’s pointer (or object)
- 50. This feature is now supported on both macOS and Linux
- 51. But why being able to call Go libraries is important for Goby?
- 52. Go is one of the most popular languages for writing high-traffic web applications
- 53. I thought Goby should include Go's concurrency support and libraries for helping build high-traffic apps
- 54. With Goby, you will be able to write high-traffic applications using Ruby-like syntax and object system
- 55. Ruby Compatible Syntax and Internal Design
- 57. (from my personal experience on Ruby) 80% of our code are • Defining classes • Defining modules • Defining methods • Calling methods
- 58. So theoretically, if we can provide same syntax and mechanism for doing above things
- 59. Users can easily port most of the Ruby gems to Goby with a few modifications
- 60. We will introduce a library management tool for Goby’s library in next release
- 61. And integrate Go’s dependency management tool in the future
- 62. Productivity
- 63. • Readability • Consistency • Predictability
- 64. Readability
- 65. How semantical a language is
- 66. I think Ruby’s syntax is perfectly semantical
- 67. This is why Goby has Ruby compatible syntax 😄
- 68. Consistency
- 69. How many ways can a developer write the same program
- 70. In Ruby, there usually are several ways
- 71. Because Ruby is very flexible
- 72. But for Goby, I want to let it be less flexible
- 73. Because I’m sick of “best practices” or “style guides”
- 74. It takes time for community to create them
- 75. For individual developers, it also takes time to learn those practices
- 76. Most importantly, developers including me still need to adjust Rubocop settings by projects!
- 77. Let’s take a look at two Ruby “best practice” examples
- 78. Those examples are all from https://github.com/bbatsov/ruby-style-guide
- 81. Obviously, those two bad practices can be forbidden on language level
- 82. Here’s our feature and plan to make Goby programs consistent
- 83. Having Strict Syntax Rules
- 84. Let’s use ‘if’ statement as our example
- 85. • No unless keyword • No inline condition • Only one way to go
- 86. Let’s take a look at our second example
- 88. Why does this matter?
- 90. So in Goby, you need to define different types of parameters in certain order
- 91. 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
- 92. This keeps method definitions consistent
- 93. And prevents unexpected behaviors
- 94. These two examples explain about how Goby’s syntax rules are designed
- 95. Plan: Official Coding Style and Practices
- 96. • Coding Style (indentation, code alignment...etc.) • Coding Practices (naming conventions, doc comment formation...etc.)
- 97. We will have these guidances once the community grows bigger
- 98. Plan: Providing Official Formatter and Linter
- 99. Because we know programmers are lazy
- 100. So we will let users format their code with only one command
- 101. Our goal is to eliminate Rubocop settings and reduce arguments
- 102. Predictability
- 103. I want to make Goby follow the “Principle of Least Astonishment”
- 104. “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
- 105. In Ruby, some features can sometimes make it hard to predict the code’s behaviors
- 107. Goby’s two approaches to be more ‘predictable’
- 108. Limiting the Affected Scope And Making the Target Explicit
- 109. Limiting the Affected Scope
- 110. I think Ruby is already using this strategy to make some features more predictable
- 111. Like ‘Refinements’
- 117. “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
- 118. “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
- 119. Ruby uses refinements to limit the scope of monkey-patching
- 120. And I want to experiment the same idea on method_missing
- 121. I want to make method_missing non- inheritable by default
- 122. If you don’t explicitly say you want to use method_missing, you won’t get unexpected behaviors
- 123. Bar#method_missing Foo#method_missing Method Missing In Ruby Bar.new.foo Bar#method_missing Foo#method_missing Bar.new.foo
- 124. Method Missing In Goby Bar#method_missing Foo#method_missing Bar.new.foo
- 125. In this way, we can prevent unexpected method_missing behaviors from ancestor classes or included modules
- 126. However
- 127. Sometimes we still need method_missing to be inheritable. E.g. When ‘Foo’ is an abstract class
- 128. Then you can explicitly enable it in every children classes
- 129. And now the method_missing is inherited
- 130. Because you need to explicitly enable inheritance of method_missing
- 131. You can always see what class will trigger method_missing just by looking at its definition
- 132. Making the Target Explicit
- 133. ‘Super’ With Explicit Target
- 134. Actually, I want to replace ‘super’ with ‘super_from’
- 135. super super_from
- 136. The only difference will be that you need to specify your 'super' target in the first argument
- 137. super super_from
- 138. This has two benefits
- 139. You can easily understand where to find the ‘super’ed method
- 140. I will explain the origin of this idea using my personal experiences
- 141. One day I was trying to find a super’s source from our codebase’s monkey-patching
- 142. I think it might refer to another module in ActiveRecord
- 143. So I checked the source code, and found this
- 146. I found that ActiveRecord includes 30+ modules
- 147. And none of them implement the ‘to_json’ method
- 148. It turns out the 'super' refers to ActiveSupport::ToJsonWithActiveSupportEncoder
- 149. So I was thinking
- 150. It would be great if the ‘super' can just tell us where it refers to
- 151. Like this
- 152. It will be a little verbose
- 153. But also makes it far more easier to predict the code’s behaviors
- 154. The freedom to specify any ancestors as source
- 157. These two features will be implemented in Goby in next few months
- 158. To Summarize
- 159. We tend to make Goby have strict syntax rules, and provide official coding guidance
- 160. This way, developers can collaborate with each other more easily and reduce arguments
- 161. • To limit the method_missing’s affecting scope • But can be enabled explicitly Forbidding method_missing’s inheritance by default
- 162. • To force users to specify super’s source • Also allows users to choose source Use ‘super_from' to replace ‘super’
- 163. We are looking for more people to join us
- 164. 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
- 165. Thanks for you listening