Summarized using AI

Beyond Ruby 3.0

Yukihiro "Matz" Matsumoto • February 02, 2021 • online • Talk

In the keynote presentation 'Beyond Ruby 3.0' by Yukihiro Matsumoto, the creator of Ruby, the focus is on the advancements made in Ruby 3.0 while ensuring its compatibility with previous versions. Matz emphasizes that the primary goal of Ruby is to create a better world for developers and users alike. Here are the key points discussed in the presentation:

  • Compatibility: Matz highlights the importance of maintaining compatibility with Ruby 2.x programs, which ensures that most applications can run without modification on Ruby 3.0. He references past struggles during major version updates that caused community splits and loss of users due to compatibility issues seen in languages like Python and PHP.

  • Performance Improvement: Ruby 3.0 introduces a Just-In-Time (JIT) compiler intended to make Ruby run three times faster than Ruby 2.0, specifically enhancing performance for CPU-intensive tasks. Matz mentions that while not every application benefits equally from the JIT compiler, benchmarks show improved performance in specific scenarios.

  • Concurrency Enhancements: With the evolution of hardware moving towards multi-core processors, Ruby 3.0 introduces two key features for concurrency: async fibers and the Ractor model. Async fibers allow Ruby to handle IO-heavy tasks more efficiently without blocking threads, while Ractors enable true parallel execution by isolating object states and limiting state sharing, thus avoiding the global interpreter lock.

  • Static Type Checkers: Addressing the rise in popularity of static typing, Ruby 3.0 aims to improve developer experience with optional type signatures and type checking, thus enhancing code quality without fully transitioning to static typing.

  • Future Development: Matz discusses the ongoing requirements for improvement in Ruby’s toolset and functionality, indicating that Ruby will continue to evolve while trying to retain its dynamic nature. Features like pattern matching and new syntax enhancements have been made to make coding more expressive.

  • Conclusion: Matz concludes by reiterating the original purpose behind creating Ruby — to contribute to a better world through effective programming. He invites the community to embrace these changes and engage with Ruby for future development.

This talk represents a forward-looking effort to address both challenges and advantages that come with Ruby's evolution while acknowledging its rich history and dedication to user needs.

Beyond Ruby 3.0
Yukihiro "Matz" Matsumoto • online • Talk

Date: February 02, 2021
Published: unknown
Announced: unknown

Beyond Ruby3 is presented by the creator of Ruby, Yukihiro Matsumoto. This was the keynote presentation at the first version of Ruby Galaxy. This talk demonstrates how Ruby3 makes progress without breaking the past. In Matz's words, Beyond Ruby3 ultimately explains Ruby's whole purpose - "to create a better world."

Ruby Galaxy v0.1

00:00:04.400 hi this is matt the creator of the ruby
00:00:10.000 today i'm going to talk about the beyond ruby 3.
00:00:15.599 so the ruby 3 uh was released under december 25th 2020 so
00:00:22.080 the we we have ruby3 finally released so that last
00:00:30.480 four or five years i i have been talking about uh the
00:00:41.120 so that but uh it's fine right there that it is compatible and it is faster
00:00:50.079 and it's better so that wonderful ruby 3 is here let me
00:00:57.840 first let me explain about the the new features and the new uh new feature of ruby3
00:01:05.760 the first important point is compatibility the almost all two point x programs
00:01:13.119 runs on rb30 that is very highly compatible
00:01:19.360 so that you know in in the past we have some uh
00:01:26.640 you know the troubles in migrating newer version but uh
00:01:33.360 this time so the almost all programs running on through all
00:01:40.079 without any modifications because the compatibility matters so we have
00:01:46.399 learned the lessons when we release that ruby 1.9
00:01:52.479 it's kind of tragedy because that we have to fix some
00:01:59.439 of the you know the misfits or the mistakes in the design language design
00:02:07.520 we had uh we had until we won eight that we had to fix
00:02:14.959 but uh it though those fix those fixes introduced
00:02:21.520 some kind of the portability issues we had some incredibility in one line
00:02:27.840 especially in encoding so that since rui19
00:02:32.959 the the ruby the fully supported unicode but to support unicode
00:02:40.720 we have to change the we have to change the encoding support
00:02:46.080 of the strings so there's you have to
00:02:52.000 modify or update your pro applications uh when you have to migrate from one a
00:02:59.440 to one nine so the the people made different decisions
00:03:05.920 some people stay using the the old one eight for a long long time
00:03:13.360 the the other part of the community the moved forward to one one
00:03:20.239 nine and then the force coming to o and to one or such that
00:03:27.200 we had some kind of the community split for more than five years the
00:03:33.840 you know the some people stay you stayed using one eight
00:03:40.640 kept away from our new features well our new our improvement for a long
00:03:48.400 long time the similar situations had
00:03:54.080 happened in other languages too for example the python3 had some
00:03:59.280 compatibility issues php 6 had a very
00:04:06.400 you know the brave change but you know the many of the community did
00:04:12.640 not want that kind of the big change with incompatibility so that the project itself was cancelled
00:04:20.479 this very similar things happened in the ecmascript 4 the ecmascript 4 was cancelled as well
00:04:29.440 but that's you know we language designers are memorized
00:04:36.080 so that we did make mistakes that
00:04:42.960 you know there are several issues and uh features that i don't like
00:04:50.400 in even in the ruby tree but you know i
00:04:57.680 want i really really wanted to fix them but uh those fix introduced
00:05:06.080 uh introduces uh those fix would introduce the incompatibility which is very very
00:05:12.479 bad so that i mostly most of them i gave up to picks
00:05:23.280 we we language designers really really want to fix those mistakes
00:05:28.400 but uh uh you know it's kind of the you know the self-satisfaction
00:05:35.440 so that it's no use for the users so that except for the little bit
00:05:43.199 cleaner language no it's no use but mostly uh
00:05:51.120 so that i you know it was very tempting to fix those
00:05:57.199 mistakes in the major releases like uh ruby two all v3o
00:06:02.560 but uh we have learned when we released when we will be one
00:06:08.720 night the compatibility matters so that you know even in the
00:06:14.240 major releases we do not we would not make those
00:06:22.479 no incredible changes
00:06:27.600 so the and uh we
00:06:32.639 you know as i said before the the major version upgrade is tempting to make up
00:06:40.080 that so that we can make uh incomparable changes but
00:06:46.840 no the we already had those many tragedies
00:06:54.560 rule one nine person three php six sigma four so that ruby three we
00:07:01.280 would not be like that the programmers love new things yes but
00:07:07.360 uh programmers hate paying for new things but i don't want
00:07:13.199 punish them from the newer version of the language
00:07:19.039 compatibility matters that's the lesson uh we we've learned uh
00:07:27.599 the progress we need to make progress we are open source we have to keep
00:07:34.319 moving forward but that we have to make progress without breaking the past
00:07:41.440 so we should keep compatibility we try to keep full compatibility
00:07:47.440 now we had very many new features in ruby 30 but basically we try to
00:07:54.960 uh those new features try to make those new features done keeping compatibility
00:08:03.039 but uh yeah i admit except for a few bucks
00:08:09.599 some programs can rely on the buggy behavior in the past so that we had to we had to fix them
00:08:17.039 that those very small amount of applications which
00:08:23.280 relies on the buggy behavior need to be fixed but uh except that ruby 3
00:08:30.960 will keep the compatibility the second one the performance
00:08:40.640 as much as uh as much as performance i i mean the atmospheric compatibility
00:08:46.560 the performance matters yeah as i told you we had the ruby one
00:08:52.320 night tragedy and then the five-year community split but uh
00:08:57.360 signature tragedy happened in python the python 3 problem but they had more than 10 years
00:09:06.000 of the community split the we had five years they had the 10
00:09:11.920 plus years so what the difference i believe this difference caused by the yav which
00:09:19.440 is the new virtual machine introduced in the ruby one nine but
00:09:24.720 the that new version machine was far faster than one eight the previous versions but
00:09:31.200 the performance matters so that uh people uh
00:09:38.240 most most of the people willing to pay the price of migrating to newer version if
00:09:45.360 they can get the the you know the better performance but so the performance matters
00:09:54.000 that's why we have introduced the jet compiler
00:09:59.200 just in time compiler with a which dynamically generous native gold
00:10:04.480 the the code name of the our jit compiler is mj since ruby 29 to
00:10:11.120 achieve the ruby 3x3 which is which means that the ruby
00:10:18.640 ruby 3 will run three times faster than the previous ruby will be 2.0
00:10:25.760 and in some benchmarks in some benchmarks we have achieved will be run three times
00:10:32.880 faster in some benchmarks especially the optic characters optical is the very cpu intensive
00:10:40.560 benchmark task which is a very which uh the zit compiler works very
00:10:47.279 effectively on that benchmarks but uh unfortunately not in various
00:10:53.120 applications yet uh the first version the ruby uh ruby 2.6 jet
00:11:01.839 where the application runs two times slower using jet compiler
00:11:09.120 but now ruby 3-0 it's almost same performance within without
00:11:15.120 yet that's that's much better but uh you know we expect faster rares
00:11:22.959 applications but we are working on it we are improving so that
00:11:28.800 uh with micro benchmarks we are doing very very very good for this complete
00:11:35.600 compiler but uh yeah we are making more progress
00:11:41.279 the more vm motivation to come so the to improve performance we are
00:11:47.600 also uh working on the concurrency as well
00:11:53.360 uh 1993 when i first started
00:11:59.600 developing ruby generally at that time one cpu
00:12:07.200 for a machine for a computer but when you buy new computer your software
00:12:14.000 run faster yeah it was good time but we have no free launch any longer
00:12:22.800 single core performance is saturated but we are now under the multi-core age
00:12:29.360 we have a lot of cores in the computers we have the dual chrome machines after
00:12:36.560 uh the quad-core machines octa-core machines or even the you know the 100 cores
00:12:43.680 in the chip on the server several machines
00:12:50.240 so that you know your core octa core 64 core or even 128
00:12:55.519 cores and thread reapers but so you have to
00:13:01.920 use more cores to upgrade the better performance in these days
00:13:08.720 but uh in that means the concurrency is a key but uh unfortunately ruby vm has
00:13:16.320 gel uh giant interpreter lock the because the threat says runtime is
00:13:23.120 very hard especially for existing languages
00:13:29.200 but uh we have to improve our concurrency
00:13:34.320 to use multiples the the by the existing
00:13:40.639 uh due to the existing like the global integrity lock so we are safer our virtual machine
00:13:47.839 would not crash when we arrived in the threads but uh
00:13:53.600 that we cannot use the the multi cores fully
00:14:02.079 that we have to improve that the our key ideas are the introducing
00:14:09.440 two new things in the world three one is the async fiber async fiber the the second one is rocker
00:14:18.720 now let me introduce the aging fiber first the aging fiber is designed for iotv
00:14:24.880 tasks like a web server or the some kind of the you know the i o heavy
00:14:32.240 programs look at you know the these days
00:14:37.519 some languages introduce the aging and their weight in in their their syntax for example
00:14:43.639 javascriptization generate the python calculation generate and then the c-sharp position gonna wait
00:14:51.680 so that those languages are along this as well so that has those kind of the
00:14:58.120 asynchronous uh task processing to introduce that
00:15:03.199 that no i o multiple multiplication
00:15:09.279 uh the ruby3 we do that async io with fibers
00:15:16.720 so we we use fibers we are not going to add any new keywords like aging and avoiding
00:15:22.959 the language then the in the
00:15:28.320 h under the asian fibers the context switches on any other operations which blocks that
00:15:36.240 you you you know the control of threads can be
00:15:43.360 switched back and forth on the eye operations or the blocking operations
00:15:50.480 so to use the the aging fiber so you need to specify the fiber scheduler
00:15:58.320 the the important thing is the asian fiber doesn't use multi-cores we just multi multiple gauged the
00:16:05.360 uh the eye operations to you know to utilize the core
00:16:12.639 more effectively you know that by using
00:16:17.839 by using a traditional block operations the you know the cpus just wait for io
00:16:26.160 and then by using threads the you know the cpu does not
00:16:33.759 uh block but its context switch is heavier than fibers but by using fibers
00:16:41.759 we are lightweight context switching we have the lightweight cons constant at context switching and then
00:16:49.600 we have the the multiplication of the the i operation the blocking operation
00:16:56.880 the first statement uh context switching is very good look at yeah
00:17:04.480 remember for example uh the node.js itself is single threaded but uh it's
00:17:10.880 fast because of that no this kind of the the asynchronous process task processing
00:17:17.919 by using the asian promises and the aging and weight so that
00:17:23.280 similar things could happen in using the
00:17:29.600 using the aging fiber yeah we will get the faster performance
00:17:36.000 for the io heavy tasks for example the falcon which is the application server will be
00:17:42.720 yeah using the fibers
00:17:48.400 achieve the performance using these fibers this this is a very similar idea actually the newer
00:17:55.200 version of the falcon and the asic gem used the
00:18:00.480 fiber schedule the async fiber and then actually the the person in charge of the
00:18:06.400 asian fiber is the samuel williams which is the author of the falcon
00:18:11.760 application starter so the you know the asian fiber does not use
00:18:18.160 the multi-cores so now how can we use multi-core for city intensive tasks
00:18:26.400 for that purpose we provide a raptor which stands for the ruby act
00:18:33.360 uh ruby raptor is uh basically isolated the object space
00:18:40.400 the communication via the sort of channels there are no state sharing or actually
00:18:46.640 the limited sharing the objects which are immutable
00:18:53.280 and recursively frozen with classroom module can be shared between practice no other
00:19:01.679 object are
00:19:06.720 not shareable so that we don't have the gill between reactors
00:19:12.320 so that that means that we can use the multi equals that we can fully
00:19:20.160 utilize the multi-core without the blocking lock this is a very
00:19:28.000 stupid rocket benchmark we make the terrain
00:19:35.200 benchmark function then the first one is the the sequential
00:19:42.480 calculation of the tri function for four times then the the second one is the
00:19:49.760 create the four raptors then collected the terrain function uh try function
00:19:57.039 in parallel in four four times the this is a very
00:20:04.320 stupid an artificial benchmark but uh this under this benchmark the
00:20:10.960 the power version runs 3.8 times faster than sequential version that
00:20:18.000 means that you know nearly theoretical uh
00:20:25.440 scale of the the performance boost uh this is the additional ones so that
00:20:32.159 i don't i don't claim that every uh function should be should act like that
00:20:40.320 create that kind of the performance boost but at least it will show us the possibility
00:20:47.120 of using multi-core so the ruby 3.0 should be
00:20:52.240 better language for the we're going to find the more bugs
00:21:01.039 uh at the age of the static typing you know aft the these days
00:21:08.640 you know after 20 tens 20 years since 2010
00:21:15.840 the static type programming language are very very popular i became very very popular gold
00:21:21.679 rush sweet and many other languages
00:21:27.039 are very popular so the the dynamic programming language like
00:21:32.720 python php and javascript went to some some kind of the half
00:21:40.480 static type programming language php other type degradation the python are the type
00:21:47.679 hints the typescript is the the static type version of javascript now they are very
00:21:54.320 popular but yeah it i feel like we feel like
00:21:59.679 you know everyone goes uh static typing so that shall we
00:22:06.880 i don't think so uh we don't want type declarations
00:22:12.400 but we do want more precise checks and that we do want to declare all year
00:22:19.120 and we do want cod completion based on types but uh we introduced the static type
00:22:27.039 chips for better our programming experience to achieve that we
00:22:34.960 added the device signatures and the type of ruby signature is the some coming that
00:22:41.600 typescript dot d dot ts from counterpart which is the type description language
00:22:49.440 that you can i descripted the class and the methods with
00:22:56.080 its type information the ruby three ships with the rbs
00:23:02.400 signatures for the core and uh some gens ships with the core if once we had
00:23:10.320 enough type information from the signatures so we will get the type checker static
00:23:17.280 type type first or the better id with better code completions or type signature pop-ups that
00:23:25.200 we would have we we will have a better programming
00:23:31.520 experience through the editors and editors and ide
00:23:37.039 the type prof is another uh artifact receipt with ruby3
00:23:43.600 the it it does the naive type checks based on the signature and it generates
00:23:50.640 the the signature for your applications the prototype of the signature i mean
00:23:57.520 for example you have this kind of the ruby program that we define class food the method
00:24:03.600 food and the bar and then method food takes argument a and then returns b and then by is the
00:24:12.159 similar but uh look at the definition of the method bar the it as the a plus
00:24:21.840 string two but uh the later the
00:24:28.880 recreate the full objects
00:24:37.760 then so the full object are full method with the argument integer and the bar
00:24:46.000 method with argument integer the argument takes integer
00:24:51.360 so a is integer but uh a integer plus strings is error so that we
00:24:58.960 the type pro will want to error type error then type profile generates uh the
00:25:07.360 the signature the this technique is used abstract interpretations
00:25:12.480 so they are using those abstract interpretation are the always generate the class foo
00:25:19.360 has method foo that takes integer and returned integers the cross bar has ah the i mean the
00:25:25.760 method bar has uh the type error so that it's not included in the generated signatures
00:25:34.240 the we want even better ruby so that we add new syntax for for example the pattern matching and
00:25:39.919 the number of parameters parameting is like this you know
00:25:46.080 you match the pattern for the past adjacent to find the person and alice whose
00:25:52.720 children is as far and then print the edge of the of some bob
00:26:01.919 and then we also added the one line pattern matching like uh you know it can be used as a
00:26:08.400 submit assignment it can be used as the the multi assignment
00:26:14.960 it can be used with the decomposition the you know sometimes very useful
00:26:22.640 when we added the number of block parameters the one two three maps uh first argument
00:26:30.080 times two now that's simple now this these are compatible very
00:26:37.919 small changes but you know it enhances you
00:26:45.279 to write shorter and more you know clear programs
00:26:52.320 but now we have ruby three three oh hold up
00:26:59.200 okay let me talk about the beyond three three
00:27:05.679 the root i'm very satisfied with the root vio in the direction we go
00:27:12.960 but i'm not satisfied with the status of the
00:27:20.080 feature completion so we need to improve our implementations
00:27:26.480 this should be faster and we need to fix small bugs and then you
00:27:33.360 know and uh we need to add more new
00:27:38.559 features so that some new features may be buggy and then some new features
00:27:45.440 maybe the feature incomplete so we especially rockets but that we need to
00:27:51.360 improve that kind of things but basically the direction is correct
00:27:56.720 but uh we need to see completions but uh and also we
00:28:04.320 are going to uh improve the the sporting tools for ruby programming
00:28:10.000 for example the solar glass the language server protocol server which can be
00:28:17.760 used as that you know the ide
00:28:22.799 the command id programs we have solved and steve as a static type checker so that we can
00:28:28.880 be improved those things by you know the supporting the ruby signature or the more interaction
00:28:37.360 with the people the robocop is the very uh useful uh linting tool but uh
00:28:44.480 i think the signature or the new the really new features can
00:28:50.640 improve the robocop for better experience the better tools enable better user experience
00:28:57.120 so that by using those tools we will have the better ruby
00:29:04.080 programming experiments experience
00:29:09.120 so that we need more tools to improve uh type checkers promoters
00:29:15.600 language server protocol the performance tuning debugger whatever so that by
00:29:21.760 adding by improving those tools we will have the better uh
00:29:28.159 productivity but i'm not going to add you know static
00:29:34.720 typing order we are not going to change the language that much but adding those tools improving to
00:29:42.960 tools that will enhance your ruby productivity
00:29:50.720 at the last but not least i want faster will be
00:29:56.399 people trust micro benchmarks the i see many many
00:30:03.039 many cases through uh people
00:30:10.000 decide languages based on micro benchmarks
00:30:15.120 i hate that but the repetition is formed by micro benchmarks
00:30:23.039 that yeah i admit it's it's kind of sad
00:30:31.200 but okay okay we will improve the performance for micro
00:30:37.600 benchmarks whether we are going to add a better jet or perhaps this is just idea yet
00:30:45.840 but uh perhaps we are going to add a multi-layer jet
00:30:52.080 the we have the m-jet but uh we uh we are going to add
00:30:58.880 we might uh be going to add the lightweight
00:31:04.000 jit the in front of the mj which might be based on the meal or
00:31:12.000 the nasa and uh yeah raptor performance should be
00:31:17.360 improved too to have the even more performance improvement
00:31:23.840 and uh the last one is just my crazy idea but a static barrier is one of them so
00:31:30.159 that you know in ruby the ruby is very very dynamic programming
00:31:36.480 images but the some dynamic aspect of the language will be
00:31:41.679 will be prohibited beyond this barrier so that
00:31:48.159 upon after this barrier the for example the method definition
00:31:54.720 is prohibited so that the method cash will work more efficiently
00:32:00.559 and this compiler can be more efficient so that we can have the
00:32:08.559 more say performant and more optimized friendly will be
00:32:16.159 without hindering the the nature of the language
00:32:23.679 anyway uh at least i promise we will keep moving forward
00:32:30.000 the ruby we will improve ruby we will keep moving forward
00:32:38.960 to create a better world i breed ruby and it's very ruby is very good
00:32:45.760 like excellent programming language yeah that's why i created ruby
00:32:51.279 with it the whole purpose of the existing of ruby is to create a
00:32:58.320 better world so that i i'm very honored
00:33:04.000 so many people use ruby and there's so many people use movie for to
00:33:10.480 create great applications whether github is uh based on ruby and their shopify is
00:33:17.200 based on ruby and the quickbooks is based on ruby the those applications those services
00:33:23.600 improve the world to for better so that
00:33:31.360 i'm very honored to the the part of this great work to improve the world
00:33:36.480 and i invite you to join us to make a better world by using ruby
00:33:43.840 by supporting ruby and uh by enjoying programming with ruby
00:33:50.480 thank you
Explore all talks recorded at Ruby Galaxy v0.1