The Changelog: Software Development, Open Source - The Story of Atom (Interview)

Episode Date: February 24, 2017

Nathan Sobo, founding member of the Atom editor team at GitHub, joined the show take us all the way back to the beginning of Atom to learn where it came from, the founding team, the problem it solves, on through to shipping 1.0 and beyond.

Bandwidth for Changelog is provided by Fastly. Learn more at Fastly.com. I'm Nathan Sobo, and you're listening to The Changelog. Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 241, and today, Nathan Sobo, one of the founding members of the Adam Editor team at GitHub joins the show. Nathan takes us all the way back to the beginning, where it came from, the founding team, how it was formed, the problems it solves, on through to 1.0 and beyond. We got three sponsors today, Linode, Hired, and Compose. On Valentine's Day, our friends at linode made some big announcements they now

offer a one gig plan for five dollars in high memory plans starting at 16 gigs of ram for 60 a month the super popular two gig plan they have which is ten dollars now has upgraded storage from 24 gigs to 30 gigs this is a huge announcement for linode and puts them in areas they've never been at this point their ram offerings across all their plans are double what most competitors offer at the same price. What does this mean? Simply put, you get more for less. Of course, Linode is our cloud server of choice, and everything we do is hosted on Linode servers. Head to linode.com slash changelog.

Use the code changelog2017 to get $20 credit. This code has unlimited uses. Share it with your friends, blog about it, tweet it, whatever. Once again, head to leno.com slash changelog. And now on to the show. All right, Jared, this is a show. I think we've been a year and a half, maybe, planning on this to some degree. What do you think?

We've been wanting to talk about Adam for a long time. A long time. We've been talking to Katrina Owen behind the scenes about this show and just various conversations to find the right person to share the story. And Nathan. Nathan's the person. How are you, Nathan? Doing great. Yeah. story and Nathan. Nathan's a person. How are you, Nathan? Doing great. Yeah, so Nathan Sobo,

a founding member of the Atom editor team at GitHub, and we love to go deep into the history of projects, especially when they're as epic as Atom is, and hear about the beginnings. So tell us about the start of Atom and your relationship to the project. Did I say it's a text editor? I think I said that, but... I think you said it. Y'all know Atom. It's a text editor, open source. Yes.

Very cool. Go ahead, Nathan. So yeah, I think the startup for me would probably be different than the start for GitHub. I've wanted to build a text editor since right after I graduated from college. It was like, I guess that was, I graduated in 2005. And I went to work for one of my professors, I was like, taking one of his comp Ling classes. And the first thing that he had me do was to take this first order logic model of English grammar, and make it work. It was a logical model. So he was basically programming in first-order logic. And he wanted me to take his logic and

animate it and actually turn it into a real program that functioned. And so one of my first tasks in doing that was to parse the first- of logic language that he had created that was only sort of working in his mind or working on paper and at the time i was a super big fan of this blog called lambda the ultimate you guys ever heard of that blog yeah not me it's it's way over my head i started reading it and i feel like i should go uh make a crud app or something. Yeah. And it was way over my head for the most part at the time, you know, but some of it I understood and all of it was interesting to me. And they talked about this formalism called parsing expression grammars, which was, you know, top down recursive descent parsers with mimoization. So I ended up grabbing a framework

that was based on that. There were only like a couple at the time. And it was such a mind blowing distinction between that and like the lex and yak situation that was going on in my compilers class a couple years prior to that, that I got really excited about parsing expression grammars. And somewhere along the line, I came up with this idea that it would be really cool to have a text editor that had one of these parsing expression grammar engines sort of baked into it so that in a really convenient way, you'd be able to express the grammar for any language, and then the editor would give you a parse tree, and you'd always have access to that. So I sort of had that idea in my back pocket and then later moved to San Francisco. And after living there for a little bit, I'm like,

okay, I'm going to start working on this text editor. And so I started with the grammar piece, building like this parsing expression grammar engine. And I got a certain way into it and I open sourced it. It was this thing called TreeTop, which is a parsing expression grammar framework for Ruby and open sourced it and then got busy with other stuff for a while. And basically it never became a text editor. It always stayed like a parsing library. But that desire to build that system

that was sort of syntactically aware editing stayed alive in me. And a while later, I decided like, OK, it's time I'm going to do this. And my plan was to move to Boulder and work halftime for Pivotal. And then the other half of the time, work on this open source text editor that I wanted to build. And I talked to a friend of mine and he said, that sounds great, but like you should go go pitch GitHub and see if they'll want to like hire you to build this editor. So I tracked down Chris Wanstroth, the CEO of GitHub at the Million User Party, which was like a crazy raging event at, was it at Mighty or some club in San Francisco.

And I tracked him down and pitched him kind of quickly on this idea. And he had remembered me from TreeTop. Like I gave a talk at RubyConf 2007 that he was at. And so he was intrigued. And he said, we got to get coffee. So a couple days later, I met him and Corey Johnson, another GitHub employee for coffee. And they revealed to me that they were also interested in building a text editor. And in fact, had been building one for, I think, a few weeks actively at that point. Although Chris had sort of dabbled with another editor called Atomicity.

Well, the same editor, depending on how you look at it. In years prior, they were getting serious about really doing it. GitHub was in this big expansionary phase where it was taking off, but it was still like... I mean, I was employee 50, so it was still pretty small. But it was clear GitHub was taking off and they were kind of excited about broadening their horizons and seeing what else they could do. And so this text editor that Chris had always wanted to build

was on that list. Just looking at the library's IO page for your treetop project, and you said it always just stayed the library but never became the text editor that you wanted it to to be shouldn't discount what a success story it really is if you look at the dependent repositories on this you have chef you have less you have uh some base camp projects depending upon it you have uh andrew cantino's uh hugen which was previously on the changelog a lot of projects using treetop so So no surprise, I guess, that Chris would know you from that. So interesting how you kind of build yourself a little bit of a resume

of somebody that can do this kind of work. Yeah, it was, you know, I never really intended it to be anything other than a text editor. So it was kind of weird how that worked out. And the weird thing was, is that I never really worked on it. I like wrote it, gave a talk about it. And then this guy in Australia, Clifford Heath, sort of took over maintenance of it. And I never touched it again. Wow. That's the beauty of open source right there. Worldwide, right?

Somebody in Australia you never met and he can pick up the ball and run with it. And that's really cool. Yeah. The Wired article. So Adam was featured in Wired around the 1.0 release date, which was middle of 2015. And in that article, it states that Chris had, Chris Wanstroth, CEO of GitHub, had imagined this editor. He loves Emacs. Emacs, of course, very powerful, but written in Lisp, and you extend it by writing Lisp.

And Chris wanted kind of an Emacs style thing with modern technologies, web technologies, and he had imagined it in 2008. Right. And so then we find him meeting up with you in 2011. It sounds like at that time, it's starting to gain steam. How did he pitch it to you? I know you pitched him on the idea of a text editor. What was his initial description of here's what we are building.

We'd love for you to help us. This is what it's going to be like. What was that pitch? Well, pretty quickly, they showed me this video of it. I mean, they gave me the basic rundown of it's going to be a web based editor. And at that point, the editor I wanted to build was like aligned with him in sort of every way spiritually. But the idea of building on web technology did not, had not occurred to me. And when he told me about it, I was almost ready to be like, no, thanks. I'll,

I'll go build an editor, uh, not on web technology. Um, like I wanted it to be mainly done in native code with like a Ruby extension interface. And so he pitched me on this web thing. They showed me this video with a cool um god who larue that song going in for the kill was real popular at the time does this video still exist and can we watch it probably does somewhere yeah i could probably try to dig it up and see if it's in my email or something. Chris probably has it. But it was this demo of the prototype that he and Corey had kind of cooked together using Ace, which they'd already been using on.com. Ace is another web-based editor interface.

And they were doing it in a Safari or WebKit window on the Mac with this very primitive bridging to the Objective-C layer. And they cobbled together something pretty cool pretty quickly, actually. So anyway, that was sort of my intro to it, doing interesting things with GIST online, if I recall correctly, and then they booted up

some little JavaScript with an asteroid ship flying around inside the DOM and shooting dom nodes uh so you could call that you could actually take over you could plug in a page and destroy the page with this thing is that what you're talking about yeah totally so they were like destroying their text editor from within with this little ship flying around yeah i think that was in that video it all kind of blurs together but um

so yeah then they sat me down and showed me the code and it was kind of funny um it almost felt like they were more worried that i was going to judge their code harshly than determining whether or not they wanted to hire me to work on this thing was like that's that's weird it's backwards right Yeah, but I kind of didn't let on. I just kind of noted that to myself. Good plan. Don't tell them. So yeah, I mean, in pretty short order, it was like I had an offer to,

I mean, it went from my plan to move to Boulder and work on it six months a year and then like consult six months a year and then like consult six months a year. And that plan was a bad plan because it involved underestimating the cost of living in Boulder and the cost of building a text editor. But anyway, I went from that to getting hired to just build open source stuff full time. And what in my mind, like I did, yeah, I don't know. It was just kind of blew my mind and I was incredibly excited. But my girlfriend at the time, now wife,

I had already kind of told her, yeah, we're moving to Boulder, we're doing this. And so she was so enamored with the idea of moving to Boulder that we still ended up moving to Boulder and I just worked remotely for GitHub, which I don't know, it was a mixed bag. It was really lonely for a while, just working on this secret project kind of all by myself out in Colorado. Yeah. Anyway. That leads me right into what I was just thinking about, which is, you know, here you are, you're in Boulder now

with your then girlfriend. She's very excited. You probably want to be outside enjoying the mountains and whatnot. But you have this ambitious project on your plate and you just said that you were the only person working on it. And so... Me and Corey were both working on it, actually. So there were two of us. Okay, so there are a couple people working on it,

but a small team. Yeah. And it's an ambitious project. I mean, just to pin some timelines, this is end of 2011, call it 2012. 1.0 shipped in 2015. So we're talking about a three, four year period. How do you start when you're like, all right, you just sit down, you got you got treetop, but that's right in Ruby. You're not going to reuse that. I wouldn't think so.

Ambitious project, where do you start? And then how do you like order and prioritize features when you're first getting that off the ground? well i mean they had a little bit of code that was already running that was built on top of ace and so the first if i recall correctly like one of the first things i took an interest in was can we make this thing behave like Vim? So I started thinking about that and researching that. And that's like a crazy place to start, I guess. But pretty quickly, the idea for the key binding system came together, which was so yeah, I guess the logic was like, okay, well, if we're going to do Vim, and that was more like, okay, we're just sort of, I don't know, trying this idea on for size.

And so the idea was that the editor should be radically extensible. Like that was what everybody wanted. And so I thought, okay, like if this thing is going to be radically extensible, let me think of something that feels like a real challenge from an extensibility perspective, which would be like really nailing modal editing. And then what problems would we need to solve to overcome that challenge? And pretty quickly, yeah, the key bindings was sort of the first thing that came to mind. And so, yeah, the idea of associating key bindings with selectors and then bubbling keyboard events

up the DOM and matching against those selectors and basically integrating tightly with the DOM for key bindings and that we needed multi-stroke bindings. And so we started working on this Vim idea like pretty early on in the thing. And then at some point, I just got like frustrated with Ace.

And I don't remember why, probably because I was full of more hubris than I have now after being beat up by five or six years of this process and i was just like we need like let's take control of this thing like we want to control the editor itself like the actual editor rather than like cobbling things together with ace and there were apis that were missing that i remember wanting i don't remember honestly the specifics of what led to that probably fairly hasty decision um and so from there it was

like okay let's load a file and get it on screen now let's get a cursor now let's move the cursor around yeah it was very just like feature at a time um we probably worked on it for maybe a year i don't remember multiple months before we started working in it full time and what drove us was basically like what were we used to from other editors that we were dying not having like that was like kind of forcing us out of adam back into vim basically it was the editor i was using at the time and just picking those features off one by one so yeah that was sort of what drove the agenda. And it was pretty fluid. Of course, couldn't spend that much time on any one thing. It was like, get something quick, working. You know, I think Adam, especially right after we launched, like before 1.0, but even to this day, although I think we've either dealt with the worst of the issues or have a few,

but like performance was not anywhere close to the top of my mind during this early period. It was just like, get something working. Yeah. Yeah. Who was the user at this point? Was it more like you two,

you, you three? Was it like, who was the base you were trying to build? I know obviously developers at large, but like who was the first user you were building for? Yeah. Just us.

That was a, it was like, can we make an editor that we can tolerate working in for a day? And then I don't remember. It's too bad I should have studied these timelines. But Chris was one of the earliest, earliest users. I remember him posting something to GitHub with like a screenshot or something of him deleting his like emacs rc which was made filled me with a good feeling you know like okay this is really on board with this thing wow um where was cory coming from you said you were a vim user yeah cory was also a vim user i think um although he he was really involved in lua i remember that background he wrote a pretty cool like lua hack for the iphone that would let you run like build iphone apps in lua so i think he had like also sort of a similar background in kind of lightweight text editor e things although

he had some background in game development he worked foris, but we were both in Vim at the time. I'm not, I don't remember his editor history prior to that. And I spent a lot of time in like, Vim was actually a pretty new adoption for me at the time. And it was part of what was like motivating this like editor urge that had been dormant for a while was being so excited about kind of the, what felt like boundless potential of

vim and emacs and so frustrated with like i don't want to learn this vim script right you know like it just felt really annoying to me to have to worry about that learning that language to do anything and so as a result i always kind of felt like I got pretty proficient in Vim, but I always kind of felt held hostage in my own editor or something. Like I had this nerd tree. I had a bunch of plugins and like sometimes they'd break and I have to figure out, you know, I just always kind of felt like I wasn't in full control. And that really drove this over the edge to actually do it. I'm with you on that. I'm a Vim user from back in college years.

So almost 15 years now I've been using Vim. But I'm one of the only people that I've ever met, and maybe you're number two now, who has like a very good working knowledge of Vim, but still like is frustrated and doesn't love it and would prefer something else. And Nerdtree and plugins that are slowing things down and breaking.

I've always, I felt comfortable in Vim, but I've never felt like this is the end-all be-all, which is what a lot of other developers, they do. They get into Vim, they learn it really well, and it is the best thing ever for them. I've never felt that way. Yeah, and to be clear, I respect them and Emacs, but yeah, I never did feel in control, if that makes sense.

So it sounds like it started very experimentally of course you're going to experiment with architecture uh early on but even the features were very i don't know we call them organic or maybe even call them ad hoc a few people just like you know what do we love from these other things or what are we missing from these other things did you have an idea like we need to hit this you have milestones or was it like chris would email you guys every once in a while and say, how's it going? And then you'd give him an update. I'm just curious on the internal structure of how you go building something like this. Because it took a while, but so far it's turned out really well.

Maybe we can learn a few things from you. I mean, it was really... So I had worked for Pivotal previously, and Pivotal is all about XP. So you sort of have this backlog of like individual things you want to make happen and you do the minimum thing that could make that thing happen. It's kind of, I mean,

there's probably more sophistication to it than that, but that was kind of my attitude. And so like to start with, it's like, okay, well, if you don't have a cursor, you can't edit text, right? I mean, those features just wrote themselves, right? Like get text on the screen't have a cursor you can't edit text right i mean those features just wrote themselves right like get text on the screen get a cursor moving around get the text editable but then there were some things that we planned like i was like okay like we want to have multi-cursor support let's do that early because if we don't then everything's

going to assume one cursor and it'll evolve the wrong direction. There was a little bit of strategy involved there, knowing that we wanted to support soft wrap, folds, all those basic things. Those were things that I did early because I knew that to be a respectable text editor, at least in my own eyes, we would need to support those features and that they were weird enough

in their impact on how APIs looked and stuff, that getting them in early was really important. But I mean, if you think it just took us a while, I mean, Atom still, honestly, if you don't add something like Nuclide or some of the other extensive packages, like the core of Atom is still like a pretty basic feature set. And none of it is hyper original in terms of the features themselves right like we needed a command palette a way to run commands you know that had its own web oriented twist and atom but that was a feature that you know other kind of lightweight text editor rather than ide ish editors had a tree view i mean mean, it was all pretty just obvious stuff

that we needed to be productive. It was basically like the stuff that we used in Vim ported over to Atom for the most part early on. Find and Replace saw like an iteration. I was kind of enamored with this text editor, Sam, that had this crazy like regex language for doing searches and like searches within searches and crazy stuff.

So our original search and replace interface was kind of like command liney. And then another guy, Ben Ogle, who joined later in the project was like, this is ridiculous and wrote something that looked a little more like what Sublime offers, which is a little more GUI oriented and stuff. But in terms of deciding what to do when, it was pretty loose. It was like just whatever felt intuitively like the most pressing need or the thing that was missing most. And it proceeded like that for a really long time.

And in terms of like what the MVPvp we were going to ship was like i mean this is probably a testament to my youth and hubris at the time but like i wasn't even really worried about that at all it was like chris told us just build something awesome he gave us no timeline and he didn't really even i mean on, he did check in more regularly. But like as GitHub heated up and things got busy, like the duration would get longer and longer between check-ins from him. And I don't even think a lot of people at GitHub knew what the hell was going on, like what we were doing. And I have to assume that most people just assumed like it was never going to ship which was never my intention like well you were like in a it seemed to me like a big r&d kind of situation where you've got a lot of dreams you got a lot of talent to bring this to fruition but you really had to sort of like poke at various different things in terms of features or ways to go to to kind of catch your ground and in a lot

of ways it seems like you were very much in like r&d rather than like knowing exactly what you want to build and you know because if you know exactly what you want to build you can build it faster i don't know i mean i had a pretty strong sense of what i wanted to build i think the trouble was like how to build it and i don't know maybe we should have built it faster i mean a lot of times i when i'm in a bad state or whatever i'm like oh I suck like this is taking so long and it's still not even where I want it to be so I feel like I mean our the plan for me the rough back of the envelope plan I mean a lot of this still isn't even done was this hyper social hyper collaborative editor and end with the syntax awareness stuff which also isn't in yet although it's in progress

we can talk about that later but like so i had this vision of like a really good general purpose text editor that looks like textmate or sublime but is extensible and flexible like vim or emacs plus having this like layer of syntax awareness that's scriptable baked into it plus being hyper collaborative and like social coding aware which is what i uh pitched chris on and what he was excited about yeah and having real-time collaborative editing like that was sort of my list that was actually like my mvp for a really long time but then like the MVP of the MVP is when we need a usable text editor if we're going to do anything. Period. And so

that on its own, I honestly don't even think Atom was exceptionally usable the day we made it public. It was traumatic to me to launch it because in a lot of ways, I was embarrassed by it that's interesting

but i think it was good ultimately that we did because like i think you've got to develop things in the heat of public scrutiny i mean it's not comfortable um but i think it's was critical to us like informing our decisions going forward from that point what's the saying if you ship something you're not comfortable or if you're embarrassed about what you ship, then it's a good thing because there's always room to improve. What's the, do you know what I'm talking about, Jared? There's a term, there's a phrase out there that's something like that. I think it's like, if you're not embarrassed when you ship, then you waited too long.

Yeah, that's it. It's exactly it. And on that note, that's a great place to pause because we had our first break coming up. So let's take this break. When we come back, we're going to dive much, much deeper. Love the direction we're going. We'll be right back.

Our friends at Hired want to help you get your next job that much easier. Searching for a new job is stressful, scary, and time-consuming. Recruiters try to sell you on all the roles you don't want and job boards feel like a black hole. Sometimes you get through the entire process only to find out at the very end that salary, company culture, or other details don't match what you're looking for. Hired is different. They're an intelligent talent matching platform for full-time and contract jobs in engineering, development, design, product management, and data science. Instead of endlessly applying to companies hoping for the best, Hired puts you in full control of when and how you connect with interesting opportunities. After completing one simple application, top employers apply to hire you.

Over a four-week time frame, you'll receive personalized interview requests and upfront salary information so you can make informed decisions about the opportunities you'd like to pursue. And if you're concerned about privacy, don't worry. Hired hides your profile from your current and your past employers. The best part, Hired is free. It doesn't cost you anything.

In fact, they pay you to get hired. Our listeners get double the normal $1,000 hiring bonus to find your next chapter on Hired. Head to hired.com slash changelog. Don't Google it. This URL is the only way to double the hiring bonus to $2,000. Once again, Hired.com slash changelog. And now back to the show. All right, we're back with Nathan Sobo talking about this awesome text editor, Adam. And Nathan, you've got a great history with this project. I love how serendipitous it was that this all came to be.

And we've been talking about the direction it's gone and how you've gotten there, the feature set, the R&D, the initial inspiration. But now you've got some years behind you. I think it's current version is like 1.14, you know, some years behind you. You're, I think it's a current version is like 1.14. I believe that's correct. Yeah. You know, you got a team behind you. What is the landscape of the Adam team now?

So it was you and Corey now who's involved. So I guess I could give you the, should I give you the succession of kind of how it's grown over time? You think? Yeah, please. Yeah. So,

yeah. So it was me and Corey and then working out for the longest time. And before it launched, Kevin Sawicki was another GitHubber that was working on some other apps that ended up being used internally, but kind of never reaching the light of general population, kind of joined our team, chewing at the edges at first.

I remember one of the first things he did is he wrote a wrap guide package, which to this day is its own package, which is kind of funny because it should probably just be a feature in the text editor. I mean, it doesn't really warrant a package, just a single line at 80 characters or whatever. But that was like one of the first things he did is implement this wrap guide package. And he kind of merged into the team. And for the longest time, it was us three. And then at some point, we acquired another company, easel.io. And Ben Ogle is the head of that. And that was like a cool web based graphics tool that I think went through Y Combinator and stuff. And we acquired them. So he joined our project and he brought a real i don't

know like a brand facing i mean i've always been really into the brand too but he actually like executed on it in terms of and that was as we were getting closer to being launched publicly so kind of defining our user facing story changing us from kind of a project to a product. A lot of that, I think, had to do with Ben and made a huge contribution there. So then we launched and I'm worried I'm going to forget people. Also the chronology. At some point, Corey left the project to do some other stuff and it was smaller for a while. And then, yeah, interestingly, my sister's boyfriend multiple years earlier had wanted to work on this other project with me and had was a physicist and then only ever programmed in fortran and i just gave him basically access to the repo and was like okay and he started making

contributions like he taught himself javascript and ruby and like started going contributions. He taught himself JavaScript and Ruby and started going to town. And so right before I joined GitHub that year before, I'd spent multiple months. I was working on this other project that he joined me. He was just out of college at that point, and we worked together, and I sort of mentored him. And then one of the last things we worked on together in sort of this mentorship phase was my idea for an incremental parser. And so he got really

intrigued by the idea, read a bunch of papers from Berkeley. And sort of while I was starting Adam and building Adam, he started working on that system, like an incremental context-free grammar-based parser. And so at some point, we hired him after him doing a period of contracting. And then the next team member was this guy, Antonio, Antonio Scandura. And... Great name. Yeah, great name. Great guy. Wow, yeah.

He opened a pull request actually i think it was an issue where we didn't support our soft wrap lines like didn't support preserving the indentation level on the soft wrap segment of the line which yeah in retrospect was terrible um but we just didn't we hadn't gotten around to implementing that and so he had like pinged me on an issue and was like hey i'm I'm using Atom. I want to fix this problem. Do you have any guidance about how to fix it? And I brought up this idea about phantom tokens.

And we went back and forth like one or two times. And then he had a pull request that was super high quality that he opened. And he sort of just committed himself to building stuff for us for multiple months. And I finally, I don't remember what strings I had to pull, but like we finally hired him as a contractor and then eventually as a full-timer. So he joined the team. And then more recently in like the past, I don't know,

I think year and a half, we've hired Katrina, Uchako, Michelle Tilly, and Ash Wilson to work on GitHub integration, which is something that we've always wanted to do. It's just been a really long time coming. And so those three are working on that. And I'm really excited about what's coming together on that front. So anyway, the team today is kind of, we also hired a Windows expert. So where is the team at today? I don't know how interesting that whole narrative was, but we kind of have a group that focuses on what I kind of call like the platform of Atom, which is like the part of Atom that other people are building on. But it also like leads into Atom, just the basic bare bones Atom installation. So that's me, Antonio, Max,

and Damien. And Damien also has like a focus on Windows stuff, although he's starting to delve into connecting to this language server protocol that Microsoft got going, and that's going pretty well. So that's the core set of people. And then we have another team of three people that are working full-time on this GitHub integration, Git interaction. And then we have Simon, who's our designer, and he kind of bounces around between us and Electron.

I mean, the story of Electron is actually pretty interesting, too. We could talk about that as well. It sounds like this is like a full-on product team now. Which is what I was trying to get at. I was like, you know, you started out serendipitously reaching out to Chris at the million-something hackathon. I forget what that was. It was like a million-user party. There you go.

It was like a million-user GitHub user. Right. And so you track him down. You're like, hey, man, I got an idea. This is what I'm known for. He's like, OK, cool. You know, you're employee number 50. You and Corey are hacking on this thing.

You have really not much of an aim in terms of like inspiration from Chris saying, hey, go do this. It's just more like build the best editor you can. Right. And then now you've got, you know, as you're laying out here, a full on team that's very product focused. You got integrations going on. You got, you know, various pieces around platform, different different platforms going on, being extracted from Electron. You know, that full story there. Yeah.

So Electron's got a whole team on its own, which was originally just me and Corey and Kevin as well. And well, Chang. So, yeah, I mean, a big like sub story of this entire thing is like, how the hell are we even going to do this? Because when Corey pitched the idea of this hybrid desktop web app, like the technology did not exist

to do that. Like we'd something kind of cobbled together with the WebKit views that you can do inside of Cocoa applications, but it was not cross-plat. And so that was like a, I mean, that was a massive- Why didn't you guys just use Electron?

Yeah, because, exactly. I wish it would have existed. That's what I would have done. That's what I would have done, hey. So I remember like just trying to figure out like how the hell are we going to do this? And like, I'd done some C++ in college, but it definitely did not equip me

to dig into the Chromium code base and figure out. And to me, it was like our original integration with the underlying operating system all went through this objective C to JavaScript bridge that was something enabled by the WebKit API, only on the Mac. And it was all synchronous because we didn't have an event loop.

And it was just, yeah, it was really cobbled together. And for the longest time, I was like, we got to have access to the NPM ecosystem. And so if we're going to have access to the NPM ecosystem, then I really meant we had to have Node APIs because all those modules use Node APIs top to bottom. So if meant we had to have node APIs, because all those modules are used node APIs top to bottom. So if we were going to have node APIs, that meant it had to be v8. And if it was v8, then that meant it had to be chromium. So that really quickly set my sights on getting

this dream of like this mashup between node.js and Chrome working working because what we had wasn't cross-platform. They knew it was a priority for all of us and it didn't have an event loop and the library ecosystem was tiny. And the whole point of having the thing in JavaScript was to tap into this huge library ecosystem. So we started with this Chromium embedded framework, which was not it.

It was like a step in the direction of Chrome, but it sort of abstracted us away from Chrome. And then I started poking around and researching, trying to dig up what I could find on who did Node and Chrome integration and found this project from the Intel Research Laboratory in China, Node WebKit, which you may have heard of.

It's like a competitor to Electron. And, you know, downloaded it. I don't remember, built it or whatever. It was really early in that project's evolution as well. And like, Atom just was crashing. Like we couldn't keep Atom running. And I remember like poking around and some IRC channel or whatever. And at some point, Cheng, who had been like an intern, I think, at that Intel Open Source Technology Center, emailed me and he's like, hey, I love GitHub, you know, blah, blah, blah, like, I want to work for you guys. And so at that point, we had like one Skype call with him. And we could barely communicate communicate because I don't speak Mandarin and he spoke English, but it wasn't a lot. And I just, I think I emailed Chris and I was like, Hey, we have to contract

this guy. I don't know. I somehow managed to contract him. And at that point it was like the communication barrier I knew was so high. The time zone difference was massive. And so at that point I was just like here are the specifications like it needs to run like i need access to node apis from inside of a browser window and i need to be able to like from a callback from like you know listing the directories on my file system i need to be able to mutate the dom like it has to be seamless go for it yeah and so that was sort of how electron was born like i think we've gotten some criticism or whatever for like not iterating on node web kit and like honestly it wasn't intentional it was more just like okay i had this person that wanted to work with us for us and be

paid by us that i couldn't communicate with and if even if i could communicate with was in a different time zone i just needed like a simple target to aim him at. And so that was basically just like build me a system that's custom designed for exactly the needs of this application, solves no other problem and is only responsible to us because that was all we had time for. And so we didn't really know it was going to become Electron. We called it Atom Shell.

He wanted to call it Direwolf, but I'm like, I don't want to call it Direwolf. It's something boring. Direwolf? Yeah. that's a bad name game of thrones we really bonded over game of thrones but yeah right on direwolf makes sense then but yeah so it was adam shell for the longest time it was just the shell of adam which is where electron kind of came from like the orbital shell stuff we have a show we actually did an entire show on electron back in gosh i guess it was august of last year so for those who want a deep deep dive with zeke zicalianos about electrons history which some of it overlaps a little bit of course because as you said you you guys pulled it out um i remember when it was adam shell that might have even been

public at a certain point but yeah that's episode 216 we'll link that up in the show notes so for those who want to continue down the electron path check out that episode as well great sounds like you had a lot of i mean obviously a lot of challenges and it sounds like even harder than i was thinking it was so trying to build a desktop class and a desktop apps with web technologies post electron like i said it's it's it's a relatively straightforward endeavor in fact you've even empowered other people who are competitors in the sense of like competing text editors to you know get to where they want to go much faster than than y'all could um because the platform wasn't there yet but have you found i'm thinking about performance but i'm sure there's probably other ways as well.

Have you found even to today, even with Electron, now that it's, you know, abstracted and stabilized and worked on by many people, have you found that there's an uncanny valley or draw like major drawbacks still with using web technologies and building desktop apps? What are your thoughts on that? I mean, performance, I feel, is a challenge. Although we can go into why I don't really think

it's actually that big of a deal. But other than that, I don't really feel an uncanny valley surrounding it. Most of the facilities that we need from the underlying operating system are available or pretty easy to get access to through like native extensions which you can just load via npm so i'm pretty happy i mean api wise i mean even now we're like working on taking advantage of some new apis in chrome that like completely

changed the game of the editor of the text editor rendering and make things so much more efficient that just weren't available. So I think that's maybe the... Do you have a for instance on that? Like, for example? Yeah, so like one of the biggest challenges was there was no way for me to detect when an editor became visible. Because an editor could be anywhere,

like it could be embedded inside of someone's package on a tab and then someone switches tabs and that editor is invisible and then some piece of state changes that changes the font size which changes the line height etc etc so i need to perform all these measurements for a variety of reasons uh in order to render only the visible text not all the text but only what's visible to the dom because the dom can't handle 10 000 lines of text and so anyway when only what's visible to the DOM because the DOM can't handle 10,000 lines of text. And so anyway, when the editor becomes visible, if the fate of things have changed, if the font size or something has changed, I need to remeasure. But I had no

API available to me until like this latest version of Electron that we're upgrading to that could tell me, oh, the editor's become visible. So for the longest time, we just, we had to pull. So that's always the debate. And like always the challenge for me, oh, the editor's become visible. So for the longest time, we just, we had to pull. So that's always the debate. And like always the challenge for me is like, I don't know, maybe I should follow worse is better philosophy, like more, but I really wanted the editor to be self-contained so that if you put the editor on the DOM somewhere, the goal would be it works. And we haven't always achieved that, but like that was always the goal. And so it needed to detect for itself it became if it became visible i didn't want the user of the editor to have to inform it

so anyway that api that now will let us do that is this thing called intersection observer which just landed in chrome but it's just kind of crazy to think and there are still things like what if i want to observe the computed style of a particular node and be notified when it changes um like that would be really nice for the editor as well because then no matter how it got styled i would be able to detect if the computed font size blah blah blah changed and remeasure but like as of now there's no way to do that and so yeah to me that's probably one of the key frustrations is just hitting places where still as amazing as they are and as many amazing things as web apis enable they're like these sometimes holes where something i need and i can't get it like measurement another

one you know at this particular character what pixel position is that at horizontally considering ligatures etc etc there's like really not a good API to answer that question efficiently, sort of like short of putting the content on the DOM and asking the question. Right. So, yeah. We definitely end up against that one as well.

Let's go one last question on the technical side and we'll head up to our next break. We have lots more to talk about, including your favorite packages and themes and must-haves. We also want to talk about the future. It has you to project a little bit into the future for us for Atom.

But on a technical level, now this is like superficial technical level, because just looking at the repository, you have 75% CoffeeScript and 25% JavaScript. Now, CoffeeScript has fallen out of flavor with many developers, especially with ES6 and such things, adding many of its features. Curious the history on CoffeeScript and the current team's opinion of it. So the history was when I showed up, you know, n weeks into adam's development they were using coffee script and that was chris and cory and at that point in time i think all of github.com's code base was done in

coffee script and you got to kind of transport yourself back to what 2009 or whatever point this decision was made yeah i mean es5 was for a ruby programmer at least, ES5 was, oh, God, I got to assign crap on the prototype. And like, what is this? And so CoffeeScript to Ruby programmers, which is what we all were, like seemed so appealing. It seemed to fix a lot of problems and make things more convenient. And it was just like, yeah, it seemed like a cool idea. You know, fast forward five years-ish, JavaScript's evolved tremendously.

And yeah, you're right. CoffeeScript is kind of, to me, it feels a little like a dead end. Like it's not standard. It's worked on by way fewer people than JavaScript. Every feature it really offers that's a positive is now in JavaScript. And there are plenty of things that it does that drive me up the wall. So our official policy is like no new CoffeeScript.

Now there are instances when we have to dig into some stuff that's written in CoffeeScript and it's like a small change and I'm not down to run this decaffeinate script and clean up the output to get it converted over. Like it's just not what I'm up down to run this decaffeinate script and clean up the output to get it converted over. It's just not what I'm up for that day. But slowly but surely, we are gradually converting everything to standards-conformant JavaScript. That's sort of the official policy at the moment.

It's kind of a file-by-file basis. Right, or more like library by library, but occasionally file by file, like in core and stuff like that. Yeah. Yeah. Interesting. Interesting. One last question. This one seems like it's a non sequitur, but it's kind of looping all the way back to when you said you brought on, I can't remember his name, but the product focused kind of the brand. Yeah. Who's no longer with us. He's moved on to other brands. That was Ben Ogle. Yeah. Okay. So Ben Ogle. So Adam has a great brand. It has a great design as the marketing pages are really good. The documentation is really good. And I just curious about the naming the was Adam

from the beginning. I know Electron got renamed from Adam shell to Electron, but we love naming stories. So tell us a little bit about the brand, the design, the naming. So the original name of Chris's project was Atomicity. And I do not know why he named it that. Like, I don't really get it. I should ask him. But it was Atomicity. And I believe it was like before I was hired, they made a command line script or whatever to launch it from the terminal. And they're like, Atomicity is really long. They just made it Atom, right? Because remember at the time, it was like you could launch TextMate with Mate. You could launch Sublime with Subble. And so like the simplest shortening of Atomicity was Atom.

And then that name was like, oh, that's a much better name and so like right around the time i was hired i think we renamed the repo or something to adam and just did the rename and then the branding just kind of grew out of that because we were interested in like the atomic era like adam it's this physics thing and like winded so that was sort of the 50s kind of came to mind which like i don't know, it's not like retrofuturism isn't exactly new, but we really liked that angle of like the atomic era. And so from that, I think we hired an illustrator at some point, it didn't really pan out, but he did some really cool atom graphics, like wallpapers and stuff that were sort of in this retro

futuristic theme. and i remember making like pinterest boards with like all of these posters from general dynamics from the 50s and you know those cheesy like advertisements that are like hand-drawn yeah about like how the world is a better tomorrow and the house of tomorrow blah blah blah like and at some point like so we had different people involved like uh that github animator who's still like i think the lead animator at github did some graphics for us but they seemed just a little too like cartoony and at some point we worked with another designer inside of github and gradually evolved toward yeah just that simple atom disc or whatever

yeah i don't know if that gives a good narrative. We have the Adam video, a little commercial we did for 1.0. I love that video. That video is so awesome. I can see the zooming out though, so I'm not sure if somebody inside the Adam team started to do this stuff, but even when you zoom out further, you've got GitHub Universe, and you've got GitHub

Satellites, you've got this sort of maybe physics perspective towards naming with uh with with github these days because it's like you know that's like atom is like this you know one of the smallest type of structures we have in our universe and you got obviously planets and satellites you got this sort of space physics kind of perspective towards naming electrons yeah yeah that i don't know how that really emerged i mean adam was named adam kind of before a lot of those themes came out and a lot of those things were named there was this really like wallpaper running around inside the company of the github

universe wallpaper where like there were like different planets like one planet looked like cuba and the other one looked like the octocat and i think that sparked a lot of excitement so i'm actually like you'll have to talk to designers to get a sense of how intentional all this has been but adam was accidental to some degree because it was atomicity it's always intentional when they write it up in the history books you know it's true we thought of it all a long time ago. It's a long, it's a plan that we've had laid out and we're just executing our plan.

Well, I teed up a break earlier and we didn't take it because we wanted to ask you about the name. So let's take that break now. And on the other side, Nathan's favorite packages. We'll talk about themes. We'll talk about the ecosystem and the future of Atom. We'll be right back. Production ready, cloud hosted databases. That's what Compose is all about.

Compose.com. Check them out. Pick your flavor. Mongo, Elasticsearch, RethinkDB, Redis, Postgres, FTD, RabbitMQ, SilaDB or MySQL. I talked to Greg Koberger, founder of ReadMe, about why they chose Compose. Take a listen. So we actually weren't using Compose at first. We had our own Mongo database set up on AWS. We were just going through a checklist of things that would just kill our company. You know, it's not to be overly dramatic, but there's a few things early on that can just destroy a company and there's no coming back from. And pretty much every single one of them was around data loss or whether it be stolen or just deleted. I don't do DevOps.

I'm a programmer and I can, you know, navigate my way around the command line. But I did not believe that I had the skills to make sure that I wouldn't just delete the database by mistake or that my backups wouldn't at some point, you know, just stop working. You know, every single scenario that I saw, like, you know, waking up and seeing that something bad had just happened, they all involved the data. If we pushed a bad, you know, push bad code

and it broke something, that can be fixed. But kind of data, either theft or loss, was the two things that I just was petrified of. It took, you know, 30 seconds to get started with Compose. We went to the site, signed up, moved over within minutes. It was fast. The interface was great. We could browse stuff online.

But kind of the biggest reason why we started using it was just scared that we were going to lose everything. If you're ready to give Compose a try, our listeners get 60 days free. Head to compose.com slash changelog to learn more. Make sure you use that URL. That's the only way to get those 60 days free and now back to the show all right we are back with nathan so we're having a fun conversation about adam and nathan i'd like

you to talk a little bit about where we are today and where we are going so you probably have you have thousands maybe maybe a million, I don't know. You have lots of users. You have people who love Adam. You also have a lot of people who are holding out. They love their Vim, perhaps their Sublime Text, and they're waiting for, you know, X, Y, or Z feature or performance to improve or these other things. So tell us the lay of the land in terms of where Adam is moving. Yeah, sounds great. So I mean, milestone zero for me has always been that we need to be a fantastic, just basic text editor.

Like, yeah, we're super extensible and you can do crazy stuff in Adam that really isn't possible anywhere else. But like, as a user, not a package author, I've always wanted it to feel smooth, feel lightweight and fast. And like, I think we've improved dramatically from even when we went 1.0 on that front. And there are improvements landing in every release or every other release.

But that's something that we're going to be continuing to focus on to round out, at least for like the first few months of this year. And I still think we could keep working on it. But in terms of scalability, we have a bunch of architectural changes coming that I think we're going to scale us up to like multiple gigabytes of text. We're already up to like 40, 50 megs before there are problems. And it's not just gigabytes for gigabytes sake. But I think when you increase the value of N, you end up discovering performance problems that, while not egregiously bad at smaller file sizes, are kind of like this sort of low-grade sand in the gears. So that has been a focus and will continue to be a focus.

And it's an incredible amount of work to get there. So that's one piece of it. But then transitioning out of that to basically add some of the first real big features that have landed in Atom for a long time. So first and foremost on the roadmap is pretty nice Git and starting the beginnings of, but it will then continue to be iterated on Git and GitHub integration. So basically being able to open up a panel, see what's unstaged and staged, stage lines back and forth, discard hunks, create commits with a nice Atom editor, and then more interesting interaction with understanding collaborative state on GitHub.

And my dream, although it'll take a while to get there, and this is going to kind of be like V1, iterate to that dream is for a lot of tasks, you won't really have to leave Atom to do collaboration. Take a while to get there, but that's where we're headed. So that's one area for expansion that I'm really excited about. So by collaboration, are you talking about like a Google Docs style? You had, you know, I'm looking at mine, you're looking at yours, and we're live editing the same file? So that's definitely something I want to do. That's not really in progress that I had a, I did a bunch of research in that area. so that I can't really put a timeline on but I can definitely say that like

more async style traditional github collaboration will be happening this year and I think there'll be a natural outgrowth from that into the real-time stuff I mean there's been a huge debate in the team of just like even even how real time is presented. Are you like full on pair programming? And if that's true, like, what do we do about things like the app that you're working on is on one person's computer, like when they run, when you run that app, what happens, et cetera. So like when it gets into real time and it's definitely somewhere I want to go, I see it as kind of maybe to start with this kind of little flirtatious outgrowth from some async collaboration that you're already having on a pull request or

something if that makes sense like you're going back and forth in comments you're seeing that stuff come in and then you're like all right why don't i just code with you and then maybe for the scope of a more limited scope working together but that's all a twinkle in my eye right now. The GitHub integration is actually, you said, underway. Right. And so that you're talking about not just Git operations, but actual integration into your public and private repos and maybe pull requests and issues. Is that the kind of stuff you're referring to? Exactly.

Exactly. And I'm really excited about what it's going to be like to be able to get a sense of like, say I have a pull request open and I'm editing some text and someone comments on the pull request and I'm like in that file and I just see a little thing pop into my gutter like ding, someone commented. Just this sense of like immersion in the collaborative experience has always been like what I pitched it, you know, even to get hired is taking a while to get to the point where I felt we could even start on it. Any concerns with distractions at that point though? Like, uh, well, we'll have to see. Yeah. I mean, I can just think of like the age old cartoon, which is like, you know, programmer there with spaghetti in his mind interrupted, boom, spaghetti's gone kind of situation. So it's like, you know, that little notification might be like a whole new problem.

Oh, totally. And I mean, maybe you won't want that notification. Maybe some people will, some people won't. Maybe the whole idea is terrible. But I think what is true is like if I'm viewing people's comments on my pull request in my text editor, I'm going to be happy about that. Yeah, me too. Because it means I can respond to those things in situ. Right.

You know, I don't have to like tap over to my editor and deal with it. So just like a tighter integration of that entire flow for Atom users is our goal. Any plans for pairing type stuff? So, yeah, I don't know. There's nothing planned. There's dreams. I mean, Antonio is still in school and has to do a thesis in Italy. So he's probably going to work on researching like the real time text collaboration technologies.

There's like operational transformation. There's also a conflict free replicated data types. Those are kind of like the two leading theoretical foundations we're working with. But like, I don't know, like we already have a pretty nice server back end for a lot of valuable stuff so we're starting there you know uh yeah but that's the more async world but yeah i grew up as a programmer pairing and i still pair you know decent chunk of the time so i'd love to make that work someday so you mentioned around the performance concerns, you mentioned that, you know, you guys are going extreme lengths to test performance bugs and to isolate them and find different ways you

can improve performance. But do you have anything else in terms of performance that you're going to also be working on over the next year or so? Well, the biggest thing is this. So one of the ways that we're addressing performance at long last is by dropping key pieces of the system down into C++, which is great because V8 is written in C++ and has a pretty extensive API from that native side of things. And so, so far, we've basically dropped a menagerie of balanced tree implementations and splay tree implementations down to C++. For example, the patch layer is this data structure that aggregates change. So in the text buffer, when you open a transaction

and then just make random edits anywhere in the file, at the end of that, how do we report to event listeners what the aggregate effect of all that change was? And the answer is not like if the before and after. So yeah, that's been a structure we've had in C++ for a few months now. Something that's been there longer is the marker index, which is a data structure that tracks logical regions. So if you have a word highlighted and then you paste text above that word, making sure that the highlight remains stable over that word and we understand the impact of that change on that region. So those are the kind of things that have been there previously. And what we're

working on now is taking more down into C++. So actually dropping the entire text buffer implementation down to the native layer and doing where possible, because in some cases, like if you're on a remote file system and different packages do different things doing the io from the native layer storing all the text as this giant immutable buffer and then representing changes made as as these patches that i described previously that are aggregated sets of changes that are composed on top of that underlying immutable text. That'll be the gateway to this feature we call snapshots, which is basically like, let me freeze the contents of the buffer

at a point in time. And that gives us a stable, something stable that we can implement, find and replace, scanning and populating an index of where the results are, which is when people search for like space in a multi-thousand line file or something crazy we still block on that so that'll get us that in the background nice and then the thing i'm most excited about is snapshots are the gateway for

what we're going to start to do hopefully in the next few months here is to integrate max brunsfeld's new parsing system into atom in a proper proper way. So the parser needs, obviously, a stable input stream, like the stream can't be editing out from underneath it. So that snapshots feature will enable the parser. We already have some pretty cool prototypes going, but the idea is, yeah, to achieve that original dream that I had back when I started Atom of always having a syntax tree available for any language you're happening to be editing so that packages can do things like, oh, let me inspect if there's like a has mini class method call

in this class that I'm looking at here. And you can just walk the parse tree to do that at any point in time. And then that code could like query the database and figure out what the columns are. Those kinds of, I think the combination of ad hoc package code with like a really reliable well-formed syntax tree could produce some pretty cool stuff so that's another thing i'm pretty excited about and we've i mean we currently use this reverse engineered textmate syntax highlighter

and it's not the fastest thing in the world. I think TextMate's is probably faster than ours, but no matter what, they're all based on Oniguruma or Regex's. It's just not that fast, whereas Max's parser can crank through a jQuery, and I think it was like 40 milliseconds. And then each additional edit, it's incremental, which means you type and you only pay for the kind of changes that you made. So each additional edit is like one millisecond or something.

And so, yeah, like our budget is about 16 milliseconds for any action to happen in order to feel responsive. So we're kind of within that budget. And I'm excited about what we'll be able to build on top of that. The other big theme, I guess, that will be supported both by this integration of this new parser and then also some work that other team members are doing on talking about language server protocol that VS Code started is just moving more in the IDE direction in terms of having

those kind of integrated language-aware features. But I want to be careful to keep Adam feeling lightweight, feeling more like him or a text mate, and have those things kind of unfurl as needed, but then stay out of your way when they're not. I want to keep that vibe of a text editor. That's a good move. I agree.

That's the holy grail is like, give me the power features when I want them or know i need them but don't feel like they're you're a huge honking ide right keep it light keep it fast right another thing we're working on is right now actively is startup time so technology we're using is this thing called v8 snapshots where you can load with some limitations run a bunch of javascript load and run a bunch of JavaScript, load and run a bunch of JavaScript and then tell V8, hey, serialize your state. And you get like this blob of binary. And then when the Atom window is born, it can be born kind of with this blob of already

evaluated JS just there in memory. So we're actively working on that right now. We had to go through every package that was still using jQuery from the good old days and remove jQuery because it does all this DOM interaction when it's evaluated that was breaking our snapshotting. But that's finally done. So yeah, I don't know. I still have this pretty big passion and people may doubt it because it's taken a while, but these are big problems to solve yeah to get this thing feeling like a sublime or i mean it's never going to be vim because it doesn't run in the terminal and it you know wasn't its core wasn't built in the late 70s early 80s but like i think

we can feel a lot lighter and snappier and and that's always a goal so you have a lot of big goals a lot of performance sounds like you're putting a lot of efforts into that project for us you know this is maybe a five six-year-old project now in terms of like heavy development project out double it go five years from now and in your you know in your perfect world what what is adam then both in terms of like how it works and then also its place in the programming community i mean are you going for utter world domination what's your goals i mean i i'm not utter world domination really doesn't matter to me like if people are happy

using whatever they use then like i'm happy for them and as a programmer i would never want to like yeah whatever it's fine use what works So world domination doesn't matter. But in terms of, I mean, my goal with Atom has always been to build the editor that I want to use for the rest of my career. And until it is that definitively, like I'm not going to stop. And honestly, that is going to probably take another five years, at least. So I mean, one big dream is an IDE, but not like feel like a text editor, but have the same kind of power as an IDE, but then also be democratized that experience. So, you know, use a simple JavaScript DSL to define the grammar for some newcomer language. And you've got really awesome facilities that are the foundation for doing refactoring or further semantic analysis, et cetera. So definitely moving into those kinds of language aware capabilities. That's one pillar

of it. And then the other pillar is never having to leave Adam to kind of do your day-to-day work in programming land, at least. So I don't know if everybody at GitHub, I haven't asked, but agrees with me on this, but I would like Adam to almost feel if you wanted it, if you kind of opted into that layer to kind of feel collaborative, like it feels like an extension of the GitHub experience, if that makes sense. So that, you know, a collaborative development environment is kind of my thought, like an environment for developing that inherently acknowledges that there are multiple people working on whatever you're doing at the same time with you and exposes valuable information about what's going on and puts you in touch with those people at appropriate times, keeps you away from that information when it would be distracting as you brought up. But yeah, what does that look like? And that's a little hand wavy right now.

Like, I think we're just starting to explore that. But yeah, social coding in your editor is another big vision. And then, of course, fast, snappy and lightweight. And of course, real time collaboration. So that's part of that big vision is, yeah, basically like, I mean, the vision I've always had is like, I love pair programming at Pivotal, like just hanging out all day, two keyboards, two mice and one monitor working with somebody. And I think it's a really powerful paradigm and it would be great to sort of enable an

online version of that. What's the next step for someone listening to this? That's like, yeah, I can actually hack in this area. I want to get involved with this project. Is it a GitHub thing? Is it an open thing to the community? How I know you've got the, what is called again? It's the flight documentation.

Flight manual. Yeah. I mean, I think that's great, but I mean, that's a great way to get involved, like learn about things around Adam. But what other ways do you provide inroads to, you know, provide onboarding contributors and. So the idea is that as much as possible, we really want to, like, anybody that wants to make something possible in their text editor, that they can do it basically via Atom's APIs. So we have thousands of packages that are published right now. And a lot of the core features in Atom, like the tree browser, the tabs, find and replace,

the thing that brings up like the most recently changed files the command t basically like the file search all these things are implemented as packages so great way to get involved is you know implement a better one of those or implement some new piece facility and like you don't need anybody's permission no one has submerged your pull request i mean you can publish that tomorrow and people can start using it and getting value out of it. So that's one layer, like the least friction layer of collaboration.

And then the next one would be, yeah, opening a pull request on either Atom Core or one of our like hundreds of different repositories that comprise the finished system when it's all combined together. So all the different features are pulled out into their own packages, et cetera. I mean, I think we're getting better,

but historically, there's not that many of us and there are a lot of people that want to get code merged. And so the problem sometimes with that is just pull requests. We're just inundated and we don't have time to make forward progress on the core of the system and review every single PR and merge it in a timely manner. Just why,

like if a package is bugging you, like work it, maybe we'll just adopt the entire replacement that you create wholesale. Like we maintained a package of Vim mode and somebody forked it and made them mode plus. And now I think in the read me, we just link everybody there and auto complete, same thing.

Auto complete plus auto complete was junk and someone replaced it. And now it's in the readme, we just link everybody there. And autocomplete, same thing. Autocomplete plus autocomplete was junk and someone replaced it. And now it's part of core. So I think in general, as an open source model, like that kind of modularity approach is ideal because it means people can do whatever they want to do. I mean, all the way up to Facebook, that's built basically an entire IDE in the form of Nuclide on top of Atom. And I use it, like when we're writing the C++ code of late, I use the Nuclide debugger. It's really great. It connects to LLDB, gives me a graphical view of it. They've got a diagnostic system to relay like linting reports. They got their own tree view. They completely replaced Atom's tree view with their own thing. They've got their own command T that has like all kinds

of cool features. And we're talking to them about upstreaming some of this stuff. But obviously they have the priority of like serving Facebook as an organization, building their ID tooling and upstreaming is part of that. But they have a lot of other things to do. But anyway, that's an example of like how far you can take it if you want to i've heard go plus i haven't actually used it because i haven't written go um but that gets really great reviews in terms of facilities that it extends adam with so to me that's the best place to start is like build a package but there is that thing like if there's a particular missing feature or piece of adam that's driving you bonkers like i mean we merge pull requests quite a few constantly but there's just always more

created than we managed to merge well if you're listening to this if you haven't been there yet adam.io a lot of good information there i love the the video too we didn't even cover the video but we're a little late on time to go deep into that. Just going back into that whole 50s nostalgic advertising. I love the creativeness that you all have on the GitHub team to do the new branding around. You've done stuff on Atom and Universe and Satellite. I think it certainly fits the bill, so to speak. Thank you. Yeah. Well, thank you so much for coming on the show, Nathan. It's been a pleasure talking to you. I know that it's been a long road and we don't blame you for the timing

as we've said a couple of times during the show. You have had a hard job to do what you've done. You led a great team and you've done something really awesome. So we look forward to the future of Adam along with you.

Thanks for coming on the show, man. Thank you so much. All right, that wraps up this episode of The Change Log. Special thanks to our sponsors, Linode, Hired, and Compose. Also, thanks to our sponsors linode hired and compose also thanks to fastly our bandwidth partner thanks to jonathan youngblood for his editing skills on the show great master cylinder for the awesome beats if you're excited about our new show

js party head to changelog.com slash js party the first few episodes are out there on the feed introducing our hosts subscribe on on iTunes, Overcast, and on Android. Thanks for listening.