 So good morning everybody, I hope you had a good RubyConf so far. My name is Matt Immunity, I'm Mervis on Twitter, and these are websites where you can find me. If you have any questions and I can't answer them at the end of this talk, please send me a tweet and I'll reply to you as soon as I can. Before we start, I want to let you know that today is a very special day. For many reasons, the first one is because it's the Adelos Muertos, it's the day of the dead. So if you're Hispanic or if you like tacos, you might want to really enjoy this day. And tonight, go get some margaritas and tacos. And if you're Hispanic and if you celebrate, well, have fun. And it's also today my birthday. So I live in San Diego, California, but my mom is back in France. And she's always worried that I don't have a lot of friends. So I just want to show her that I have some friends. So I'm gonna record it, and you guys are gonna sing for me please. Happy birthday. So in English is fine, my mom speaks English. You can speak in German, Tim, if you want. All right, so one, two, three, thank you. It's also Brian, a help camp birthday. So if you want to make him happy, go on Code Climate and give it a try. I'm sure we'll be really happy. All right, let's get started. So before we talk about programming languages, I sat down with a linguist and I asked her, can we talk about human languages? Let's talk about it. I speak a couple languages, but I want to understand a bit more what it means to study languages. And we talked about it, and she came up with this theory that was discovered quite a while back by two linguists called Sapien Worth. And they basically came up with the conclusion that the way languages are designed affects the way we see the world, the world view we have, and the way we behave too. So it seems logical when you think about it, but they had to actually prove it, so they did a lot of research. And an example of that is a tribe that they found in the middle of nowhere, I'm not sure where it was. But this tribe didn't have a way of talking about the past or the future. So they could never say yesterday this happened or tomorrow we will do that. They were stuck in the present, and the way they would be, okay. We don't want to hear anymore of this. All right. So for those of you who don't know, we just walked in. Today is Matt's birthday. They just sung for me, thank you. You bastard. Well, you may have sung for him, but did you get a six pack of beer? Wow, thank you guys, thank you. Merci, thank you. Thank you. Happy birthday, Matt. Thank you very much. He always gets nervous when he talks, so. So I have to drink him now? Okay, all right, that's it. If we can't sing to you, you can at least drink the beer. All right. It's noon on the east coast. Yeah, so we could. It's hour late. Thank you, guys. Thank you. Happy birthday. Thank you. All right, so I was explaining that languages affect our behaviors and the worldview. And this tribe really was stuck in the present because the language didn't allow them to talk about the past or the future. So based on that, I wanted to study more programming languages, but I'm not a linguist. And I was not really good at school, so I wasn't really sure how to do it. But I did what I could, and I came up with a few things. First, I discovered a few things you should not do, at least things that didn't work for me. The first thing was to study a language by just looking at Hello World and say, okay, I don't like it or I like it. Hello World is a very bad way of looking at language. It's like if you would hear one sentence in one language, and you would judge the entire language based on that sentence. And that sentence actually doesn't mean much. The other thing I realized is that syntax is a very bad way of looking at a language. It is true that it's the first thing you see. It's true that when you look at a language, you look at the syntax, and you might have a feeling about it. You might react to it, but it's actually not the right way of looking at a language because the syntax hides a lot of concepts behind it. So how did I do it? How do I think we should do it? Well, I think you first should look at the philosophy of the language. You should think about it. What did the language designer was trying to do with his language or a language? Also, you want to make sure you find the right use of the language. You don't want to have a Michael Jordan language playing baseball or golf because it just doesn't work. And it's not because of the hands. Actually, Michael Jordan uses hands on all these ports, but he sucked at two of them. So it's not that simple. But what you really want to do is to be curious about it and come up to the language with new eyes. Try to get rid of the expectations you have, the worldview you're coming from, and try to look at it like if it was the first language you would learn and try to understand it. So I studied a few languages. I came up with this grid, and it was very boring, so I said, forget about it. I focused on seven languages, and I was going to talk to you about seven languages, but my talk was about two hours long. And I realized of these seven languages, there are only four languages I really like, or that are really interesting, that are very interesting to study based on our knowledge of Ruby. So I decided to focus on three languages, closure, Scala, and Go. Then on the second part of the talk, I tried to think about how these languages affected the way I write Ruby code. So I do write a bit of these languages. I write way more Ruby code than I write closure, Go, and Scala code. But by studying these languages and by writing some amount of these other languages, I realized the way I was writing Ruby code changed. And my view of Ruby code changed. And my view of maths as a language designer actually also changed. So the format of the language study will be very simple. I will take a Ruby class. So this is the example where I create a class with two getters and setters. I have a constructor. I have a start method. At the end, I create an instance of the object, and then I call method on it. So that's kind of my halo world, but a bit more complex, so I can compare languages and give me an idea of what it could look like. That's kind of my entry point into the language. Now, it's not a good way of judging the language. Again, it's not a way of judging anything. It's just a way to try to take something we all know and apply it to something else. Then for each language, I will look at a use case. What's the main use case I found for the language? What's the philosophy? What do I dislike? What do I like about it? And where to start if you want to learn the language? So let's start by Go. Go is a language by Google. That was released a few years ago. It's a compile language. It's a structural type language. So what that means is that instead of having functions taking typed arguments, the functions will take objects that respond to a certain structure, a certain way the object is defined. So concretely, what that means is that you can define a function that could be applied to any object that respects a certain interface, and an interface is basically saying, these are the criteria for my object that need to be respected so I can call this function on that. Go is also an object-oriented language, which might be surprising if you really didn't study Go, but it's a fully object-oriented language, but it's a lightweight object-oriented language, and they really revisited the way object-oriented programming works, and they took a different twist on it. It's also a fully functional language, so you have higher order functions, you have anonymous functions, you have all these things. What you saw Jim do this morning in a keynote, you can also do that with Go. I'm not sure why you would want to do it, but you can do it. Learning Go is actually easy to normal. If you have any background in C, it's slightly easier because there's a concept of a pointer, and you might not know what a pointer is, but because the language is very small, you get in the language really quickly and you can have fun pretty fast. Here's an example of the Ruby class I showed it to you at the beginning, ported to Ruby. We defined the package, which is the name of the application we're in, basically, of the library. Then we import the library, which is like requiring Ruby. Then we create a new class, which is the equivalent of a class. It's a type, which is a struct that has two members, name and topic, and both of them are strings. Then we define this function, start, that can be applied to a pointer of a presentation class. Here it is. Now we could change that to have an interface. Well, I don't know what's going on there, sorry. We have this start method that will return a string, and then we concatenate the string based on the two members' name and topic for the struct. Then we have the function main that gets called at the beginning when the program starts. We create an instance of talk passing two different arguments, so mat and go for name and topic, and then we print the output of the function. It's not too, too hard to follow. It seems pretty simple. It doesn't have all the semicolons. It kind of looks a little bit like Ruby, but not too much. So what's the main use case? For me, the best use case for go is concurrency. And I will show that to you by showing an example of a simple code I wrote. And the idea was I want to call three websites at the same time, and I want to concurrently fetch three resources, wait for it without blocking, and then get all the responses coming at the end. So the code, again, we define a package. We import three libraries. Then we define an array of strings that has the three different URLs. We define a new type, which contains three elements, URL, response, which is a pointer to HTTP response, which comes from net HTTP, and then an error so we can look at the error if we have an error. Then this is the entire code for my application, and it highlights the use of concurrency in go. So we have this function that takes a param, which is an array of strings, and we will send back HTTP responses, an array of HTTP responses, and we create what we call a channel. And the channel is the way go does concurrency. You basically have this concept of a channel that's in the middle, and we're gonna write this channel and read to this channel. So we don't share memory by talking between the different threads or however we do concurrency. We talk through this broker in the middle, which is a channel. That's buffered with a certain length. Then we create an empty array for the responses, and then we look through the URLs that were being passed, and we start this go function. So this is an anonymous function. That's a go function, meaning that it's async. So it gets started separately. It can be in different threads or not, depending on the system resources. And this function will take a URL, will print it, then it will do an HTTP get of the URL, and will respond with a tuple, which is the response object, and will be the error code that might happen if the resource is not available. Then once we have that, we create this object, the HTTP response object that we defined before. We create an instance of that, and we push it into the channel. So this is the channel we have here. Finally, we call this anonymous function by passing the URL that was coming from the looping we did through the URLs. Then once we do that, we do a for loop. So we just look through, we just basically loop, and we say, if there is anything in the channel, get it for me. And if we have something, we'll print the URL that was coming from the channel, and then we'll append the response to the array. And if we add all the responses based on the length of the URLs, we'll return that. Otherwise, what we'll do is just print a little dot and slip for a little bit so the loop is not too tight. So that's it. That's the entire code. To use it, we'll have a main function, and we say, get all the URLs, and for each of them, we're going to print it and see the result. When we compile this code, so in Go, you compile to machine code directly. So you just say, go build. This is the file I have, and you print that out as a binary, as a machine code file. And you can see it actually comes back. I said, I want to fetch this URL, this URL, and this URL, but the order that comes back is actually different. So we implemented a very nice way without sharing memory of doing concurrency. And Go is really good at that. Go is also good at a lot of other things, but for me, that's the main use case for Go, it makes concurrency easy. So what's the philosophy of the language? Well, really Go tries to be the new C. It tries to be a very simple, very brief language. You don't have to write a lot of code. You keep it very isolated. It fits in your brain, and it's following the UNIX philosophy. So taking the UNIX and C as a language to the next level, which is concurrency. And that's really what C is trying to do. What I don't like about Go is that it's sometimes a bit too low level. Sometimes I wish it was a bit higher level so we could do things. It would be more accessible for more people. There's also the fact that Go doesn't have a really good garbage collector. So if you compare with the JVM, of course the garbage collector is not as good. It's decent, and you can get really good performance. It has also limited adoption. So that's not really true anymore since One.org got released, and a lot of people started using it. Hampton, Kathleen, who wrote Hamel used that in his company for a very interesting project. You should talk to him about that. Google uses it also internally, and they replace a bunch of C++ code by Go, including a project that they have that lets you download Chrome. So every time you go and you download Chrome, the binary. They add a C++ front-end that was taking all this requests and using concurrency to fit that, and they replace that by Go. The other thing I don't really like, it comes from the standard library. Sometimes you had some weird conventions that would be surprising to me coming to the language. I guess I would just get used to it. So what do I like about Go? Well, the specs of the language are so simple, I actually can get them to fit in my head. So if you compare with Ruby, Ruby is a very complex language, and to actually follow the specs is hard, because you have a lot of flexibility and you can do a lot of more things. Go is simpler, and I actually enjoy that when I write simple code, because I know exactly what the language will do and I know what to expect. The standard libraries of Go are really, really good. You have everything almost in the standard libraries, from a proto buffer to all the net HTTP libraries. You have JSON, you have everything. I'm looking for a specific one, I can remember it. You really find most of what you need, you'll find it in the standard libraries and they really try hard to do that. Concurrency, we saw that. You have this concept of Go routines and the channels that are very efficient and a very simple way of thinking about concurrency without having to use locks and mutexes. A lot of the conventions are actually sensitive, even though I complain about it in the first slide, you'll see that when you start using Go, they'll tell you this is how you organize your language. They even have a tool that tells you how to format your code. You can run it and it basically reformats your code so it follows the convention. It makes things easier when you get started and when you don't know the language and it also helps when you have a team of people trying to follow the same conventions. Compilation is fast. You can compile a very, very big Go app faster than you can start a boot-up Rails application. So it's really, really quick. Okay, Rails is really slow, but it's still really fast. What's that? No, it's not setting a very high bar. It's basically almost as fast as running a scripting language in some cases. So it's really fast. So you don't really feel like you have to wait five minutes while it compiles. The way you organize the code is flexible. You don't have to do it the C way. They have this concept of package compiling and the linker is really smart. It's a very nice way of doing it, especially when you come from a scripting language. The take on object-oriented is actually very interesting and I didn't have time to really spend a lot of time on that, but I would really challenge you to look at how they thought about object-oriented and how you can have types and more or inheritance the way they do it which is not the usual way and how you can share functions between different object types. We also have all the features of functional programming that we love coming from Ruby. The error handling is actually very interesting in Ruby, in Go, because coming from Ruby or from Java, we're used to raising exceptions everywhere. If you use Rails, if you don't find a resource, we just raise an exception and then we'll do some control flow. In Go, if I just go back quickly, you can see here I was returning, I do an HTTP get if that returns an error, this value will be filled with the error, otherwise it will be nil and I can actually ignore it. The idea is that if you raise an exception, you will need to catch it at a higher level and now you actually bridge the separation of constraints because code that's above needs to know about the code that's underneath and needs to know how to handle it if there's a problem and it's not always the right thing to do. You actually have to handle manually the error, which seems a bit odd at first, but I really like it and I'll talk about it towards the end when I will explain what I changed in the way I write a Ruby code. Documentation is really good for Go and you can go in all the packages, you can see how they write their code in Go and it makes things, it makes it for a really good way of learning the Go syntax and how the Go authors write their own libraries. The website for Go is really good at golang.org, they have a tour, you can follow the different steps, you do it in the browser, you don't need to install anything. You have a bunch of books, the book on the right is a cheap book, it's a community book that was written by somebody in the community, the other ones are professional books. It's really easy to get started, I would suggest you spend a few hours just to see if you like it or not and see if it can challenge you. We're totally different, we're going from SeaWorld to Lisp Scheme World and we're going to talk about closure. So who actually knows a bit of closure? You have a few hands. Okay, so actually a bunch of you already tried closure. So let me share with you my own experience and you might disagree with it but that's my experience. So closure is a compile language, it's dynamically typed but you can also mention types. So you can say this is a function and it will actually return a specific type so the compiler can optimize it but it's really dynamically typed language. It's a functional language that tries to be as functional as possible, everything should be a list, everything is data. It's not technically really true all the time but they're really trying hard. It's also object-oriented. So that's what people don't always know about closure and actually closure people don't really like to say that but I'll show it to you. It's also object-oriented because closure tries to be a practical implementation of scheme and sometimes object-oriented programming makes a lot of sense. The learning curve for closure is normal to nightmare and the reason why I put that is because starting is actually not too too hard. Once you stop thinking about C programming and you understand how to write code it's actually pretty easy to get started but the problem I had with closure is as I was learning more and more about it you need to know more and more functions and you need to have all these things fit in your head and you need to be able to context switch back and forth and that becomes really hard for me at least in the long term. So again, the example. Some examples at the beginning we define here a protocol so this is not an implementation, this is just documentation. My protocol is called talk and it has a function called start that will return the speaker and the topic. Then I create this record which is basically a class called presentation that has text two arguments in the list name and topic. Then here I implement I basically say I'm implementing the protocol called talk and I define this method called start that doesn't take any arguments we don't care about what's being passed and would return a concatenated string of this is, hi this is the name that's being passed here and I will talk about the topic. Then to create an instance we say deaf talk that's going to be my instance, presentation. Notice the dot here as a presentation, mat and closure so this is the list that will basically be extracted here and get these two variables and then I call start talk so you can see scheme reads from left to right. Okay, so this is the example in object oriented programming now most of the time when you write closure you don't really write code like that but I will show it to you because that's what I did for languages. So the best use case I found for closure is data processing. Data processing is basically the idea of we have data we want to go through the data extract some value of that and process it and handle it and do something special with it. A use case for that is I want to count all the words in a single file name and this is the implementation I've never seen closure or scheme it might be a bit hard to understand how things work just for the record I had to actually Google that this here operator is called a thrush operator and that's it I just had to Google it so I wanted to share it with you to show that I know something and I learned something so thrush operator great so in this case you can see the code is not too big and we're processing the data and we're just passing it through different functions so what's the philosophy of closure well the philosophy is Lisbon scheme are really good we really like this languages we like functional programming but we want to get something practical because fully functional programming languages are awesome but then it's hard to build concrete things with them to do something really efficient we don't have all the libraries it's not efficient you don't have the libraries you don't have potentially a good garbage collector you don't have all the things you get from the JVM so instead of reinventing the world let's just put ourselves on top of the JVM try to get all the Java developers to come over learn some some scheme but also offer some of the flexibility of calling doing the interop calling into Java and also doing some object oriented programming if needed so what I don't like with closure is that I was lied to I felt I thought it would be very simple I thought oh I'm going to be able to get this closure thing done in a few weeks and then I'll be an expert in closure which turns out it took me a while and I went I even took classes and I still feel dumb when I write closure like just getting the namespace right I just never get the syntax right which is another point it's not always consistent even though it tries to be consistent it's actually not always consistent another problem I have is that you need to know a lot of the functions in the macros you need to know what they do you have a really good command line tool that will give you the documentation for it but I find myself having a very small brain and having a hard time keeping all of that in my head and I have to look up for functions all the time so granted if I was writing closure every day eight hours a day that would probably after a couple of months or years I probably should be able to handle that but right now I have a bit of a hard time a smaller issue I had is that I was thinking a I'm going to write web services in closure I'm going to do cool stuff I'm doing with Ruby but I want concurrency so I'm going to write closure code instead and turns out that the closure community is not really web oriented it's really about data processing so even though you have a few libraries and a few frameworks that are interesting most people don't really care too much about doing normal web webby stuff they will do web related stuff but more in the data sense of the word another big problem I had is the mental context switch if you go from closure to Ruby from closure to Scala from closure to anything you always have to take a few minutes and just think oh wait this is closure this is how I write it and when you go back to the other language the same thing and finally one thing I really hate and this I really hate and I really wish I would fix it in closure is the error stack absolutely meaningless if you have any problem with closure you have an exception you have something happening there's no way you could guess what it is and I first I thought I was just stupid so I asked experts and they're like let me let's look at the source code and we'll understand what you did wrong and that's not really the point of having error stacks so that's a problem I really wish they would solve quickly so what do I like about closure well I can tell you for data processing this is really awesome you keep it very simple very focused you get it done it's you really isolate things and you get good performance you can also use a Java interop so if you need the library you need to do a crypto you can actually end up using a Java library so you have libraries for a lot of things and you can deploy this thing really easily on the JVM so it's something the fight that's easy to use it's an easy scheme that's practical and really good for data processing so how do you how do you get started well you have a bunch of books that are really good I personally recommend you go to this URL and you take the catas so it's basically a bunch of exercises that teach you the language by going through step by step solving small problems learning how to write scheme in closure basically and that's a really good way of learning and then just take a small project and try to do it in closure alright let's move on to the last language Scala so Scala is probably the closest language we have from Ruby at least from my perspective before I get too far into that I just want to stop and explain a bit more about Scala Scala is a compiled language it has static infradynamic types and actually also structural typing so most of the time you would use static and infratiping means that if the compiler can guess the type of the object you don't need to mention it so usually what you do is when you write a method you say this method take this argument and you will define the argument types and the return you might also want to document it otherwise it can be guessed most of the time when you actually implement the method inside the block you usually don't type it you don't have to actually set the types so if you come from Java or if you know a bit of Java you know how unknowing it can be to or even Objective-C have to set all the types all the time and especially when you come from Ruby Scala comes basically brings kind of an alternative of in between these two things the dynamic typing is a new feature you can actually turn on dynamic typing and just have Scala being written like Ruby I'm not sure why you wouldn't want to do that but you can do it it's a fully oriented language like Ruby and a fully functional language like Ruby the learning for Scala is between normal and hard I think to get started with Scala is really easy because you can write Scala the way you write Ruby code it's it's actually interesting because you end up writing this code it looks exactly like your Ruby code and you're like oh yeah I can write Scala and then you take this code and you send that to a Scala expert and it looks like this is the worst code ever you don't do that but it helps you because you feel productive you start writing code so I was really pushed to learn Scala by Marcel Molino from Twitter and it kind of became my mentor where I write Ruby code in Scala which is bad Scala basically and I send that to him and he's like okay this is what you're going to fix you do this, this way, this way, this way and it makes the learning faster however and you have a lot of things that sometimes you might look at and be like what's this operator, what does that mean and it's a bit of putting and that's why it's a bit harder to learn it's not as easy as go for instance so how does it look like well we define a class called presentation that takes two arguments named arguments name and topic, there are strings here we say their value and basically what that means is that once they are passed they become immutable of their values in the class so we can call them from outside the class and they won't be changed now my name and the topic won't change through the presentation so that's fine we could use variables but Scala is trying to encourage you to use immutable types if you can then we define here instead of defining a function we could define a function but we don't have to, we can have a value that take all these params and that's the constructor and that creates this start object which is a value that's going to be a representation passing math and Scala and then I call it talk.start and it will return the string so what's the use case I kind of scratched my head on that one basically it's good for service oriented architecture and it's whenever you need more enterprising Ruby so enterprising Ruby sounds really bad for a lot of people but if you come from Java and if you need some of the things in Java and if you actually build a big thing that needs more than what Ruby can provide, Scala is a good alternative. I'm not saying you should pick Scala instead of Ruby what I'm saying is in some cases it might make a lot of sense. There's also a lot of it that you might enjoy in the language and the academic approach of the design is actually also interesting. So to take an example I'll talk about how Twitter used Finnegal so Finnegal is a library that Twitter wrote to handle the service oriented approach and this is how they do it and I don't work at Twitter so I might be wrong and they explain it to me hopefully I learn properly. But you send an HTTP request goes through an HTTP proxy which is written in Scala using Finnegal which is the library and that's being passed into the apitwitter.com endpoint via HTTP and here let's say you ask for all my tweets they're gonna split the request and they're gonna send some of the requests to the user service so they can get some information about you and they will send another thrift request to the timeline service to get other information and then from there they're gonna make some other requests to other back ends and then everything will come back and get grouped together and come back as a response for the user. So they build a system using futures and pipelines. So what's a future, what's a pipeline? Well the future is basically saying I will return something in the future but not right now so just wait for it it's like a same concept of a promise basically you say I'm sending something you'll get it but not right now just wait for it and the pipeline is basically saying you send a bunch of requests at the same time you get them back and then you create one response you send back somewhere. So the way they implement it in Scala to show a bit of Scala code is like that say this is my authenticated user it would return a future of a user and to do that we call user.authenticate we pass the email in the password so that looks like normal Ruby code but what will happen is that in this specific case it won't return right away. It would return a future object but the value of user is not yet available and then to look up the tweets we'll get a future of a sequence of tweets so you can think of it as an array of tweets and for that we call authenticated user which is the object we created before. We do a flat map which is like Ruby and then we have a lambda we have a block so it's basically like a map in Ruby but instead of having the two pipes to define user here you say user and then you have the fat arrow and we're passing the value that will be returned by here inside this call. So say whenever you get the authenticated user send it to tweet find by old user passing this user and it will come back a better way or more idiomatic way of writing this code in Scala is to use the four yield operator and here we say get this whenever you get that user put it into this user object or variable and then call this tweet find by old user and pass the tweets the response of that in this object and then we're going to yield that. So that's how you do async code with Scala in the Twitter library. So you end up with async blocking or not depending on what you want. Futures you get the full the functional programming aspect and the object oriented aspect at the same time. This is just the implementation of a server I'm running out of time so I won't go through it but we basically define a service we define an address and then we build a server by passing the name the codec we want so it's going to be HTTP instead of thrift then we bind it to the address and then we link it or build it using the service so the request will be sent to the service there. Coming from Ruby you will see that Scala has a lot of things we already know. You have the concept of any variable which is functional programming basically so you have all the maps the inject the partition the zip all these things you have anonymous methods or functions you have default params you can do metaprogramming you can even do method missing which you probably should not do in Scala but you can do it. Duck typing you can use mixins they have actually a concept of traits which is slightly different than mixins but it's more or less the same and turns out because a lot of Ruby people end up doing Scala and because the Scala community just liked it I guess they picked up a lot on testing so you have good testing library like Rspec that's being ported to Scala and you also have a built-in testing framework that's pretty good. What you do get that you don't have I should not have put the first one on the list but you have inner methods so it's kind of funny when you learn Scala because you will define a first method to say def foo and inside that you can define def bar and call it from inside but it's basically scoped inside this method so you have a writing code that leaves in the scope of the method that's actually quite elegant when you get used to it. You also have lazy evals and streams which is the equivalent of Ruby 2.0 lazy enumerables so you can create infinite loops or infinite streams or collections and you just keep on going through them until you find what you need and the evaluation is done if you remember what Jim was saying this morning in Ruby we evaluate the arguments right away in Scala you can choose to evaluate them right away when you pass them or later on and that's how they implemented lazy eval as part of the language you have a great garbage collector which is the JVM1 performance Scala is way faster than Ruby looking at very small benchmarks on small code I was porting it was between 2 to 10 50 types depending on the code you write what you do so you get really good performance improvement and you stay more or less with the same Ruby philosophy it's also faster at least from what I saw on the benchmarks I saw than closure if you do functional programming I found Scala faster than closure which surprised me but at the same time one is type to the other one is not so that's maybe why and finally the thing that was surprising was the fight that actually really enjoyed using an IDE because that's what Marcel told me to use and I just listen to him and turns out being able to be inside a function and click on a variable and get the entire definition of the variable what you can do with it is nice being able to get the errors being caught before you run them in runtime is also quite nice because that happens in Ruby quite often you call a method that doesn't exist on an object and you catch it pretty quickly with test but having the tools around the language is actually quite nice the philosophy of Scala is basically Ruby minus scripting plus static typing that's kind of how I said it's probably not the way a Scala person will present it to you but that's the way I said and it's really for me the academic version of Ruby I found that Scala being written by a professor at the University of Lausanne in Switzerland has been thinking a lot about what he wanted to do one of the first compiler for Java the one that's still being used and he applied a lot of this knowledge into the language design and you don't get the freedom you get with Ruby but you get a more academic version of it so what I didn't like with the language is that first it has a huge surface learning all the types, the collections, the operators all this thing actually takes some time they're not really hard and if you have Java knowledge it's much faster it's much easier but it's actually huge the learning curve can be a bit impressive at first you get started you're excited and then you want to do something a bit more complex and you realize wait I don't know what to do here the syntax is often abused or it feels abused you have the colon colon with plus at the beginning plus on the other side we'll do different things you have all these different things that are a bit hard to learn the documentation, not that great it's funny but it's just coming from something academic you would expect a good documentation and I found the documentation to not be that great now coming from Ruby we're used to that or we were used to that so it's not a big problem I felt that Scala tried to do everything and nothing at the same time the fact that you mix object oriented and functional programming I found myself with the same issues I had with Ruby at the beginning which is I have 15 ways of doing this thing which one is the right way and if you do Python you know in Python you only have one way of doing one thing but Matt was really nice and said you know what in my language I don't want to force you to do anything and you're free to do it because I don't know exactly how you're going to use it which gave us this powerful language but when you learn it and that's my case with Scala it's always a bit hard to know when do I do this what's the right way of doing it and is there a right way I'm not sure about that and finally the JVM is something that I I like it and it's in my next slide but at the same time I don't like it I wish I had something smaller that could just ship with my application that would be just lighter and not this crazy big thing I don't fully understand so what do I like about Scala well first I feel really close to Ruby or Python I feel like when I write Scala I'm not lost it's not a different world it's not like when I write closure where it's a different mental shift it does a lot of what closure offers because you can do functional programming you can do it in Scala so I find that for things where I'm not really sure if I want to do full functional programming or not I would have a tendency to go to Scala because I'm more comfortable with Scala than I have with closure because it's more familiar it's easy to get started because again it's close to what we know Infra types are great because when you start writing new code you don't feel like the type are just getting in your way or they don't get in your way as much as if you write another language that's strongly typed or statically typed the functional approach is flexible you really have a focus on parallelism and concurrency which you might not have in other languages pattern matching is something I don't have time to talk about but if you come from Erlang you know what it is it's something you have in Scala that I find very interesting the ecosystem of Scala is quite rich I found a lot of libraries probably because you have people like LinkedIn and Twitter and other people using it the community is rich and you can use the JVM and the CLR which I didn't realize until I studied the language you can actually run Scala on .NET which I will not do it but you can which is cool so how do you learn it well you have the Twitter Scala School so Twitter Road they have this all curriculum to learn Scala when you join Twitter and they actually publish that and you can actually do that there's a tour of Scala that works you through learning the language and you have the Coursera Online class which is which I just finished and it's really amazing there were seven weeks of classes that were taught by Martin Odorski the language designer and implementer of Scala and it was a lot of fun really good exercises you can probably start again and you get the online classes available probably online so I'm running a bit of time sorry about that how did all this learning affect the way I write Ruby at the end of the day I still write Ruby more than I write other languages so somebody asked me this question and I was thinking about it and I was like you know I'm not sure and I had a discussion with Brian Help Camp because he was writing some of the code and he was doing it in an object oriented way and I said you know what we should do that in functional we should actually use functional program in this case and we had this discussion about why and how the first realization I add and Jim really showed that this morning during his keynote is that Ruby is as functional as it is object oriented now it's not purely functional so maybe what I just said is wrong it's a functional program a functional programming language you didn't have to have immutable types to be a functional programming language and often when we think about Ruby we only think about the OO aspect of it we do use blocks, we do use lambdas we use functional programming but we kind of don't want to call it like that we want to do everything object oriented and I realized well this is too bad because we have these two paradigms and we should really embrace them because the language designer behind that wanted us to use these two things because there's value in both and they are both complementary we can find, we just need to find the right place to use the right paradigm so when do you do that and I don't have a really good answer I can just tell you what I came up with based on the feedback I had from the Scala community and articles I read from different people and basically the concept in Scala at least is functional programming should be used when you extend your program with new operations when you extend your program with new data you use object oriented programming instead so say differently if your data doesn't change you can use functional programming if it doesn't change and evolves then you probably should use object oriented programming if you want more information about that what I came up with come and find me at the end send me a tweet we can discuss about it I'm not quite sure I can actually write a blog post to explain with specific use cases but I find that the Scala community was a good community to discuss these issues and I think that as part of the Ruby community we should do the same thing because we have the same tools also something we probably all know it's not because you can do something that you should do it it seems logical but when you look at a lot of Ruby code we write we have a tendency to do a lot of crazy things just because we can and I would like to thank Matt for giving us all this flexibility to do all this crazy thing because it's a lot of fun and we can explore it but at the same time remember there's an implementation you need to run language on top of an implementation and if you care about performance, if you care about having other people maintain your code you need to think about the way you organize your code which is not specific to Ruby but think about side effects thinking about metaprogramming complex code wanted to do object oriented everywhere there's a cost to that so you need to think about it because it's not because Matt allows you to do it that you should do it Matt is a very good guy he wants you to do everything you want so you should typing, I realized I actually like typing I remember a few years ago I was saying I would really like to have optional typing in Ruby I would like to have this option because in some cases if you have a method and this method takes an argument called name it seems logical to you that it might be a string but it might be actually an object that represents a string that's something else and being able to define an API and be able to have this API contract saying that the API takes these arguments and they have this type or they will respond to these methods the same way Godos does it and I would actually output this type of information it's very useful in specific cases especially when you write libraries if you write web APIs it's actually also a very good thing to have now that's a different topic but typing is actually not that bad and it evolved a lot and now with info typing you get a lot of value that you don't have when you just have purely dynamic typing also realize that testing is not documentation so a lot of people talked about that I won't spend too much time on it but when you don't know a language go in the test and try to understand what's going on it's a nightmare when you go and you look at the source code of a language and you see exactly what the input is expected, what the output is actually it helps a lot so you should keep on testing and you should write test but don't forget to also document the way your software your program behaves and what is being expected I'm not asking you to document every single line inside of the method but explain the outside of it error handling I talked about that when we looked at Go I have a tendency now to return this tuple an array of two objects one is the object that comes back from my method and the other is the initial error that can be raised that can come from the object so you can actually create an exception object and not raise it, you can just send it and let other people above it handle it so usually I have a tendency to do that in my libraries the way I do it so I will make a request if something goes bad I will return it as an object and I will decide if I want to raise an exception or not or if I want to just pass this information back to the people who will use this library and they can decide what they want to do I'm not fully sure it's a good idea I just feel like using exception for control flow is not the best idea ever all the time it's actually probably a bad idea but there are some cases where it makes sense so let's move on compilers, actually I realize compilers are much more fun than they used to be they don't get in new way as much as they used to or at least maybe I just got better and I also realize that if my code can be optimized for the compiler so if my compiler can understand the way I write my code and can process that it also means that my brain should be able to handle it better so I started changing a little bit the way I write code and I started keeping my structures simple so if you have an array in Ruby you can put any types in the array you can actually start passing different types of objects and if you have a compiler you just don't like that or you need to put a special thing in your object when you send that and I realized well I could actually write Ruby the same way I would write Scala for instance and just choose one type and stick to it in most cases and it would actually keep my code much simpler I don't have to check on the type of the object that's being passed I don't have to do all these things I end up with simpler code that actually ends up running also faster when I realize that once again simplicity matters and Ruby gives us a lot of flexibility a lot of options to do really complex code but we also have the functional programming aspect of Ruby which forces you to keep it simple because you cannot build something very complex while you could but it looks ugly really quickly and everybody will yell at you if you do that in functional programming language but if you have 10 layers of abstraction in OOP people won't really complain about it if you look at a lot of Ruby code there are 10 different abstraction layers and people think my method is only 5 lines or 3 lines of code but actually it's not that simple because when you look at the object graph and how you call this method it's very complicated so functional programming is one way of helping that and what I'm trying to do now is when I can I keep my code simpler by sometimes switching to functional programming for a very specific use case so at the end of this journey I found myself pleased because I came to what I find are some of the limits of Ruby which is good because in everything you have limits and if you understand these limits that means I can pick what's best when it's the best time to do that and I came up with 3 points for what I think the limits of Ruby are performance concurrency and freedom so performance is an issue we know and it's actually a hard problem because it's very much like concurrency is based on the language design you cannot everything is a compromise and you cannot have something very flexible and also very performant or you can but it's really really hard and it will take a long time so you need to choose now performance is a word that means everything and nothing I realize that people think well that means Ruby is slow well Ruby is slower than Scala than Go and Closure but you know what most of the time it's fast enough and I write web services and I did that for Sony PlayStation and I do that now for Living Social and we get response time between 5 to 15 milliseconds writing Ruby code this is fast enough I cannot justify even though I would love to just play with these other languages and write some of my services with that I would not get a much much better performance gain by using other languages where it gets a bit more tricky and a lot of people talked about that I won't go to deep into it but there is a bit of a problem with Ruby at this level you can get concurrency different ways it doesn't mean you can't I'm just saying that languages that came after Ruby like the three we just studied they have when they were designed they thought about concurrency I'm sure when Matt started designing Ruby in 93 or when he released it in 1983 he was not thinking well concurrency is a big deal and that's going to be the future of programming he had threads and he has we have a lot of cool things in Ruby that allow us to get concurrency we can use multiple interpreters we can do a lot of things but the language was not designed the same way newer languages are designed and the last one is freedom freedom is what I get when I write Ruby freedom is basically Matt's letting me make any mistakes I want and not getting in my way it lets me explore what I want to do the way I want but there's a cost to this freedom and I need to be willing to pay it in most cases I'm willing to pay it in some other cases I can't afford this freedom and I will choose to restrict this freedom by choosing another language that makes compromises that are different so at the end of the day looking at all these things I realize I'm not a Ruby developer anymore actually I'm a developer I'm a problem solver but actually that's what people like to say and I thought about it and it actually sounds bad I can imagine this guy on a small desk in a wide room with a small window just solving problems and people just bring little problems to him and he's just like type, yeah I fix this problem and you know if that's my life that's a bit sad because I don't want to be just solving problems all day long what I want is to build products I want to build something and I'm not talking about the startup concept of I want to have this app and I can make millions off of it I just want to build something something that would change the world around me or just a few people something that would make my life easier or somebody else's life easier so you know what the language you use is just a detail you can use Ruby, you can use Sky you can use PHP whatever language you use you can build a great product the only difference if you don't choose wisely the language the way you will solve this problem will be affected because languages as we saw at the beginning shape the way you solve problems and solving problems is the way you build products so choosing a language can affect the end result of your product so you need to be curious and you need to learn new languages and the reason why you want to do that is because you want to think about how to build products differently you want to solve problems different ways so you can end up with other results and there's nothing wrong with looking at other languages and going back to the one you like and say you know what actually write Ruby there's nothing wrong with Ruby or in this specific case I'm going to take another language because it solves this problem differently and in back sense what's very valuable is when you learn other things and you go back to the way you write Ruby and now you write Ruby code it fits better your brain it's just a really good feeling so go and build all some stuff with whatever language you want design your own language have fun with it understand the concept behind it and just enjoy building stuff thank you