CoRecursive: Coding Stories - Tech Talk: Tech Evangelism and Open source With Gabriel Gonzalez

Episode Date: November 1, 2019

What makes some pieces of technology take off? Why is java popular and not small talk or Haskell. Gabe is a popular blogger, a former Haskell cheerleader, and creator of the Dhal configuration language. Today we talk about marketing and tech evangelism. "One common mistake I see a lot of new open source developers make is they tried to build what I call the hype train. Where they have started a new project that has a lot of poTech Evangelism with Gabriel Gonzalez tential and they advertise on hacker news hoping that, okay, we're gonna generate a lot of hype, maybe get a lot of influx of new contributors, new contributes, new features, generate more hype and so forth." "They hope that there'll be that virtuous cycle that will get them to the mainstream in practice, that never happens. Usually, the thing about contributors is that their needs are always going to be fragmented, right? If you have eight new contributors, they're going to be taking you in eight different directions. You should focus on one direction and sometimes that means not only doing a lot of work yourself, but it's explicitly saying no to something and saying this is not where I want to take the product right now." Links: Crossing the Chasm Dhall Lang Adam's SE Radio Interview with Gabe Haskell For All - Gabe's Blog

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 influx of new contributors. In practice, that never happens. Hello, this is Adam Gordon-Bell. Join me as I learn about building software. This is Code Recursive. That was Gabriel Gonzalez. Gabe is a popular blogger, creator of the Pipes Library for Haskell. He also created DALL, which is super interesting for 10 programming language type reasons and probably, you know, just as many ops, dev ops 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 DAO. 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 finding more mainstream success than Scala? What else? And we also talked 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. Gabe, thanks so much for coming on the podcast. This is actually our second interview. So I talked to you on SE Radio about Dahl. 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 I or a listener is really keen on some library or language that's maybe a bit French. I'm hoping that today you can tell me how that I might like advocate for it. So when did you first try to advocate for technology? So this 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 about technology, evangel difficulties, and convincing other people to adopt technology. It's far harder than you think. There are a lot of things that I wish I had known back then that I know now that would have made it a lot easier. It seems like everybody who learns Haskell maybe goes into this mode. Maybe that's just my...

That's correct. What was your pitch for using Haskell? 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. Like, you know, you don't, you have type inference. You don't, it's not like heavyweight, like Java. So it's still type, but you don't have to pay the freight. It's very like good data structures.

Good for data science, for example, easy to transform things, especially in memory and stuff. Because for me, I was coming from a background of a phd student that was exactly what i needed i needed to be able to like quickly change my mind because my advisor kept changing his mind about where he wanted the project to go so i want something 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 yeah at that time i didn't really know what other people were looking for a language and how to frame it in frame it to appeal to them i was just thinking about it in terms of like what i needed out of the language so this was at twitter right no this is

like before even twitter i mean sorry okay so like this is back when i was a phd student i was already doing like blogging and trying to get people to use Haskell. But I did actually try to do evangelism when I was at Twitter to try and get them to use Haskell as well. And had you like perfected your let's use Haskell pitch by that point?

No, not at all. But so while I did not convince them to use Haskell, I learned much more about like, 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, you didn't convince them in

the end, but the things that had more of an impact with things like it's stable, low maintenance, low total cost of ownership, won't get paged on weekends or late nights for Haskell service breaking, things like that. That's what really warms their heart when they're looking, at least for the niche that Haskell occupies. Interesting.

So yeah, I can see the pager one, especially being useful. We check the stuff at compile time, so we're not going to have something blow up in production. So did those arguments resonate? about like twitter is the largest scholar company in the world right so they got a huge scholar code base the marginal improvement from switching to from scala to haskell is small enough that you can't really justify the switching costs for example and you actually find that like usually where haskell takes root is in displacing a much more terrible language than like skull is actually pretty good you know i have some comparisons of the scholar but like as far as languages go it's pretty high up there if now if you're trying to make the case this place say you know php right then i was like oh yes let's please i'll take anything else right whatever and that way just like whatever language comes up next they'll they'll be fine that is not what i would have

expected because like yeah you're like oh scala has some of these things that Haskell has. So you think it's a smaller jump to Haskell. Like the convincing should be easier, I would think. But you're saying, no, it's actually, there's just not enough difference to matter. Well, you have to think about in terms of that, what is the niche you're trying to occupy? And is that niche well served? So in this case, the niche, at least for Twitter and more generally, for both Scala and Haskell is, you know, backend web service. And Scala was already doing a pretty

good job. So you really, when you're trying to get a technology adopted, you want to target a use case that is really poorly served by like the existing set of mainstream technologies. For example, like for backend web services, like it's kind of okay to use Scala, right? There's already like, you know, a mature ecosystem there. So it's like, what's, you know, 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, which talks about how you make things appeal to mainstream programmers. And one thing you learn from that book is that, you know, mainstream programmers, they're like a herd, right? Nobody wants to be the one that sticks their neck out. So if you want them to get them to try something new and to deviate from the herd,

you need to basically make it so that they have to, right? 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. Heather, she was describing how Scala as like a bunch of penguins who like go up to the water, but they're all afraid to go in because there could be some sort of prey. And then like Twitter fell in and started using the language. And then once they did, then like other penguins weren't afraid to get in. Yes. In fact, the book actually talks about this phenomenon, which is that one of the most successful strategies for getting technology to transition from early adopters to mainstream programmers is you have to target a really narrow mainstream use case. Because the thing about early adopters and mainstream programmers is that they don't

really overlap, right? So like early adopters do not make good references for mainstream programmers. I described the example, you know, trying to convince a 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, right? About revolutionary changes that will transform things. Mainstream programmers are not, right? You know, they're evolutionary and they just have a different set of values.

And so that makes it hard, right? Because you actually like, you know, a lot of new technologies kind of get stuck in the early adopter phase. Haskell is the perfect example of that because they haven't really penetrated the mainstream market. But 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 case and then grow from there. 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, right? So like picking a specific area seems like a strange choice. It seems like narrowing your possible audience, right? 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 where people say like, what do I use Haskell for? And Haskell programmers will say, it's a general purpose programming language. You can use it for anything, right? 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, right? They want to adopt something that is a fully featured product. So, for example, like Java, right? 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 that's already been worked out by this point. Compared with Haskell, people are a little bit scared because they think, you know, am I going to have to do a little bit of extra work to get this going? And it may depend. 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 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 and actually become a general transformational platform. So you mentioned crossing the chasm. I know this book mainly just from this like diagram. It's like a bell curve. And then it has like the very left,

most part of the bell curve is like says early adopters. And then like the middle is like mainstream. And then I don't know, there's some third part, but like, 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? So the thing about mainstream programmers, and 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 like the standard way of doing things because they really love standardization so like a perfect example would be like you know you got this big tech company you know they're considering whether or not to use let's say go right and like once they're convinced but to use go then it's in their best interest to get the whole company just to just like let's we're going to make the switch everybody's going to be using go right they don't want fragmentation they just want one approved mainstream standard 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, making officially support integrations. You asked about Rust specifically. I would say Rust is already penetrating the mainstream. A good example of this would be when Amazon, I think Amazon like added official Rust support to one of their SDKs.

I forgot. Maybe it was like for the Lambdas or something like that. So when you see like big tech companies offering official support for your language, that's how you know you're mainstream. Again, those are the mainstream programmers trying to standardize on your platform. Like you won't

see that in Haskell. Like Haskell, we always have every time a new platform comes out, the Haskell community has to like do the third party bindings to whatever that platform or SDKs because they don't have the support of the mainstream programmers to do it for them. Oh, yeah. Like even silly things like the whatever Gmail API,

it might have code examples for Go and Rust and Java and Python, but Haskell's not there. Yes. So mainstream programmers, they like there to be order. They hate chaos. They 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 the newcomers. There's always like for any new market or

application, there's always like this weird point where like it's not really well defined, like what the market even is, right? 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 we're way better than all the other alternatives and once you convince them 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 like, whether that means like 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. That's interesting and i assume like 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 yeah i mean that would describe the early adopters, right? So that is exactly

the personality of early adopters, which is that like, they see the potential, right? But they're not loyal to technology. They just want to, and that's actually

one of the reasons why mainstream programmers really don't like early adopters because like mainstream programmers like are very loyal by nature. They're the ones

that are entrusted with like committing, maintaining systems long term, you know, building a career for a specific vertical. Earlyters are not like they're just moving kind of like locusts from one technology to the next looking for the next revolutionary advantage that i mean i'm sure early adopters like either but they do in a positive way but like that's the way that

mainstream point of view early adopters it's like they're just they don't have any long-term loyalties or careers so they can't be. They're not dependable in any way. That's funny. Yeah. I mean, early adopters, going back to that diagram, the bell curve, early adopters do play a important part in that lifecycle, right? They prove that the technology can be used for a use case, right? It's not like paperware, right?

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 not only provide the proof of value, but they can also help provide resources. One thing that's important to keep in mind is the book was actually written for startups. The book was not an open source technology evangelism handbook, but rather a startup handbook. But a lot of the advice from that book is actually useful for open source tech evangelism too. And specifically for startups,

early adopters can provide initial source of like seed funding. Like there's sort of like a hidden source of venture capital to use the book's own words. So they can keep a technology going, at least to be able to develop the product until it can finally have enough resources to build out that polished mainstream use case. But at some point you have to wean yourself off of early adopters and make build out that polished mainstream use case.

But at some point, you have to wean yourself off of early adopters and make that jump to the mainstream use case. So I read the book like so, so long ago, and I never had this perspective on tech evangelism, but it's called Crossing the Chasm because like nobody makes it across, I guess. 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, right? You see like, okay, Adopter 1 is using it for this use case. Adopter 2 is using it for this use case. Adopter 3 is using it for this other use case. And the book says, you don't want to play the field. You've got to pick one use case and really focus on it.

Otherwise, you're not going to have the resources to build out that polished like i said 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. Let's posit examples around this to maybe make a bit more sense. So like, I don't know a ton about Rust, but I've done a couple interviews. And I think that Jim Blandy, when I talked to him is 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 complex and here's something better is that what you're talking about is that like a beachhead is that a specific use case 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 right like we're getting a growing number of cVEs 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 user. They don't want to use Java. They want to do low-level stuff, maybe embedded programming or high-performance programming or low latency. Maybe they don't want GC pods for their server. So that's the compelling reason to buy. You're drowning in segmentation faults and other 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++, right? 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 it would be 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. And now they don't say anything like a better C++. What they say is that 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, right?

So they're like narrowing in. I would actually say that's still not narrow enough. Honestly. I mean, I think that, like I said, I think by this point they've kind of already crossed. So I wouldn't be too concerned about them. But like, if you were still, if you were still not mainstream yet,

you would not want to have that tagline. It's like, oh, we're a mobile assembly or I forgot what the other things you said. Or like maybe for command line tools, like that's not what you want to do, right? You just want to have that tagline. It's like, oh, we're a mobile assembly, or I forgot what the other things you said. Or like maybe for command line tools, like that's not what you want to do, right? You just want to pick one, make sure that's really polished. And generally you just,

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 when advertising technology. Like example, like let's say, going back to Haskell, right? So Haskell says like, you know, maybe it's great for data science.'s like well is it is it like how good are the plotting and charting

libraries right it's like maybe it's good in some ways right but there's still deficiencies in other ways right so you don't really want to sell it for say data science unless you've really thought through all the use cases like okay like some data sciences can data science overlaps a little bit with machine learning or statistics like how good is the statistics or machine learning libraries does haskell have good bindings 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 because like once you really get into a vertical you realize wow i have a lot to do before this is really ready to go yeah so like

i'm sure i've told this story before but years ago i was learning haskell trying to introduce it my work and so i built some web services and uh then i had to like pull data from this other service that used like 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 right it's like so then you're stopped in your tracks right i guess the early adopter move is like building your whole home soap parsing library yeah exactly so the early adopter would be totally fine creating a soap binding if they had to. A mainstream adopter,

when if they hit something like that, there would be a negative reference for Haskell. Say like they would be telling other mainstream 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. 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. The early adopter will not necessarily help build it out. So early adopters are project oriented, right? They will often want like customizations for their specific transformational project because like they have a, or 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 and try 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 into a staffing vertical. You really just have to kind of like hoard resources and then focus them all yourself without the help of early adopters into a stabbing vertical you really just have to kind of like hoard resources and then focus them all yourself without the help of early adopters into getting that one vertical totally polished 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 yes the author of classic

has i'm using the analogy of a bowling pin which is that once you knock down 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 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. Maybe they have to do stuff and make... They work at a company, a large company, that company has CI, right? So they're going to ask their company, okay, we need to use Rust. We have to. And we need CI

support because the whole company standardizes on CI. So they're going to ask their company, you have to add Rust support to CI. And all of a sudden, the CI people start using Rust and they'll be like, oh, hey, Rust is actually pretty good. Maybe we can start replacing some of our CI services in Rust. And 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. So then they go to Ops and say, okay, we need you to add Rust support for building Docker images or what have you, right? And then the ops will try it out and be like, oh, hey, like this is Rust. Maybe we should start using Rust for our use case too. And that's how it spreads

once you have that one mainstream use case. 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? 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 where Haskell is very polished. And so it's compilers or programming

language implementations or interpreters. And that was actually what got Haskell into our company is that we really needed to build, it was a very specific language we need to build in our product that users could like explore the high level insights. We're a network security company. We want users to be able to explore the insights we collect. And so we needed a programming language for that use case. And so Haskell was the best in class compiler's language. So that's the initial mainstream use case. Right, and then once we adopted it for that use case, all of a sudden, like other people in the company

started using like old, new web services, and you know, for the company, why don't we use Haskell for that too? In fact, it's actually better, because then we can share code in the programming language, right? We don't need to call out as like a sub-process or a service, right? You know, it's just a library dependency that's very good right that reduces the possible

points of failure and then we need ci support for haskell and so that's how it's spread in at least inside our company same thing like i keep most other stories i hear in industry of haskell getting taking root at bigger companies is typically in the programming language route 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. Well, I mean, it's not just enough to have 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, which is not enough to have the killer use case.

You need to have a clearly identified buyer, so somebody in the company who has either economic or technical authority to adopt. I'll give a counterexample. So once I asked somebody in my own company, like, what do you think is the reason to adopt Haskell? And he said, like, I think it's concurrency. But you think about it,

like there is no director of concurrency at Facebook. They might have a data science division or privacy and safety division, but currency is not the way that companies think about things. There is no clear person

in the company who can adopt the technology. Whereas, if you say compilers or programming language theory, there is usually like there's a compilers team at various companies. That gives you like the clear person that you target and sell to and then who has authority

to introduce language into your company. Another example would be like ops. That's another clear vertical you can target within a company. Oh, that's interesting. Because like memory safety for like Rust, like that's not a person who's in charge of memory safety.

But like embedded is probably a team. Yes, so you might have like a chip design team or a firmware team within a company and they would be the technical buyers of the open source technology. What were the three things? Well, there's four of them, right? So 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 uh newcomers 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 you want to be that first one so that you can then have very good then you can have the staying power against

competitors and if there is a leader in an area then do you focus in even more like no you just find another use case just give up on that area yeah i mean you focus in even more? 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 is the defender. Again, mainstream programmers just want to standardize the... I mean, the only way you'll really surpass the existing technology is if they

really mess things up. They just release... It will be like the Angular 2 I don't know if they have 3 Angular had this like really breaking release at some point

right that really pissed people off and like that would have been a good opportunity for like one of their competitors to then like leapfrog ahead of them

to be like the new best in class for whatever it was that Angular does I'm not too familiar with the frontend ecosystem but yeah I think

that's what React did basically to my vague understanding, knowing nothing of JavaScript frameworks. Exactly. So if the leader makes a huge misstep like that, then there's an opportunity. But assuming that they just sort of play it safe,

keep incrementally improving, and don't rock the boat, they'll probably just continue to remain the leader for a very long time. One I was thinking about is TypeScript. So I looked it up. TypeScript's 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? First off, that's a very good slogan. And 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 book talks about is how you position your product. So position is how basically it's like when customers try to adopt your product, or at least they're 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, like 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?

And that's called the product positioning. So usually you have like a second thing. So usually, actually, there's a slight way we can improve upon our slogan by instead of saying it's scale, saying like specifically compare it to an analogous technology. But even just saying it's scale is already pretty good. So you're saying like, this is what we're doing better. It's like we can do this at scale, whereas previously we couldn't before.

So what would we compare it to? What's your improvement? Let's hear the new slogan. 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 type in it's not just like it does types but you can do like type inference and stuff like that so normally i might

say like this i still think it's not good, but like maybe like, you know, it's like the Haskell for JavaScript, right? 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's like a really good one. Like an example of a bad one to use as a comparison

would be it's like Elm, but for JavaScript. And that's a really bad one because Elm is competing for that exact same market. So you don't want to use them as the product positioning. Preferably it'd be some language with type inference that's not competing for the JavaScript market. It's interesting because I think that people who were probably early adopters for TypeScript,

they were people, I'm just guessing, who didn't like JavaScript that much, right? Who didn't like that it didn't have strong static type guarantees. That's probably the people who were the early adopters, right? 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 would be like, no, why is it better? JavaScript is great. You're just making me add some type annotations. 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 like the people who are struggling under that issue have a very compelling reason to adopt, to deviate from the herd

because they have a good excuse to do so. But if you just says like, it's just a prettier JavaScript or a more elegant JavaScript, right? That's not the compelling reason to adopt. So we have a reason, a buyer, a customer, a leader. 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. Like it's okay to have competition as long as they haven't really gotten that strong foothold. But once one particular technology gets like 50% or more market share,

then it's staying. Yeah. Because the mainstream programmers, once they've learned something, then you know, that's the tool they'll use. Yes. They don't want to change.

They're very reluctant to change. So when I previously talked to you, it was about DAW. Oh, actually, we didn't talk about Nix. I don't know if we want to talk about that. Yeah, Nix is actually a very interesting use case. Okay. So Nix is still a technology

I would consider not mainstream yet. I think most people would associate Nix with early adopters at this point, or they may not even know what Nix is, for example. So what is Nix? So Nix is a package manager, but even that's not a really good description. Nix is actually doing a lot of things, which again, is kind of like a danger area. So it's a package manager, but there's also NixOS, which is an operating system.

There's also Nix packages, which is like a monorepo of packages. There's NixOps, 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, right? And so it's already hard to even just answer the question, what is next? It's 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, right? If you're trying to mix two things and get them to react, you want them to be at very high density and concentration, right? So if your message is diluted, it's infragmented,

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 NixOS, which is the operating system. It's essentially an operating system 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 boot parameters, I can patch the kernel, what version of system D I'm running, I can define

services, everything. It's just like a well-orchestrated whole. And it's immutable, so it supports rollbacks. It's declarative. It's fantastic for ops or DevOps in particular, but even just ops. If Nix ever goes mainstream, I think NixOS will be the key use case that we'll get in mainstream, but it still needs to be polished more before it does so.

Their slogan should be like, your OS in code or something like that. Yes, there's a name. It's really good for GitOps, which is like, you know, very control-based ops. And because, yeah, like everything is declarative.

And not only that, everything is source-based. I guess the closest thing in this area would be like Docker Ansible. All those other technologies, like a lot of your dependencies are binary dependencies, right? So if there's something wrong with them,

you can't really fix them, right? It's like, okay, I got to hopefully release a patched version or something like that. But otherwise, you have very little control over fixing things. Whereas in Nix, like everything is fully specified down to, you can patch every single thing that you depend on, not just in the system, but like 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 bill. It is Docker built by Gen2 developers. Yeah, exactly. That's a really good, that's actually a really good slogan, by the way. It's like Gen2 but for Docker, right? So like Docker is the market positioning.

Gen2 is the product positioning, right? So that's a very good adoption slogan. Yeah. So do you need like the overlap of people who are Gentoo people and interested in Docker? You don't need them to overlap. The key thing about the product positioning is like the Docker user,

who's considering using NixOS, doesn't really need to actually use Gentoo. They just need to understand that like Gentoo is a mainstream thing that was transformational in some way that I understand. Then VIX OS is going to be transformational in that same way and like the problem that Gentoo solves is the same problem I'm having right now with Docker yeah I can see that right there are businesses where they have very specific builds of their OSs that they use you know 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, like Docker is great, but it just says from X and it pulls in this image. I don't know what's in that. And then it adds things on top. Yes. So I think the reason I brought this up is because you had some experience like evangelizing for Nix.

Yes. So in our company, like the main issue we had was lack of reproducible builds and lack of support for rollbacks. So for example, I think the one case that really sticks out in my mind is early on in our company's history,

we were about to assemble our first end-to-end 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 like what we did is like before the demo, we did, we just deployed it. We said, okay, And it was a mix of Docker and Ansible at the time. And it just totally crapped the bed.

Because what we did is before the demo, we just deployed it. We said, okay, it seems to be working. There was some issues, but it was fine. We said, okay, now we're just going to deploy it again. It should be item-coded. So just to verify that it just works. Turns out it was not. So we just redeployed it.

No changes. All of a sudden, brick to the system. And 30 minutes before the demo, we're all scrambling to get it working again. And so like that was the compelling reason to adopt something new is that like we could not get reproducible and again, lack of rollbacks, right? So like brick the system,

we could not roll back to the last working version. So these are like the key things you were 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's support for immutable deployments, rollbacks is perfect. Nothing to change, no new investment necessary. I was the economic buyer. I was responsible at the time. I was the economic buyer because I was responsible at the time. I was tasked with fixing the system to get it working.

Eventually, my effort formed a team, which is sort of like our DevOps team within our company. That's the vertical, DevOps. The lead of the DevOps team is the technical. DevOps is technically not a team. A lot of people listening to this will say, DevOps is a culture of mixing dev and ops.

But so technically, we're actually a systems and shared infrastructure team, not a DevOps team. But anyway, our team is the vertical that has the authority to adopt 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, you know, Ansible, Docker, Chef, Puppet, whatever, they're all totally bad in this regard nobody has like taken the clear leadership on fixing this problem right and nix totally nailed it so those are like those all those stars lined up for nix at least to be adopted within our company yeah because you could be like i can upgrade the kernel version and then just roll it back if it doesn't work the little things happen all the time in our company where we've just like tried really random changes to our system and we break the system and then just roll it back if it doesn't work. The little things happen all the time in our company where we've just like 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 like best of breed technologies long before they would probably be safe to use for other platforms. That's interesting. And then the topic that originally got us here was a doll, which I feel like I should spell like D-H-A-L-L. Yeah. That's why the doll 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.

To me, this is like the interesting use case that shows how you've taken these ideas of tech evangelism as you've like butted your head against pushing various pieces of technology. So like if I were to describe Dahl, 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 Dahl to people?

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 for the same issue with TypeScript, which is that it does a good job of describing what the market is, which is YAML, right? That's what we're trying to displace. If you use YAML, we're talking to you. Non-repetitive is like, that's the product positioning, right? So it's like, that's the problem we're trying to solve.

It'd be much nicer if there were like a mainstream technology we could compare to that we could explain what are the features that Dull offers. What makes it difficult is that there isn't another mainstream total functional programming language like Dull. So that's what makes the positioning a little bit more difficult. So we settled for something that was simple, clear, and something that is totally mature and polished. It's not hard to do for Dull. It's something that everything can, that is totally mature and polished. Like it's, it's not hard to do right for dull, but it's something that everything else does

really badly, right? All the other attempts to fix this problem have been very poor. A lot of people like, apart from like people doing like Jinja templates, YAML or Helm or Kubernetes. So why YAML? It's a configuration format. Yes. So it could replace XML or INI files or et cetera, but you focus in on YAML.

Yeah. Part of the reason why is because one, we just want to narrow the use case, right? It's easier to just displace YAML than try and displace, you know, four other different configuration languages. Second reason why is we actually don't, we actually target a narrower market than YAML. In fact, we're going to be calling that out more prominently soon. The narrow market is ops related in YAML. So like Docker Compose, Kubernetes, I mean, also not YAML, but JSON also supported, CloudFormation, 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 the company. And three, if we're not displacing all YAML,

we're just displacing ops related YAML, then that's much less work for us to do to develop a polished product. But actually we can narrow it down even further. And so like the one specific ops use case that we're really digging into right now is Kubernetes. So like, so Kubernetes is the market. And then if I were to give the slogan of DOL, it would be kind of like, it's like Agda, but for Kubernetes. If Agda were a mainstream technology, which it's not. A lot of people don't appreciate how similar DOL is to Agda. So yeah, Kubernetes is the market that we're trying to prove 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 Ksonet, Helm, all of them have just fallen flat, and people are looking for a much better solution to this problem. And Dall is already kind of starting to go viral in the Kubernetes community for exactly this reason. And one of the things we're working on is just developing that whole product so there's no question that DALL is the best solution.

So right now DALL is okay. You can use DALL to generate YAML. Kubernetes understands YAML so you can read it in. But you could actually polish it more. So what if DALL had Go bindings, which it will soon, then you could actually just have the QB control command read DOL files natively without having to go through an AML intermediate, for example. Or like what if DOL had a repository of Helm-like charts? And then that would be another reason. It's like, again, like mainstream

programmer doesn't want to write all those charts themselves, right? So they're not going to DOL unless that large repository of charts is already present there for them. So like those are the things that you really need to use to build out that fully developed use case. And then once we can get adoption from the Kubernetes community,

it'll slowly branch out because like 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 CloudFormation configuration

or my Terraform configuration. And so they'll say, okay, so now I want to get those into DAW too so they can all share the same code or configuration in this case and all be in sync with each other. And so that's how DOL spreads from one ops technology to another ops technology. And then all of a sudden, they say, well, it's not just ops things. There's going to be lots of services that need program configuration.

And it'd be nice if those services could just read shared values that were shared with the deployment via DAW, right? So all of a sudden, your people are going to want to have services reading in DAW 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. Like at some point you have DAW, it's better configuration.

And then at some point it's like DAW, it's better than YAML. And now you're like, DAW, it's how you configure Kubernetes. So how did you find this niche? So usually when you're first starting out, you have 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, right?

Some people were adopting Dahl for entirely different use cases. I think the reason we focused in on Kubernetes was just because, one, there's a very clear void in the market. Kubernetes, well, out of all the ops-related ones, Kubernetes has the largest and most sprawling invigoration, so the largest compelling

reason to buy. Two, there was a void there. Again, like you said, there were several challengers that stepped up, Ksonet, Helm. They tried and failed, so there's still a void that are Again, like you said, there were several challengers that stepped up. Case on that helm, they tried and failed. So there's still a void that are 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 unmaintainable. 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 the complete whole product. And 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

had already created adult Kubernetes that auto-generates 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 CloudFormation, there's more work we need to do to flesh out the entire whole product. Whereas if we went for Terraform or CloudFormation, there's more work we have to put in before we have the fully developed experience. What's a complete whole product? 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 like, there'll always be a migration cost,

like you have to translate things. But even that we've actually kind of made easier too. So for example, there's a YAML to DAW, where if you just give it the expected type, it'll auto-convert your YAML files to DALT configuration files. So even that is kind of a very low migration path. And it's also

not just like their surrounding tooling, like how easy is it to install the DALT tools, static Linux executables, various packages, how easy is it to train people? All those details are part of the whole product. 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. It's interesting because TypeScript that we were talking about earlier, like 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. Yeah, like going back to Rust, which is one of the examples,

like Rust, you can bind to C if that's what you want to do, right? So there is that migration path that you can slowly carve out stuff from C and turn it into Rust. So whenever you're trying to adopt a missing vertical, you want to make sure you have good integration with the existing previous leader of that vertical.

So like if we're displacing YAML, we got to make sure there's a smooth migration path from YAML to DAW. Yeah, there was some really old story. Maybe it comes from that crossing the Chasm book about WordPerfect and Microsoft Word. So like WordPerfect, they changed their file format at some point.

And like you couldn't open one version of the file in like 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. version of the file in like 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.

Yeah, that's one thing that's really important is that like that actually 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, right? 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 in which you would like to stabilize your APIs or create an RFC, for example. So if I have some open source project, I built it and I'm interested in seeing it grow, and I'm kind of the main force behind it, like you are with Dahl.

I only have so much time in the day. How do I decide, should I be fixing some bug that came in? Should I be evangelizing in whatever format it is? Should I be on Hacker News, just telling people how awesome my product is? Should I be fixing bugs? Should I be, what do I do? Definitely don't rely too much on other people

getting that whole product out. So like 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're starting a new project that has a lot of potential. And they advertise on Hacker News hoping that, okay, we're going to generate a lot of hype, maybe get a lot of influx of new contributors. Those new contributors will add new features, generate more hype, and so forth. And then they hope that there will be that virtuous cycle that will get them to the mainstream.

In practice, that never happens. Usually, the thing about contributors is that their needs are always going to be fragmented, right? 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 need to focus on one direction. And sometimes that means not only doing a lot of work yourself, but explicitly saying no to some contributors 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. So you might deny, you know, merging some pull requests, even if it adds a feature because the feature isn't in the direction you want to go? An example of this was like, I think the feature I've had to deny the most out of any other feature for Dull is support for templating. So first off, so already it doesn't help the YAML use case, right? But you can say, okay, it doesn't help. Maybe they're not going to use it, but it doesn't hurt, right? But actually it does hurt because it's something that we have to support, Right. It's interesting because you're saying,

yeah, we want to get this viral mishappening where it spreads, but you're also saying like you're against what sounds like promotion based growth or something. Yes. Is there a distinction there? 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. Like 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, right? They've already thought to use you even before they've done a comparative analysis of technologies right they've already thought to like 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 like trying to rationalize that decision right so they may write a design document saying i'm comparing x y and z right but they know in the back of their head x is really the best here like that's my gut feeling based on what all 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. How is this done? Like, that sounds great, but I don't, what steps do you take to do that? Focus and prioritization are always the key here. So like, again, like as an open source developer, you have very limited resources, right?

Even more than a startup, right? Because a startup, you at least get paid somewhat, as well as a tech company, right? Open source is totally free volunteer only you're very little of your own time and for people who are other contributors like you don't know if they're going to start stop contributing tomorrow so you have to very carefully pour your resources and pay them on very selected things so for example like i'm not going to work on something or at least i'm going to spend very little time on things that don't get me closer to

building out that polished kubernetes use case So an example of a thing that I would work on right now that would help Kubernetes use case would be performance. So DAW, there are ways we can improve its performance because DAW configuration files for Kubernetes can get quite large. So you want to have a very fast interpreter so it's snappy and gives good results. I think marketing is really underestimated as a force amplifier for engineering. Because if you don't have a very careful marketing understanding of what is the small vertical that you're targeting, then you end up 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. Yeah. And how do you get the perspective of the customer, the adopter in this case? Once you advertise that you're going for a use case, just tentatively commit to it. You can always change your mind later.

So I can say like, okay, I'm going to make Dahl the best in class for Kubernetes. And then you sort of like made that commitment, that personal, you stake your brand on it. Once you do that, all of a sudden you're going to get a flood of feedback saying like, I know you said Dall 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 tentative committal can generate a lot more feedback. Whereas if you're playing the field, you're not going to get that rich feedback. 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 that 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 like filtering. Yeah, or a graph database. So actually, the funny thing about GraphQL is that was one of the use cases

that was an option back when we were trying to figure out what vertical should Dull target. Because a lot of people said like, Dull would actually be an okay GraphQL, maybe a little bit verbose, right? But it's very powerful, right? So you can use that to filter down or transform basically just like because doll's first class code you can push a lot of logic upstream into the server and it's totally safe to do because doll is you know um is a totally safe language to interpret we decided

not to go with that because for a lot of reasons which is that i mean i think i won't go into the reasons but like i think that space still is that's a market that's not mature. I think GraphQL is okay there, but I think the main issue with GraphQL is you still have to do a lot of work, right? You know, it's like the front end doesn't have to do a lot of work to use GraphQL. But on the back end, you still have to do a lot of investment to take your existing APIs 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 like, there needs to be more that needs to be built on the backend

to just like automatically take advantage of GraphQL so that the backend team doesn't need to invest any more resources to adopt GraphQL. It means like the backend needs to be automatic. We shouldn't need to have a person maintaining the GraphQL server. Yeah, because it's like GraphQL, their slogan could be like,

it's like SQL for your backend services except you have to build the database yourself. You have to do all this. It is a format. Why don't I just use SQL? Right? Yeah, exactly. Yeah, we talked about Rust, TypeScript. So Haskell, it sounds like you would

market it as for building programming languages. Yes. Yeah, Haskell has very well-developed resources and ecosystem for doing that. Lots of great libraries. Like, I mean, Dull is a perfect example of that, right? I was trying to build Dull. Haskell is a great language for building Dull.

And because that's actually allowed Dull to iterate very quickly. Like, I get tons of feature requests every week. And without Haskell, it would be 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 DAW. For example, there's a very efficient way to write interpreters. It's called normalization by evaluation. And if I just search normalization by evaluation in Haskell, I'm going to get some complete examples of compilers and interpreters implemented in Pascal. I can just like copy and paste

or modify and reuse in my project. So like I have to do absolutely nothing to get fantastic results out of the language. So it's just that whole ecosystem of supporting resources that makes it excellent. And then Scala is an interesting one. You talked about that at Twitter. How would you sell it?

I think big data is the closest thing to the mainstream use case of Adopt 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 just like, it's not necessarily because Scala is intrinsically better data processing. It's just that there's like, it can interact with Java. So you get Hadoop, there's probably Scala bindings to everything, there's Scalding and there's Spark

and there's a lot of resources because like Scala has like 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 project you can copy and paste and modify to do what you want.

So I think that it's all down to that fully developed whole product that gets Scala adopted for big data processing. So if you look at the Scala website, it says Scala combines object-oriented and functional programming in one concise high-level language. Yeah, that's already a terrible slogan, right?

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 ACA 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 like for big data. And then ACA says, build distributed applications more easily. Like they have more cohesive statements. Another thing that makes big data good, let's think about the four, you know,

reasons for adoption. So clear technical customer, right? Companies have big data teams. So like, there you go. The leader of that team, that's the person who has the authority to adopt compelling reasons to buy.

Like your data doesn't fit on one machine anymore, right? You've maxed out Ram, you maxed out MVME drives, maxed out disks. Still not enough, right? You got to use big data.

And also because Java is just like, just using low-level Java to do big data is extremely verbose and time-consuming. Yeah, I just, I wouldn't recommend it. Old product, right? We've got Spark and all these other literature resources and packages that you can use and lots of example projects.

Competition, right? There's not a lot of out there, right? You're not a lot out there, right? You're not going to do big data in Python. Maybe Rust at some point. I think Rust would actually be a great language for doing big data because it solves a lot of the efficiency issues that plague JVM.

It's just missing a lot. It's ready to go, so it's just not there yet. You're not going to use Ruby, which is slow. You're not going to use Go. There's not a lot of big data libraries in Go. You're not going to use Haskell.

I mean, you could use Haskellkell but like again the maturity is not there so again lack of competition makes it easy for skull to establish itself as the leader of that market yeah and a lot of like data people data scientists etc right they're using python and then the spark position explains to them they're like oh this is for big data yeah i mean so that's the interesting thing about would be like Scala appears to kind of penetrate the mainstream with the big data use case. And I think about like, what will be the domino effect from there? Because I

still don't quite see the domino effect just yet. Like it's like you see maybe distributed systems and that seems to be quite it. Like, because it's not really well positioned to take advantage of other things, right? Like it's not easy to write command line tools in Scala. Like, you know, JVM runtime just adds too much to them and it's just missing that that viral effect to spread out I think right now so I think I would classify it 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 if Haskell gets into the mainstream via the compiler's use case it will spread faster than 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 it was like, that would be the one thing that Scala should focus on is like fixing those interop issues with other ecosystems so that it can grow more viral and establish that horizontal that it still is missing. 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. I was like, oh, it's like Scala, but less good. It's like almost exactly the same in a lot of simple use cases. Right. But I think that it's succeeding. Like it's taking off at like a very fast pace. And the interesting thing is that I think that they targeted like Android app development as like a big use case. Yes, that's the proverbial killer app of development. So that's actually one of the reasons.

Actually, I want to take back what I said about Scala going mainstream because I think going back to what I said before, one of the indicators actually i want to take back what i said about scholar going mainstream because i think though going back to what i said before one of the indicators of something going mainstream is when you are officially like endorsed or standardized by things and actually i don't see that right now for scholar yet you don't see like people saying like we have to have a scholar sdk for this or like we have to have skull support for android or we have to have skull support for you know various other things like those are, I think, would be the key indicators I would be looking for for mainstream adoption. So I think while maybe Skull has gone mainstream

in perhaps some large tech companies like Twitter, I think in the broader industry, we're still missing those industry-wide standardization processes that would herald it going horizontal. 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? Yeah, that'll 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?

Yeah, they'll make it better. Again, what you're looking for is, the sign of going mainstream is that your users do it for you, right? So somebody who is not a Kotlin developer says, like, we have to have Kotlin support for Android. Like, it's not an option to go without it. That's the key. It's like going back to the hassle community right the hassle community can always

keep like doing the work of adding haskell bindings to each new sdk or platform right but that's not the indicator of my mainstream right it only happens when non-haskell developers are force people to use haskell then you know you've gone mainstream so how will you know when doll is mainstream will that be like when kubernetes says this is a way to configure things? Yeah, so very simply, when Kubernetes natively supports DAW, then that's how I'll know that DAW has gone mainstream. So I think this is super interesting

because I guess I'm an early adopter for a lot of things. Me too. It's interesting to think about how you kind of get things to this mainstream place. 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 and evangelism is a great way to make good use of your free time and to hone your message. So you won't say that your technology is like what an object oriented, whatever it was,

that's the slogan was. It's also because it helps you better understand what, like, especially it's really great for people like me who are early adopters, right? It helps you better understand what like especially it's really great for people like me who are early adopters right it helps you like for me 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 did once i worked at a big tech company right but if i had this book i would have learned this before joining twitter what is that makes these people tick so if you if you consider yourself an early adopter and you're trying to figure out how does a mainstream programmer think, feel, evaluate technology, this is a great book for getting into that mindset.

So how would you sell Haskell now if you were back at Twitter? So I would just not sell it. And then part of good marketing is specifically not chasing sales. So don't try to sell it where it doesn't fit. And your users won't appreciate that. Because if you try to sell it for a poor fit, then that generates negative references. So don't oversell it. Just figure out what you're good at and stick to that.

It's like a great example of this would be Go, right? Go doesn't pretend to be everything, right? It's like, we're just good at web services and that may be command line tools and that's it, right? We're not going to sell ourselves as being anything more ambitious than that. Another one you just made me think of is functional programming, right?

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 like, what's the big use case here? And I said like, I don't know, it's great for everything, right, just how you should write code. I don't think that was a compelling argument for them. Yeah, I mean, first off, functional programming is just poorly defined already.

So yeah, I think functional programming is not really ready as a market of its own yet, but specific use cases of it may be ready. Interesting. All right, Gabe, thanks so much for your time. This has been a lot of fun. Yeah, you're very welcome. Thank you too. 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 Dahl. Dahl is not sold as some like Agnefer 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 you know, 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 programmer. 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, right? I was seriously considering going around talking to everybody about the beauty of higher kind of

types. Higher kind of types are, and I think everybody should want them in their programming language, but I think it's missing the point. If 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, right? 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 Dahl, 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, ah, 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. And that was kind of their beachhead. And from there, it spread to other areas. I think that Kotlin is still less popular than Scalab, 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, right? 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 leave behind others. Have a very clear message.

I hope you enjoyed the interview. Let me know what you think.