Opening Keynote - Good Change, Bad Change
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 69 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/37788 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | |
| Genre |
Ruby Conference 201729 / 69
2
5
8
11
13
19
20
21
32
33
34
35
37
40
43
44
52
54
55
56
57
58
62
64
65
67
00:00
MathematicsAssociative propertyComputer virusBitPresentation of a groupCommitment schemeMereologyField (computer science)SummierbarkeitSampling (statistics)XMLUMLLecture/Conference
01:37
Scripting languageData typeFormal languageGroup actionDifferent (Kate Ryan album)Projective planePartition (number theory)Bit ratePhysical lawSoftwareArithmetic meanWordBitCodeMultiplication signFormal languageDivision (mathematics)Endliche ModelltheorieNumerical analysisLine (geometry)State of matterQuicksortCountingGame theorySet theoryCASE <Informatik>SummierbarkeitOffice suiteJava appletAbstractionMathematicsSoftware developerSource codePerfect groupTerm (mathematics)Euler anglesNamespaceSocial classRing (mathematics)Gastropod shellVirtualizationLecture/Conference
08:37
Physical systemHuman migrationElement (mathematics)Exclusive orFrustrationState of matterConservation lawArithmetic progressionPhysical systemMultiplication signPoint (geometry)ChainSequenceVideo gameGroup actionFigurate numberInverse elementHypermediaReal numberMathematicsDivision (mathematics)Control flowServer (computing)Capability Maturity ModelRight angleElement (mathematics)ForceFrustrationGoodness of fitHuman migrationFormal language2 (number)MereologyRevision controlProjective planeOpen sourceLecture/Conference
15:21
Formal languageJust-in-Time-CompilerCompilerRead-only memoryLibrary (computing)Address spaceHash functionPrice indexMatching (graph theory)Constraint (mathematics)Library (computing)Semiconductor memoryComputing platformHash functionMultiplication signJust-in-Time-CompilerGame controllerProduct (business)Address spaceFormal languagePortable communications deviceVirtualizationLocal ringVariable (mathematics)ResultantImplementationOcean currentBranch (computer science)Heat transferMathematicsRepresentation (politics)Physical systemOpen setNeuroinformatikRevision controlFocus (optics)Programmer (hardware)Virtual machineBefehlsprozessorState of matterWordCASE <Informatik>MereologyRing (mathematics)Sampling (statistics)ReliefAuthorizationGraph coloringCommunications protocolTheorySocial classStandard deviationInterpreter (computing)Particle systemCuboidFreewareView (database)Reading (process)Computer programmingAnnihilator (ring theory)VideoconferencingVideo gamePhysical lawData conversionObservational studyBlock (periodic table)Water vaporLecture/Conference
25:12
Price indexRead-only memoryJust-in-Time-CompilerMachine codeImplementationCompilerStructural loadBenchmarkComplete metric spaceAverageTracing (software)Error messageExplosionAdditionCodeJust-in-Time-CompilerMachine codeNintendo Co. Ltd.CodeBenchmarkMultiplication signLengthCuboidSequenceError messageImplementationInheritance (object-oriented programming)Default (computer science)AdditionBefehlsprozessorAsynchronous Transfer ModeTouchscreenCombinational logicPoint (geometry)VirtualizationResultantGraph coloringBitThread (computing)Software testing1 (number)Real numberSemiconductor memoryComputer fileCompilation albumMathematicsSoftware developerLocal ringSet theoryVariable (mathematics)DebuggerAverageRepresentation (politics)String (computer science)Social classStandard deviationFormal languageLibrary (computing)Decision theoryEqualiser (mathematics)Natural numberCovering spaceBuildingConnectivity (graph theory)Client (computing)Endliche ModelltheorieParameter (computer programming)Lie groupOpticsSequelVarianceSampling (statistics)Online helpPhysical systemLine (geometry)Type theoryMereologySoftwareComplex (psychology)Numerical analysisElectronic mailing listComputer programmingCASE <Informatik>Lecture/Conference
35:04
String (computer science)Default (computer science)Read-only memoryReal numberPattern matchingBacktrackingData modelConcurrency (computer science)MultiplicationInflection pointKolmogorov complexityData typeFluid staticsMathematical analysisFormal languageComputer programmingType theoryDecision theoryExpert systemForm (programming)Strategy gameOffice suiteLie groupBit rateDivisorWebsiteFactory (trading post)Slide ruleMappingLibrary (computing)Operator (mathematics)Product (business)Strategy gameStress (mechanics)Complex (psychology)Group actionDependent and independent variablesMultiplication signPairwise comparisonLattice (group)Workstation <Musikinstrument>Sign (mathematics)MereologyState of matterDecision theoryFormal languagePoint (geometry)Endliche ModelltheorieSummierbarkeitGraph (mathematics)QuicksortReverse engineeringSoftwareDegree (graph theory)Expert systemRadiusObject (grammar)Parameter (computer programming)Error messageProgramming languageForm (programming)String (computer science)Mobile appConcurrency (computer science)Functional programmingRevision controlTable (information)Domain nameDefault (computer science)Pattern languageCodeConsistencyType theorySemantics (computer science)Fluid staticsWeb applicationVirtualizationVirtual machineGraph (mathematics)Multi-core processorNeuroinformatikGene clusterComputer programmingMathematicsRecursionCASE <Informatik>Goodness of fitHash functionFamilyReal numberThread (computing)Lecture/Conference
44:55
Strategy gameoutputUnicodeBacktrackingBlock (periodic table)ConsistencySoftware developerVideo gameFormal languageTwitterStrategy gameDampingTerm (mathematics)Event horizonLattice (order)WikiMathematicsoutputCartesian coordinate systemDomain nameWeb 2.0Goodness of fitControl flowSoftware frameworkLibrary (computing)Computer scienceUniform resource locatorBlock (periodic table)String (computer science)Revision controlRight angleMultiplication signSoftwareProgramming languageScheduling (computing)Level (video gaming)ImplementationWechselseitiger AusschlussMessage passingOrder (biology)CAN busLogical constantInternetworkingFrame problemError messageSystem callData structureState of matterTheoryWordGraph theoryDigital photographyDivision (mathematics)QuicksortCommunications protocolMobile appGroup actionInsertion lossSet theorySign (mathematics)Interrupt <Informatik>Software testingClassical physicsTelecommunicationMereologyPlotterPhysical lawSemiconductor memoryPoint (geometry)ResultantArithmetic meanGame theoryLecture/Conference
54:47
Coma BerenicesXML
Transcript: English(auto-generated)
00:12
Hello, everyone. Oh, hello. This is Matt.
00:21
Great to see you. May I ask you some questions? First time, raise your hand. It's so cute, thank you. Welcome to the RubyConf. Yeah, yeah.
00:41
The first speakers, not really. I don't see them. Okay, there you are. Okay, welcome to RubyConf. As always, I have to start with some little bit complain about speaking, giving a keynote presentation in English.
01:01
English. So, I wish everyone could speak Japanese. Doste, nihon bo hanasuma senka. Anyway, but still, I try to be nice.
01:22
So, it's working. Yes. There's some coin phrase like a mean swan. That stands for, oops. Matt is nice and so we are nice.
01:45
We have this kind of stickers on some laptops. Actually, I like this phrase because that sounds like a minasan in Japanese, which means everyone. So, that term shows inclusive attitudes of the community.
02:05
Yeah, that's quite nice phrase, though it's kind of embarrassing for me. I know me, I'm not really a nice person.
02:23
Yeah, inside. So, because the phrase minasan is so embarrassing for me, so I coined, the last year, you know, I coined up the words like a mean, ring swan,
02:41
which stands for Ruby is nice or we are nice. Ruby is okay, it's a, you know, generated shell of things so it is nice, at least it's trying to be nice to you, unless you look into the source code.
03:00
But this year, we don't need excuse, so be nice. Yeah, shake hands with your next person. Yeah, be nice, be nice, yeah.
03:26
That's a good word, very nice, very nice. Try keeping being nice, that's the community. That's where our community shines. Now, Ruby is no longer a new kid on the corner,
03:41
a new kid on the corner, oh, what new kids? New kid on the corner. We have grown older. It's born in 1993. According to the definition of the birthday of the language
04:01
I believe, for the software, it is quite important, the name is pretty important for the software, because the software is the virtual entity, so the name is the only thing we can grab that kind of virtual abstract thing.
04:23
So the date I named my language, Ruby, is February 24th, 1993. Okay, February 24th, 1993, I made a mistake.
04:42
So it returned 25 soon, on this day. So that means that Ruby has grown older. Actually, it's as old as Java. Java project was started in 93, and Java was released to the public in 95.
05:02
Ruby project was started on 93, then Ruby was released to the public in December 23rd. On the 21st, 1995, so that Ruby is as old as Java. So recently, new language came in,
05:22
for example TypeScript, Swift, Go, Elixir, and a lot more, so that, you know, the people, some people, so try to try new language, or even went to, gone to new language, so that people, some people claim that Ruby is dead.
05:43
No one uses Ruby, oh really. But I believe the people here use Ruby, right? So that, so many people, maybe millions of people,
06:04
still using Ruby, and writing the numerous applications, all over the world. So I attended some conferences, some conference has even 1,000 attendees. This one is so big, and we have, I don't know,
06:23
700, 800 people here, and it is fantastic, and Ruby is still alive. So the, but if I made some kind of big political change that breaks your software, the people will scream.
06:46
So that tendency, the language designers make mistakes, so no one perfect. So the language designers wants to fix those kind of
07:01
mistakes in the past. So a lot of language made some kind of fix, and then compatible changes. Like we did in Ruby 1.9, so we had a huge compatibility gap between 1.8 and 1.9, I don't regret that, but that made some kind of community division,
07:24
that is kind of tragedy. And then Python 2 and Python 3 has compatibility gap, and they suffered some kind of huge division for more than 10 years. The community suffered that kind of problem. And then the people, the PHP developers
07:45
may try to create the better PHP language, as really PHP 6, but they made so drastic changes so that the community did not follow.
08:02
So the project was canceled. So we don't have PHP 6, it was canceled. So we have PHP 7, which is more moderate change. So ECMAScript 4 has also canceled.
08:22
So that ECMAScript 4 has a ton of things, like the namespace things, class things, a lot of things, but no one followed. No one in the community followed that changes. So the project was canceled. So they restarted ECMAScript 5 from ECMAScript 3,
08:46
they're adding classes, so they took the gradual changes. So the ECMAScript 6 and 7 gradually getting close to the ECMAScript 4, which was canceled,
09:02
but it took years to get there. So it's sometimes called the second system syndrome. So that, yeah, we are not perfect, so we made mistakes, so we start the mistakes, like a technical debt.
09:21
So at some point, we got mad, and we wanted to throw everything away. Then start from scratch, which is the second system. But the very few second system runs well,
09:42
will succeed, because the second system introduced a huge compatibility problem, so put the burden on the users. So Ruby should be stable, because Ruby is mature,
10:04
Ruby is grown up. So if we don't keep compatibility, so the community suffered a migration cost. Users are using old version,
10:23
causing community division, like we did, or in the past, Ruby 1.8.3 introduced a slight compatibility problem, but it crossed rails. And some part of the community boycotted the version.
10:44
Yeah, it was shocked, I was shocked. I put my effort to create Ruby 1.8.3 at the time, the best Ruby ever, at that point, so I released it, and at least the part of the community
11:04
refused that Ruby, because of the compatibility issue. Or Python 3 are the same thing, so the Python community, Python developers,
11:21
create the best language they can imagine, but the community refused to use the new version of the language. Or like I said, some project was canceled, like PHP 6 and X3.4, or some people leave the community
11:41
for the new language. So open source community is a kind of weird thing, so it's a group of people, but we have no legit membership. We don't have the membership initiation of the Ruby community or anything like that.
12:04
It's non-exclusive, you use Ruby, but at the same time you use JavaScript, right? Although I don't. Yeah, if you use Ruby, probably sometimes you might use other language like Elixir, Go, Swift, or whatever.
12:23
So the membership is non-exclusive. So we cannot expect a strong loyalty to the community. Yeah, actually the Ruby community has, the member of the Ruby community has a strong loyalty,
12:42
but we cannot force them to stay. So if something happens, or if some other new technology is so attractive, so people will leave. So yeah, we cannot stop them. So we need to attract community
13:03
by making some kind of the breaking change. So we might push our community members away from our language, so otherwise community members go away,
13:21
so if, so that we can, in general, it is quite difficult to make breaking change to keep our community active. But to keep our community active, if we keep compatibility, it's boring.
13:47
Ruby will leave for more attractive languages, or technologies, or whatever, like Fortran, or whatever, it's kind of a contradiction. We want our community pretty active and growing,
14:03
and then to keep them active. So if we keep compatibility, it's boring. People will leave. If we make progress, if we make changes, some of them should be, could be breaking change.
14:22
And then people will scream, and people will leave. No matter which way we go, people will leave. Too bad. So the problem is changes. So we like changes, like yes we can change them.
14:45
Yeah. But at the same time, we hate changes. So that we have to manage changes. So there are good changes and bad changes.
15:01
Bad changes are changes that bring frustration. Right? So what kind of changes do you feel frustrated? For example, changes that make you work. No, you love to work. Do you?
15:22
Changes that make you work unwillingly. So when you don't want to work, when you're forced to work, you upset, right? So the changes that surprise you, the bad change? No, you love to surprise, don't you?
15:42
Surprise! So the changes that make you angry, that is bad change. So in short, changes with a benefit is bad changes. So benefit, performance, better performance,
16:03
better productivity, or the changes that make you excited or make you joy, they are good benefits to perform the change. And clean language is not benefit.
16:20
For me, yes, but not for you. So you don't care, you don't care Ruby's clean language or not, yeah, basically, unless you thought the beginner. So, you know, making language clean or simpler
16:41
is kind of the self-affection of the designer. So I have to forget about that kind of self-affection. So avoid bad changes. That is an important design principle that can be applied to your software.
17:03
So forget about yourselves. So try to satisfy your users. Try not to make your users scream. So how about the good changes? The performance is a good change. So no one complains about the faster Ruby, right?
17:23
So Ruby itself is not designed as a fast language because my primary focus in design of Ruby is the enjoyable, satisfactory, satisfactory, or something like that. So I want the programmer's burden
17:46
pushed away from humans to the computers. So I want computers work more and humans work less. So in that sense, language has to be slow because the language has to do more things.
18:05
So the Ruby tends to be slower than, say, some language, the Java, C++, whatever. But that's kind of intentional because I push these buttons to the version sheet,
18:21
to the language, to the computer. But we try to make Ruby faster. So since we released Ruby 2.0 in 2013, so every year, the Ruby is getting faster and faster. In average, we have made Ruby faster
18:46
by five to 10% each year. So Ruby 2.x, 2.0, 2.1, 2.2, and we are going to have the 2.5 this year. So every Ruby 2.0 release improves 5.5.
19:02
So five to 10% each year. And that's not enough, that's not enough. So two years ago, in this keynote, so I present the phrase that is the Ruby 3x3, that means the Ruby 3 will be three times faster than Ruby 2.0.
19:24
So it's two years ago, it was kind of dream. You know, I didn't really believe it is possible, but we have to, we have to motivate us,
19:42
the community, to make Ruby faster. So dramatically faster. And so it has been dream until this year. We had some new technology in MCH.
20:01
M JIT stands for MRI JIT. So MRI means the match Ruby interpreter, which is not true for Ruby 2 any longer. So we call, I call MRI as C Ruby from now on. So it is kind of JIT compiler for C Ruby.
20:24
So the adding JIT compiler makes Ruby faster, but so Ruby has a lot of constraint because of its history, because of the past uses, because of the compatibility. These are constraints, the memory usage
20:42
and dependency and the portability. So memory usage means that the C Ruby with JIT should run on smallest of the items, which has 500 meg, I mean. It is quite small in today's standard,
21:03
but it should run on this time. So that, you know, you cannot consume as much memory as possible to make it faster, but at the best minimum, so the C Ruby must run on smallest of the items.
21:22
Mostly because I was hired by a worker. So JIT can be turned off, so the C Ruby without JIT consumes as much memory as Ruby C Ruby 2.
21:40
And the dependency, so C Ruby should not depend on the huge third-party library. That we cannot maintain by ourself. So we cannot control them, third-party libraries. They may have bugs. They may not put our issues in priority. So the product may be abundant.
22:03
So we may need to focus and think about ourselves. But the most JIT libraries are so complex and so difficult to make. So we avoid using third-party JIT libraries. So there are some kinds of JIT libraries out there. So for example, LLVM JIT, or GNU Lightning, or libJIT.
22:24
So those have some issues for the sake of the maintainability, or controllable, or licensing issue. So the latter two comes with the LGPL,
22:43
which is okay, but not ideal. So portability, Ruby runs on many, many, many platforms. So this should run as many platforms as it does now. So it should run on Linux OS X, or Mac OS, or Windows,
23:05
or some kind of other ways, or other systems. Even older ones, like AIX, and SunOS, or Solaris. And then on many CPUs, like Intel, ARM, Nips, or whatever.
23:25
So regarding those constraints, so it's nearly impossible, until this year, that it's done by our hero, the blood, you know, and Makarov, from Letmat, who is also the open address hash table, which we proved a lot in last year.
23:44
So he was the father, he is the father of the JIT. So you can check out the current status of MJIT here, the VN Makarov, Ruby, three RTL MJIT branch.
24:01
So the important things is, it is RTL, it is GCC ground, and it is necessary. Let me explain those things. So RTL stands for the registered transfer language. So it's a register-based internal representation.
24:21
So the stock IR and the register IR is a hot topic in the implementation of the virtual machine. So the current implementation of the Ruby virtual machine, YARV, uses the stock IR, like this. Get local from local variable B,
24:42
you push into the stack. The get local from the local variable C index, then push into the stack. Then up there, the plus, it took the two operands from a stack, then pushed the result. Then pushed the result into the local variable A index.
25:02
That is the stack-based IR, used by YARV. The RTL used the register-based IR. So the plus, the local variable B and C, then pushed the result into A, in one instruction.
25:24
So YARV uses the stack-based IR, and the stack-based IR is simpler and shorter, and the register-based IR creates less instruction. Register-based IR creates less memory traffic, and it's kind of controversial, but the register-based IR runs faster,
25:43
and the people in the stack-based camp will complain about that. Then the RAT replaced the YARV by his RTL VM. This is quite the task, and he did it in a year.
26:02
That's quite amazing. And then, which is as fast as 2.4, the current release of the Ruby 3.2? And then, which consists of as much memory as 2.4? That is a pretty important thing. That means, if we count on the JIT,
26:23
the CRuby with RTL, which is the baseline of the JIT compiler, runs as fast as Ruby 2.4, the current implementation, and the Ruby consumes as much memory as Ruby 2.4. So since the Ruby 2.4 runs on the smallest dyno,
26:43
so the RTL, the CRuby with RTL VM runs on the smallest dyno, if we count off the JIT compiler, please. Then here, we implement the JIT, so that compile those RTL to the native code.
27:03
So RTL VM, oops, RTL can be JIT compiled into C5. Then, those C5s are compiled to machine code inside of the .socl4j file.
27:23
Then, they're compiled with the command line GCC or Clang. Then, then we get loaded. So which is kind of, you know, complex aspects. But it makes the implementation of JIT pretty much simpler.
27:42
And the main default. So the current implementation, you just generate the out code in the memory, then execute the out code in memory. That's simple. But the baseline RTL VM generates RTL instead of the out code.
28:02
So then execute the RTL as an interpreted way. Then, MJIT generates RTL, which is the same as the previous steps. Then generates JIT from RTL. It compiles C, .c file by GCC or Clang.
28:23
Then .load compiled .so files. Then execute. So the, you know, it's pretty complex, but he out-froaded most of the compilation work into the worker thread. So it runs quite fast.
28:43
So actually, the MJIT is far from completion. So that it doesn't run Rails yet. But it runs most of the Ruby tests and Ruby steps, but it does not run Rails yet.
29:01
So our benchmarks are pretty complete. Still, it's multi-benchmarks. Not real world ones. But MJIT runs six times faster than virtual in average in microbenchmarks. So then MJIT comes in four times more memory than virtual.
29:20
In microbenchmarks, it tends to be exaggerated. The result tends to be exaggerated. So the auto-carrot, which is a little bit more realistic task, which auto-carrot is the kind of NES, Nintendo Entertainment System Emulator.
29:42
So it has some kind of benchmark mode. So it runs as fast update, the screen update, as possible without, you know, screen drawing. So in those kind of benchmark mode, MJIT runs 2.8 times faster than Ruby 2.0. 2.8 times faster than Ruby 2.0.
30:03
Not bad. Not bad. So the auto-carrot is the CPU intensive software, so it is pretty easy to make it faster by adding JIT. Anyway, so 2.8 times faster.
30:22
And the important thing is MJIT consumes 1.16 times more memory, so 20% more. So 2.8 times faster with 2.2 times more memory. It's quite number, it's quite promising. So not bad.
30:41
So we have clear benefit. So we are going to add that kind of improvement, which is technically attractive to the community and developers. So in addition, we are going to add a better tool set.
31:00
So for example, faster tracing. So by faster tracing, we are going to have a better debugger or better profiler. Or we can have a better coverage. Or we are trying to make Ruby errors more understandable.
31:22
For example, we recently added the JUMIN gem. So we, in 2.4, we made some kind of typo in our software. The error message includes the right, did you mean this without that?
31:41
See, so that you can easily fix that kind of simple typo error. So these kind of things, the tool set change and the performance things is keeping compatibility is quite nice. And mean addition is also nice and good changes.
32:02
Mean addition rarely breaks compatibility. So adding classes, adding methods. So we are keeping doing that kind of things. So we will add convenient methods and convenient classes to the language and standard libraries. So for example, in Ruby 2.5,
32:22
we are going to add this method. Things graphing clusters. Which is, in the past, the strings are sequence of bytes. It's quite simple. We only have the 128 characters,
32:42
including the controlling characters, at most, 128. 128. But the country or culture like us have the thousand characters. So the single byte is too small for a character.
33:00
So we introduced something in the code point. Which is that we can represent thousands of characters in multi-byte sequences. Sometimes at the viral length. So the ASCII-A has the length of a byte.
33:22
Or maybe the Japanese characters have three byte lengths or something like that. But it's not enough. So the people, after Unicode,
33:41
people open the box of punctua. Namely, Moji. So, yeah, and you're not familiar, Moji. So the parents and children.
34:01
But do you know that you can't combine these things? So it used to be this character. This is one code point thing. But we recently added the, you know, the sense of marriage. The ladies and ladies can get together.
34:21
Or maybe the guys together. Or maybe skin colors. Yellow, white, black, whatever. Maybe we are going to have some blue skin. So that, you know, if you add the male character,
34:44
then combine the blue skin, yellow skin, maybe. So you can have the yellow skin, male, or Moji. So you can combine them. This is one character. But consists of the two code points.
35:03
The combination of the two code points is called graphing in Unicode. So we recently supported Unicode 10 in Ruby 2.5. So that we have to handle those kind of the combined code points in the graphing.
35:23
So that if you want to split up the strings according to the graphing, you have to use the graphing, I mean, the graphing clusters. So, and we also added the strings,
35:40
each graphing character, each graphing clusters, so that you can have the, you know, each graphing clusters at a time. So that's quite complex though. So there's no clear difference between good and bad in some cases.
36:00
So we have some kind of controversial changes in the future. So I'm going to introduce some kind of controversial changes. We are somewhat wondering to integrate the future Ruby. So for example, frozen string literals by default. So some phrases, oh, thank you.
36:22
Some not. We have benefit, it's faster. And we don't have to generate the string object for each, the string literal reference. So it's faster, and it's because it's less memory. That's a good point. And also, making string frozen,
36:44
you can find some kind of errors very early. But we have disadvantages, like this. It's incompatible, so it would break some code, or many code. So yeah, for example, in Ruby 2, I don't remember,
37:03
Ruby 2.2, we introduced some kind of magic comment, which is the string, frozen string literal, true. So that makes the string literals frozen if you specified it. And that, that broke your software.
37:21
That broke your software. That broke so many softwares. So that, I'm not sure how much of you freeze or not, after seeing that kind of errors. So that's one thing we are wondering. It's, yeah, many things sounds nice,
37:44
but introduce some kind of, so we have keyword arguments. So right now, the Ruby keyword arguments are somewhat fake, because you can specify the keyword argument like this,
38:02
but in reality, in semantics, it says this will come like this. So the hash table at the end of the argument list, which is the real semantics of the keyword argument, is calling size.
38:20
It makes language simpler, but implementation, or semantics of the keyword arguments, very complex. So making a real keyword argument to the Ruby, it makes Ruby simpler, faster, and consistent. That's the thing.
38:40
But it will be incompatible. It will break this function, especially C functions. Or we are considering about adding pattern matching to the language, as function language has. And then, yeah, the problem is,
39:02
we are lacking the characters and the syntax, so we have no idea what kind of language we are going to add. Or tail-top optimization, which some language has. So if it is, it will make some Ruby program faster,
39:24
and then no recursion will be made. And then, we have disadvantage for the tail-top condition, which is confusing backtrace, because, you know, it's, the tail-top removed the call size,
39:40
so that the backtrace will be reduced from the actual call size. Or we are trying to investigate in the autographic concurrency model, so that Koichi, who is in charge of the YAG,
40:02
the working on designing the something named Guild. So the benefit is clear, so that by adding that kind of, the new, better, concurrency model, we can be multi-core aware, so you can utilize the multi-cores that the computer has.
40:23
But we have disadvantage as well, so adding, we are not going to remove threads, so adding new concurrency model, along with threads, has two concurrency model in the language, and it makes the language more complex,
40:42
or less understandable. So we are researching on the static type analysis, so by adding that kind of static type analysis, we just find more errors in our time, which is good, but it makes language more complex and less flexible.
41:04
So the, yeah, for the up-to-date research, so we have tomorrow, the before, tomorrow before lunch, Python Ruby programming language session in room algorithm, so whether we're roomed
41:21
by so-called Max Model, we share our family name, but we are not, we don't, yes. Yeah, Max Model is pretty common family name in Japan. So there's no clear decision in those changes, so we might add them, we might not, not clear,
41:42
so that we have common thread off, so good things and bad things at the same time, so we might take the changes for the sake of good things, or we might abandon the changes for the sake of the best disadvantages.
42:02
So the design of Ruby language, I am fully responsible. I'm a lead designer. Every language change requires my approval, still. After 25 years, I am responsible, so blame me.
42:21
But at the same time, I am not an expert at everything, so I don't know, I don't, I know little about the concurrency, for example. I know little about web applications. Yeah, that's BHH. Not BHH. So that, that means we need to hear from you
42:44
because Ruby is a tool for you to write software. So you are an expert of your domain, not me. So don't ask me for the guidance of your domain.
43:03
So, but, I'd like to ask you about your domain. So, no more 1A3, no more boy clubbing.
43:20
So the strategy is here, minimize the impact, maximize the benefits, and form agreement. So the minimize impact is the emphasize compatibility. That's what this app does most of the time, so that I try to minimize the impact of the upgrade.
43:42
So we try to, we try to allow you to safely upgrade to newer version from, say, 2.2 to 2.3, or 2.3 to 2.4, or even to 2.5. So, yeah, it's a responsibility of virtual technology,
44:05
but at the same time, it's falling. So we have to sometimes make breaking change. So at the, for those kind of the breaking change, we have to maximize the benefit, and the clear language, or simpler syntax, or something,
44:24
is not among those 10. So for example, Ruby 1.9 produced some breaking changes, but at the same time, Ruby 1.9 runs three to five times
44:40
faster in average than Ruby 1.8, due to the, because of the new virtual machine. So the Ruby 1.9 has a clear benefit of the performance, so the people gradually, it took time, unfortunately, it took five years,
45:02
but the gradually community have said that can change with a clear benefit. Or the third strategy is form agreement. Yeah, for like Ruby on Rails. Yeah, they made breaking change all the time. But yeah, as I've heard,
45:24
so the web technology is changing so quickly, so if they took the conservative strategies, they left it behind from the up-to-date technology, so they tried to make the breaking changes,
45:41
and the update, up-to-date technology. So yeah, if the community agrees with it, that's okay. But the technical language is pretty much the domain of the computer science. So I don't think we can form that kind of agreement for the languages.
46:01
Yeah, but we try. There's no clear winning strategy, so we pick the best strategy for each changes. So we need point from you. The time, place, and location. So time means that our release schedules. So as you might know, we release the new Ruby version
46:24
each year on Christmas Day. That's a Christmas gift from the community. So that means that from January to August, we discuss about the new features, new technologies, new implementations.
46:43
Then September to October, so we release candidates. Then in November, we freeze the features. So no new features after November. So that we just fix that. So that we have those kinds of time frames
47:02
for the new version. And there are places, so we, on the internet. So we have the site, burns-ruby-lang.org, which is our issue tracker, runs on breadline. So that we can discuss about the new features, bugs, and the proposals, and everything.
47:22
So that if you have any ideas, proposals, feel free to submit the issues on this site. So that we can discuss about that. And then, yeah, I'm sorry that I have to refuse most of them, I'm sorry.
47:42
Yeah, mostly because of the consistency for constraint, for some just redundant ideas. But yeah, you have to stand that. But besides that, we have had a lot of value input
48:05
from those kind of proposals. So that last five years, most of the Ruby improvement, progress, had come from the proposal from the community.
48:22
So I'm pretty glad that. So I'm still a lead designer of the language, but the ideas of new changes, new features, new improvement, most of them came from the community.
48:40
I'm proud of that. So the occasions, so by looking at our wiki, so we have the Ruby developer meeting each month, face to face, so in Tokyo.
49:00
I'm sorry. I'm sorry. But we are talking about the, you know, the reason is what we discuss, and what we are going to discuss in English. So that you can see what we discuss,
49:21
and you can propose what to discuss in the meeting. So that sometimes we forget about discussing your issues. So that ping us by writing these wiki pages. So that okay, you, I submit this nifty proposal,
49:41
but you don't pass them for a month or two. So that, what do you think about that? That kind of ping pings can be done in our issue trackers or on our wiki pages. So that you can even perceive me to writing down to the wiki page.
50:02
So that it's a community effort. So the term language designer no longer means I design everything. So instead, the community design most of the language,
50:21
then I make decisions. So the definition of the designer has been changed for those years. In summary of this talk, so there are good changes about changes in design. So every design, Ruby design of course,
50:41
your application design, your framework design, your library design, every design, has good changes, bad changes. You have to manage your changes. So that we try to maximize the good changes. And the minimizing bad changes.
51:00
We need more input from me. Just because, so the Ruby is for you. It's a new for me. So I just wanted to create all my program, my own programming language. So I, Ruby was originally designed for me, myself. So I'm pretty selfish.
51:24
But for those years, so many people use Ruby, love Ruby, you know, the right software in Ruby, so that Ruby became your language. That means, so we need more input from the community,
51:42
and from you. To reduce my mistakes. So, by the way, this is the end of my talk. And in addition, I'm going to introduce the new Ruby 2.5. So that, Ruby 2.5 has,
52:04
this, the Ruby 2.5 relatively minor release. So that we had added some kind of top level constant lookup, like in the past, string, clang, clang, clang, strings,
52:21
no meaningless reference, works as a top level string. But we have been removed. Then the backtrace, if you make errors, so that you see the backtrace in software. So that the backtrace order is reversed.
52:40
And you can put the rescue else and shoo inside the do block, and then we added the use self method. Yeah, some desperately need that, I don't know. And then we supported the Unicode too, Unicode can. And then we have, I include the performance,
53:00
the mutex has rewritten, and the pass the block passing, and then the trace instruction is refactored from scratch. One more thing, we are going to celebrate with the 25th anniversary, on February 24th, 2018.
53:20
So we are going to have some kind of celebration party in Tokyo on that day. But it's, not many of you can attend that party in Tokyo, and then it is, yeah, the attendees is one of the people maximum,
53:41
so that it's too small. So we are going to have some kind of virtual event. So that, yeah, tweet your memory, your inspiration, or whatever, about Ruby, to celebrate with the 25th anniversary of Ruby,
54:01
and tweet with this hashtag, 365. So we can, I think after the birthday, so we can gather these tweets, and put it into the one site, to celebrate the Ruby 20th birthday, and yeah, to recall what you feel for that day,
54:24
for that day, that year, that week, I can know how Ruby changed your life. So that's all folks. Thank you.