The Changelog: Software Development, Open Source - Crystal: Fast as C, Slick as Ruby (Interview)

Episode Date: January 29, 2016

Ary Borenszweig and Juan Wajnerman, the folks behind Crystal, joined the show to talk about the goals of the language, how it's the best of both worlds between Ruby and C, why if it's so close to and inspired by Ruby why not just give their time/effort to Ruby instead, the new compiler, and we also discussed what's left before Crystal can go 1.0.

I'm Ari Bornzweg, and I'm Juan Wachnerman, and you're listening to The Change Log. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 192, and we're talking today about Crystal Lang, fast as sea, slick as ruby. We had Ari Bornzweg and Juan Wachnerman on the show today talking 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 why if it's so close to and inspired by Ruby, why not just give their time and effort to Ruby 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 TopTal around here. Go to T-O-P-T-A-L dot com, or if you'd like a personal introduction to someone at TopTal, give me a shout. Email me at adam at changelog.com. 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 at TopTile 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, living the dream, being able to travel the 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 at changelog.com. And now, on to the show. Everyone, we're here today talking about Crystal Line. We got two awesome people from Buenos Aires, Argentina joining us today.

Ari Bornzweg and Juan. I don't know how to say the last name. Help me out. How do you say the last name? I pronounce it Wachnerman. Wachnerman. Okay. Anyway, it works for you okay gotcha and jerry you're here of course so say 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 know when it 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 um we talked about crystal laying there we've talked about it a couple times here and there it hasn't quite bubbled up too much but we knew we wanted to get them on the show we tweeted 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 uh started on this but uh so i guess welcome to the 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 uh who are you what do you do hi everyone um so i'm a programmer, and I don't know what specifically to say. But you guys are both from Manus, right? Manus Technology.

Yes. That's behind this language, and you're the dev lead. Is that right? Yes. Okay. That's right. Gotcha. And Juan, how about you?

Well, I've been working on Manas almost from the beginning. That was like 12 years ago. I'm kind of a co-founder of this company. And yeah, we do a lot of bunch of stuff. Basically, software consulting. And well, yeah,'m not really much uh i have many roles here like a dev leader and programmer and also cto and uh yeah yeah jared and i were talking about the home page for your company actually manis.com.ar so that's m-a-n-a-s.com.ar and 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 friends called me and he said hey i'm starting this this company they want to join me and uh i said yes of course and uh even though i started with a much smaller salary and uh the good thing is that we could decide what projects to

to take and which projects we don't and so 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 staff 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 a word picture for the 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, so you'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 yeah, it's like 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 the 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 here to 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 homepage, crystallang.org,

you'll find that there are a series of goals set out for the language, which is Ruby-inspired syntax, statically type-checked, statically type-checked but 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'd 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 why they're desirable in a 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 Manas, we use Ruby a lot for many projects. We still use Ruby. In particular, we use Ruby a lot for many projects. We still use Ruby. 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 an elegant solution for each algorithm or problem that you 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 the 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 start to have performance issues.

And we need to migrate some parts of our backend to another language. And we move parts of some projects to Erlang, for example, or to Go just to match with the performance requirements. So we've been thinking why we need to move to another language. What if we could have a language that provides both the elegance of Ruby, but the 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 solve the performance issues in Ruby,

most of the time you have specific gems that reimplement some of the solutions in C language. Right. And nobody likes that because who wants to write C language in this century? So that would be the third goal. This is it means

if you want performance, you don't need to reimplement part of your code in C. 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 Ruby programmer

and you want to 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. You know, kind of the most, or at least for me, the one I think of most often is like NoCodeGiri or similar when it comes to parsing XML or HTML. You know, you have a C library in there.

And the idea with Crystal is you still want to have that speed, but you don't want to have the C in there. So everything's in Crystal, right? Exactly. You don't want to leave 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 metaprogramming

capabilities, right? And everybody loves that. And it's hard if it's not impossible to have the same kind of metaprogramming in a statically compiled language, right? Right. So we introduce things like macros that are evaluated at different stages of the compilation that allow us to generate code that gives you the sense of having meta-programming, 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 that you can't have great tooling around type checking and whatnot, or the dynamic types. And you decide enough is enough. We're going to 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'd you guys get up the gumption to actually write that first line of code? That would be Yari. 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, hmm, 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 lexer parser and all of the stages as we learned things. Of course, we had experience with other languages before,

so we knew what we wanted. And that's basically the story of the beginnings. So through the magic of Git 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, you know, 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 4th, 2012. Aria, it was yourself. Which included 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 and you're kind of writing some sort of 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 is another repository.

It's under my account, Asterite, that also has crystal, but it's not a fork. It was like the previous version of the language, which was not very good. Once Juan joined, we rewrote 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 C bindings. 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. I went to your GitHub, which is github.com slash A-S-T-E-R-I-T-E. So for those listening along, I'll go to the show notes too. That'll be there. But it goes back to 2011. And what's in the first version, I guess, of this? And Jared's question was thinking 2012. What's in 2011?

What's the whole world there? I don't know know it was just something it was a toy at that point i think i think just ideas yeah just just ideas uh 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, OK, now that we learned a bit, let's go a bit more serious. Well, the truth is these goals were not from the beginning. I already 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 and uh but but from the beginning it was just like an experiment that he was doing on his own and when he showed me it was like well you know Ari is a extremely humble guy and uh seems like he didn't know what he has in his hands and he showed me this this and I say, wow, 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 people think 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 is a huge inspiration. Were you guys going for similar type of syntax? Were you 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 in a Crystal binary and be able to run the same code? Or is it just inspired by Ruby? Well, in the beginning, 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 won't make a Ruby compatible language. It won't be a Ruby implementation. We want to keep the feeling, but it's a completely different language. I just want to kind of go back to 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, 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 now have people supporting you on Bounty Source. So it's been a large effort, and if it continues success, it'll continue to be a larger effort

as it grows and changes. And Adam, I'm kind of stealing your question here a little bit, because you mentioned this in our pre-call, which is if you love Ruby so much, why not just take all of that time and effort and money or whatever it was that you guys have put into Crystal

and give that to Ruby over the years? Similar to some companies are coming out now. I think it was 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 somebody work with the Ruby core team in order to improve performance.

From your guys' perspective, and 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 with retrospect, you guys can look back and comment on that idea instead. Well, I think Ruby could probably be much faster than it is right now. It could probably make a lot of improvements. I don't really know they can actually match the speed and the efficiency of a language that compiles to a executable binary, you know, like Crystal or Go or C, right? I mean, they can improve the current state, but they will never be able to match that kind of performance.

There's another thing that's the second goal that's statically type-checked. And it's really common in Ruby, and we've experienced it, that when you need to refactor a big code or make changes, unless you have like 150% load like more than 100 i don't know you you have to make have tests uh everywhere uh you you're not sure that you're not breaking something and eventually you get undefined method uh something at runtime and that's like that 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 this is 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 completely self-hosting a Crystal-based compiler. Also want to ask you how you go about getting those syntax highlights on GitHub for a brand new language. So stay tuned, and we will ask those questions after the break. Our friends at Linode are huge fans of the show and many of the developers that work at Linode

listen to the show. They're huge fans of what we're doing here and they want to support what 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 2 free months. Plans start at just $10 a month. They have 8 data centers spread across the entire world. North America, Europe, Asia Pacific. They got hourly billing with a monthly cap on 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, 40 gigabit network, Intel E5 processors. Again, use the code changelog20 to get a $20 credit with unlimited uses. Tell your friends. It doesn't expire until the end of this year, so use it as many times as you want. Share it to everyone you know. Head to lenode.com slash changelog to get started all right we are back with Ari and Juan talking about crystal language its history why it exists all the time and effort they put into it

and um I gotta admit guys you got a lot of people 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-based compiler to the Crystal one, how long that took, and also the standard library and so on, we would eventually be able to port the compiler quickly. That didn't turn out 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 this 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 report to the new compiler and so on. So it was a task that never seemed to end. But eventually we said, okay, let's stop fixing bugs 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 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 ManusTech slash Crystal repository.

So as I said, you've managed to kind of capture the hearts of people and you've got people excited. When did you first announce Crystal to the open source community? And what was the decision making around that announcement? And then how was it received? I actually don't remember when was the first time we make this public. And I think it wasn't on Hacker 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 them still do the same. So 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 or I don't know. And luckily and amazingly the reception was amazing and like 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 it was transferred to this project somehow. Well, you might say that a 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 you too. But that one hit our radar. I think it was within the last six months or so, a kind of a Sinatra inspired crystal based web framework.

So yes, crystal has arrived in that regard. You said amazingly people received it. Well, Crystal has arrived in that regard. You said amazingly people received it well. Any buddy 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, Kemal, 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 try, I mean, we have enough work to do making the language and making fixing bugs in the language and making perform better every day and we let just the other other people in the community to create the frameworks around the language and we want to focus on the on the language itself yeah i was most i was mostly saying that tongue-in-cheek about the web framework thing. It just seems like every new language

pops some sort of Rails-inspired web framework, and sometimes the merits of that will invoke more excitement, and sometimes not. Let's ask from this perspective. We're going to talk about the future here real quick, about Crystal, because you guys have a big change in the works.

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

for Crystal as a programming language language feel free to go out there and share your hopes and dreams what what would be what would be the awesomest success story for crystal looking back 10-15 years from now well for me the uh the most successful state will be the one that uh 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 choosing Go language right now or Erlang because of the concurrency capabilities. But they're not happy 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 future, 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 an 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 that 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 inferring types like this, and the compiler works like this. And will it be able to handle like 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, it's not fun at all. And we want a language that's fun to use. So in all aspects. And adding 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 and on several things right now but we wanted to announce it to have to know others opinions and to announce it to to to make sure like we won't disappoint a lot of people later like the more we wait and maybe it's worse when you say announce you mean the fact that you're gonna have to rewrite the compiler is that what you mean by that? That you'll 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'll 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 fast as c and we know that uh the fastest c has a bunch of things in there like the type of notations 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 um and the lack of types or excuse me the 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 compile times in the future?

And it seems like that's something that you guys have been struggling with and you decided to rewrite the compiler, add the type annotations, and kind of diverge further from Ruby. Is that a good summary? Yes, that's exactly it. We actually don't need to rewrite the compiler we

can just force uh type annotations and make it work like that but with those type annotations we we can have a we can make a faster and more efficient uh 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 growing as we added more features, but we didn't have the idea of how the language was going to look once finished or once having most of the features that we wanted. So this is obviously a huge breaking change for all current users of the language, right?

Yes. Their code's not going to compile anymore, probably, when they switch to the new. Yes, but 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. And it seems like if I was a current user of the language, I would be more concerned with the slowdown than I would be with the type annotations and with the, you know, the changes to the 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, and 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 there no setback as far as getting Crystal to that 1.0? Yes, I don't know how much time it will take. But in the meantime, we are continuing,

evolving the standard library, fixing 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 annotations but since the current compiler already infers those types and will 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 feeling that you have to maintain features or try to be backward compatible just because there is a community out there that is using the language. Well, we always try to 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 I feel that making breaking changes is actually because we actually talk with them and share decisions so they actually feel they're part of the decisions that we make in the language so it's not that someone's going to get angry because we broke the compatibility with the background with previous versions. So at this stage, the current state of the project, we want to still be able to have freedom of breaking things. We think that we did things that are wrong in the past. And we still want to make the best language that we can. So if we want to, if we have to maintain backward compatibility, that is not possible.

Yeah. I mean, you're still exploring. I mean, you're pre 1.0, so it's not as if, you know, you even say on the top of your homepage, you know, we've mentioned the bounty source, but that you, you know, 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 a language. So to me, if someone's using it or adopting it, they can sort of take on those same risks. If you're going to use it for something then you understand that things may or will change and you have to be okay with that yeah that's true

so i went searching a little bit to find you know the feedback on that announcement because it is a big announcement um and like like you guys said you know that you're some people are well you may not have said this but i was at least thinking of it, is you'll have certain people, there'll be backlash, and there'll be other people that are all for it. And for the most part, it seemed like, somewhat surprisingly to me, it seems like most of the response was relatively positive.

So that's probably great to see. There was some sad voices out there. So we need to take another break. But on the other side, I want to at least bring up one kind of contrary opinion to this move with the new compiler and see if you guys can, you know, your thoughts on that opinion. So we'll do that right after we hear from the sponsor. Be right back. Here at the Change Law, we have two emails we'd love for you to subscribe to. The first is Change Law 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 radar. It's our editorialized take on what happened this week in open source and software development. Go to changelaw.com slash 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 10 p.m. 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 changelog.com slash nightly. 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 dissenting opinions. And unfortunately, I have copy and pasted one into my notes, which is really the only bad response out there. But I just want to see if you guys can address this. Anonymous, I'll leave it anonymous, says,

sorry, but this is a huge damper on the appeal of Crystal. Its 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 negative responses are kind of in that same vein. So I just was 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. 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 new 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 um 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 multi-threaded and have a better GC. Actually anything that makes Crystal to make better use of your hardware resources because right, the master version works in a single thread. And it works better than a 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 Juan 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 Crystal. 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 Julian Portalia, who is also collaborating with us. It's working. You can use it right now. It's decentralized, but we want it to be... 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 one can say something about that, because he's also really interested in that. I can explain why we don't want a centralized repository of dependencies. Yeah, when Ari said that, that's what perked up in my ears. I was like, why not a centralized repository for them?

Well, the thing is, sometimes I think something that happens with the gems and the Ruby gems repository is that someone takes some specific name for a library that have a very specific purpose. For example, you're going to make a Postgres driver. So someone created the library and of course they named it Postgres and they publish it and maybe then they abandoned the library or maybe someone else comes with a better approach for making the same library but the name is already taken 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, a common namespace that we have to share and be the first to register the name before others a world's library with the same name you know remember when you looked up on rubygems.org too you know in the same vein of like if you had an idea for a gem i remember jared back in the day when win was on this call still yet in the the changelog uh he's an api junkie and he would always at the time he was like writing ruby rappers for everything you could think of it was linkedin it was clout it was this was that and i can remember how excited he would get if he like searched for xyz on ruby gems and it wasn't available and it would say hey make this yours so in that in that same right i can kind of see coming from the the roots of of crystal with ruby and you know but to, I'm wondering if that's a...

I get the concern for that, and maybe I'm taking it further than it should be, but I wonder if that should just be the community thing and not a repository thing, because NPM is pretty huge and they've not had to deal with stuff like that. In the end, the community will resolve who the canonical version is

or what the best version is just by dependencies in other 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 about that. And we don't want to have control. Maybe we can give some ideas to the community about how we think this should 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 else focuses on the dependency manager. And if it works better than what we thought, that's good.

How are they handled right now? Is there any dependency management whatsoever right now? Yes, it is. It's called Shards. Okay. Right now it works with GitHub repositories. Okay. So it's using versioned repos or Git-based repos

versus like a central repository. Exactly. Yeah, I use the text as versions. Gotcha. Let's talk about getting started. I know we've talked deeply about the various ins and outs of the living in the shadow of Ruby, so to speak, and growing up and hopefully becoming a 1.0

and all the other things around Crystal language. Someone's out there listening. Let's say they're new to it. They love Ruby. This is 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 things 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 already provide packages for most of the platforms that we we could support and if you're using homebrew i like the the flag you have there with LLVM. So if you're planning to contribute back to the project

and you're using Homebrew, is that the same option on Arch Linux and the other options you can still pass a flag to? Or do 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 Linux packages is a big task. So maybe someone can help us with that. Well, good. We have a question coming up at the end

that will probably help highlight some of those things. But, but okay so you've got different packages on debian red hat arch linux uh using homebrew for mac and then you even have a tarball if you want to compile or pull down the source or from the source itself you can go any of those directions so what's is there a web option if someone wanted to go and plug something into the web and not have to actually install locally is there an option for the web there's play.crystallang.org nice where you can yeah the best thing is that all of these tools like shards and play.crystallang.org weren't made but by us that's why i say it's amazing. Like people 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 anything else. You know, and we also mentioned at the top of your home page you've got fund crystal and help it become production ready so we've mentioned at least in happenstance your your bounty source which uh to this date four thousand five hundred thirty one dollars have been raised so each month you're getting around eleven hundred,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, Manus.

So you guys are both developers there, co-founder to a degree, CTO, early in the call you mentioned. So what's happening with Bounty Source? How can people step in and, I guess, support this? Is it one just financially supporting it? Is there other ways to step in and support Crystal Language moving forward to become fast as C and Slick like 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 at work time, 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 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 you know obviously you've got some roots in Ruby, but you're spreading your own wings and making your own path.

So it's always a fun direction to go. And we, we love having new languages here on the change log and always getting a deep dive into what y'all are doing. Is there anything else you guys want to cover before we tail off the show? Anything else? No, I don't think so.

We enjoyed having you on the show today. Thank you so much for joining us and all listeners out there listening. Thank you for tuning in as well, but that's it for now. So let's say goodbye. Bye. Thanks for coming on guys. Okay.

Thank you. Bye. We'll see you next time. Bye.