キーノートを一度一度としてとても慣れています特に英語で話す必要がありますなぜ日本語を話していないのか今日は3.0のLuby 3.0やS3.0のLuby 3.0のS3.0を後で説明しますまず皆さんが来てくださってとても嬉しかったです私は友情と嬉しさをとても嬉しかったですこれはLubyの言語のプロパティーですありがとうございますとても嬉しかったですとても嬉しかったです次の45分で私の悪い英語を見てみましょうとても先ほどシンボルをお話ししますシンボルはLubyの言語のプロパティーですこれはシンボルシンボルはアブジェクトのアドエントファイヤーですシンボルはアブジェクトをアプロセントを彼らのプロガムの表現は彼らはリスをとてもっとこのレシートプログラムでシンボルは非常に自然なアブジェクトを実はリスプのシンボルはアタムのリスプロゲミング語の一つです私は学校で一つのリスプロゲミング語の影響があって私はこのリスプロゲミング語の影響があって私は一つのリスプロゲミング語の影響があって私は説明することを勉強したことを勉強しましたそして私はこのデザインに影響をしていましたSo when I started designing programming languages named Ruby,so I stole many features and attributes from this programming language.So the symbol is one of them.So actually the symbols are one of the biggest list inference in Ruby.And then symbols are identifiers.Symbols have identification numbers inside as an implementation.And then in fact, in the very, very early stage of Ruby development,symbols are numbers.So the symbol literals are the different notation of the fixnums.So back then, symbol.class returns a fixnum.So it used to be fixnums.But the list is minor, I admit.And then there are so few lists or ex-lisp users.So for those of us, the list inference symbols are naturally not strings.But I received so many feature requestsabout unifying strings and symbols.So that is my wonder about those requests.So symbols, for me, from my perception,so the symbols are strings are so different.So why they want to unify them?But symbols are not strings, are strings are not symbols.So actually, I didn't understand what they thought about by that kind of feature request.But let me clear myself, be open mind, remove prejudice.And then if an object looks like a string,and it looks like a string,it is a string.So for those who don't understand Lisp,who don't have any influence from Lisp,so they saw strings as some kind of immutable strings.So I opened my mind.So I tried unifying a string as symbols and failed.That introduced a huge incompatibility.So some part of the Ruby community understands Lisp.And then understands Lisp culture of the symbols as identifiers.And then the other part of the Ruby community understands symbols as some kind of immutable strings.That kind of conflict within the community,especially the people who had a very strong influence from Rails.So easier to confuse strings and symbols.And then there are class names like harsh words in I don't remember the name.But the hash that yeah, that one.So I got a mountain of arrows.So I just gave up.So in Ruby, symbols are not strings.I made up my mind.Symbols are identifiers.But that reminds me about identity.Actually, in Japanese, my language,we don't have the term identity.So it is quite a difficult concept for us to understand identity.But thinking about me, my true identity,who am I?Or who are you really?Is an identity.So who are you really?For me, I'm a programmer.I'm a hacker.A person who makes impossible possible.At least one I want to be like that.And a language designer.And by the way, how many language designers do you know?Me, Guido, Larry, Ourasens, or somewhere else.Like a Jose Varian for Elixirs recently.And then you.So I'm serious.You should be.You are a language designer.So I encourage you to design your own programming language.So maybe I confused you, but let me quote from this guy.The Dave Thomas.Our Dave Thomas.We have a lot of Dave Thomas out there.But this Dave Thomas once said in a conference back then.So programming is a process of designing your own DSL.The programming is a process of designing your own DSL.So designing your library, designing your API,designing your framework, designing your user interfaceis kind of language.So because interface is a fundamental language,designing interface is designing a language.Designing API is designing a language.Designing framework is designing a language.So there are languages between machine and man, humans.So we are language designers seriously.The designing difficult task.There are a lot of pitfalls.So by designing languages, there are so difficult tasks.There's actually tens of thousands of programming languagesout there, in a narrow sense only,with very few programming language success.Just because there are so many pitfalls and trapsin designing programming language.The biggest one is second system syndrome.Second system syndrome, or SSS3 in short,is as time goes by, systems will go bigger and more complex.Programmers or designers working on that system,getting sick of working on that kind of complex system.So they are easy to create bugs.Easy hard to maintain.So your gradually become sick of maintainingthat kind of complex system, grown-up system.The original system was born small, simple, beautiful, and usable.But as time grows, it goes by,the system gradually creeping into the more complex monsters.So this is second system syndrome.So for most of the systems, especially long-living systems,the second system syndrome creeps in.So the second system, we cannot avoid meeting second system syndrome.So when you got sick of maintaining that kind of complex systems,you were tempted to throw away everything.So let's start from scratch.So let's use that kind of knowledge, experience.So then recreate better things from scratch from zero.So that would be very, very attractive for developers.So creating new systems is very fun, attractive, amusing.So we will be very happy about the second system,second better system, second more beautiful system.But the most of the challenges will fail.Somehow, this is the true nature of second system syndrome.And then implementing clearer, better system from scratchis far more difficult than we expect.Then they fail.That happens all the time.That happens all the time.So especially for programming language,just because the programming language has longer lifetimescomparing to other applications.For example, so we have the oldest programming language named Fortran, which still lives.It was born in, I don't know, 60-something years ago.And the very old programming language like Kabul and Lisp still lives.So the programming languages tend to have long, long lifetimes.So those kind of long living systems will sufferabout the second system syndrome.Because language will live longer for using of this question.So for example, the power five is great programming language.But they suffer about the second system syndrome.They throw away everything.They redesign better, cleaner, and monster language.And then they declare it will be released in this Christmas.Wow.Actually, last week I attended the yet another power conference in Tokyoand the Lally wall was there.So he proudly declares the release plan of the power six.Finally, after 15 years of work.Wow.Creating the great second system.Now not released publicly for 15 years.Wow.And then there is no exception.We had some kind of second system syndrome in some degree.So we had this conflict between the Ruby 1.8 versus Ruby 1.9.So in Ruby 1.9, we re-implemented the virtual machine.We replaced the virtual machine.And then we introduced the multi-lingualization,which can handle the multiple character encodings.Unicode, ShiftJS, EUC, or IS or something.So currently Ruby 1.9 and Ruby 2.0,I mean Ruby 2 handles more than 80 character encodings natively.So we introduced this kind of multi-lingualization,or M17N in short.So that introduced the compatibility gap.So you have to somewhat tweak your program to run on Ruby 1.9.So that took a long time to migrate.When we released Ruby 1.9 in,I don't remember the year,but since then,So we get a 4.1.9 acceptance that took more than five yearsfor just upgrading the one version, five years.But is there anyone still using Ruby 1.8?Ah,don't.Yeah, it's about time to move on.We are open source.We have to keep moving forward.So we are now in Ruby 2.2 era.So please move on.Ruby 1.8 is slower.Actually,that virtual machine is implemented by me, myself.And actually,I confess,I don't trust myself.So Ruby 1.9 and Ruby 2 has much better virtual machine.Anyway,we have done better than other languages.So we have done better to conquer to the second system syndrome.But how?And then how can we overcome second system syndrome?So we have three points.We have never thrown away everything.And then we had some kind of version illusion,Version illusion,and third,we have some kind of a migration by it.Okay,let me explain one by one.We have never thrown away everything.Despite we had a need to move on,to replace the virtual machine,to gain more performance,or replace the object representation,or need for the replacing the garbage collectors,we have many needs for the next system.The second system.But we have never thrown away everything.And we never started from scratch.So we have replaced everything one by one.So we have replaced the string plusfor the better string object representation.And we have replaced the virtual machine.So we have replaced the object representation in generalSo that we can have the...We consume less memory.And we replace the garbage collector.So in fact,the Ruby 1.9 is the big step forward.But still,it's a kind of the improvement of the previous systems.We haven't thrown away the Ruby 1.8.We just replaced one by one part by partto gain a more better performance.And we try to keep compatibility as much as possible.We prepare the test streetsand run test streets before and after the replacement.And we have the behavior change.We rewrite the test.Then write the test for new spec and new behavior.So we also prepare the migration pathfor new features,like multilingualization.We have introduced some kind of the magic commentsto specify the string encoding in your source fileor something like that.So we have never tried two drastic changes.So drastic change is very tempting.So that throw away everything,reimplement the neat,clear,small,nifty feature from scratchis very much tempting for programmers.But we have never tried that.So we took the improvement step by step.So the second is versionally-illusioned.Usually,we have the Python 2 and the Python 3 syndromeor Python 4.5 and Python 6 gap.But we did some kind of the 1.8 and 1.9.That seems an illusionally small step.That's kind of the illusion.For us,that helps conquer that kind of the migration gapor the second system syndrome gap.But still,it took five years.So for other languages,like a Python 5 and Python 6,it may take much longer than that,maybe.The second one is not that important, though.And the third part is migration byte.So what?The moving 1.9 had a huge benefit for users.Just replacing Ruby 1.9 makes your programlanse twice or three times fasterjust by replacing it.And then you have to pay some kind of the migration costjust because the 1.8 and 1.9was a little bit incompatible.But the performance gain will be the huge motivationto move on.So for other systems,so having cleaner inside,cleaner systems,or the easier to maintain systemis no use for mere users.So they don't want to pay that kind of costjust to follow the version upgrade.But Ruby 1.9 had some kind of the huge bait.So the performance gain is a huge motivationyou for users.So from,I mean, in summary,rural sound of the second system syndrome isdown push too hard,and push softly,push steadily.So the compatibility is the key.So 2.0,which was introduced two years ago,I mean.2 years ago had almost perfect compatibility.So the last version of 1.9 was a 1.9.3.And then 1.9.3,and then Ruby version 2.0had almost perfect compatibility.You can just drop in replacement.You can use 2.0 as a drop in replacement.Along with the huge feature enhancement.For example,some kind of aspect feature things,or some kind ofrefinements of the names of the bundling.But still,the Ruby 2.0 works perfectlyto run the system written for 1.9.But as time goes by,the second system syndrome comes again.So there are some kind of knees and 1.3.0.But we don't forget the rules.Don't push too hard,push softly,push steady.So we started working Ruby 3.0 last year.But we started from experimenting first.But we had some very wild and crazy ideas,a lot of them.But we experimented them one by one.Then after it turns,they turned out to work nicely,compatible.So we will introduce them in Ruby 3.0.So they are experiments.We don't promise anything for Ruby 3.0 yet.So we don't promise any plans,schedules,or the roadmap or anything.But the basic concept of the Ruby 3.0 improvement will be these three parts.The man-machine collaboration,performance, and concurrency.So the first one,the man-machine collaboration means we called as the communication between man and machine from man to machine.We called.Then the machine reports back errors as a compiler or runtime error.But recently we have the IDEs integrated to our development environment for the better communication between the programmers and the machines.But we want to try something different.So we call it proactive warning.So for example,Ruby 3.0,I mean Ruby 2.3.Ruby 2.3,which will be released in the coming Christmas,this December,will have this disuming feature.So if you kind of make,when you make some kind of type mistake,types.So the error message will suggest the right name for your variable name,method name or something.So like Google does.So did you mean something?You put the class name strings,but did you mean string or something like that?So we will have that in coming Ruby 2.3.But that kind of enhancement will help programmer to write correct code in short amount of time.So the proactive or noisy warning will help us.So that will gradually introduce as soft typing.The term soft typing is not gradual typing.Gradual typing is the optional typing in other words.So as say the other language,like typescript.So that which has any class,any type.When you use any,it works as a dynamic type programming language,like Ruby or Python or the plain JavaScript.But the other part of the programming,so you declare the type of variables or the return values.So you will have some kind of static typing.But I don't like that.Because by introducing the gradual typing or the optional static typing,so you have to annotate the program.But think about that.Your Ruby program runs without that kind of type regulation.So why do we have to write down that kind of redundant?So it's kind of against the dry from my perspective.So don't repeat yourself.So dry principle avoids duplicates and avoid redundancy.So avoid copying and paste because it's bad.But type decreases redundant for Ruby at least.So I don't want to force by the programming language to write down the types.So because Ruby runs without them,without type declarations.So we are lazy.I am lazy.We are too lazy to maintain duplicates.So the soft typing,soft typing the static,the kind of static analysis.Everything,the whole program at once,and the final contradiction.This is not 100% correct type checking,but it helps you find that kind of type contradiction.So that would help you fix bugs.So that kind of typing,we want to introduce to Ruby 3.0.But we are very early stage of experiment.So I,again,we don't make any promise about soft typing.But I really,really wish we could have some kind of assistant from compilers to write correct programs.The second,I mean,the performance.So the making Ruby faster is kind of difficult task.So many people think about JIT,just in time compiler.So compiles everything into the native machine code at runtime.But from our experiments,so we made some kind of JIT compiler for Ruby 2.0.I mean,to be 2.0.So that system is in a RUJIT.It is a tracing JIT for Ruby.So the Ruby association with the organization behind the helping maintenance,help development will be the language.And they gave the grant to develop this RUJIT.So then we found out the,using RUJIT,Ruby runs several time faster for many benchmarks.Many micro benchmarks,I mean.But it consumes a lot of memory at the same time.For example,the tracing JIT compiles the trace.I don't think I can explain correctly.Ask somebody.The trace is the execution path of the programs.So if this short amount of code,the trace branches at the loop or the conditional statement.So the tracing JIT,when tracing JIT sees the conditional statement.So the tracing JIT compiles two separate machine instructions for the true conditions and false conditions.That kind of things.So because of that kind of tracing,the tracing JIT compiles a lot of traces and consumes a lot of memory.But the bad part is that recently we were very easy to see memory bottleneck.And I work for the company named Heroku.And it is the execution unit named Dino.And the smallest Heroku Dino has only has 520 meg of memory,which is very easy to meet in the Rails applications.So if we introduce that kind of tracing JIT,the Ruby with JIT will not run on this small dinos.That is very terrible for many users.Maybe good for Heroku the company.You have to pay.But it is not good news for Heroku users.So we gave up that kind of tracing JIT.So we will try the alternative JIT compiler method named method JIT.Actually,a few weeks ago,the IBM offered JIT technology for Ruby.But I haven't talked with him yet.So I don't know yet what their intention or what technology they are going to offer.But we very welcome about their offer.So I wish we could do anything better to make Ruby faster for Ruby 3.0 or earlier.And concurrency,the big issue.So when I started designing Ruby 20 years ago,actually 22 years ago,computers has only one CPU for computers.So we don't have to worry about multi-core.But these days we have dual-core octa-core or even more cores in the computer.So we have to utilize these cores.So we really,really need for concurrency.But we have something named JIT,Jail in our Ruby version machine.Jail stands for the global interpreter lock,which is to protect the program,the portion of the program,which is not thread safe.So the Ruby users see one Ruby thread at the time for CPU intensive work.So Ruby use the multi-core when for the IO intensive works,just ask operating system or system calls to run.And we do the other things.But for CPU intensive work,so global interpreter lock hinders the performance.So many people want to remove the Jail.So I once tried to prepare the compile option to remove Jail.But I didn't do that.But you will see how many programs will crash without global interpreter lock.But I wasn't too mean to protect you.But we have several things.We have some kind of native threads for IO intensive work.Jail Ruby and Ruby.Jail Ruby and Ruby.Jail Ruby is thread safe relatively better.And we have event machines and cool IO for event-driven programming.And we are still working on concurrency.But concurrency is heard.Thread safety is very,very difficult.Thread is too complex.Concurrency itself in nature is very complex.So remember,this conference started 30 minutes later,later.But we had a concurrency problem at the reception desk.You know that?We have long lines of queue.And we have resource sharing, deadlocks,everything.The concurrency is heard in nature.So we need for more abstract concurrency models.So when we have fine-grade concurrency control,we have better performance,possibly.But we are very easy to make mistake,make sense and bad.So more abstract concurrency models will have less performance.But much cleaner and less error-prone.So my big plan for Ruby.Jail Ruby is one of the more abstract concurrency.For example,actors and add warning when you use this directory.Then remove jail.This is my plan for Ruby 3.0.And then what is our better concurrency model?So we have several ideas.For example,actors like Elixir does,OrOlon does,Or some other programming languages does,are like Go.Or some kind of ownership models.So ownership models is kind of like the memory management model of the language named Rust.But we apply that kind of similar model for concurrency.One thread owns the object.So only the threads that owns the object can modify the object.So the other object can refer the object to look at the object,but they cannot change the value.So you don't have to worry about what?The locking,the modification,and the gradual deadlock from those kind of data sharing.And the other idea is a stream or pipeline model.Like the plain old celldabs.So today I will introduce about the last one,the stream model.The stream model is a pretty simple model,and it doesn't cover 100% of concurrency.But when it works,it works pretty well.So this is the future Ruby concurrency programming.It looks like an Elixir pipeline operator,but it is different.Okay,standard in pipes into the standard out.This is the statement to prepare some kind of stream or pipeline from standard in to standard out.That works just like a cat program.Read standard in,then write standard out.This is the very easy echo server of the socket echo server.The create sockets,then connect the pipeline to the map.Then receive the client socket.Then connect the input from the client socket.Reverse back to the same socket.This is the simple echo server.This is the next example is the simple net cat.Read a line from standard in.Then send it to the network socket.Then receive the output from the network socket.So unlike shell programming,these pipeline operators just prepare the pipeline.It doesn't run at this point.So we will,in my idea,we don't make promise anything.But we will introduce the new operator,the new pipeline operator.Then that creates pipeline.Then at the end of the program,the program,the virtual machine will enter the event route.So the simple cat one.This program creates the pipeline.At the end of the program,the next line,the Ruby virtual machine will enter into the event loop.Then we,the event loop,read the input from standard in to standard out.Then when the input is closed,the gradually event loop will finish.This is the simple cat program.So in that way,the normal Ruby program,the program will be structured like this.The normal Ruby that creates the pipelines.Pipelines,I made a mistake.Then the program will enter into the threat-safe event-driven loop.So it's kind of like a loop Goldberg programming.So prepare the pipelines.Then throw the balls into the pipeline.Or maybe the dominoes,the lined dominoes.Then at the end of the programs,event loop just push the domino.The event loop will be a threat-safe.Just because in the event loop mode,every object,in my idea,every object will be immutable.So the program will not modify the object.So we don't have to worry about the sharing.Then we will have the object immutability in threat mode.So we don't have to worry about it.We have some kind of experimental language named stream here,which is some kind of a Ruby-like programming language,as a proof of concept of this programming model.It doesn't work well yet.It's just a Thai programming language.But it's just a proof of concept of this stream model in programming.It seems works well,I hope.You can check out this repository afterwards.Anyway,so again,we are still experimenting with a lot of wild and crazy ideas.And we will be very open-minded.So if you have a great idea for new Ruby or the great idea to improve the communityor improve the language and improve the future.So please let us know about that and write the future request.But remember,we will not throw away everything in the future.So we will keep compatibility.So when you write your future request,please keep it in mind,in your mind.So we make no promise about the future of Ruby.We will announce any road map.But let us talk about Ruby 3.0.So to make some kind of gradual step to create better future,while keeping compatibility.So happy hacking.Thank you.