Gabriel Gonzalez: One common mistake I see a lot of new open source developers make is they try to build what I call the hype train, where they advertise on Hacker News hoping that, okay, we’re going to generate a lot of hype, maybe get a lot of new influx of new contributors. In practice, that never happens.
Intro
Adam: Hello, this is Adam Gordon Bell. Join me as I learn about building software. This is Corecursive. That was Gabriel Gonzalez. Gabe is a popular blogger, creator of the pipes library for Haskell. He also created Dhall, which is super interesting for 10 programming language type reasons, and probably just as many ops, DevOps type reasons. Check out my Software Engineering Radio interview with Gabe to learn more about that. We spent a long time discussing some of the interesting aspects of Dhall. But that is not what I’m talking to him about today. Today, we are talking about marketing. How do you market a programming language? What makes an open source project succeed? How do you become a tech evangelist in your company? Why is Kotlin funding more mainstream success in Scala? What else? Let’s talk about why does the Hacker News hype train fail to lead to adoption of a library or technology? And stay tuned to the end, I have some more thoughts about this super interesting talk. I hope you enjoy it.
The Hacker News Hype Train
Adam: Gabe, thanks so much for coming on the podcast. This is actually our second interview. So I talked to you on SE Radio about Dhall. That was a lot of fun. But you mentioned in that talk some stuff about evangelizing for technology. So this is like my problem statement. You don’t have to answer it immediately. But let’s say that, like I or a listener is really keen on some library or language that’s maybe a bit fringe. I’m hoping that today, you can tell me how I might advocate for it. So when did you first try to advocate for technology?
Gabriel Gonzalez: So for me, it started way back when I fell in love with Haskell. I was a PhD. student at the time. And I found out Haskell, I learned more about it. And I was super into it. I felt the need to tell the whole rest of the world that they need to be using Haskell. And so that’s where I started learning a little bit of technology [inaudible 00:02:28] difficulties in convincing other people to adopt technology. It’s far harder than you think. There are a lot of things I wish I had known back then that I know now that would have made it a lot easier.
Adam: It seems like everybody who learns Haskell maybe goes into this mode.
Gabriel Gonzalez: Yeah, that’s correct.
Adam: What was your pitch for using Haskell?
Gabriel Gonzalez: I don’t exactly remember what was the pitch I used back then. But I think it was like a combination of it’s really lightweight. You have type inference. It’s not heavyweight like Java. So you still type but you don’t have to pay the freight. It’s very good data structures, good for data science, for example, easy to transform things, especially in memory stuff. Because for me, I was coming from a background of a PhD. student, that was exactly what I needed. I need to be able to quickly change my mind, because my advisor kept changing his mind about where he wanted the project to go. So I was, like very refactor friendly, easy to maintain, good data structures, good collections, and so forth. And you’re probably already thinking like, “Yeah, that’s kind of like a really long winded elevator pitch right there already.”, right?
Adam: Yeah.
Gabriel Gonzalez: At that time, I didn’t really know what other people were looking for a language and how to frame it to appeal to them. I was just thinking about it in terms of like what I needed out of a language.
Adam: So this was Twitter, right?
Gabriel Gonzalez: No, this was way before even Twitter, I mean, sorry. So this is back when I was a PhD. student and I was already doing blogging and trying to use Haskell. But I did actually try to do evangelism when I was at Twitter to get to try and get them to use Haskell as well.
Adam: And then do you like… perfected your let’s use Haskell pitch by that point?
Evangelism at Twitter
Gabriel Gonzalez: No, not at all. So while I did not convince them to use Haskell, I learned much more about what is the mindset of the mainstream programmer and what they’re looking for in a technology. For example, if you said something like Haskell is very terse, and point free and elegant, those are all very negative things from their point of view. The things that actually would resonate much more with them, or you didn’t convince them yet, but things like that had more of an impact than things like it’s stable, low maintenance, low total cost of ownership. You’ll get paged on weekends or late nights for hostile service breaking, things like that. That’s what really warms their heart when they’re looking at least for the niche that Haskell occupies.
Adam: Interesting. So yeah, I can see the pager on, especially being useful. We check this stuff at compile time, so we’re not going to have things blow up in production. So did those arguments resonate?
Gabriel Gonzalez: In the end, I think the biggest things that made it hard for them to adopt it is that there wasn’t a killer reason to adopt. If you think about like Twitter is the largest Scala company in the world. Right. So they got a huge Scala code base. The marginal improvement from switching from Scala to Haskell is small enough that you can’t really justify the switching cost for example. You actually find that usually where Haskell takes root is in displacing a much more terrible language than… Scala’s actually pretty good. I used to compare it to Scala, but like, as far as we can just go, it’s pretty high up there. Now, if you’re trying to make the case displace saying PHP, yes, please, I’ll take anything else, Haskell, whatever. And I’m always just like whatever language comes up next will be fine.
Adam: That is not what I would have expected. Because yeah, you’re like, oh, Scala has some of these things that Haskell has. So you think it’s a smaller jump to Haskell. The convincing should be easier I would think but you’re saying no, there’s just not enough difference to matter.
Gabriel Gonzalez: Well, you have to think about in terms of what is the niche you’re trying to occupy. Is that niche well served? So in this case, the niche for Twitter, not anymore for both Scala and Haskell’s back end web service, and Scala was already doing a pretty good job. So really, when you’re trying to get a technology adopted, you want to target a use case that is really poorly served by the existing set of mainstream technologies. For example, for back end web services, like it’s kind of okay to use Scala. There’s already like a mature ecosystem there. So it’s like people aren’t going to change unless they really have to. And I mentioned to you in the previous podcast, the book Crossing the Chasm was about how you make things appeal to mainstream programmers. And one thing you learn from that book is that mainstream programmers, they’re like a herd. Nobody wants to be the one that sticks their neck out. So if you want to get them to try something new and to deviate from the herd, you need to basically make it so that they have to. There needs to be some huge tire fire. They need to be hemorrhaging time or money in some way that they don’t even have a choice except to adopt this technology.
Adam: Heather, she was describing how Scala as like a bunch of penguins who go up to the water, but they’re all afraid to go in because there could be some sort of prey. And then Twitter fell in and started using the language. And then once they did, then other penguins weren’t afraid to get in.
Crossing the Chasm
Gabriel Gonzalez: Yes. This book actually talks about this phenomenon, which is that one of the most successful strategies for getting technology and transition from early adopters to mainstream programmers is you have to target a really narrow, mainstream use case. The thing about early adopters and mainstream programmers is that they don’t really overlap, right. So early adopters do not make good references for mainstream programmers. I described the example of trying to convince the mainstream programmer. The language early adopters use to sell things is totally different from the language mainstream adopters use to sell each other on technologies. So early adopters are all about, they’re visionaries. They’re about revolutionary changes that will transform things. Mainstream programmers are not. They’re evolutionary, and they just have a different set of values.
And so that makes it hard, because you actually, a lot of new technologies kind of get stuck in the early adopter phase, like Haskell is the perfect example of that, because they haven’t really penetrated the mainstream market. The thing is, once you make that initial mainstream use case, then it starts to spread because mainstream programmers make very good references for other mainstream programmers. It’s just like finding that beachhead, where you can get some mainstream use cases and then grow from there.
The Programming Language Fallacy
Adam: It’s a strange idea. It makes sense. But when I think about a programming language, oftentimes, they’re Turing complete, they can do everything. So picking a specific area seems like a strange choice. It seems like narrowing your possible audience, right?
Gabriel Gonzalez: Yes. So this is the general purpose programming language fallacy that I find a lot of new programming languages run into. Haskell made this mistake all the time when people say like, what do I use Haskell for and Haskell programs will say, it’s a general purpose programming language. You can use it for anything. And that’s not really going to fly. The reason it’s not going to fly is that mainstream programmers do not adopt something that is 80%, complete. They want to adopt something that is a fully featured product. So for example, like Java, they adopt Java because they know there’s not going to be some missing functionality that’s going to block them at an unexpected time. They’re not going to have to worry about maybe the runtime or set of available libraries, or weird issues. They assume it’s already been worked out by this point, compared with Haskell, people are scared because I think am I going to have to do like a little bit of extra work to get this going?
And it may depend like maybe the maturity of the ecosystem might vary from application domain to application domain. So it’s not enough to say that it’s a general purpose programming language. It needs to be very well developed for the use case that they have in mind, because they don’t want to invest the work to make it usable, they just want to adopt it. So all technologies have this awkward period where they’re trying to at least satisfy this one vertical, so they can get that mainstream edge. And then once they satisfy the vertical, they can slowly spread horizontally to actually become a general transformational platform.
Adam: So you mentioned Crossing the Chasm. I know this book, mainly just from this diagram. It’s like a bell curve. And then it has the very leftmost part of the bell curve says early adopters, and then the middle is like mainstream. And then I don’t know, there’s some third part, but how do you know where you are? Let’s say if I’m a big evangelist for Rust, it seems to be growing in popularity, how does Rust know where they are on this chart?
Mainstream Programmers
Gabriel Gonzalez: So the thing about mainstream programmers, this is to answer your question, mainstream programmers, once they adopt a technology, they make the choice to adopt. They become very loyal supporters, so they’re hard to win over. But once you get their support, they will do everything in their power to make you the standard way of doing things because they really love standardization. So a perfect example will be like, you have this big tech company, they’re considering whether or not to use the [inaudible 00:11:19]. And once they’re convinced to use Go, then it’s in their best interest to get the whole company just to, we’re going to make the switch, everybody’s going to be using Go. They don’t want fragmentation. They just want one approved, mainstream way of doing things.
So that’s how you know when you’ve crossed the chasm and you enter the mainstream market is you start seeing mainstream programmers doing everything they can to standardize on your technology. So like adding official support integrations. You asked about Rust specifically, I would say Rust is already penetrating the mainstream. So a good example of this would be when Amazon, I think Amazon might have added official Rust support to one of their SDKs I forgot. It was like for the Lambdas or something like that. So when you see big tech companies offering official support for your language, that’s how you know your mainstream. Again, those are the mainstream programmers trying to standardize on your platform. You won’t see that at Haskell. At Haskell, we always have, every time a new platform comes out, the Haskell community has to do the third party bindings to whatever that platform or SDK, because they don’t have the support of the mainstream programmers to do it for them.
Adam: Oh, yeah, even silly things like whatever Gmail API, it might have code examples for Go and Rust and Java and Python, but the Haskell is not there.
Gabriel Gonzalez: Yes. So mainstream programmers, they like there to be order. They hate chaos, hate fragmentation, they want there to be a clear winner for any given niche or market or application. Like I said, once you win them over, they really want to defend your advantage against newcomers. There’s always like, for any new market or application, there’s always this weird point where it’s not really well defined, like what the market even is. Sometimes you just have to convince them that this is actually its own new application that is a mainstream use case in the first place. And then once you convince them, then it’s like, “Okay, now we’re convinced that this is a problem that we need to solve. Then you need to also convince them we’re the best solution in this category, way better than all the other alternatives.” And once you get to that, they’ll say like, “Okay, we will defend you as the leader, because we want there to be a leader and only one in this category. We don’t want to have to switch for a very long time so we’re going to protect you from any newcomer technology by, whether that means adding integrations, adding SDKs, defending you on social media or Reddit or Hacker News, anything to protect your position of dominance as much as possible.”
Early Adopters Are Flaky
Adam: That’s interesting. And I assume that means the early adopters, the people who are actually, if you haven’t become this popular, the people who you actually have in your community, I think the thing you’re implying is like they’re flighty and can’t be trusted, because they’re on to the next new shiny thing.
Gabriel Gonzalez: Yeah, I mean that would describe the early adopters. So that is exactly the personality of early adopters, which is that they see the potential but they’re not loyal to technology. They just want to, and that’s actually one reason why mainstream programmers really don’t like early adopters, because mainstream firms are very loyal by nature. They’re the ones that are trusted with maintaining systems long term. You’re building a career for a specific vertical. Early adopters are not. They’re just moving kind of like locusts from one technology to the next looking for the next revolution. I’m sure early adopters view it in the positive way, but that’s the way that mainstream programmers view early adopters. It’s like they don’t have any long term loyalties or careers. So they can’t be trusted. They’re not dependable.
Adam: That’s funny.
Gabriel Gonzalez: I mean, early adopters, going back to that diagram, developer, early adopters do play a part in that life cycle. They prove that the technology can be used for a use case. It’s not like vaporware. At that point, there still is potentially a lot more work that needs to be done before it’s really a polished use case for the mainstream. And they can also then not only provide the proof of value, but they can also help provide resources. One thing that’s important, the book was actually written for startups. The book was not an open source technology evangelism handbook, rather a startup handbook. But a lot of advice from that book is actually useful for open source tech evangelists too. Specifically for startups, early adopters can provide initial source of seed funding. They’re sort of like a hidden source of venture capital to use the books on words. So we can keep the technology going, at least to be able to develop the product until we can finally have enough resources to build out that polished, mainstream use case. But I said at some point, you have to wean yourself off early adopters and make that jump to the mainstream use case.
Adam: So I read the book so, so long ago, and I never had this perspective on tech evangelism, but it’s called Crossing the Chasm because nobody makes it across, I guess.
Gabriel Gonzalez: Yeah, it’s very difficult to do. And part of what makes it difficult is that you don’t really have a lot of data to make that decision. Because remember, you’ve only had a few early adopters. You see, okay adopter one is using it for this use case. Adopter two is using it for this use case. Adopter three is using it for this use case. And the book says you don’t want to play the field, you got to pick one use case and really focus on it. Otherwise, you’re going to have the resources to build out that polished. If you have three 80% use cases, nobody in the mainstream is going to adopt it. But if you have one 100% polished use case, then you’re going to get traction in the mainstream. And it’s really hard to figure out which one you focus on, because you don’t really know which one of those is really going to be the killer app.
Rust Advocacy
Adam: Let’s posit examples around this to maybe make a bit more sense. So I don’t know a ton about Ross. But I’ve done a couple interviews. And I think that Jim Blandy, when I talked to him in the earlier days of Rust, he was kind of like this is just better C++. So C++ has a lot of things. It’s complex. And here’s something better. Is that what you’re talking about? Is that like a beachhead? Is that a specific use case?
Gabriel Gonzalez: Yes. So the way you identify a really good beachhead is four things. So one is that you need to identify a compelling reason to buy. So going to Rust, that would be no memory safety issues. We’re getting a growing number of CDEs every single year and the safety of C is really rapidly being called into question. So people are very keen to replace C with a safe alternative. But garbage collected languages are not an option for the use. They don’t want to use Java, they want to do low level stuff, maybe embedded programming or high performance programming or low latency. They don’t want GC pause for their server.
So that’s the compelling reason to buy, like you’re drowning in segmentation faults and other and heartbleed attacks, and you’re just looking for a better solution. Second thing you need is what’s called the whole product. So you need to be able to be as good as what was there before. And this goes back to what you said about Rust is basically just a better C++. What that means is that they sufficiently built out the maturity and polish necessary to displace the existing use case. People adopting it know that they don’t need to do any extra work to make the transition to Rust or at least very minimal, compared to like C++. So they know they’re not going to have to do any research or experimentation or new library development.
Adam: And now they don’t say anything like a better C++. What they say is Rust has four distinct domains, command line usage, networking, embedded devices and web assembly. So it sounds like they’re taking something from your playbook and saying like, we can’t say we’re just better than C++, because that’s probably a massive ask. So they’re like narrowing in.
Gabriel Gonzalez: I would actually say that’s still not narrow enough. I mean, I think that at this point, they’ve kind of already crossed, so I wouldn’t be too concerned about them. But if you’re still not mainstream yet, you would not want to have that tagline. It’s like a remote assembly or I forgot what the other things you said or maybe command line tools. That’s not what you want to do. You just want to pick one, make sure that’s really polished. In general, you do not want to advertise use cases that are not 100% well developed. That’s like a really big mistake a lot of people do whenever they see technology.
Let’s say, going back to Haskell, right? So Haskell’s like well, maybe it’s great for data science. It’s like, well, is it like the plotting and charting libraries? So maybe it’s good in some ways, but there’s still deficiencies in other ways. So you don’t really want to sell it, or say data science unless you’ve really thought through all the use cases like okay, like some data sciences, data science overlaps a little bit with machine learning or statistics, like how good is statistics or machine learning libraries. Does Haskell have good binding as TensorFlow? All those little details are, you have to get all of them right, in order to get into the mainstream for that particular vertical? That’s why it’s so important to focus on just one is like, once you really get into, you realize, wow, I have a lot to do before I’m ready to go.
Adam: Yeah. So I’m sure I told the story before, but years ago, learning Haskell trying to introduce it my work. And so I built some web services. And then I had to pull data from this other service that use SOAP. And then I remember asking Haskell gurus like, how do I interact with like a SOAP based web service? I think the answer was basically like, “Oh, gross. Don’t do that.” Because nobody had done that. It’s like that. So then you’re stopped in your tracks. I guess the early adopter move is like building your whole home, so parsing library.
Gabriel Gonzalez: Yeah, exactly. So the early adopter will be totally fine creating SOAP binding if they had to. A mainstream adopter, when, if they hit something like that, there’ll be a negative reference for Haskell. They would be telling other major programmers, please do not use Haskell. It’s not mature for this use case, stay away. That’s why it’s very important not to advertise use cases which are not fully polished, because then you start generating negative references, which will be very hard to dispel later.
Early Adopter Won’t Build Your Product
Adam: But it’s tricky. Because if you get an early adopter into this use case, then they’ll help build it out. But if you get a mainstream programmer into this use case, then they’ll advertise against it?
Gabriel Gonzalez: The early adopter will not necessarily help build out. So the early adopters are project oriented. They will often want like customizations for their specific transformational project. It’s like they have a goal. They want to do something revolutionary, which is not necessarily specific to your technology. They see your technology as an enabler of their revolutionary project. But they’re really only interested in customizations which benefit their project. So you have to walk a fine line trying to figure out ways to improve it for their use case, that also gets you further to addressing a vertical. But even then, it’s kind of difficult because each early adopter is really probably going to be targeting a different vertical if you’re not careful. So you really only want to devote resources to one vertical if you can, as much as possible. That’s what makes it very challenging to parlay early adopters and to start a new vertical. You really just have to kind of hoard resources, and then focus them all yourself without the help of early adopters into getting that one vertical fully polished.
Adam: So for Rust, you would say instead of those four things, like if Rust were earlier in the game, you would pick one. You would be like Rust is for embedded.
Gabriel Gonzalez: Yes, the author of Crossing the Chasm used the analogy of a bowling pin, which is that once you knocked out one mainstream use case, it starts to tend to spread into other mainstream use cases. So let’s say you’ve got these Rust programmers, they’ve already accepted these, you have these mainstream embedded programmers. They’ve accepted that Rust is what we want to be using now. It’s the new official, best in class embedded programming language. And now they’re highly motivated to start convincing their colleagues, their other mainstream colleagues to use Rust, like maybe they have to do stuff if they work in a company, a large tech company, that company has CI. So they’re going to ask their company, okay, like we need to use Rust, we have to, and we need CI support because the whole company standardized on CI, so they’re going to ask the company you have to add Rust support to CI.
And also the CI people start using Rust and be like, “Oh, hey, Rust is actually pretty good. Maybe we can start replacing some of our CI services in Rust.” That’s the bowling pin. So now you’ve got a new mainstream Rust adopter. And then they say, “Okay, well, now we need to not only build this in CI, we need to deploy it.” And then they go to ops, and say, “Okay, we need you to add Rust support to build docker images or what have you.” And then the ops will try and be like, “Oh, hey we should start using Rust for our use case, too.” And that’s how it spreads, once you have that one mainstream use case.
Adam: In your history, you tried Haskell evangelism during your PhD., you tried it at Twitter. So have you tried other approaches to evangelism throughout your career?
Gabriel Gonzalez: Ah, yes. So at Awake Security, we actually have adopted two relatively new technologies. So one is Haskell and one is Nix. Actually, this is a case where Haskell has a fairly well developed mainstream use case. And that’s how it got into the company. There is one use case for Haskell that’s very polished. And so it’s compiler, so programming language implementations or interpreters. And that was actually what got Haskell into our companies, that we really needed to build a basic language needed to build an AR product, that you just explore the high level insights. We were a security company, we want you to be able to explore the insights we collect. And so we need a programming language for that use case.
And so Haskell is the best in class compilers language. So that’s the initial mainstream use case. And then once we adopted it for that use case, and also like other people, the company has started using old web services for our company, use Haskell for that, too. It’s actually better because then we can share code in the programming language. We don’t need to call out as a sub process or a service right now. It’s just a library dependency. That’s very good. That reduces the possible points of failure. Then we need CI support for Haskell. And so that’s how it’s spread and at least inside our company, same thing like I keep most other stories I hear in the industry of Haskell taking root at bigger companies just typically in the programming language route.
Adam: Interesting, yeah. And you could even, I’m trying to think if you could expand that to like some sort of parsing. There’s parsing that’s not building your own language, I guess verifying the format of something or yeah.
Gabriel Gonzalez: Well, I mean it’s not as much the use case. So this goes into the third point of what you’re looking for, when you’re trying to get a technology adopted with just not enough to have the use case. You need to have a clearly identified buyer to somebody within the company who has either economic or technical authority to adopt. I’ll give a counter example. So once I asked somebody in my own company, what do you think is the reason to adopt Haskell? And he said, “I think it’s concurrency.”, but you think about there is no director of concurrency at Facebook. They might have a Data Science Division or Privacy and Safety Division. But currency is not like the way the companies think about things. So there is no clear person in the company who can adopt the technology. Whereas like you say compilers or programming language theory, they’re essentially like, there’s a compilers team at every company, so that gives you the clear person that you target and sell to, and then who has authority to introduce the language into your company. Another example will be like ops, that’s another clear vertical you can target within a company.
Adam: Now it’s interesting, because memory safety for like Rust. That’s not a person who’s in charge of memory safety but embedded is probably a team.
Gabriel Gonzalez: Yes, yeah. So you might have like a chip design team or a firmware team within the company. And they would be the technical buyers of the open source technology.
Adam: What were the three things?
Gabriel Gonzalez: Well, there’s four of them, so obviously a compelling reason to buy. So polished, whole product. Three is target customer that can buy. And four is, is there already a leader? So ideally, there should not be an existing leader, because remember, going back to mainstream programmers, but once they’ve identified the clear leader of whatever space you’re trying to occupy, they’re going to defend them to the death against a newcomer. So you don’t want to attack a proverbial fortified hill. So you want to make sure that whatever use case you’re addressing, there isn’t like a very well established best in class solution yet. You want to be that first one, so that you can have very good, then you can have the staying power against competitors.
How Angular Lost Its Momentum
Adam: And if there is a leader in an area, then do you focus in even more?
Gabriel Gonzalez: No, you just find another use case. Just give up on that area. I mean, you could penetrate it but you’ll always play second fiddle to whatever the defender is, again mainstream programmers just want to standardize. I think the only way you’ll like really surpass the existing technology is that they really mess things up. It will be like they just released, it will be like the Angular, the Angular 2, I don’t know if they have 3. But Angular does a really breaking release at some point. And it really pissed people off. And that would have been a good opportunity for one of their competitors to then leap probably ahead of them to be the new best in class whatever it was that Angular does. I’m not too familiar with the front end ecosystem.
Adam: Yeah, I think that’s what React did basically, to my vague understanding, knowing nothing of JavaScript frameworks.
Gabriel Gonzalez: Exactly. So the leader makes a huge misstep like that, then there’s an opportunity, but assuming that they just play it safe, keep incrementally improving and don’t rock the boat. I’ll probably just continue to remain the leader for a very long time.
TypeScript Messaging Is Great
Adam: What I was thinking about is TypeScript, so I looked it up TypeScript slogan, is JavaScript at scale, I think, pretty sure that’s what it is. Yeah, I don’t know, is that a good fit or not? What do you think? Is that a niche?
Gabriel Gonzalez: First of all, that’s a very good slogan. So the reason I like it is that one thing that the book talks about is how you position your product. So position is how basically, it’s like when customers try to adopt your product, rather than thinking about adopting your product, they try to compare you to other technologies. And when they do so, usually there are two reference points they need for comparison. So the first reference point is what technology am I displacing. So that’s called the market positioning. So in this case, going back to that slogan, JavaScript at scale. JavaScript is the market that TypeScript is displacing.
The second positioning is like, okay, so you’re displacing this, what makes you better than whatever it is you’re displacing? That’s called the product positioning, so you usually have like a second thing, but usually, actually, there’s a slight way we can improve upon their slogan by the first thing is scale, same like specifically compare it to an analogous technology, but even just saying at scale was already pretty good. So you’re saying this is what we’re doing better. It’s like we can do this at scale, whereas previously, we couldn’t before.
Adam: So what do we compare it to? What’s your improvement? Let’s hear the new slogan.
Gabriel Gonzalez: Let’s see. So the best comparison for product positioning is something that had a similar transformational effect in another ecosystem, but that’s not useful for the market you’re trying to displace. So a good example would be TypeScript. I think it does like a lot of typing. It’s not just like it does types but you can do type in friends and stuff like that. So normally, I might say this is not good, but maybe it’s like the Haskell for JavaScript. But that’s not good because Haskell is not a mainstream technology. You want to pick a mainstream technology with type inference to use as the clear positioning. I don’t know if there is like a really good one. An example of a bad one to use the comparison would be it’s like Elm, but for JavaScript, and that’s really bad because Elm is competing for that exact same market. [inaudible 00:30:25] product positioning, probably be some language with type inference that’s not competing for the JavaScript market.
Adam: It’s interesting, because I think that people who are probably early adopters for TypeScript, they were people, I’m just guessing, who didn’t like JavaScript that much, who didn’t like that it didn’t have strong static type guarantees. That’s probably the people who were the early adopters. But the market is all of the JavaScript developers. So if my slogan for TypeScript was like it’s JavaScript, but better, JavaScript developers wouldn’t like that, because they’ll be like, no, why is it better? JavaScript is great. You’re just making me add some type annotations.
Gabriel Gonzalez: Yeah, the reason the slogan works well, is again, it clearly calls out what is the huge problem that JavaScript people are suffering, which is that like JavaScript does not scale well, to large code bases. So it forces, the people who are struggling under that issue have a very compelling reason to adopt, to deviate from the herd, because they haven’t a good excuse to do so. Whereas if you just says like, it’s just a prettier JavaScript or more elegant JavaScript, that’s not the compelling reason to adopt.
Adam: So you have a reason, a buyer, customer, leader.
Gabriel Gonzalez: I would say yes, a target customer, compelling reason to buy, fully polished whole product, and then no competition, or at least competition that has not dominated the market yet. Yeah. So that’s what’s really important. It’s okay to have competition, as long as they haven’t really gotten that strong foothold. But once one particular technology gets 50% or more market share, then it’s staying.
Adam: Yeah. Because the mainstream programmers, once they’ve learned something, then that’s the tool they’ll use.
Gabriel Gonzalez: Yes, they don’t want to change. They’re very reluctant to change.
Nix Marketing
Adam: So when I previously talked to you, it was about Dhall. Oh, actually, we didn’t talk about Nix. I don’t know if we want to talk about that.
Gabriel Gonzalez: Yeah, Nix is actually a very interesting use case. So Nix is a technology I would consider not mainstream yet. I think most people would associate Nix are early adopters at this point, or they may not even know what Nix is, for example.
Adam: So what is Nix?
Gabriel Gonzalez: It’s a package manager, but even that’s not a really good description because Nix is actually doing a lot of things, which again, is kind of like a danger area. So it’s like it’s a package manager. There’s also Nix OS, which is an operating system. There’s also Nix packages, which is like a monorepo of packages. There’s Nix Ops, which is a deployment tool. There’s Hydra, which is like a CI tool. So there’s like this ecosystem of half baked stuff floating around. And so it’s already hard to even just answer the question, what is Nix is really difficult. And that’s bad for adoption.
Because when you want to penetrate the mainstream, you need your message to be viral. You want all the mainstream programmers to agree what is the reason to adopt? It’s kind of like a chemical reaction. If you’re trying to mix two things and get them to react, you want them to be in a very high density and concentration. So if your message is diluted and fragmented, you don’t get that chain reaction to occur. So I think out of all those things that I mentioned, the one that’s closest to mainstream adoption would be Nix OS, which is the operating system. It’s essentially an operating system where that is completely declarative, fully defined. You can configure literally everything about the operating system using the exact same option format. So I can configure new parameters, I can patch the kernel, what version of system VM running, I can find services, everything. It’s just like a well orchestrated poll that’s immutable, so it supports rollbacks. It’s narrative. It’s fantastic for ops, or DevOps in particular, but even just ops. If Nix ever goes mainstream, I think Nix OS will be the key use case that will get it mainstream, but it still needs to be polished more before that too.
Adam: Their slogan should be like your OS in code or something like that.
Gabriel Gonzalez: Yes, there’s a name. It’s really good for Git Ops, which is like source control based Ops, and VC, and everything is declarative. And in all that everything is source based. I guess the closest thing in this area would be like Docker and Ansible. All those other technologies, a lot of your dependencies are binary dependencies. So if there’s something wrong with them, you can’t really fix them. It’s like okay, I got to hopefully release a patched version, or something like that. But otherwise, you have very little control of fixing things. Whereas in Nix, everything is fully specified down to, you can patch every single thing that you depend on, not just in the system, but in the things that were used to build your system. I could patch GCC that was used to build the system D that my system uses. That’s like the level of control you have over the entire build.
Adam: It is Docker built by Gentoo developers.
Gabriel Gonzalez: Exactly. That’s actually a really good slogan by the way. It’s like Gentoo for Docker. Docker is the market positioning, Gentoo is the product positioning. So that’s a very good adoption slogan.
Adam: Yeah. So you need like the overlap of people who are Gentoo people and interested in Docker.
Gabriel Gonzalez: You don’t need them to overlap. The key thing about product positioning is like the Docker user who’s really considering using Nix OS doesn’t really need to actually use Gentoo. They just need to understand that like Gentoo is a nice big thing that was transformational in some way that I understand, then Nix OS is going to be transformational in that same way. And they’re like, the problem that Gentoo solves is the same problem I’m having right now with Docker.
Adam: Yeah, I can see that, right. There are businesses where they have very specific builds of their OS’ that they use using Gentoo or something. And now they’re transitioning to this, like Kubernetes Docker world, and they’re like, but we really want to specify every little detail. We don’t want, Docker is great, but it just says from X and it pulls in this image. I don’t know what’s in that and adds things on top. So I think the reason I brought this up is because you had some experience like evangelizing for Nix.
Gabriel Gonzalez: Yes. So in our company, the main issue we had was lack of reproducible builds and lack of support for rollbacks. So for me, for example, I think the one case that really sticks on my mind is early on in our company’s history, we were about to summon our first entrant system to demo for management. And it was like it was a mix of Docker and Ansible at the time, and it just totally crapped the bed. Because before the demo we did, we deployed it. We said okay, it’s easily working, there are some issues, but it’s fine. I said okay, now we’re just going to deploy it again, it should be item potent. So just to verify that it just works. It turns out it was not.
So we just need a point, no changes often break to the system, like 30 minutes before the demo, we’re all scrambling to get it working again. And so that was the compelling reason to adopt something new is that like, we could not get reproducible, and lack of rollbacks. So break the system, we could not roll back to the last working version. So these are the key things we are looking for in a new technology to fix the problem that we were having. And Nix just nailed those two use cases perfectly, like Nix has that. That is very well polished in Nix. It’s amazing. And so that was like so we had the compelling reason to buy, we had the whole products like Nix has support for deployments, rollbacks is perfect, nothing to change, no new investment necessary.
I was the economic buyer. I was responsible at the time when I was tasked with fixing the system to get it working this eventually, like my [inaudible 00:37:32] team, which is sort of like our kind of a DevOps team within our company. So that’s the vertical DevOps. And so the lead of the DevOps team is the technical DevOps team, like a lot of people will see this and will say, like, DevOps is the culture of mixing Dev and Ops, but particularly really [inaudible 00:37:48] in shared infrastructure teams, not a DevOps team.
But anyway, our team is the vertical that has the authority to use Nix and ask the rest of the company to begin using it. And then competition is like again, there’s no clear leader in this space, like all the other tools for deployment, like Ansible, Docker, Chef, Puppet, whatever, they’re all totally bad in this regard. Nobody has taken the clear leadership on fixing this problem. And Nix totally nailed it. So those stars lined up for Nix to at least be adopted within our company.
Adam: Yeah. Because you could be like, I can upgrade the kernel version, and then just roll it back if it doesn’t work.
Gabriel Gonzalez: This happens all the time where we’ve tried really random changes to our system, and we break the system, and then just roll it back to the last reboot, and then it’s as if nothing happened. So it’s very nice in that regard. So it really enabled a lot of experimentation inside of our company to try best of breed technologies long before it would probably be safe to use it for other platforms.
Dhall Is for Replacing YAML
Adam: That’s interesting. And then the topic that originally got us here was a Dhall, which I feel like I should spell, like D-H-A-L-L.
Gabriel Gonzalez: Yeah. That’s why the Dhall README has like how to pronounce it in IPA at the bottom of the README, just in case there’s any confusion. But I agree.
Adam: To me, this is like the interesting use case that shows how you’ve taken these ideas of tech evangelism as you’ve been into your head against pushing various pieces of technology. So if I were to describe Dhall, I would say like some Haskell guy rethought configuration from first principles, but that’s not what it says on the website. How do you describe Dhall to people?
Gabriel Gonzalez: Our slogan right now is a non repetitive alternative to YAML. And actually, I still think it’s not a good slogan. And it’s like the same issue with TypeScript, which is that it does a good job of describing what the market is, which is YAML. That’s what we’re trying to displace. If you use YAML, we’re talking to you. Non repetitive, it’s like that’s the product positioning. So that’s the problem we’re trying to solve. It would be much nicer if they’re like a mainstream technology, we could compare to that we could explain what are the features that Dhall offers. What makes it difficult is that there isn’t another mainstream total functional programming language like Dhall. So that’s what makes the positioning a little bit more difficult. So we sell it for something that was simple, clear and something that’s meeting, that is totally mature and polished. It’s not hard to do for Dhall. And yet it’s something that everything else does really badly. All the other attempts to fix this problem have been very poor. A lot of people are familiar like people doing Jinja templates at YAML or Helm for Kubernetes.
Adam: So why YAML? It’s a configuration format?
Gabriel Gonzalez: Yes.
Adam: So it could replace XML or INI files or et cetera. But you focus in on the YAML.
Gabriel Gonzalez: Yeah, part of the reason why is because one, we just want to narrow the use case. It’s easier to just displace YAML than trying to displace four other different configuration languages. Second reason why is we actually target a narrower market with YAML. In fact, we’re going to be calling that out more prominently soon. That narrow market is obsolete in YAML, so like Docker Compose, Kubernetes. I mean also not YAML but JSON also supported cloud formation, things like that. But again, the advantage of narrowing things down is that one, we can more clearly identify the problem. Two, there’s a more clear buyer, which is ops team, in this case, the ops vertical within a company, and three, if we’re not displacing all YAML, we’re just displacing ops server YAML, then that’s much less work for us to do to develop a polished product.
But actually, we can narrow down even further. And so the one specific ops use case that we’re really digging into right now is Kubernetes. So Kubernetes is the market. And then if I were to give the slogan of Dhall, it would be kind of like it’s like Agda, but for Kubernetes if Agda were a mainstream technology, which is not actually. A lot of people don’t appreciate how similar Dhall is to Agda. So yeah, Kubernetes is the market that we’re trying to grow upon again, because it’s very simple. There’s a huge problem with the Kubernetes ecosystem right now, which is that Kubernetes is there’s no clear, quality, decisive leader in the solution for dealing with large Kubernetes files. There have been a lot of attempts like case on a Helm. All of them have just fallen flat and people looking for a much better solution to this problem.
And those already kind of started to go viral in the Kubernetes community for exactly this reason. They have Dhall and one of the things we’re working on is just developing that whole product. So there’s no question that Dhall’s the best solution. So Dhall is okay, you can use Dhall to generate YAML. Kubernetes understands YAML, so you can read it in, but you could actually polish it more. So for me, when if Dhall had Go binding, which it will soon, then you could actually just have the QB control command, read all files natively without having to go through in the emulator media, for example.
What Dhall had a repository of Helm like charts, and then that would be another reason, like again, a mainstream programmer doesn’t want to write all those charts themselves, like in Dhall, unless that large repository of charts is already present there for them. Those are the things that you need to use to build out that fully developed use case. And then once we can get adoption from the Kubernetes community, it will slowly branch out because ops people using Kubernetes will be like, “Well, I want to make sure my Kubernetes configuration stays in sync with, I don’t know, my cloud formation configuration, or my terraform configuration.” So now, allow me to get those in the Dhall too. So they can all share the same code, or configuration in this case, and they’ll be in sync with each other. And so that’s how Dhall spreads from one ops technology to another ops technology.
And then all sudden, they say like, “Well, it’s not just ops things.” There’s gonna be lots of services that need program configuration, and it would be nice if those services could just read shared values that were shared with the deployment via Dhall. So all of a sudden, you people are going to want to have services reading in both configuration files natively. And the chain continues. But you just need that one initial use case, which in this case will be Kubernetes, to create that chain reaction of adoption.
Adam: Like at some point, you have Dhall, it’s better configuration. And then at some point, it’s like Dhall, it’s better than YAML and now you’re like Dhall, it’s how you configure Kubernetes. So how did you find this niche?
Gabriel Gonzalez: So usually, when you’re first starting out, a lot of early adopters, they’ll come to you with all these projects, and they’ll be kind of diverse. Only a few of my initial early adopters were Kubernetes related. Some people were adopting Dhall for entirely different use cases. I think the reason we focused on Kubernetes was just because, one, there’s a very clear void in the market. Kubernetes will, out of all the ops related ones, Kubernetes has the largest and most sprawling configuration. So the largest compelling reason to buy.
Two, there’s a void there. Again, like you said, there are several challengers that stepped up on that home, they tried and failed. So there’s still a void there left in the market waiting for somebody to step in. And people already understand the compelling reason to buy, which is that they know Kubernetes files are maintainable. You’ve got a clear technical buyer, which is ops, that’s the vertical. So all we’re missing to line up all the stars is just have a complete whole product. The other reason we chose Kubernetes is because that’s the one we were closest to developing the complete whole product because some early adopters have already created Dhall Kubernetes that our Kubernetes bindings from the API specification. So really, at this point, we’re just missing the native Go bindings and the repository of charts. And that’s all we need to do to flesh out the entire whole product. Whereas if we went for like terraform or cloud formation, there’s more work we have to put into before we have the fully developed experience.
Adam: What’s a complete whole product?
Gabriel Gonzalez: Basically, it just means the adopter doesn’t have to take any risks or do any additional work to adopt. I mean they might have to do, there’ll always be a migration cost, like you have to translate things. But even that, we’ve actually kind of made easier to, something like Gamble to Dhall, where if you just give it the expected type, it will auto convert your YAML files to Dhall configuration files. So even that is kind of a very slow migration path. And it’s also not just like, their surrounding tooling, like how easy is it to install the doc tools, size the executables, various packages, how easy is it to train people, all those details are part of the whole product, not the actual, it’s not just the executable you deliver but it’s the whole ecosystem of things around it that comprise the whole product. And that’s why it’s really important to focus on one use case because building out that ecosystem of documentation and tooling and IDE support and packaging and distribution is a significant amount of work to do even just for one vertical.
Onboarding Is the Key
Adam: It’s interesting, because TypeScript that we were talking about earlier, it seems their onboarding is run this command to get TypeScript installed, whatever, and then just change the file extension from like JS to TS. So it sounds like one of the keys is to have a really low friction onboarding process for some specific use case.
Gabriel Gonzalez: Yeah, like going back to Rust, which is an example of Rust, you can bind to see if that’s what you want to do. So there is that migration path that you can slowly carve out from C and turn it into Rust. So whenever you’re trying to adopt in this vertical, you want to make sure you have good integration with the existing previous leader of that vertical. So if we’re just placing Gamble, we got to make sure there’s a smooth migration path from Gamble to Dhall.
Adam: Yeah, there was some really old story, maybe it comes from the Crossing the Chasm book about WordPerfect and Microsoft Word. So like WordPerfect, they changed their file format at some point. And you couldn’t open one version of the file in the newer version, yes. And then So Microsoft Word made it so you could open that old version, and everybody just switched, because there was no migration path on the Corel side. But on the Microsoft side, they just stole their migration.
Gabriel Gonzalez: Yeah, that’s one thing that’s really important is that usually is more relevant to after you’ve crossed into the mainstream market is that once mainstream developers are in the process of trying to standardize your technology industry wide, you don’t want to rock the boat. You just kind of want to freeze what you have, and not make significant changes and let them do the work for you. That’s a good point, which you would like stabilize your APIs or create an RFC, for example.
Ignore the Hype Train
Adam: So if I have some open source project, I built it, and I’m interested in seeing it grow. I’m kind of the main force behind it like you are with Dhall and I only have so much time in the day, how do I decide should I be fixing some bugs that came in? Should I be evangelizing in whatever format is, should I be like on Hacker News, just telling people how awesome my product is? Should I be fixing bugs? Should I be, what do I do?
Gabriel Gonzalez: Definitely, don’t rely too much on other people getting that full product out. So one common mistake I see a lot of new open source developers make is they try to build what I call the hype train, where there’s a new project that has a lot of potential, and they advertise on Hacker News, hoping that okay, we were able to generate a lot of hype, maybe get a lot of influx of new contributors, where we contribute a lot of new features, generate more hype, and so forth. And then they hope that there’ll be that virtuous cycle that will bring them to the mainstream. In practice, that never happens. Usually, the thing about contributors is that their niches are always going to be fragmented. If you have eight new contributors, they’re going to be taking you in eight different directions. Again, if you want to get that vertical built, you focus on one direction. And sometimes that means not only doing a lot of work yourself, but it’s explicitly saying no to something trivial, saying like this is not where I want to take the product right now. We should not build this out, because this is just going to slow us down, add more maintenance, make us less flexible and agile.
Adam: So you might deny merging some pull requests, even if it adds a feature, because the feature isn’t in the direction you want to go?
Gabriel Gonzalez: An example of this was like, I think the feature I’ve had to deny the most out of any other feature for Dhall is support for templating. So first off, so already, it doesn’t help the YAML use case. Because okay, it doesn’t help. Maybe they’re not going to use it, but it doesn’t hurt. But actually, it does hurt because it’s something that you have to support.
Adam: It’s interesting, because you’re saying yeah, we want to get this viral this happening where it spreads, but you’re also saying, you’re against what sounds like promotion based growth or something?
Gabriel Gonzalez: Yes.
Adam: Is there a distinction there?
Gabriel Gonzalez: So this is why I think one of the coolest things about the book, which is that it teaches you that marketing is not just advertising or branding or evangelism. Marketing is really about prioritization and focus. And if you get that right, you actually don’t need to do a lot of advertising. So for example, if you’ve done your job well then your target adopter already wants to use you, even before they’ve done a comparative analysis of technologies. But they already thought that it should be clear to them that for a given vertical, you’re the best choice for that vertical. At that point, they’re just sort of trying to rationalize that decision. So they may write a design document saying I’m comparing X, Y and Z but they know in the back of their head, X is really the best here. That’s my gut feeling based on what my friends have told me and what I’ve read and my initial perceptions of it. And so at that point, they’re just trying to rationalize their choice of X. And marketing is about building that focus, maturity, and polish by careful prioritization so that you are there and you’ve created an X shaped hole in their head that they really need to fill.
Adam: How is this done? That sounds great. But what steps do you take to do that?
Gabriel Gonzalez: Focus and prioritization are always the key here. So again, as an open source developer, you have very limited resources. Even more than a startup, because in startup, you at least get paid somewhat like a company. Open source is totally free, volunteer only, give very little of your own time. And for people who are other contributors, you don’t know if they’re going to stop contributing tomorrow. So you have to very carefully pour your resources and pay them on pre selected things.
So for example, I’m not going to work on something, or at least I will spend little time on things that don’t get me closer to building out that polished Kubernetes use case. So like, an example of a thing that I would work on right now that would help you with today’s use case would be performance. So Dhall, there are ways we can improve performance, because doc configuration files for Kubernetes can get quite large so you want to have a very fast and snappy, gives good results.
I think marketing is really underestimated as a force amplifier for engineering. If you don’t have a very careful marketing, understanding of what is the small vertical that you’re targeting, then you’re spreading yourself very thin, because you don’t really know what you’re trying to build. Once you have that clarity of vision for what is the polished product that you’re trying to build, you get much better utilization of your engineering resources, whether you’re an open source team or a startup team. That’s why I think marketing is something that’s very important to get right when you’re a small organization in general.
Adam: Yeah, and how do you get the perspective of the customer, the adopter, in this case?
Gabriel Gonzalez: Once you advertise that you’re going for a use case, just totally commit to it, but you can always change your mind later. So I can say like, “Okay, I’m going to make Dhall the best in class with Kubernetes.” You sort of made that commitment, that personal, you stake your brand on it. Once you do that, also you get a flood of feedback, saying like, “I know, you said Dhall is good for Kubernetes. But it’s not, here’s why. Here’s what you need to fix to get to that point.” And so just that kind of committal can generate a lot more feedback, whereas if you’re playing the field, you’re not going to get that rich feedback.
GraphQL
Adam: So some random pieces of technology, I’m trying to think about, like GraphQL. So I think GraphQL is pretty cool. Their slogan says a query language for your API. The thing I found with GraphQL, is the most people have heard the term, but they don’t know what it is or they specifically misunderstand what it is and think it’s like SQL or that it’s based on-
Gabriel Gonzalez: A graph filtering.
Adam: Yeah, or a graph database.
Gabriel Gonzalez: So actually finding what GraphQL is, that was one of the use cases, that was an option back when we were trying to figure out what vertical should Dhall target, because a lot of people said Dhall would actually be an okay GraphQL, maybe a little bit verbose, but it’s very powerful, so you can use that to filter down or transform. Because Dhall’s first class code, you can push a lot of logic upstream into the server, and it’s totally safe to do because Dhall is a totally safe language to interpret.
We’d like not to go with that, if you’ve heard a lot of reasons that I mean, I think I won’t go into the reasons but I think that space still is, that’s a market that’s not mature, I think GraphQL’s okay there. But I think that the main issue with GraphQL is you still have to do a lot of work. The front end doesn’t do have to do a lot of work to use GraphQL. But on the back end, you still have to do a lot of investments, like take your existing API’s and wrap them in a way that GraphQL understands. So it’s not just like out of the box support. So I think like GraphQL needs to have, it needs to be more that needs to be built on the back end, just like automatically take advantage of GraphQL so that the back end team doesn’t need to invest any more resources to adopt GraphQL. The back end needs to be automatic. We shouldn’t need to have a person maintaining the GraphQL server.
Adam: Yeah, because like GraphQL, their slogan could be like, it’s like SQL for your back end services, except you have to build the database yourself. You have to do all this under.
Gabriel Gonzalez: It’s like it is a form of SQL, right?
Adam: Yeah, exactly. Yeah. We talked about Rust, TypeScript. So Haskell, it sounds like you would market it as for building programming language.
Gabriel Gonzalez: Yeah. Haskell has very well developed resources for doing that. Lots of great libraries like in Dhall we already have all of that. He goes, I was trying to build Dhall. Haskell is a great language for building Dhall. And it’s actually allowed me to iterate very quickly. I get tons of feature requests every week, and without Haskell, it would me much more difficult to keep up with the sheer volume of those feature requests. There are lots of great literature and documentation on how to build programming languages in Dhall. Like for example, there’s a very efficient way to write interpreters. That’s called normalization by evaluation. And I think if I just search normalization by evaluation in Haskell, I’m going to get some complete examples of compilers interpreters implemented in Haskell. I can just copy and paste or modify and use it in my project. So I have to do absolutely nothing to get fantastic results out of the language. So it’s just a whole ecosystem of supporting resources that makes it excellent.
Scala Evangelism
Adam: And Scala is an interesting one. You talked about that at Twitter. How would you sell it?
Gabriel Gonzalez: I think big data is the closest thing to the mainstream use case of Scala. That’s what Twitter used it for. And like Spark, I think is one of the common things that drive people to adopt Scala. It’s also why we use it at our own company, a lot of the big data processing we use is written in Scala. And again, it’s not necessarily because Scala is intrinsically better at data processing. It’s just that it can interact with Java. So you get Hadoop, there’s place called bindings to everything, there scalding and/or Spark. And there’s a lot of resources because Scala has staked its brand on big data, or maybe data science to a lesser extent. And so people start writing supporting documentation and resources, like how to install Spark on your machine, how to use Spark to do this simple example, like here’s a product, you can copy and paste and modify to do what you want. So I think that is all down to that fully developed whole product that gets Scala adopted for big data processing.
Adam: So if you look at the Scala website, it says Scala combines object oriented functional programming in one concise high level.
Gabriel Gonzalez: That’s a terrible [inaudible 00:56:55].
Adam: Yeah. But then whenever people mention it to me who aren’t familiar with it, it’s either Spark. They’re like, “Oh, yeah, for big data, right?” Or it’s like Akka and Actors, and both of these things I use neither of them. But they have more compelling use cases, like Spark just says something like Spark’s position is for big data. And then Akka says build distributed applications more easily. They have more cohesive statements.
Gabriel Gonzalez: Yeah, another thing that makes big data good, let’s think about the four reasons for adoption. So clear technical customer, like companies have big data teams. So there you go, the leader of that team, that is the person who has the authority to adopt, compelling reason to buy, like your data doesn’t fit on one machine anymore, you’ve maxed out RAM, you’ve maxed out NVMe drives, maxed out just still not enough, you got to use big data. And also feels like Java’s just using the level dollar big data is extremely verbos and time consuming. I wouldn’t recommend it. On product, we got Spark and all these other literature, resources and packages that you can use and lots of examples of projects. Competition, there’s not a lot out there. You’re not going to do big data in Python, maybe Rust at some point, I think Rust actually can be a great language for doing big data because of the efficiency issues that plagued JVM. It’s like it’s just missing a lot. So it’s ready to go. So it’s not there yet. You have to use Ruby, too slow. You can just go like there’s no big libraries and go, I can use Haskell. I mean, you could use Haskell, but again, the maturity is not there. So again, lack of competition makes it easy for Scala to establish itself as the leader of that market.
Adam: Yeah. And a lot of data people, data scientists, et cetera, they’re using Python. And then the Spark position explained to them, they’re like, “Oh, this is for big data.”
Gabriel Gonzalez: Yeah. I mean, so that’s the interesting thing about it would be like Scala appears to kind of penetrate the mainstream with the big data use case. I think about like, what will be the domino effect from there, because I still don’t quite see the domino effect just yet. It seems like we see maybe distributed systems. But that seems to be quite it, because it’s not really well positioned to take advantage of other things. It’s not easy to write command line tools in Scala, like, JVM won’t take this adds too much to them. And it’s just missing that viral effect just spread out, I think right now. So I think I would classify as mainstream, but it needs to do more so that it can branch out and I think it’s missing. If it doesn’t do that soon. I think at some point, it has to get into the mainstream via the compilers use case. It will spread faster than in Scala will because Haskell has a lot of advantages over Scala like one is that much lighter weight, better runtime, better currency support, better for command line tools, better interop with other languages and ecosystems. And so that’s, I think, is like, that would be the one thing that Scala should focus on is fixing those interop issues with other ecosystems so that it can go more viral and establish that horizontal that it still is missing.
Kotlin vs Scala
Adam: Yeah. And so an interesting use case, like you just made me think of this is like Kotlin. So the first time I saw it, somebody gave a presentation on it and I was like, “Oh, it’s like Scala, but it’s good.” It’s like almost exactly the same in a lot of simple use cases. But I think that it’s succeeding, like it’s taking off at a very fast pace. And the interesting thing is that I think that they targeted Android app development as a big use case.
Gabriel Gonzalez: Yes, that’s the proverbial killer app of development. So that’s actually one of the reasons, I actually want to take back what I said about Scala being mainstream because I think going back to I said before, one of the indicators of something going mainstream is when you’re officially endorsed or standardized by things. And actually, I don’t see that right now for Scala yet. You don’t see people saying, we have to have a Scala SDK for this or we have to have Scala support for Android or we have to have Scala support for various other things like those, I think would be like the key indicators I’m looking for, for mainstream adoption. So I think well, maybe Scala has gone mainstream, and perhaps some large tech companies like Twitter, I think in the broader industry, we’re still missing those industry wide sterilization processes that would herald it going horizontal.
Adam: Yeah. And then with Kotlin having targeted Android initially, that gives them a better chance you think because they’ve kind of got one domain under their belt?
Gabriel Gonzalez: Yeah, that will make it better. Again, what you’re looking for is the side going mainstream is that your users do it for you. So somebody says somebody who is not a Kotlin developer says we have to have Kotlin support for Android, like it’s not an option to go without it. That’s the key. You can always like, going back to the Haskell community, Haskell community can always keep doing the work of adding Haskell bindings to each new SDK or platform. But that’s not the indicator by mainstream. It only happens when non Haskell developers force people to use Haskell. Then you know you’ve gone mainstream.
Adam: So how will you know when Dhall is mainstream? Will that be like when Kubernetes says this is a way to configure things?
Gabriel Gonzalez: Yeah. So very simply, when Kubernetes natively supports Dhall, then that’s how I’ll know that Dhall has gone mainstream.
Adam: So I think this is super interesting. Because like yeah, I guess I’m an early adopter for a lot of things and it’s interesting to think about how you kind of get things to this mainstream place.
Gabriel Gonzalez: Yeah, I’ll recommend to the audience, if you haven’t read The Crossing the Chasm, the book, you should. If you’re doing open source technology evangelism, it’s a great way to make good use of your free time, and to hone your message. So you want to say that your technology is like an object oriented, whatever the slogan was, if it helps you better understand, it’s really great for people like me who are early adopters. It helps you figure out, well, I wish I had this book before I joined Twitter. Because before I joined Twitter, I didn’t really understand the mindset of a mainstream programmer. I didn’t want to be part of the big tech company. But if I had this book, I would have learned this before joining Twitter, what it is that makes these people tick. So if you consider yourself an early adopter and you’re trying to figure out how does the mainstream programmer think, feel, evaluate technologies, this is a great book for getting into that mindset.
Selling Functional Programming
Adam: So how would you sell Haskell now, if you were back at Twitter?
Gabriel Gonzalez: So I will just not sell it. I mean part of good marketing is specifically not chasing sales. So don’t try to sell it where it doesn’t fit. And your users will appreciate that. Because if you try to sell it for a poor fit, then that generates negative references. So don’t oversell it. Figure out what you’re good at and stick to that. It’s like a great example of this would be Go. Go doesn’t pretend to be everything. It’s like we’re just good at web services. And that maybe command line tool and that’s it. We’re not going to solve ourselves with being anything more ambitious than that.
Adam: Another one you just made me think of is functional programming. So I was on some podcast with a bunch of C sharp developers, they were asking me about functional programming. I explained it, hopefully all right. And then they said, “What’s the big use case here?” And I said like, “I don’t know, it’s great for everything. You should write code.” I don’t think that was a compelling argument for them.
Gabriel Gonzalez: Yeah, I mean, first off, fp is just poorly defined already. So yeah, I think functional programming is not really a market of its own yet, a specific use case of it may be ready.
Adam: Interesting. All right, Gabe, thanks so much for your time. This has been a lot of fun.
Gabriel Gonzalez: You’re very welcome. And thank you too.
Closing Thoughts
Adam: That was the show. Gabe’s thoughts on this topic are profoundly affecting my thinking. For one, I love to evangelize for functional programming. And as Gabe points out, that is not really a fruitful endeavor. Take a look at how Gabe is positioning Dhall. Dhall is not sold as some like active for config to maximize hipster points, but he’s actually targeting a very specific narrow use case, better Kubernetes configuration.
I think when I started programming, it was all about the cool things I could build. But slowly, certain aesthetic sensibilities have taken over, which is totally fine. But when I gush about referential transparency, I’m not really selling anybody. I’m speaking the language of an early adopter and I’m attempting to sell to a mainstream programming. So I have a certain aesthetic of programming that I think is valuable and I want people to adopt it. How should I do that? I was seriously considering going around talking to everybody about the beauty of higher kind of types. Higher kind of types are great, I think everybody should want them in their programming language. But I think it’s missing the point.
Gabe is successful at selling his Agda based language to ops people as the simplest solution for doing Kubernetes configs. Then I think myself and everyone out there who likes kind of fringe technologies that haven’t yet hit mainstream adoption, we need to learn from Gabe. What is this move that he’s doing? It’s selling a complete product for a narrow use case, and then stepping back and watching adoption take off. I mean, I don’t think he’s got there yet with Dhall but it definitely seems like he has a playbook that he understands.
When I first heard of Kotlin, I didn’t really get what people were excited about. It seemed to me like it was Scala dialect that sort of had better marketing. And some of the people who were talking to me about it were people previously who were like, Scala seems kind of complicated. But I think that maybe I understand it better now. Because when it first came out, the first things I heard about it was Kotlin was for Android development. That was kind of their beachhead. And from there it spread to other areas.
I think that Kotlin is still less popular than Scala. But I think that they maybe understand this marketing playbook that Gabe was talking about in ways that other languages are missing. Yeah, so if you are a proponent of some programming language, some open source library, some new way to do X, I think that Gabe’s rules that he adapted from Crossing the Chasm make a lot of sense. Think of a specific use case, pick one, and make sure that that onboarding process for that use case is solid, that it’s the simplest thing, people who aren’t even interested in all the coolness of the new way you thought to do X, they would still use it because it’s just the easiest way. And I forget all his other rules, but make sure there’s not already an existing leader in that space and make sure that you just focus on that use case and be behind others. Have a very clear message. I hope you enjoyed the interview. Let me know what you think.
Sticher
Overcast
Dec 02, 2024
42
min