Crystal: Fast as C, Slick as Ruby

I'm ari borensburg. And I'm juan guapram. And you're listening to the changelog. Welcome back everyone.

This is the Change Vlog. I'm your host, Adam Stuk. This is episode 192. We're talking today about Crystal Lang, fast as sea slick as rwby.

We had Ari Bornsweg and Juan Wachman on the show today. Talked about this awesome language. We covered so many awesome things. The language goals, how it's the best of both worlds between Ruby and C and wife.

It's so close to and inspired by Ruby. Why not just give our time to effort to RWBY instead? We talked about the new compiler and we also discussed what's left before Crystal can go 1.0. Our first sponsor of the show is Toptal.

Friends of the show. We love Toptao around here. Go to TLP TV or if you like your personal introduction on the Toptal, give me a shout. Email [email protected].

whether you're an awesome engineer, an awesome designer, or someone looking for awesome engineers and awesome designers, give me a shout. I'd love to give you a personal introduction to someone top to get you on the right step forward, getting to that next great developer or designer working with you or being that next great designer or developer working through Toptal. Live the dream, meet a travel world and do all the things that Toptal provides to software developers and designers. Again, T O p t a l.com or email me adam changelog.com and now onto the show, everyone.

We're here today talking about Crystal Land. We got two awesome people from Buenos Aires, Argentina today. Ari Born, Swag and Juan. I don't know how to say last name.

Help me, help me. How do we say that last name? Anyway, words for you. Gotcha.

And Jared, you're here. Core. So what's up? I'm here.

What's up, everybody? Guys, welcome to the show. No, thank you, Jerry. We've been this hit our radar.

I don't want to hit your radar, but our radar as a, as a. You know, our weekly email, when we shipped out issue 32, which was forever ago, basically we talked about Crystal Lane there. We talked about it a couple times here and there. It hasn't quite leveled up too much, but we knew we wanted to get them on the show.

We tweeted it to you guys way back when. I think it was about at least six or seven months ago that we were wanting to get a show started on this, but so I guess we'll do A show for one. Which is awesome to finally get you on here. So let's maybe start off with some introductions.

So with Ari, what's. Who are you and what you do? Hi everyone. So I'm a programmer and I don't know what specifically they say but you guys are both from Manus, right?

Manis Technology that's behind this language and you're the devil, is that right? Yes, that's right. Gotcha. And Juan, how about you?

Well, I've been working on Manus almost from the beginning. Like this was like 12 years ago. I'm kind of a co founder of this company. Yeah, we do a lot of bunch of stuff basically so far.

Consulting and well, yeah, I'm pretty much. I have many roles here like a dev leader and programmer and also CTO and Yeah, yeah, Jared and I were talking about the homepage for your company actually manus.com ar so that's M A N A S.com ar we're just talking about how it walks you through choosing if you're the right company for people to work with. So that's pretty interesting. Well, that's interesting and also related with how Manas started.

You know, I've been working for many software consulting companies and one day one of my best friend called me and he said, hey, I'm starting this company, you want to join me? And I said yes, of course. And even though I started with a much smaller salary and the good thing is that we could decide which projects to take and which projects we don't. And so we could decide.

Right. Be a bit more selective then. Yeah, exactly. So that's pretty much the inspiration of the company that we want to make.

The cool stuff and the things that we really know how to do and how can we make use of our best skills just to kind of paint a little bit of work picture for listeners. If you go check out their website which is in the show notes, they have a little colored meter in the center and it says they're looking for a software company. Let's see if it's the right choice. And on the far left hand side is try Google and as you work your way to the other side it's oh yes, they're very excited.

There's a series of questions which you can checkbox that kind of describes what kind of project you have and as you check certain ones it moves meter left or right. So check that out. It's definitely an interesting concept and I think a nice way of you guys, you know, helping your customers self select for more interesting projects. Yeah, yeah.

So we're gonna talk about Crystal, which is a programming language that calls itself as fast as C and as slick as Ruby. If you hit up the page crystal doling.org, you'll find that there are a series of goals set out for the language, which is Ruby inspired syntax, Static type checked, static type check without having to specify the type of variables or method arguments. A series of language goals for Crystal, the kind of language that you guys want it to be. And I was hoping that we start off with you kind of walking us through those goals.

I believe there's about five or six of them and explaining what they are, what they mean, and, and why are there arbol in programming language. So the first one is Ruby inspired syntax. That's like one of the things that motivated the creation of the language. And the second point too is that we really like Ruby syntax.

It's very readable, it's elegant. So that's basically it. So just to add to the previous one, and here at Manus, we use Ruby a lot for many projects we still use Ruby, but in particular we use Ruby on Rails because it's really fast to prototype a new project and come up with a solution that actually works in minimal time. So that's what we love about Ruby and Ruby on Rails.

And when we started with Crystal, we wanted to have the same feeling in our language. Like with Ruby, you can always come up with a nulligan solution for each algorithm or a problem that we need to solve. And we wanted the same in Crystal. So that's why we inspired on the syntax.

And also not only the syntax, but also the standard library and the feelings of language when you're coding. But normally one of the problems that we have with Ruby is the performance for many projects once the project grows and we starting to have performance issues and we need to migrate some part of a backend to another language and we move parts of some projects to Airline, for example, or to go just to match with the performance requirements. So we've been thinking about why we need to move to another language. What if we we could have a language that provides both the elegance of Ruby but performance of a compiled language.

So that's what motivates some of these goals for the language. Also, if you look at how many projects solves their performance issues in Ruby, most of the time you have specific gems that implement some of the solutions in C language and nobody likes that because who could want to write C language in this century? So that would be the Third load, this is. It means if you want performance, you don't need to reimplement part of your code.

And see, you have to be able to write your code just in Crystal and get the best of your CPU or other resources. Right. So right now, if you're a GUI programmer and you won't have a specific section of code that needs to be highly performant, you'll often write that in C and then have a Ruby wrapper binding to that C layer. Kind of the most, at least for me, the one I think most often like Noko Guri are similar when it comes to parsing XML or HTML.

You have a C library in there. And the idea of Crystal is you still want to have that speed, but you don't want to have a C in there. So everything's in Crystal, right? Exactly.

You don't want to need the language to get performance. And the next one you have there is to have compile time evaluation and generation of code to avoid boilerplate code. Can you explain that one? That's another strong point about Ruby, the metabroming capabilities.

Right. And everybody loves that. And it's hard if it's not impossible to have the same kind of metaboloming in a statically compiled language. Right.

So we introduce things like macros that are evaluated at different stages of the compilation that allows you to generate code that gives you the sense of having metabolomy, but in a different way. So you have these specific goals. You like Ruby but you don't like certain aspects of it, specifically performance, the C bindings, the fact you can have great tooling around, type checking and whatnot, the dynamic types, and you decide, enough is enough, we're gonna write our own programming language. So for me, I guess I'm kind of a small.

I consider myself a small thinker. Like I have small ideas. I'm an app developer, so I think about like applications more so than languages are, are very intimidating. So when it comes to let's write our own language, that was, to me, that's a crazy idea.

I love that people like you want to do those kind of things and I like to use languages and study them, but to like write my own is incredibly overwhelming. So I guess the question is whose crazy idea was this? And kind of how did it, how did you guys get the gunction to actually write that first line of code? Yes.

So that idea was mine. When I decided to do it, it wasn't like, okay, I'm going to make a language. It was just an experiment. I said this Idea is interesting, let's see what I can do with it.

And I started doing it alone. And then eventually I showed it to Juan and he said like, wow, this is a nice idea. I'll join and let's work together to make it work. But all the time, like an experiment, a hobby, something fun to do.

It's not like this is our 10th language that we are implementing and now we have experience. It was just we did the lecture parser on all of the stages as we learned things. Of course, we had experience with other languages before, so we knew what we wanted. That's basically the story of the beginning.

So through the magic of get commit histories, I went back and checked out your very first commit, which will help to give some timing around this project because it is a new programming language. That being said, it's almost four years old. So programming languages take a while to grow up. And something created in 2012 is definitely still a young language.

But your first commit was September 4, 2012. Aria as yourself, which include a lexer, a parser, an AST, a few other things. And it was completely written in Ruby at that time, which is interesting because of course it's the tool that you guys love. You're kind of writing somewhat of a replacement in it in Ruby, which is kind of cool.

But at that point, when you hit that first commit, there was a fair bit of code there. Did you have a crystal hello World at that point? Well, in fact, there's another repository, it's under my account, Asterite, that also has crystal, but it's like, it's not a fork. It was like the previous version of the language, which was not very good.

Once I joined, we wrote things from scratch. And so that was maybe one year or two years ago before that first commit you found. Okay, I think there was a hello World or something similar, but maybe with. So it goes back even further back into like what, like 2011, 2010, something like that.

2011, yeah, that's what I was getting. I was trying to page back quickly as you said that, onto your GitHub, which is GitHub.com A S T E R I T E so for those listening along with the show notes too, they'll be there, but it goes back to 2011 and what's. What's in the first version. I guess this sincere question was thinking 2012, what's in 2011, what's the whole world there?

I don't know, it was just something. It was a toy at that point. I think. I think ideas yeah, just, just ideas, some things with closures and how to.

It was just maybe to learn how to, how to start making a language. And then we said, okay, now that we learned a bit, let's go a bit more serious. Well, the truth is these goals were not from the beginning, right? Ari started this like an experiment and once we decided that this could be a good thing to do seriously, then we set up these goals.

But from the beginning it was just like an experiment he was doing on his own. And when he showed me, it was like, well, you know, Ari is an extremely humble guy and seems like he didn't know what he has in his hands. He showed me this and I said, well, this could be a big thing. So one of the things that I think about when it comes to programming languages is and probably a lot of things about this because it's the part that we interact with which is the semantics and the syntax and the way it looks.

Crystal is, you know, its main selling point is slick as Ruby, obviously Ruby's a huge inspiration. Were you guys going for similar type of syntax? We're trying to get identical. Were you trying to, you know, port Ruby in such a way that you could actually like, you know, swap out the Ruby binary and swap it in a crystal binary and be able to run the same code or is it just inspired by Ruby?

Well, in the beginning we wanted, we started with something that was like 100% compatible with Ruby but obviously the standard library was empty and you couldn't do much. But we soon realized that that wasn't going to work because Ruby is very dynamic and we wanted a statically typed language. So we had to make some concessions like adding some types to generic type arguments. And at that point we said, okay, we want to preserve that Ruby feeling when you program, but we want make a Ruby compatible language.

It won't be a Ruby implementation, we want to give the feeling, but it's a completely different language. Just want to kind of go back to that, you know, that time in 2011, 2012 maybe when you guys got serious in 2012 and said, okay, we're going to do this and here we are, you know, it's just the beginning of 2016. So you got roughly four years into this, tons of hours. I'm sure we'll talk about it later, but you're now have people supporting you on Bounty Source.

So it's been a large effort and it's continued success. It'll continue to be a larger effort as it grows and changes. And Adam kind of steal Your question here a little bit because you mentioned this in a pre call which is if you love Ruby so much why not just take all that time and effort and money or whatever it was you guys put into Crystal and give that to Ruby over the years similar to some companies are coming out now I think it's AppFolio recently announced that they want Ruby 3 to be three times faster and so they're going to hire a performance developer. I can't remember the details exactly but they're going to have to be working with the Ruby core team in order to improve performance from your guys perspective.

And maybe you know, maybe it's because these weren't your original goals but couldn't it be slick as Ruby and fast as Ruby as opposed to a whole new thing and maybe, maybe with retrospect you guys can go back and comment on that, on that idea instead. Well I think, I mean Ruby could be probably be much faster than it is right now. It could probably make a lot of improvements but I don't really know they can actually match the speed and efficiency of a language that applies to an executive binary, you know like Crystal or Go or C. Right.

I mean they can probe the current state but they will never be able to match that kind of performance. So now that's another thing that it's one of the, it's the second goal that's statically type check. That's when and it's really common in Ruby we've experienced it that when you need to refactor a big code or make changes unless you have like 150% like more than 100, I don't know you have to make have tests everywhere, you're not sure that you're not breaking something and eventually you get undefined method something at runtime and that's like, that's not good. So with static type checks that issue is gone.

And also as a side effect you can like compile your code and make it more efficient but there are two things so performance and static type checks and I don't think they are going to add eventually static type checks to Ruby. Maybe they'll add type annotations but they will improve the error messages. Maybe but I don't think like you will be able to say okay check the types for my program because Ruby wants to or at least I know that wants to preserve that dynamic nature. It's really hard to change Ruby to a statically typed language.

Agreed 100%. Well I think it's a good chance to stop for a Moment, take a break. On the other side of the break, we want to track it between the time where you had a Ruby based compiler for Crystal and how you got it to be self hosting a crystal based compiler. Also want to ask you how you go about getting those syntax highlights on GitHub for brandy language.

So stay tuned and we will ask those questions after the break. Our friends Linode are huge fans of the show and many developers that work at Linode listen to the show. They're huge fans, they want to support we're doing and we want to invite you to try out Linode, one of the most fastest efficient SSD cloud servers on the market. Use our code changelog20 to get 20 in credit.

Basically two free months plans starting just 10 bucks a month. They have eight data centers spread across the entire world, North America, Europe, Asia Pacific. You got hourly bill with a monthly capital all plans and add on services. You get full root access for more control, run VMs, run containers or even your own private git server.

You can enjoy native SSD storage or GBiT network Intel E5 processors. Again use the code changelog20 to get $20 credit with unlimited uses. Tell your friends it doesn't expire until the end of this year, so use it as many times you want. Share it to everyone you know.

Head to the note.com changeloft to get started. All right, we are back with Ariane. Juan, let's talk about Crystal language, its history, why it exists all the time, effort they put into it and I gotta make you got a lot of people pretty, pretty interested in it. So we're talking about 2012.

You guys had a Ruby based compiler and a syntax for the Crystal language. But now if you go to the repository it's 99.9% crystal. So at a certain point you had a self hosting Crystal based compiler and I was hoping one of you can take us kind of, you know, a brief history of how you went from the Ruby compiler to the Crystal one, how long it took in tell us about that code from Ruby to Crystal. Because we actually did the compiler in Ruby hoping that because the syntax is similar and also the standard library and so on, we would eventually be able to port the compiler quickly.

That didn't turn to be quite true because Ruby's standard library is more or less complete. So we had to implement all of that in Crystal. So it was like okay, let's try to port the compiler to Crystal. Oh we are missing these things so let's do them.

Oh, we found these bugs in the compiler, so let's fix them. And everything we did to the compiler, which was written in Ruby, we had to react, port to the new compiler, and so on. So it was like it was a task that never seemed to end. But eventually we said, okay, let's stop fixing bugs that's in the current compiler, let's try to make the next compiler in Crystal work around some issues.

And eventually we did it. I don't know how much it took, maybe one year, but it wasn't a year dedicated to porting the compiler. It was growing the current compiler, growing the standard library, fixing bugs and making new features and so on. It was really a really fun task.

I think once you get to compile a program that when you compile it again, it gives the same program and then you say, okay, I don't need Ruby anymore for this and I can go on with just this language. It's really cool. So you guys have, as of now you have about 4,100, almost 4,200 stars, 335 forks and 119 contributors. That's on the Manistech Crystal repository.

So as I said, you managed to kind of capture the hearts of people and you got people excited. When did you first announce Crystal to the open source community and what was the decision making around that announcement and how was it received? I actually don't remember when was the first time we made this public and I think it was in hyper news or something like that. Of course we immediately attracted attention from the Ruby community because of the similarities of language, of course.

And of course many of them were expecting that we were doing a compiled Ruby and many of, many of them still do the same. I think we decided to announce it or maybe make it public. It was public from the beginning, but we decided, I don't know, to post it in Hacker News or something like that, to have a second opinion about the project because we thought it was something cool, something nice. But maybe others didn't think like that, I don't know.

And luckily, and amazingly the reception was amazing and a small community started to grow. There are people in Japan and Turkey giving talks, having small communities. It's really something. I think we didn't expect that.

And maybe all of that happened because Ruby's community and the people there are really nice and really helpful and they want to collaborate, they want to do something good. And like it was transferred to this project somehow. Well, you might say that the programming language has officially arrived when it gets its first Rails inspired web framework, which you guys now Have Amethyst. I say you guys, as in the Crystal community wasn't written by YouTube, but that one hit our radar.

I think it was within the last six months or so a kind of Sinatra inspired Crystal based web framework. So yes, Crystal has arrived in that regard. You said amazingly, people received it. Well, anybody in particular or any stories that you have of people using it that were surprised to you or delighted to see Crystal projects such as Amethyst kind of coming out that you couldn't possibly have imagined anything like that?

I think more than the code, I think like the community doing talks in countries like we searched the Internet and found talks and said, oh look, they are talking about Crystal here. We didn't know that they are doing stuff. Of course the frameworks and the code is also something that's really helpful and nice, but I don't know, I enjoy more the community around it and I don't know if Amethyst is the Rails framework of Crystal. Like everyone's trying to do Rails for Crystal because maybe that's the most successful language for a project for Ruby.

Now there's another one, Frost, that's in the early stages and another one came out which is like Sinatra. But we really think of Crystal as being able to do other things like command line applications, web servers, maybe not using a huge framework. We try not to influence much about how a web framework would be designed. In Crystal we have enough work to do making the language and fixing back in the language and making it perform better every day and we let just other people in the community to create a framework around the language and we want to focus on the language itself.

Yeah, I was mostly saying that tongue in cheek about the web framework thing. Just seems like every new language pops a sort of web framework and sometimes the merits of that will, you know, invoke more excitement and sometimes not. Let's have some respect. We'll talk about the future here real quick about Crystal because you guys had a big change in the works.

You announced it just a few weeks back, a big change coming to the programming language. And I'll talk about that in detail. But first let's talk about like an imaginary future where Crystal is as successful as you could possibly imagine. Like what's the ultimate end goal or success state look like for Crystal as a programming language?

Feel free to go out there and share your hopes and dreams. What would be the awesome success story for crystal Looking back 10, 15 years from now? Well, for me the most successful date would be the one that, I mean, when a developer wants to create a project that requires all the kind of stuff that you need right now, like performance and the ability to manage high amounts of concurrency. And you choose Crystal because it gives you that, but also gives you the benefits of a language that is similar to Ruby.

You know, many people are using Go language right now or Link because of the concurrency capabilities, but they're unhappy with the language itself because they feel so restricted in the object oriented aspects. So in the future I would like to choose Crystal because it matches both requirements. Speaking of the feature you recently wrote, that post I mentioned before called the Future of Crystal, wherein you tell a bit of a Christmas story, which is kind of a fun read if you guys are interested. That's in the show notes about kind of imagined future where Crystal becomes abandoned.

And it's mostly due to these increased compile times, which seems to be only a small problem right now. But as you guys say in a little tale, it's a growing problem. And so you decided to rewrite the compiler. Can you tell a story on that decision and all that went into it?

That question was always around like, okay, we are infring types like this and the compiler works like this and will it be able to handle a huge project or without you having to wait a lot of time. And from time to time we thought about some solutions, but we didn't end up with many solutions. And eventually we realized that this way wasn't going to work. So it was kind of like in the beginning when we decided to add some types to generic types.

We realized without that the language couldn't continue evolving and adapting to greater needs. So this time we decided or we concluded that we needed some type annotations, for instance variables and a few other places. With this we have an algorithm and we have an idea of how to make this scale for bigger projects. Because waiting for stuff to compile is not fun at all.

And we want a language that's fun to use. So in all aspects and current type annotations here and there, just a few ones won't take that fun or it will take that fun less than having to wait a lot of time to compile your code. And we wanted to announce it. It's like we are working on the compiler but not fully dedicated to it.

It's like we are working on many 10 on several things right now, but we wanted to announce it to have to know others opinions and to announce it to make sure we won't disappoint a lot of people later. The more we wait, maybe it's worse. When you say announce, you mean the fact that you're going to have to rewrite the compiler. Is that what you mean by that?

That you have to add some more type annotations? In some places, like right now, you're not forced to do that, but once the new compiler arrives, you have to do that. And many complain because they say no. In Ruby we don't want, you don't need to use type annotations.

So yeah, this is not a good decision, but it's a different language. So it seems like we're hitting on a bit of the crux is the trade offs right between your goals. On right, you have two goals, slick as Ruby and Fastest C. And we know that the fastest C has a bunch of things in there like type of notifications and it's not just speed.

And like it's hard to be a servant of two masters and you have to pick one or the other in certain circumstances. And it seems like what you're finding out with the dynamism and the lack of types, or excuse me, the lack of type annotations required currently, is that the compiler suffers. And so you have to make these decisions between, well, do we take the language this direction, which is further away from our Ruby syntax, our Ruby semantics, but closer to, but ultimately better, or do we stick with this and possibly have these super long compiled times in the future? And it seems like that's something that you guys have been struggling with.

You decided to rewrite the compiler, add the type annotations and kind of diverge further from movie. Is that a good summary? Yeah, so that's exactly it. We actually don't need to rewrite the compiler, we can just force type annotations and make it work like that.

But with those type annotations we can make a faster and more efficient compiler implementation. So that's why we decided to like completely do it. And it's also because now we have like an idea of the whole language that we want. In the beginning it was just drawing as we added more features where we didn't have the idea of how the language going to look once finished or once having most of the features features that we wanted.

So this is obviously a huge breaking change for all current users of the language, right? Yes. Compile anymore probably when they switch to the new. Yes, but on the other side, on the other hand, we didn't hit 1.0 yet.

So in most of our releases we break code because we take the opportunity. Since we are not at 1.0, we want to make sure we get the best standard library and compiler and language that we want before having to decide, okay, now we are going to be backwards compatible from now on. It seems like if I was a current user of language, I would be more concerned with the slowdown than I would be with the type annotations and with the changes to language itself. Because it seems like a rewrite of the compiler is a huge undertaking.

And as you said, there's lots of other aspects of the language that need building out, such as the standard library, but I think dependencies management also a thing that needs to happen. Do you think this is going to set you guys back? Is it six months? Is it three months?

Is it no setback as far as getting crystals to that 1.0? Yes. I don't know how much time it will take, but in the meantime we are continuing evolving and set the library, fixing bugs, adding some features. So it's not necessary for the compiler to be completed quickly because the upgrade or the migration path you need to do is like really simple.

You need to add some type of annotations, but since the current compiler already impresses those types, we probably make a tool that automatically adds those type annotations. So when we started we had complete freedom of choosing when to break things. Right. So after we make it public and you start thinking that you have to maintain features or try to be backward compatible just because there's a community out there that is using the language.

Well, we always try to put communicate to our community that the language is not in production ready state. So I think most of the people from our community is not just users of the language, but people that want to contribute to the evolution of the language. So feel that making breaking changes is actually because we actually talk with them and share the decisions so they actually feel they're parts of the decision that we're making the language. So it's not that someone's going to get angry because we broke the compatibility with the pattern with previous versions.

So at this stage, the current state of the project, we want to still be able to have trigger of breaking things. We think that we did things that are wrong in the past and if you want to make the language that we can. So if we want to, if you have to maintain backward compatibility, that is not possible. Yeah, anyway, you're still exploring, I mean you're pre 1.0, so it's not as if you know, even say on the top of your homepage, you know, we mentioned the, mentioned the bounty source, but that you're raising money, you can help fund it and become production ready.

So that means that you're still exploring, you're still kind of identifying where you're trying to go as language. So to me, if someone's using or adopting it, they can sort of take on those same risks. If you're using it for something, then you might understand that things may or will change and you have to do with that. Yeah, that's true.

So I was searching a little bit to find the feedback on that announcement because it is a big announcement and like, like you guys said, you know, you're some people are. Well, you may not said this, but I was at least thinking of it as you have certain people that we backlash on. The other people are all for it. And for the most part it seemed like so surprising to me.

It seems like most of the response was relatively positive. So that's probably great to see. There was, you know, some sad voices out there. So we need to take another break.

But on the other side, I want to bring up one kind of contrary opinion to this move with the new compiler and see if you guys can your thoughts on that opinion. So we'll do that right after we hear from the sponsor. Here's the change ball. We have two emails we'd love for you to subscribe to.

The first is Changelog Weekly. Now we've been shipping this email for several years now. We ship it every single Saturday morning. It's everything that hits our open source radio.

It's our editorialized take on what happened this week in open source and software development. Go to changelog.com weekly to subscribe. And our second email is changelog Nightly. Every single night we ship this email out covering all the top new and top star repos on GitHub at 10pm central time.

It's all the latest stuff on GitHub before it blows up. It's often our own radar. We're often creating shows and finding new people, finding new projects, putting things on our own radar based on what we find in there. So we'd love for you to subscribe to that.

Head to chainful.com knightley and now back to the show. All right, we are back talking about the future of Crystal and the newly announced rewrite of the compiler. Guys, like I said before the break, mostly solid reaction from your users and your community about this decision. Seems like the right way forward.

But as is always on the Internet, there are some dissentive opinions and unfortunately I have copy and pasted one of my notes which is really the only which is really the only bad response out there but just want you guys to address this Anonymous I'll leave it Anonymous says Sorry but this is a huge damper on the appeal of Crystal. It's Ruby like syntax and being mostly typeless was a differentiator. I suspected the types on array and hash would eventually be solved and removed. Going the opposite way removes much of the differentiation and puts it into a class of a number of new LLVM based languages of which there are no shortage of.

I'm assuming all native responses are kind of in that same vein. So I just curious about your thoughts, your reaction to that reaction. Of course it's a reaction. I don't know if we don't like it, but we also agree on that reaction because maybe since we are so similar to Ruby in many things, people expect things to go closer to Ruby, but I don't know.

I think it's not that of a big change and it's true that there are many other LLVM based languages out there, but I think Crystal has many features. Like one of the top features I think is blocks that are in Ruby and in Crystal and I don't know if there are many other languages that have blocks. You can have closures but it's different because you can break or do next and other things from a block that makes it a bit different. And like many other things that we keep from Ruby, I don't know, my advice would be to wait and try it out once we finish it and to realize that it's not that of a big change.

Because most of the time you're writing methods, you're writing code. For example, someone writes a library and you want to use it. You don't need to define your types, you just write a method, invoke methods and stuff like that. And in those cases you don't need type annotations.

So I don't know, I think it's a matter of time to see if the reaction is just fear or something like that or it's something that's real well said. Aside from the new compiler, what are the other missing pieces? I think I mentioned dependencies. Maybe you can speak to that one before you guys are ready to call Crystal 1.0 production ready and you know, available for general use.

What else is missing? Well, for 1.0 we wanted to have a proper support for concurrency. That means we want to go multithreaded and have a better gc. Actually anything that makes freestyle to make better use of your hardware resources.

Because right now the master version works in a single state and it works better than an Node JS application. But we don't think our goal is to be a better language than Node js. We want to make a language that again makes the best use of your hardware resources. So have a good concurrency support.

That's one of the goals for 1.0, and personally it's one of my preferred goals. Yes, that's one of the goals. I think one loves concurrency and efficiency, especially regarding how much your computer can do. Other goals are finishing the documentation, which is a huge task not only for the language but also the standard library, and then fixing bugs and maybe adding some features like we have named arguments, but we want to enhance that.

Maybe some other keywords like retry or just small features, small language additions. But I think that's basically it. Those are the main three missing things from Kristen. I think I teed up the dependencies conversation.

Could you just speak to that specific point? Well, we have a dependency manager. It was written by Julien Portalier who's also collaborating with us. It's working.

You can use it Right now it's decentralized, but we want it to be. But we don't want to have a central registry. And even though it's working, we want to continue a bit of work there to make sure it scales without needing a central registry, but in a way that you can still find things that you want. Maybe Juan can say something about that because he's also really interested in that.

I can explain why we don't want to centralize the repository of dependencies. Yeah, when Ari said I was that's what worked up Myers. Like why not a centralized repository for. Well, the thing is, sometimes I think something that happens with the James and the rubychain repository is that someone takes some specific name for a library that have a very specific purpose.

You know, for example, you know you're going to make a postgres driver. So someone created the library and of course they name it postgres and they publish it and maybe then they abandon the library or maybe someone else comes with a better approach for making the same library, but the names are retaken. So you have to start using names like postgres through and someone has to know that the right version of the library is the one that with the two or something like that. So instead of that we want to make sure that there is no central common namespace that we have to share and be the first to register the name before other makes a works library with the same Name, you know, when you looked it up on rubygems.org too, you know, the same vein of like if you had an idea for a gem.

I remember Jared back in the day when he was on this call still yet in the Changelog, he's an API junkie. He would always, at the time he was like writing Ruby wrappers for everything you think of. It was LinkedIn, it was clouds, it was this, was that. And I can remember how excited he would get if he like searched for XYZ on RubyGems and it wasn't available and say, hey, make this yours.

So in that scene where I can kind of see coming from the roots of Crystal with Ruby and, and you know, but to me I'm wondering if that's a, you know, I get the concern for that and maybe I'm taking it further than it should be. But I wonder if that's just really the community thing and not like a repository thing because, you know, NPM is pretty huge and they've not had to deal with stuff like that. Like in the end the community will resolve who the canonical version is or what the best version is just by, you know, dependencies on the libraries rather than trying to solve it at the package manager level, so to speak. Yeah, and the truth is at the end we probably don't have control over that and we don't want to have control.

Maybe we can give some ideas to the community about how we think this will work, but we don't want to have the final decision. And maybe someone comes with a better solution and we focus on the language, someone will focus on the dependence manager and if it works better than what we thought, that's good. How are they handled right now? Is there any dependency management right now?

Yes, it is. It's called Shards and right now it works with the GitHub repositories. Okay, so it's using version repos or you know, git based repos versus like a central repository. Exactly.

Yeah. I use the DAX as versions. Gotcha. Let's talk about getting started.

I know we've talked deeply about, you know, the various ins and outs of the living, the shadow of Ruby, so to speak, and grow up and hopefully becoming a 1.0 and all the other things around Crystal language. Someone's not going to listen. Let's say they're new to it, they love Ruby, it's the first time they're hearing about Crystal. What do they do?

How do they get started? How do they play with it? What's the very first thing they can do to sort of test the water, so to speak. Well, right now with support we have installers for Debian based Linuxes and also Red Hat based Linuxes.

And also we have an official package in Homebrew. So the first thing you have to do is install it. So we really provide packages for most of the platform that we could support. And if you're using Homebrew, I like the flag you have there with LLVM stuff you're trying to contribute back to project and using Homebrew, is that the same option on Arch Linux and the other options you can still pass the flag to or you get the LLVM by default on other package, I guess.

Not using Homebrew? No, unfortunately on Linux the package is. Maybe we need someone that understands a lot more than us about how to make a proper package to the different Linux distributions. But you know, maintaining a linear package is a big task.

So maybe someone can help us with that. Although we have a question coming up the end that will probably help highlight some of those things. But ok, so you've got different packages on Debian, Red Hat, Arch Linux, using Homebrew for Mac and then you even have a tarball. If you want to compile or pull down the source from the source itself, you can go in this direction.

So is there a web option? If someone wanted to go and plug something into the web and have it actually installed locally. Is there an option for the web display.fristalang.org Nice where you can. The best thing is that all of these tools like shards and play.pristalang.org made by us.

That's why I say it's amazing like we started evolving the language and the tools around it. So you can. Yes, you can try code there in several versions of the language and run it. Don't try to run an HTTP server.

But you know, and we also mentioned at the top of your homepage you've got fund Crystal and help it become crypto ready. So we've mentioned at least in happenstance your bounty source which to this date $4,501 has been raised. So each month we get around $1,100 of support. We didn't go deeply into this, but it seems like the roots of Crystal and at least the motivations of it have some tie back to your company managed.

So you guys are both developers there? Co founder to a degree. CTO earlier thank you mentioned. So what.

What is. What's happening with dinosaurs? How can people step in and I guess support. This is one just financially supporting us.

Is there other ways to step in and support Crystal Language moving forward to become Fast Async and split Ruby? So basically most of the time we spend doing Crystal is our free time and as the project gets bigger there are more tasks and we really want to do it not in our free time. So Bounty Source is one way, one of the best ways you can help us to make that possible because we can work like at work time and fully motivated and not tired from work. But there are many options to contribute, like if you send bug fixes or documentation which is lacking, and also additions to the standard library that you think like those are great ways to contribute because the less we need to do or we rely on the community, the better.

Well fellas, it was definitely a fun time here talking with you about this language and obviously you've got some roots in rwby, but you're spreading your own wings and making your own path, so it's always a fun direction to go. We love having new languages here on the changelog and always getting a deep dive into what you are doing. Is there anything else you guys want to cover before we tail off the show? Anything else else?

No, I don't think so. We enjoyed having on the show today. Thank you so much for joining us and all listeners out there listening. Thank you for tuning as well.

But that's it for now, so let's say goodbye. All right, thanks for guys. Okay, thank you. Bye.