00:59 - Sean Stephens Introduction

Kyle Jessup Introduction

01:04 - Perfect 

03:14 - The Lasso Language and Framework

07:10 - Lasso Parts => Perfect

13:42 - Developer Response to Perfect

15:32 - What Perfect Currently Consists Of

20:02 - Getting Started on Perfect

23:50 - Open Source, Licensing, and Contribution

28:50 - Swift on Windows

29:40 - Swift and the Backend Ecosystem

30:55 - Why Choose Swift?

33:48 - Performance

35:39 - Benchmarks 

38:26 - Use Cases

Picks

Charlestown, SC (Jaim)
Amphibious (Kyle)
Pleiades (Sean)
SwiftyGPIO (Andrew)
Anker (Andrew)

 

Hi everybody and welcome to iPhreaks Episode number 140. This week on our panel we have Jaim Zuber.

Hello from Minneapolis.

I'm Andrew Madsen from Salt Lake City. This week we're going to be talking to Sean Stephens and Kyle Jessup from the Perfect project. Sean, do you want to give us a little bit of an intro about what Perfect is?

Absolutely. Perfect is a web framework of full back end, and server for developing applications with— so effectively it is a server-side Swift.

I'm not really as, as competitor but you could say that our competitor would be Node or PHP or anyone of the other frameworks or languages out there that people use for backend work.

Great. So I've, I've been interested in and working in Swift since it was released a year and a half ago. When Apple announced that it was going to be open sourced at WWDC last summer, I think one of— the first thoughts that a lot of people had was, will open source means that it'd run in Linux and that means maybe we can write back-ends in it. At least, I thought of that and I remember talking to some other people.

So, is this something you start working on as soon as that possibility became a clear one? Give us a little bit of the history of what you were thinking in starting this.

So, Kyle and I came from a, a different back-end which is the Lasso back-end. We'll probably be talking a little bit of that today.

What we did when we heard Apple open source is we went out drinking because we realized that'd be another competitor for backend for what we were doing at that time was not a project in in the Lasso world.

We came with this same realization that you did which is Swift— being such a beautiful language— would likely start to compete as a back-end language and we went out to start drinking. Seemed like the logical thing to do.

I think that's what you have when you're about to start on a project as big as this is.

[Laughs] Exactly. I was actually sitting at a bar where Kyle and I we're talking and he said, "I've got a great idea. Why don't we take all of the intelligence of what we've done with the Lasso Project and bring that over into the swift world and use all of the many years of the history of Lasso in this new project? That, that we'd be able to use Swift both on the front and the back for mobile development."

He and I stared at one another for a bit and realized that was the logical thing to do.

I must admit that never having heard of Lasso or if I have, I don't know anything about it. I don't remember. But I quickly pulled up the Wikipedia article about it.

Tell us a little bit about Lasso. It seems like Kyle's name is right there on the page as being the designer but how did that start? Just briefly, what is Lasso all about?

Well so this is, there's a long history to Lasso. So let me just go quickly into that. Lasso has actually started in the mid-90's as you can see from that article and what it was, was a web design the company went “Hey we, we should be able to use file maker” which was Apple's product for— access type product for those who don't know— we should be able to connect that with the web and they started working with different scripts and different things. And Apple's script— an Apple script version came out. One, once, they realized how effective that was, they went, "Hey let's go build a product." So they brought in a young designer, a young engineer whose name was Kyle Jessup! Oddly enough is sitting right here beside me.

They went built a first product which was Lasso. Now, what's interesting is, is that Apple saw how incredible this was. At that time Apple was two companies— there was Apple computers which was hardware and there was Clarus which was the software front-end which includes file maker, Clarus homepage, other things. They actually licensed Lasso into their product as CDML – Clarus Dynamic Markup Language. So in fact, Apple's first web language, their first back-end was in fact CDML which was Lasso.

Jobs in 1997 went back to Apple, he cut off I think there was 80 prod— 80 products something to that effect. One of them was Lasso and he went through and cut off everything that wasn't part of the original vision of his. Lasso ended up back going its own direction with the company at the time which is Blue World. Now this is— a one hour show I think so we probably couldn't go through the entire story of the history of Lasso. But it is still popular amongst Mac users and, and amongst education and defense and other things.

There's very specific niches where it's used a lot. But as the back-end languages continued to grow and thrive in its own niche, as a competitor to back-end or server-side languages like Node, PHP. Now, Lasso version 9.3 is out. It's got also sorts of amazing, nifty things. But as a language, A, it has— had and still has a lot of backwards compatibility things built in to it which makes them as a huge language. It's truly remarkable. But it's also an embedded language and other things which has limited its ability to grow. One of the key things that's been limited about it is it’s close source and open sign it, completely at this point would be very dangerous because US Defense Department uses it and CCs uses it and battleships use it.

So, instead we realized this an opportunity which was when Apple did this whole open source thing process or talked about doing it with Swift; that we could take all of the genius behind or underneath Lasso and move it over into Swift. This started as a conversation because when Swift first came out, Kyle and I were sitting at a table and I said, "What do you think of Swift?" Kyle looked at me and said, "It's the perfect language. It's exactly what I would go and design for Lasso

10."

It's obvious it did not— it doesn't have the same maturity as some of the older languages like Lasso. But it's certainly was going the right direction. It had no baggage and no problems. So, it was literally out of nowhere exactly what a language should be from scratch.

Okay. So Lasso itself is a language. It's also the framework— am I'm talking about that right?

Yes. That is correct. You can build web sites with; run back-ends with it etc. It's fully featured language. [Pause]

Okay. So what parts are coming to Swift in Perfect? How would that compared to existing web frameworks again? Node.js, Rails, something like that— do they have similarities?

Yes. Obviously Perfect is a very new idea we're just— I could be getting of what means to happen in order to make it a fully featured web tool kit. I would say the core thing that's people go building or what – iOS are building apps.

The front-end of an app needs to connect, in many cases, with the back-end in order to share data and access that data. Usually that involves connecting with data sources, connecting without things and pulling all that information together. That's typically what one would use Node to do. Of course, if we're using Node and we've got the same field type of sets, et cetera on one side and on the front end, you've got other pieces. You want them— you're going to end up doing the code twice. So, instead the idea is you can now use the front or build the front and the back-end in the same language so that you can use less code to do the same amount of work. Does that answer the question?

Somewhat. Now certain web frameworks are very low level where you end up in front of a lot of things yourself versus Rails that does a lot of things for you. It builds up, builds up your models, your views. I'm just wondering, did you see Perfect being something that has a lot of magic that builds stuff for you so you can go fast if you do it the, the Perfect way or something that you're more inclined to do things in smaller things where you have more control?

Right now it's less— you get less than you would get from say, Rails. You're talking about active record and things like that. We do have plans to build in some components that would do all these magical back-ends [inaudible] for you.

Currently, right now it's more of a do it yourself. We have all the basic functionality that you need for doing web requests. We have built in new WebSockets. Of course we have objects for handling the request and the response for your http. But as far as assembling the contents, that's more of a manual effort at his point. But we did build in connectors for several data bases. We have support for MongoDB, Postgres and MySQL. We have plans support for, ODBC and Oracle at this point also.

I think the question always is and we hit this with Lasso where the Lasso Project just kept on including more and more and more pieces until it became absolutely huge and almost unmanageable. A lot of those pieces should have been other separate projects or separate pieces. So, I guess the question what framework is— at what point does it actually limit you by growing too large?

I think we're going to learn that as we go; also, realizing that we consider this a mobile first backend as opposed to many of the other, say Rails, which is really a web development back-end. Pretty [inaudible] for saying that but this is really— the intent here is to make sure that your apps have a back-end that makes sense.

The logical evolution of it— which is I'm not going to say necessarily inevitable but I’d like to think of as inevitable— is that eventually Swift – once a compiler comes out for Android, a compiler for Black Berry and a compiler for Windows etc. As it gradually progresses and takes over, there will be in fact one language that you can do everything with which would Swift which would be beautiful.

I want to go back to something you just— you were just talking about, about the project getting too big and I think one thing that makes Node and other web frameworks really attractive— my limited experience with web development is with Node, so that's why I'm using that but Node itself, is really actually not that big. Doesn't, doesn't really cover all that much.

The web server and being able to do received requests and send responses; but NPM is a huge part of Node cause there are all this packages out there that other people have written and they tend to be— well as far as I know they’re all open source. I think it's gotten to the point where you don't really— you can't— nobody writes a Node app without using other packages and, and usually quite a number of them. I'm thinking you probably see a similar situation in the future for Perfect?

Absolutely. Something like gems where you can take an object components as you need them. We don't want it to be one monolithic thing that you download every time and put on every server because that just creates additional attacks surfaces and additional liabilities for anyone who’s managing production server. So, the more simplistic we can keep it, so that we can keep it simple to bring in the pieces that you need makes sense.

So I think you guys just got a big boost when Apple open sourced Swift last month. Something that at least I had no idea was coming was the Swift package manager. It seems to really be – maybe even more so than for writing an app in Swift, this is what package manager should be really nice for working with Swift on Linux and doing back-end, that kind of thing. So, I imagined you were happy to see that?

Unbelievably so. We spent six months of our lives working our way on a project that we had no idea – even though Apple had, in fact, put up their hands and said, “We will open source.”

A, they didn't say when and B, we weren’t sure how. But when they did, we had our – our plan was to put a Linux version of Perfect out. We thought it would take 7-8 months so, our project plan was fairly long and aggressive. And yet thanks to Apple putting things out that we weren't expecting. We're able to get it out in a matter of weeks.

So beyond happy. We were ecstatic. The project— everything that we've done and this is the test which built the beauty of Swift and the genius of Kyle perhaps. But also, everything that we’ve gone to attack for example WebSockets, we thought this would take months or— to make sure it's implemented correctly. But in fact we've done it in a matter of weeks. We’re so far ahead of schedule that we’ve thrown out everything that we've predicted so far.

I think the community as the whole that's really excited by the way the Apple did the open source release because some of us, maybe the pessimist among us thought that they would just do a source code dump like they've done with objective C in the past.

Now, they really went all in so that certainly was a good thing for you working on Perfect but just the community is a whole makes the whole thing much more viable for these uses outside of iOS development.

I want to get into some of the technical details with Kyle but one, one other thing I want to ask you, Sean, is about the response you've received from the iOS development community. To go along with that, I wonder if you've heard much from people who are outside iOS development. It's, it's an obvious thing for iOS developers that are already working in Swift and whatever. But what about people who are coming from other platforms and other technologies and are maybe interested in Swift as a language on some merits. What have you heard from people?

The obviously, as you've probably seen from all those soft metrics and quotations, we’ve had thousands of people literally. I think we're going to cross 5,000 GitHub stars today and 15,000 twitter followers. This is a matter of five weeks. It's astonishing.

As to who of those are web developers versus iOS developers versus— I'm not really sure which are which. What I would say is we've had great trouble keeping up. We've had dozens of people write us and say, "How can we move forward? What can we do to help?" We've had hundreds of people write in and say, "What else can we do to, to move you forward?" We've had thousands of dollars in donations. That's just astonishing to me. We've had Fortune 500 call us and say, "Hey we'd like, we'd like to do some proof of concepts with you. Are you willing to fly to Germany and fly to wherever to come work with us?"

It's unbelievable. We've had difficulty responding to the emails, to be honest.

Well, it certainly it has gone all over. I think I heard about it, about it when you first announced but it's been consistently at the top of people's discussion, stuff like that. Kyle, do you mind answering some technical questions?

I don't mind at all.

I just want an overview of what Perfect currently consists of. You mentioned that you can do web requests and responses. I assumed that it also encompasses a basic web server? What does it cover so far?

Right now, it consists of what we call PerfectLib which is a framework which contains basically the core functionality. It consists of two different server variants. We do have the standalone http server. We also include a FastCGI server and a module for Apache. So you can write it either standalone or with Apache. The standalone server will also support SSL.

The whole package is designed to be highly concurrent. So it has threading built in to the core. To achieve that, we used libevent which is a piece of software which Lasso itself also uses so I’ve had a good deal of experience with that.

Is libevent an open source library?

It is, yes. And it basically lets you sit up events for your io occurrences so as soon as you try to read data, nothing's available, you can swap in another thread until that data comes in. So, you built the core of both servers— the HTTP server and the FastCGI server of both uses technology.

One of my next question was going to be the force Swift was open source at the beginning of December, I think most people, myself included, assumed that the release would be fairly limited. In particular I think a lot of people thought that the Swift standard library would be part of that release but that foundation, which of course, is essentially the standard library for Objective-C and it has a lot more in it than the Swift Standard Library. I think most people thought foundation would not be included.

I saw people writing projects that they called – they called Linux ready even before Swift was on Linux. They would say this project is Linux ready and what they meant by that is it only uses the Swift standard library. It does not use foundation. Of course, the open source release does include foundation, although it's not done yet but it will be. Another thing it also includes is with libdispatch, grand central dispatch.

I'm curious to know if the fact that those are part of the open source release may change some of your plans for implementation or some of the technical details of the way you're writing Perfect.

Yeah. That was a little bit of a surprise— a pleasant surprise to see that that they had intended to re-write core foundation all in Swift and release it. But as you mentioned, it's not complete yet. I didn't believe they were going to do that. I didn't expect it and so— of course I did what everybody else did which is, just try and stick to the basic Swift Library there. Even do my own imports of things such as ICU for Unicode handling, Perl for local networking graphing stuff.

The goal is as the core foundation gets more fleshed out then we would not include these components. I know that they— Swift itself uses ICU in the core and what's more of the niceties that we get from ICU which is just Unicode handling— very robust manner. Once those become more fleshed out in the core foundation we will definitely remove those dependencies because I like to keep things lean and not have a lot of things that we need to include to be able to use this project.

Cool. That makes sense. But I guess it's— in some ways a good thing that you did not count on those because like we mentioned, they're not really done yet and you would have ended up delaying the release of Perfect.

Yeah. That's right and [crosstalk] even with libdispatch – I'm a big fan of lib gcd and libdispatch. I had originally written all of Swift using that with the hopes that it would be available or if it wasn't available through them, maybe I could get a compiling myself.

The reality was it wasn't ready to go on Linux. So I had it back out and re-implement a lot of that stuff using pthreads. Currently Perfect doesn't— you can of course use GCD if you're just writing something on OS 10. Of course, you can use it on your mobile app. But on the server-side particularly on Linux, it uses all pthreads threading and locking; that kind of stuff.

I want to start hacking on Perfect. What do I need to do? You said, you have the standalone server, can I just run that from the command line and it goes?

You can run that from the command line if you're developing on OS 10, of course, if you're using Xcode. We also have a standalone app which is the little window that lets you start and stop the server. The beauty of this project, if you're doing mobile development is that you're doing it all in Xcode and you can debug both the client and the server at the same time. Ideally, it just take that code and compile them on Linux and be ready to go. So the best way to start is just to download the repository that we have over on GitHub.

We have a slew of examples which start from the very basics, show several of the different features such as URL routing, mustache, template part processing and things like that. Just run those examples in Xcode like you would do in the other Swift projects. Just poke at it a bit.

Okay. That makes sense. Now, if I want to do host something. Am I pretty much just hand crafting Apache myself, installing it? You said you had a module for it or is there— is it in pre-built where can throw a [inaudible] quickly?

We don't include pre-built binaries. But we do have – make files for Linux particularly the Apache module make file is pretty robust and will download any packages that you need on [inaudible]. We do have some configuration snippets there and the read me’s on GitHub as well which help you – point you in the right direction if you're going to use Apache. If you have any experience with Apache configuration, you know that they're all unique snowflakes. Everybody has their own different ways to do stuff. We tried to keep it unobtrusive and a simple as possible.

I would say, there's a number of different places you can get support or help. So if you go on to Gitter, for example, from the GitHub page; or if you write in a problem that we can usually help people very quickly get up and running; so people get stuck there's lots of support already, which is astonishing, from the community that's evolving. Also, what's interesting is, we do have plans we're working on the ability to quickly spend app, for example, an AWS cloud virtual server so that someone who's not used to doing back-end work or used to doing it in some other way could quickly get their project app and running.

Our goal is to try and eventually make it so incredibly easy that there would be no reason to use anything but Perfect especially if you're an app developer and having done a lot of back-end work.

I'm glad to hear that as somebody who is an app developer and has not done a lot of back-end work but has done a little bit. It's a lot to figure out just to get an app up and running. There are things like Heroku that make that a lot easier. But I'm glad to hear that you're working on support for that thing.

Absolutely. I think that's, that's probably the biggest thing that we will be working on this year is developing some relationships with some cloud providers and making it incredibly simple to get up for app developers who are trying to get specially an MVP up and running. Of course, if somebody then wants to put up a full production, set up servers together etc., you could still download Perfect and use it in the production capacity because it does have— because it has the history of Lasso and has that built with that in mind. It does have the scalability to be able to grow as big as the organization continues to grow.

It's an interesting history with the Lasso history with a close sourced proprietory company. Now we've got Perfect. Now if you're tied with GitHub, that means there are parts that are open source. Is it all open sourced? How is it licensed? How do you all put money in your bank account? How does that work?

[Laughs] We're going to give it away for free and make it up on volume, I think is the solution. Just kidding. Right now, everything is open sourced on GitHub. Everything is open for anyone to see and use remembering that the difference between Lasso and Perfect is that Lasso is a language comparable to Swift. In this case, Swift is the open source language and Perfect is the framework and back-end for it.

In terms of how it's licensed, it's currently under the AGPL which is— there's a number of questions about why we chose the AGPL. In fact, we're going to be releasing a lot around that. Really, we did that because it makes a lot of sense where were sitting that anyone should be able to use this for free. But if you're going to improve it, then go sell it, we'd like to get those improvements back so that the whole community benefits. In fact, we went through a lot of time and a lot of work with the Mozilla people as well as others which shall remained unnamed for now. But working with a number of people in the open source world to get a better sense of exactly which licensed we should use and how we're going to apply it. Our goal is that we want this to be the— we love Swift and we want Perfect to be the go-to back-end. The only way it's ever going to happen is if it's open sourced.

I guess your question how is it that we make money? We are as well going to bring out enterprise licenses eventually. A number of people have approached us and said, "Hey we really like an enterprise license because we want to do our own thing. We want to incorporate it to— we don't want any questions. At the moment we're saying it well, "We'd give you a free enterprise license as long as you want to— for the current version." Because our goal is to continue to improve it until it is the best product around. The best back-end option.

We hope to— we haven't exactly determined how revenues going to come in but we have some great ideas. The obvious idea is A, we're talking about spending up AWS servers. We'd like to become a partner with a cloud provider. Then we'll clip a ticket on the way through for that which wouldn't affect the prize or to a developer. It’s the same prize other way but still allows us to put money back in to make sure that our team can grow and continue pushing this product. And as well offering configuration tools and simplicity tools to make it easy to get things up and running. Monitoring, server monitoring.

What’s interesting is, we have all of these products already in the Lasso product. We'll be bringing a lot of those over into the Perfect world over the next few years.

Very cool. Yeah. That's a pretty solid approach. You have that free, available – people can use if you want more support, you pay for it. Lot of big companies are little worried about using open source software without enterprise support.

Exactly.

They want to use it but it’s stamped somehow, some of it stands behind it so that makes sense.

I shouldn't say this. In fact, we're still on this model from a couple of organizations, one of the key ones being MongoDB. I'm not just implying that but watching how it is that they've approached the world. We think that their approach is excellent. It makes a lot of sense so we're following up with them.

Along those lines, I'm interested to know— I think you were some of the first people that are really seriously be working on a project, a Swift project that runs on Linux as a very important part of it. So, having done a little bit with Swift on Linux, I know there's still a lot to be done in terms of Swift— Swift open source. I wonder if you guys are plan to contribute back to the Swift open source project?

There's some spelling mistakes that we found.

[Chuckles] Yeah. You and about a thousand other people.

Yeah we’d really like to. We've talked about Lasso a lot and one, another similarity between Lasso and Swift is that Lasso is built on LLVM. We’ve got that working on OS 10, of course, a variety of Linux and Windows also. I know that there's currently no support for Windows with Swift. That's something we were just chatting freely about, Sean and I the other day is— that's something we might want to take on and help contribute.

I do have a lot of experience with LVLM and I am looking forward to finding something that I could give back to more of a lower level. I’d say, lower level than spelling mistakes.

That's good to hear. I've been surprised at how little effort about Swift on Windows. The company I work for— I do Mac development mostly but the company I work for does Windows development as well. In fact all of our back-end services are written in C# and .Net. We run on Microsoft Azure and all that. Although I think the Azure has support for Linux servers but I don't know seems it would be a pretty valuable thing to have Perfect and Swift in general working on Windows.

Yeah. You find a lot of people that are deploying on Windows. Half deploy on Windows. It's mandated by the company. You find a lot of companies. They make their database choice because they don't have a choice. They have to use Oracle or something like that to go server. There's a big opportunity there to have this product available for the people that really have to use Windows for one reason or another.

I have a question for the use case for using Swift as back-end language. You've mentioned the one thing— it makes sense to have the back-end and in [inaudible] code doing the same things. But as a purely language perspective, how does Swift fit in to the back-end ecosystem? Do you have any comments on that?

One thing that I really enjoyed from Swift is its strong static type checking. Well, there're certainly nice things about using dynamic languages for prototyping. In my experience, as your systems get bigger and bigger they become more unwieldy. Then I think about Swift being statically typechecked is that if you changed the name of a function, you know it immediately throughout your entire code base because it won't compile anymore.

Again, if, if you're doing quick prototyping and things like that, the static-type check can be able a little annoying at times but with a bigger system, it will become a live saver, I believe.

That's one of the things that I really like about using Swift on the server-side is that, I think, it really enables you to build bigger, more sophisticated systems.

Definitely. The compilers are a bunch of unit test that run every time. If you do unit test, the cloud does a lot of things for you. But being with other server languages, there's a lot of server languages that have strong typing. Why is Swift better than a C# or a Java or say Go?

Because it doesn't suck, I will say.

I don't have any experience with Go. I've done a bit of Java in the past and a little bit of C# but not in any production quality. I like C#. There's a lot of things to like about it. I particularly like the link, the way they built in structured quarter language into the language. I think that's really nice. It's something that I borrowed and put into Lasso as well.

That said, I think there's a lot of similarities. You get the static type checking like we've talked about but Swift has a clean, lean feeling to it while still giving you a lot of flexibility and the power that you'd expect from these languages. A lot of it is probably that it's brand new and still really shiny. Hopefully they can keep that luster— hopefully we can keep that luster, all of us, as we progress the language into the future. I know there's going to be some changes as the language moves toward 3.0 but my hope is that it can stay clean and fresh feeling.

I think there's a natural elegance as well to Swift where— and, and anyone looking at Swift can get a sense of how it fits together. If you put a page of Java beside a page of Swift, the page of Java looks like garble-y guke. It doesn't feel natural, you can't tell organically what's going on versus Swift which you look at, it's almost a maturity of language where someone's thought through exactly what the Perfect language would look like if someone really were to develop a language without any backwards pressure from anyone else to do it in a certain way. I think that's the— not the first language but any language that has really been able to capture that is Swift.

Java, for example was originally built for, I think, it was a television. Now it obviously has matured significantly. But Swift was built for mobile first development for app development and for all the other things that are now – that languages are typically used for. In this case, a web development and other things, Swift is perfect which is why we picked the name, by the way.

That was going to be my last question— how did you pick the name?

I think Swift is— I'm really excited about it and happy about Swift. I heard somebody say once that Swift reads like pseudocode and I don't it's alone in that. I think there are other languages that do. But there's certainly a certain elegance to reading Swift. It's a pretty language for the most part.

I want to know maybe it's too early, maybe it's too early and you don't really know yet but one of the things that set Swift apart some of the languages that it looks like, superficially, is that Swift is not an interpreted language like Python or Ruby or Java Script. It's a compiled language like C or C++. And Apple from the very beginning has made some pretty aggressive performance claims for it. I wonder if you've— maybe it's hard to compare cause Apple's an [inaudible] but is the performance characteristics of Swift something that's important to you when working on Perfect.

Well definitely. For the server-side, a lot of what the server does is isle bounding. You're just waiting for data to come in or go out. But as a request comes in, you simply want to process it as quickly as you possibly can. The whole goal here is that you can support thousands of clients at once.

Performance is very important. I think that's why you particularly— I'm not to pick on Ruby but I think it got a bad name a little while back due to its performance. It wasn't, it wasn't necessarily ideal for the server-side. It was very flexible. You can get stuff done quickly. I'm not going to argue that. But I think for a server-side language is you really want something that's going to use the hardware as hard as it possibly can and just get those requests completed and move on to the next one as fast as possible.

So, a lot of why Swift is so performant is because it is statically compiled, obviously. The more dynamic a language is, it's just inherently slower. That's almost just a fact. Again, it goes back to static type checking and being fully compiled. I think that's great for the server-side. Although it does make things a little bit less flexible particularly when you're doing prototyping.

Are there any benchmarks between different frameworks? Obviously, I heard Ruby or Python is not going to be that fast as interpreted. Swift has the potential of being very fast cause it's close to the wire a bunch of things like Java which are [inaudible] compiled but they've been hacking on Java servers for decades and Java can go very fast. How soon can we start comparing things? See if the promises of Swift are paying off yet because they're definitely— it does have potential to be pretty fast.

Yeah. The only benchmarks we have up and you'll find those on the wiki section of our GitHub repo. The only benchmarks we have right now are comparing and sever speed against Apache. We compare against Apache and our built in HTTP server; then Apache with a FastCGI server just to get some performance metrics and do a little bit of benchmarking. When you go to compare the frameworks, it is hard to make things apples to apples because they are different. They do things differently. That’s something we would like to do but we have not done yet.

Or a third party yet. Realistically, we probably shouldn't be the ones testing ourselves. If there were some other third party say, listening to this program, who would do some testing for us, we'd love to see the results. We anticipate that we are going to be radically faster or at least comparable to anything that exists today. Just because of the history of Lasso being incredibly fast mixed with the speed of Swift and all of the logic behind that.

I also believe that the longer term vision of Perfect and Swift together because of the obviously user interface experience and the SCL benefits of getting things up quicker. There's a lot of higher level elevated benefits to using a language to build your applications with which aren't just about prototyping but also about getting the stuff out to the user quickly. I think when that stuff starts to pay off, that's when the real obvious value of Swift and Perfect will start to be seen which is people can build a web site that we can get out faster or build data and get data out and use less hardware and less cost in the long term. That speed is going to be something that we're constantly going to be focused on.

Yeah. Definitely. As you get things like the internet things and things like that where you have just tons of devices that might be hitting your web server. Having something that actually run on— it does compile and actually can speed up a request and also keep the CPU usage down. So, it makes sense to get things done to a— as lower level as you can for a lot of applications I think that will become more and more important as we move forward.

Absolutely.

I think one of my last questions is, I wonder if you've seen anyone that's already using Perfect for something that they've already written back in service – that is using Perfect whether it's in production or just hobby or learning project. Curious to know what's already out there.

We've seen some people hype up on twitter and such and on the Gitter – the chat channel as well that they have had been working on. I don't think there's anything in production yet. I know that we have been using Perfect for, I think, three client projects now; mobile apps which would require back-ends servers. These are all still on development. None have been released yet but they're on the way.

It's great because we're, we're eating on dogfood. We do, we do mobile apps for clients here and all kinds of other services. Perfect is – we're moving all of our work so as Perfect is developing, a lot of that is coming from the necessity we see as we develop these client projects.

For example, one of the— one project we just recently did is a signaling server for web RTC which is a chat system which uses both our rest API and WebSockets and concert. That one in particular was really great for shaking out some bugs and adding some new features and just pushing project forward.

So as we do this we're rolling back all of our changes and all of the things we see that we need to have in Perfect back out there into the project and to the community. I'll also note that this, again, makes the point that this, this isn't a project that's going to die because there already are production apps in play or being built using it. We're betting our lives on this so, we're not intending to be one of those dead GitHub projects. We're going to make sure this continues to grow and improve. I'll take as much feedback from the community as we can get to make it the best product out there and go head-to-head with the likes of Java, Node, PHP, Python and anyone else that does back-end or server-side work all under the [inaudible] of Swift.

I'm, I'm excited about this personally. Just in the last, I don't know, 6 months to a year I've been babbling with and wanting to get in to back-end work. But realistically, I don't— I would as much rather use the same language that I'm using to do app development and for the last while that has been Swift. So this is a really exciting project for me because it should make back-end development a lot easier and less of a learning curve plus a lot of fun to write Swift.

Indeed.

Is there anything else about Perfect that you think we didn't talk about that we should mention?

Not particularly. We think that we covered a lot of the – where we came from which is really— it's not really— it's a new project but it comes from a huge history. In a way, it was Apple's first language and we're back to it being Apple's language again. We've connected the dots in a meaningful way.

We are at the course of this year. We are going to be hiring more people to continue to grow the Perfect project and work with it. This is going to be a project that continues to have legs, and grow, and move and, continue to take feedback from any corner of the world that makes suggestions on how we can to improve it. Really, our genuine interest today and anybody who’s interested in being part of the grounds [inaudible] at the very, very beginning.

One thing we are looking for right now is for people who want to— honestly, from linear perspective there's really only two of us right now. We want that to turn into many more who are interested in getting the word out there. So, going to conferences and asking question about what else are we missing. So if anybody’s out there who'd like be an evangelist for Perfect to help us move the whole project forward, we'd love to hear from you.

Great. I'm going to try get it set up and get a little project running and maybe get a presentation ready for CocoaHeads. We actually have a DevChat.tv or Chuck does some Remote Conferences and we have an iOS 1 coming up in April. So maybe I'll see if I can do a talk about it.

Awesome! We'll look after you.

So if there's not anything else I guess we get to picks. Jaim, do you have some picks for us?

Yeah. I've one pick. I've got a travel pick. I'm headed down to Charlestown in South Carolina which normally wouldn't be at my top list of destinations but my family there— my sister and my family all lived down there.

You're probably not thinking of Charlestown your first street food town but it is a slim food town. We [inaudible] the barbeque from South Carolina which is one of the better places and one of the pillars of barbeque in the US. But also Charlestown itself has some great foods— a lot of sea food, shrimp and grits. So if you're in the area, you probably know about it but if you're not it's a cool place to visit and has tons of old buildings which is just weird in the US; stuff of the 1700s which doesn't really have them much here. Those are all gone. That's my one pick. It's a cool place and I'm visiting.

I saw Anthony Bourdain Show was in Charlestown on Sunday and I watched it. I don't usually watch that show but it was on— oh the food looked really good; the food he was eating.

Oh yeah. Southern food.

I’m kind of jealous.

That would be good.

Let's see. Kyle, do you have some picks for us?

Yeah. I have one pick for you guys. We here, like I've mentioned we do a lot of web development here. We have a CSS framework that was developed in house. It's called Amphibious and TechMind is a simple, elegant responsive front-end rapid development kit. That's something that we've been using here for a lot of projects. We think it's worth checking out.

Cool. I’ll have to check that out myself. Sean, what about you? Do you have any picks for us?

I do. I found a [inaudible] company up here in Canada. I don't know much about them yet. The company's Pleiades— pleiades.ca. What this is, is it's a drone company based on Linux.

I'm hoping that they'll pick up the phone from me and that we can get Perfect running with Swift on a drone. So not only can we develop back-ends, mobile apps and Apple watch applications. We can also interact with drones. That will be a dream come true.

I'd like to see that. That would be pretty cool.

Awesome! I'll make it happen and I'll call you.

So I've got, I've got a couple of picks myself.

My first pick goes along with Sean's there. I talked about this last week or week before but I got Swift running on my Raspberry Pi over the Christmas break. I had a lot of fun with that and did a blog post on it. I was excited at the response and I said – and I started working on it the GPIO library for Raspberry Pi so that Swift could be used to do robotics or whatever it is you want to do on a Raspberry Pi. But part of that is, is IO and I wanted to be able to do that from Swift.

So, I went so far as to create the repository and start playing around with it but got distracted and hadn't made any progress. Luckily, somebody else did it. So my pick is SwiftyGPIO and this is just an open source library— Swift library for, for using the GPIO pins on your Raspberry Pi. It also supports a bunch other boards like the Beaglebone and one that I'm excited about is that the chip which is a nine-dollar single board computer. So, this is cool if you're going to do any kind of embedded stuff, robotics in Swift. I'm excited to see this stuff happening.

My other pick is a company called Anker. I think that's how you say it. Anker or Anker, they make chargers but I've just been really impressed with their stuff. I've got a few of their iPhone chargers; I've got a USB hub that was made by them. I've just been impressed with the quality and, and they're not super expensive but they make stuff that looks nice and works really well. So those are my picks.

Awesome!

Alright guys, well thanks for coming on. I think that was— it was really good to hear about Perfect and get a good overview of the project and where it came from, where it's going. I think people will be interested to hear about it.

Thanks a lot.

Thank you.

Really appreciated. You guys rock!