Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#80 - Vedang
26 Plays2 years ago
We have another awesome Clojurian Vedang from Incredible India, we talk about Indian food, culture and working at one of the first Clojure startups in India Helpshift.
Recommended
Transcript
Introduction to Episode 80 and Cultural Journey
00:00:15
Speaker
Welcome to Deaf and episode number 80 I guess. We are at 80 and we are going east again in this episode and you know going to my home country as I say motherland and Netherlands is my fatherland now. It's where your nudges are, isn't it?
00:00:38
Speaker
Yes, my nethers are in the Netherlands now. I can't move it anymore. Literally, my ass is in the Netherlands now. Anyway, welcome to Deafen, episode number 80. This is me, an Indian guy in the Netherlands, and we have all the way from Belgium.
00:01:00
Speaker
Yeah, well, you know, I think, uh, the deaf end is an octogenarian, so am I. So, you know, let's carry on.
Vedank on Indian Culture and Food
00:01:08
Speaker
And then we have our special guest, um, joining us at an ungodly hour from, uh, amazing country, the incredible India. Vedank, welcome to the episode. Hello, hello, hello guys.
00:01:23
Speaker
Hi there. So let's get started. Let's get, get a deep dive into, into Indian culture. And before, I think last time we did one Indian episode, if you can call it. So we started with asking like, what is your favorite dish and favorite dessert and all that stuff. So I think we should start with food obviously, right? Because India, you know, food, better food than Netherlands, obviously, you know.
00:01:46
Speaker
Maybe even Belgium. All the things I prepared to talk about, this was not one of them. I mean, yeah, I can talk about food for sure, but it's not like some smart answer.
00:02:01
Speaker
There's a sweet called ukritche modak, which I just had recently, which is quite good. It's a very puneri sweet coconut-based filling, which is absolutely delicious. And I think anyone who comes to India should definitely come to Maharashtra to try that out.
Meaning of Vedank's Name and Cultural Links
00:02:20
Speaker
You should explain the words, right? Because you're assuming that people know what puneri means.
00:02:25
Speaker
What is Pune? Pune is the city that I live in, that I've grown up in. In India, any part of India you go, the food is going to be drastically different. The range is just incredible. I am from the state of Maharashtra and the cuisine is Marathi here.
00:02:51
Speaker
And the dish that I named, which is Ukuriche Modak, basically a very bad bastardized translation would be steamed Momos, which they are not. But that would be like a close comparison. They are a sweet and they're had at specific festivals. They are supposed to be Ganesha's favorite dish. So Lord Ganesha, Ganpati.
00:03:17
Speaker
And that's basically the event when they are made most often. So there was a festival last week, was there? No, no, there was just me having a craving last week. So yeah, it wasn't. It's not necessarily just for the festival, but it's definitely had during the festival.
00:03:40
Speaker
Yeah. So you don't need a reason to eat, you know, sweet stuff in India. You just keep munching on them every day. Right. Nice. Cool. On that sweet note, I think Vedang, it's by
India's Food Culture and Pune as an Educational Hub
00:03:53
Speaker
the way, it's really a very nice name. I like that it's abstract enough, but it is also concrete enough. Right. It's like it's just saying like Vedang is not specifying which Veda you are, but also saying you're part of something. So
00:04:07
Speaker
Cool name, by the way. What does it mean then? Because I don't get that. So what? So in India, a lot of the names have meaning. I don't know if this is true in the Netherlands or in Belgium. I don't know if names. You don't want to know Netherlands names. So Vedang basically is somebody who knows, who encompasses the body of the four Vedas. The four Vedas are the founding texts of Hinduism.
00:04:39
Speaker
Yeah, so Vedang if you just break it up the word, it's basically just Veda plus Anga and Anga is body and Veda is Vedas. So the body of the Vedas basically. So that's the name, that's the meaning of the name.
00:04:53
Speaker
Okay. So you're kind of like the equivalent of the Bible in the West, like the four books of the Bible. You're the four books of the Hindu religion. If you get into the number of books in the Hindu religion, we're going to spend a lot of time right here. So there are four Vedas. Then there are the two mythologies,
Vedank's Programming Journey and Helpshift Transition
00:05:15
Speaker
which is Mahabharata and Ramayana. Then there are 18 Mahapuranas. And I do not know how many Upanishads
00:05:22
Speaker
are there. I have no idea. Yeah. So 32 are the principal ones. And then they say at least a thousand Upanishads and all that stuff. Yeah. Anyway, I love Indian theology. Yeah. Yeah. Yeah. I think compared to the other religions where it's much easier to have like one book and then finish it off. But I think India is more like a multiple religions. I think Maharashtra would be a different religion, right? Pretty much if it is not part of the Hinduism, then the Ganesh thing would be a different religion pretty much.
00:05:52
Speaker
No, so Maharashtra is majority Hindu. And yeah, I mean, most of India is majority Hindu, but Maharashtra is where all the learned Brahmins and things like that. So Pune, for example, has the name Oxford of the East. It used to be the learning center during the Maratha kingdom, which was a century long, 17th century, 18th century, I guess, 1700s to 1800s.
00:06:19
Speaker
So a lot of the educational institutions and churches and temples and stuff are around there. Yes. Which is also the reason why the software industry kind of grew up in Pune. So, I mean, apart from Bangalore, Pune has a pretty strong software industry because of access to college students. A lot of colleges here.
00:06:44
Speaker
So is it like a university town as well then? Has it got that feel? Or is it too big for that?
00:06:52
Speaker
It is now, it's too big for that, but earlier it used to be a town for people to retire to and for university kids. So all the fans and people from Bombay would retire to Pune. And then university kids would be there to study. So you would retire to Pune and then enjoy your life in, what is it, Lonavla or the hilly area?
00:07:37
Speaker
I don't know, I don't know the geography. Yeah, mountains on all sides, no beach. And yeah, it used to be like nice rolling countryside. Well, there is if you travel, you know, not enough. Not in Pune. Not in Pune, probably. I'm joking about that. I know enough geography.
00:07:39
Speaker
Yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah.
00:08:05
Speaker
Cool. So I think let's let's you know obviously we'll come back to all these topics again and again during the course of our discussion. So let's let's dive into whether you know you because this is Closure Podcast and then we'll get back to Closure at some point or maybe now.
Growth of Clojure in India and Developer Challenges
00:08:23
Speaker
So let's talk about you know your your journey like so where do you work and how did you get into Closure you know the from 1700s until now you know how is the knowledge has been transformed
00:08:34
Speaker
Let's hear everything. Great, great. You will actually like this story, Vijay. One member of the audience, well, that's good. Yes. Don't tell me. Has it got anything to do with EMACs? Absolutely. Oh, fuck. Okay. Isn't that a dead giveaway when they say, I'm going to like it? Welcome to the EMAC section of this episode.
00:09:02
Speaker
So I was a C programmer, a C, C++ programmer. And systems engineering was a big thing when I was in college, actually. So most of the jobs in Pune used to be around systems, and I had a job in Symantec. But everybody there used Visual Studio, and my mentor in college had taught me Emacs, and I was very stubbornly an Emacs person.
00:09:27
Speaker
You started on the right foot, man. You started on the right foot. Absolutely. I am very strongly of that opinion. I was coming to a point in life where I didn't want to just copy paste Emacs configuration anymore. I actually wanted to understand what I was doing. I was at that point tinkering in my life where I wanted to really understand this
00:09:51
Speaker
Now, at that point in time, there happened to be a company called Infinity Beta, which one of my classmates was working in. And this was a bunch of common lispers who had... So there was a company called ClearTrip in India. There is... Oh, yeah, yeah. That's one of the famous examples of lisp companies in India. Yeah. So ClearTrip was, I guess, similar to Expedia, you could say, for the business. And it was really fast and beautiful, and the engine was a common lisp.
00:10:19
Speaker
And they were in the process of rewriting everything to Java because they had grown big. And so these guys left that company and they started their own new company called Infinitely Beta. And the change they made, this was by Shampai and Ghosh and Adityo, Deshmukh and Nandanbakshi and people like that. The change they made was that they moved from Common Lisp to Closure.
00:10:45
Speaker
This was in 2009. Closure was fairly new at that time. They moved from CommonLifts to Closure because it was on the JVM. They just had the experience of people telling them that JVM is the future. We want to move to JVM. They said, let's start out with a list which is on the JVM and let's see where it takes us.
00:11:05
Speaker
So they made this company, and my friend reached out to me, and these guys were all Emacs users, because there was nothing else for Clojure at that time, I think. So I was like, hey, I'm going to get Emacs Lisp out of this, for sure. Whether I get anything else or not, I don't know.
00:11:25
Speaker
Finally, you can configure it yourself. Yes, yes. Then I joined that company and I love Closure. I fell in love with Closure and I'm still there. The company changed its name from Infinity Beta to Help Shift. So that's basically 2010. So how long has this been? Infinity Beta slash Help Shift. So how long have you been working for them now?
00:11:50
Speaker
11 years now. So I started in 2010 and company started in 2009. So when I joined, we were like less than 10 people.
00:12:01
Speaker
Yeah. I don't want to pounce that, but do you have a good Emacs setup now? Yes, absolutely. After 20 years. If you've reached enlightenment, then, you know, the path towards Emacs enlightenment has been a rocky one by the sound of things, but you're finally getting there.
00:12:21
Speaker
So he just said he's the body of knowledge. So, you know, yeah, yeah, yeah. Additional information from IMAX. I mean, he comes with, in India, we say everything is in Vedas already, you know? So I'm pretty sure Elisp is also in Vedas already. Or at least recursive grammar. I'm pretty sure it's there. Tinkering with IMAX is like what I do when I'm bored, basically, right? So every day thing is like, oh, if I'm bored, let's do, let's look at some new package and let's try something else.
00:12:50
Speaker
and then break everything and then restore everything from Git reset. So it's been almost 10 years of closure. So how did you see closure growing or evolving? Let's talk about from an Indian perspective. I think we were just chatting before we said we'll begin the episode.
00:13:15
Speaker
you know,
Helpshift's Product-Market Fit and Tech Stack Evolution
00:13:16
Speaker
statistically speaking, you know, just by sheer numbers for every programming language, there should be more Indians working in them, given the amount of people there. So how is it there right now? And how did it change in the last 10 years? You know, putting closure at the center.
00:13:36
Speaker
So, when we started, there were very few closer programmers in India. We were there and then there was, I think there was, Debashish Ghosh, who had written a book called DSLs in Action. There was Amit Rathod who had a book called... Wasn't he the Scarlet guy though, Debashish? Yes, yes, that's right. But his book had an... Amit also wrote a book, right?
00:13:58
Speaker
I think so. Programming enclosure or something like that. I don't remember the name. So they were there. And then I think around 2012, 2013, the lens was started, which is a consulting firm, which is quite like is doing really well even today. And then there were a bunch of like C42 was there, which I think also started around the same time, which was bought by Gojek and became the leadership of Gojek. And I believe they were also doing closure. So I don't know firsthand, but I think they were also doing closure.
00:14:28
Speaker
Staples was there in India for a while. They were hiring out people who were doing closure. So it's always been in small pockets. It isn't as non-existent as people think. One of the things that I have seen happening is that a lot of our programmers, so today we have maybe 30, 35 closure engineers in HelpShift. And at least 30, 35 people have learned closure at HelpShift, spent a good four or five years and graduated.
00:14:57
Speaker
moved on to other companies and these guys have moved on to a lot of places in Europe and outside India.
00:15:05
Speaker
The number of Indians doing closure probably is larger than is immediately obvious. There just aren't great big examples in India that we can say that, OK, here is a giant company. That's closure. We don't have it out around Indian diaspora rather than just subcontinent of India. That's right. That's right. Yeah. OK. And how is specifically in India, for example,
00:15:33
Speaker
Is the closure thing pretty much concentrated in and around Pune Bombay metropolitan area? Do you have different companies doing in Bangalore or maybe in the north, in Noida or Delhi or Kolkata? How is it there? I know of a bunch of people who are doing closure in Pune and Bangalore. But outside of Pune and Bangalore, I'm not very aware. There are a lot of companies in Delhi, but Delhi actually is not something that I am aware of. So I don't know if they're doing closure or not.
00:16:04
Speaker
Yeah, yeah. So, I mean, you know, one of the things, well, it's interesting, isn't it? I mean, I guess a lot of, maybe I'm mischaracterizing this, but I think a lot of Indian work is kind of like contracting to European companies or American companies. So I guess some of the tech choices are driven by those companies rather than necessarily by
00:16:30
Speaker
the employees that are working for them. So is that one of the kind of reasons why the kind of like homegrown closure community isn't as big as? Yes, absolutely.
00:16:44
Speaker
So product companies are in their infancy in India. So India was mainly a services industry for a while. And today we have a lot of big product companies, but you can think of them as copies of successful product companies in the US. So US has Amazon, we have Flipkart, US has Uber, we have Ola, things like that. Big companies which have copied successful models.
00:17:11
Speaker
I think we are at a point in life where you'll soon start seeing Indian companies, product companies, which are coming up just to solve Indian problems. So then I think that focus will shift a little bit more towards more esoteric languages.
00:17:26
Speaker
So I know for sure that like I know people who are working in our land and Haskell and elixir and these languages have a little bit of adoption in India. It's not that they are completely non-existent but we don't have like you won't I at least I don't I'm not aware of like open source stuff coming out of here or people giving talks about it or driving the direction of any such thing. So I think that's missing.
00:17:52
Speaker
Yeah. I think for Haskell, I remember reading about one company from Chennai called Hasura or something. I think they were doing like a Haskell container or stuff, something like that. I was really happy to see like, oh, there is Haskell stuff in India, like super cool. So I think because we're talking about different product companies and everything, it'll be nice to explain what you guys do, like your product, what
00:18:19
Speaker
what kind of product you're building and what does Helpshift mean? And when did it break the infinite beta and then became RC and then product? Okay. So what Helpshift is, is the business terminology for it is in-app CRM. So basically we provide an SDK to mobile app developers. And the pitch is that if you're an app developer, you think your end user is going to have a problem.
00:18:48
Speaker
and they're going to need help, then you need our SDK in your app. So this SDK provides an interface, a WhatsApp-like interface to the end user. When the end user says, I want help, he gets a chat interface and he chats with the support agents on the other side. And the support agents on the other side get a Gmail-like interface where all these issues are coming up and they're answering the problems. So that's like the simple, what do you say, thousand-degree view of the whole product.
00:19:19
Speaker
How we got here from infinitely beta is like a long story. We did a bunch of pivots and we tried a few things. We started out doing something called paisa.com, which was going to be for portfolio management.
00:19:32
Speaker
And then we found we could not compete with the existing incumbents like money control and stuff like that because they had real financial advisors and media teams and things like that, which we did not have. So we said, how do we compete with this? And at that time, Kura was really big in India.
00:19:51
Speaker
So what we did was we said, okay, let's create a Quora-like thing for PESA where people can help each other by asking questions and answering questions. So we created something called Ask PESA. And that became quite popular. And then our investors said that, hey, this is a great thing. You should just do this for the enterprise.
00:20:12
Speaker
Then we moved into something like Cora for Enterprise. I think there was a company called Yammer, which was also doing something similar. Then from there, the whole thing was that what is needed is customer support. When people come to Enterprise, they really want customer support.
00:20:32
Speaker
And there are too many solutions on the web that are already doing this, right? But nobody's doing it for mobile apps. This was in like 2012. And mobile apps were like, they weren't even that big of a thing in India at that time. So I remember the co-founders of the company, they went to the US and then they came back and they're like, the future is mobile apps. And everybody's going to be doing mobile apps. And we need to be doing support for mobile apps.
00:20:56
Speaker
And that's basically when we pivoted and that was where I think we found product market fit. So we kind of really found revenue and product market fit there and we kind of started growing. So we've stayed with that for the last eight years.
Onboarding Engineers and Training at Helpshift
00:21:10
Speaker
Yeah, so it's pretty a long time thinking in terms of closures, adoption and evolution, right? If you started in almost like 2009, 2010, let's say 2010, that's, I think that was still when, well, we didn't have CIDR, it was still SLIME, I think. Yes, yes, SLIME, EMAX with SLIME. Yeah, yeah, Liningen just started up, or maybe even Liningen wasn't there, I'm not sure, because when I started it was still closure main, so there was no Liningen.
00:21:37
Speaker
So how did your tech stack evolve over the period and how old is your code? Is there something that hasn't been touched for 10 years and then it's still there? There are things which have not been touched for eight years at least. So what happened was, so these pivots kind of like resets, right? So we could just throw everything away and start from scratch. So those were like great points for starting with new technology.
00:22:04
Speaker
and then adopting things like line engine and all the new things that started coming up, protocols and stuff like that. But once we found product market fit, then there was no going back and resetting and starting from scratch. So there are parts of the code which are old and have not been touched, they just work.
00:22:25
Speaker
And that's testament to Closr's strength as well, actually. You can just keep upgrading Closr and things will just continue working. Today, we are a line engine focused company. We don't do Dev story done because we have not found a way to adopt it so far. Things just work for us.
00:22:47
Speaker
So that is one of the problems that you have with like long running code bases where you kind of get stuck in the patterns of the time when you were, uh, when you were doing this work, like you need conscious thought to move towards newer stuff, which, which can be hard. Maybe, maybe it's also a question of, you know, because you, because everything's kind of working for you.
00:23:09
Speaker
There has to be enough of a payback to justify the investment exactly and i guess if you're starting from scratch you might look left and might look right and you can make a choice but if you've already committed to something then. Why change really have to have a good reason that's absolutely right that's actually it's really hard to.
00:23:28
Speaker
make a good business case for trying out new tooling when the old one works perfectly fine. So yes, that's something that's a problem. For me, the only thing that I thought, not the only thing, but the major thing that depth.even brought was this ability to depend on a git sha
00:23:49
Speaker
rather than a maven artifact. And again, if you don't need that, then it's difficult to go to that next level. With learning and you can do that now, right? I mean, you can also do that with learning and...
00:24:03
Speaker
I think there is a plugin or something. No, we have just never felt the need for it, right? So if you want to do local development, then line engine has that with local install and class, check out, check out. So those things are there. And if you are ready to publish an artifact, you're ready to publish an artifact. So you generally don't want to pull from a GitHub.
00:24:29
Speaker
So, I mean, we haven't hit that use case. I'm sure there are people who have, but we haven't.
00:24:35
Speaker
Yeah. And so because you, you're almost like 35 people and obviously most, well, pretty much everybody working in closure and how difficult has it been to find, I cannot say closure programmers because as you mentioned, like there are not many closure programmers available in India. How did you transition people into writing closure code, especially when, when you have a, I'm assuming a reasonably large code base that you
Hiring for Niche Tech and Talent Strategies
00:25:04
Speaker
have,
00:25:04
Speaker
entire company running on Closure. So how did you find people? What kind of attributes that you look for to bring them into Closure? That's actually a great question. So we have around 70 engineers actually, but we have a big SDK team, big front-end team, they don't do Closure. So Closure is only on the backend and in the data platform basically.
00:25:29
Speaker
In so many years of existence, we have not been able to hire anyone who already knew Closure. We just haven't formed them. We have to apply them. A lot of people have come to us who are interested in learning Closure.
00:25:47
Speaker
So they've approached us because they want to learn it. And that has happened. But but in most cases, it's just people who want to work. And then we have to train them, we have to teach them. So it was it was very hard for us to find senior engineers. So we went down the path of just hiring out of college and growing engineers. We have spent a lot of like our time on onboarding and mentoring and teaching as a full time job and fleshing that out, that aspect out. And
00:26:17
Speaker
It's a long investment and it pays off, but because people get molded according to the culture, they really have that ethos and things like that. But it's a big problem with closure for us, which is that it isn't easy to just say, okay, let's hire five more people. It just doesn't happen. Hey, I have the pun now. So you're helping people shift into closure. Yes, absolutely. I just thought about it.
00:26:48
Speaker
Nice. So before we move on, I mean, is that, you know, you say you can't like just hire five people that program closure. So is that constraining you or do you find like within a fairly short period, you can get people on board and they're productive or, you know, what's the story there?
00:27:07
Speaker
So, we have really worked hard on our onboarding. So, I remember earlier, it used to be like six months for somebody to be productive, because at that point in time, they had to learn Emacs and Closure.
00:27:22
Speaker
So that was just like set for their life. So that's not a prerequisite then, you know, you must know EMACs. If you don't know closure, that's fine. If you don't know EMACs, fuck off. You know, one of these philosophical schools, I think it's probably Aristotle School or something, there used to be a sign, or at least they say that there used to be a sign, let nobody enter who doesn't know geometry or something. So your company has a thing like, let nobody enter who doesn't know EMACs.
00:27:52
Speaker
Yeah, so because I mean there wasn't like there wasn't touring outside of Emacs for closure at that point. Yeah, yeah, yeah. And then we had like IntelliJ, Cursive and now we have BSCode and a lot of the new people prefer that and they use that. So we cut down that onboarding time from six months to three months from three months. Currently it stands at like one, one and a half month.
00:28:15
Speaker
where people join the company and then they are productive. So if I can just summarize then, Emacs is not very productive and cursive and VS Code is very productive. That's what we're kind of summarizing that, yeah? No, the thing that current time is on the closure onboarding, not Emacs onboarding. So, Emacs onboarding was always a week. Rest of the time was because of the closure tooling support.
00:28:37
Speaker
I don't know about that. It seems like it's going for three months to one month and that's more than a week, but okay. I'm not a mathematician. Fair enough. So the way I look at it is that UMAX is like the really steep curve that you have to take time to learn and then you can fly for the rest of your life. So that's basically the way I look at it. Yeah, it's funny.
00:29:03
Speaker
Okay. So, we've got better tooling now. That's good. Yeah. Yeah, so I'm a bit of onboarding. We focused quite a bit on that. But it's hard to get senior engineers, right? Because they, like one part of senior engineers is they rarely want to change their stack, their tech stack, because I've invested eight years of my life in this, why should I change to something else, blah, blah, blah, right?
00:29:32
Speaker
So that's one thing which is it's hard to convince them to try something new and that, you know, when you learn this, it's going to change your life or you're going to find something worthwhile to learn here. So that's hard. And then it's a matter of like, you know, they have to stick around for them to make an impact. So they have to onboard, they have to really like learn new things.
00:29:54
Speaker
So yeah, it's hard for sure. It's a bit of a humbling experience basically, isn't it? And, uh, but I think, you know, most, uh, for me, if you're, if you get a good senior engineer who kind of really knows that the landscape of technology, then the language should be a small part of that really, you know, because a lot of the, like the domain of computing is not in a particular stack or in a particular language, is it?
00:30:21
Speaker
There are a few people who will say that these are challenging problems that I want to solve, and then they'll do it in whichever language they need to do it in. But that is not my experience so far. In terms of hiring, it's a little bit hard to convince people about these things.
00:30:42
Speaker
they really have to see that it will be great for them, that it will be something that, and I think this is a problem with Closure in general, that the Closure community kind of needs to talk about, which is when there was hype around Closure, we did not have this problem. Because people would say that, hey, I'm going to spend some time learning this and it's going to go on my resume and I'm going to get lots of job offers from lots of big companies. But now that Closure is not like the cool kid on the block,
00:31:10
Speaker
That kind of is hard as a selling point, right? So I think closer has joined the
00:31:16
Speaker
the family of Haskell and Orlang and things like that. It makes sense in a place like India or anywhere else. Because even here, if I say, okay, come and work in closure for me, then people are thinking about the next job as well. Because if I'm in India, for example, there are four companies that I can apply for versus 20,000 companies that I can get my career by writing Java.
00:31:46
Speaker
It's kind of a no-brainer to see that, okay, I'm going to spend two years on a language which I can only move from Helpshift to Nalenzo to Gojek, and that's pretty much my limitation. And if I do Java, then there is practically, for street, there are like, like, like, Chaiologists, like, there is just, you know, T-stall level software companies. There are so many. So it's also a career thing, right?
00:32:12
Speaker
That would be my guess.
Benefits and Challenges of Using Clojure
00:32:14
Speaker
Yeah, I'm going to invest, learn new language, and I have to relearn or unlearn all the stuff that I have so far. And it feels like a retrograde than I'm progressing in my career. So that could be one reason, I think. Yeah. So we have to tell them that, hey, things you learn here will help you in whichever programming language you are going to use.
00:32:41
Speaker
Exactly. I have had people come to me and say that, okay, I really agree with you. This is something that's changed my life even in Java, not just in your closure, but even in this immutability and everything being data-driven. These two are really strong, really strong ones, and they aren't really something that Java developers are used to.
00:33:07
Speaker
Yeah, but I think it also helps that other languages also started talking about functional programming, especially Java, the Lambdas coming in. Because at one point, all this functional programming was just Haskell or Scala a little bit, and then Clojure pretty much. And the quote unquote mainstream languages like Java or even Rust, and Rust is pretty new, but other languages are not talking about functional programming that much. But then suddenly there was a bit of a
00:33:35
Speaker
um slow um how do you call upgrade of these languages into functional paradigms and then then you see the patterns everywhere like oh okay now what i'm learning here is is going to be useful there
00:33:50
Speaker
I think event-driven paradigm, the growth of event-driven systems kind of brought this about. So this renewed interest in function programming because event-driven also has this data flowing through functions kind of a feel to it.
00:34:06
Speaker
In fact, we didn't consciously choose an event-driven architecture, we just ended up at it in helping because of the way that we wrote our Closer code. That's something that was quite interesting for me to look back on. Initially, when we wrote our Closer code, it was so bad because we took this whole functional thing to the whole extreme case where even database updates were wrapped in individual functions.
00:34:33
Speaker
So you would have individual functions which were updating individual parts of documents, which was the stupidest thing that anybody has ever done. And then we were like, dude, this is terrible. Why should why we're doing it this way? But you're like, who wrote this? Oh, wait, that's me. God damn it. This is stupid. Get blame. Oh, fuck, it's me. Yeah, stop doing get blame.
00:35:02
Speaker
So anyways, that was so we wrote the initial thing we wrote was like a thrush model. Pipelines, basically pipelines and closure. And we used to do all the really critical stuff one after the other. And then for all the non critical things like sending out metrics and sending out the event to some other place and blah, blah, blah, we used to have like a giant future, which again was a pipeline. So we used to spawn a future. And in that future, there was again a pipeline.
00:35:29
Speaker
And that caused a lot of problems as we started scaling up. And then we were like, Hey, why are we doing this in the future? We should just like make these independent services and just emit events. And that kind of just like came naturally. And then we figured out that, Oh, okay, this is what event
00:35:48
Speaker
driven architecture or event sourcing or all those things are. So what do you use as a mechanism for transmitting events between services?
00:36:01
Speaker
use Kafka, of course you do. Yes. No, I mean, I would like to say that we took a bet on Kafka early on. So I want to just be that we were one of the first ones who were using Kafka from 0.8 or 0.6 or whatever Kafka version was the one that was early. Early versions.
00:36:23
Speaker
So what is with all this experience of large you know very large closure code base and everything so can you touch a bit upon both sides of it like you know what is you know unicorns pooping rainbows everything is awesome and then what is like okay this is shit and this this could be way better if we didn't see you know so
00:36:48
Speaker
So can you give us the two sides of larger closure code base and pain and, you know, not so good.
00:36:56
Speaker
So on the unicorn side, I think everybody talks about this. Rebel driven development really is like a game changer. And also all the patterns it kind of teaches you to think in terms of data. It really helps with testing. So for example, in our case, one of the surprising ways that we found our developers were testing was that they were just sitting with each other and they were creating
00:37:21
Speaker
these arrays of data, right? Like user logs in, user does blah, blah, blah, blah, blah, blah, blah, blah. And then they would just test it on their machine and they would say, hey, this is not working. Give the array of data to somebody else on group chat or whatever. And that other person would run the same test on their machine and say, okay, let me debug this and figure out what's happening. So they built systems for testing, which were fully data driven, simply as a side effect of doing it on the
00:37:49
Speaker
It wasn't like we later we realized, hey, this is a great pattern. Like if you write tests like this, they become easily reproducible and easily things like that. And so that, that is like a one end of it.
Overcoming Technical Debt in Clojure Projects
00:38:03
Speaker
Oh, one great thing, like when we were a startup, when we were like, oh, and we had like eight nodes, I remember eight was the limit.
00:38:09
Speaker
I used to be connected to all eight production repels at one time from my Emacs. So I have literally had this situation where our CEO was demoing this in San Francisco somewhere and something was wrong. And he called up and he said, you guys have written shit code, it's not working. My demo is failing in front of investors. And we said, wait, wait, wait, wait, wait, just give us two minutes. And we added like def inside the code and hot patched everything.
00:38:37
Speaker
And then we said, okay, run it again. And then we captured that input and we debugged it, fixed it. Then we said, okay, run it again. It's going to work now. Right. And this was done in like 15 minutes. And the investors were super impressed at like, this is the pace at which these guys are deploying to production. And yeah, so that was, I really miss hot patching in production. I think hot patching in production was super powerful. So you don't do that anymore.
00:39:00
Speaker
We couldn't do it, right? I mean, we were at a point where we had made rules like, if you hot patch some code, then you have to announce it, and you have to make sure that you create a tag before you go home that day, right? And the announcement has to be like, hey, I have hot patch code. Please don't deploy, because if you deploy, you'll break whatever I hot patched. And it's just not scalable. It can't work. That's true. I think it's really fun when you're debugging. See, I see your debugging is quite a lot, yeah. Yes.
00:39:30
Speaker
Yeah, I think it's fun when you have a system where it's continuously running and the only way to build the system is in the old lispers way of organically building the whole system. There is always something running, but the world is not the same anymore, I think.
00:39:51
Speaker
Because you want reproducibility, you want a proper history of things. It's fun to do. It's more or less like going into a server on SSH and then modifying the configuration files.
00:40:07
Speaker
At runtime, you know, change something in proc file system and then hope that everything is going to work. Sort of shit. That's not a thing anymore. So it used to be a thing. I think the thing is though, I think the thing is that you want developers to be able to develop as if it's production on their local machines. And you can't do that otherwise, kind of. You can't do that if you're constantly like using production images and patching production images all the time. Yeah, exactly. How do we develop again?
00:40:36
Speaker
It's a recipe for disaster down the line. So we stopped before we hit some major outage because of it. But I think REPLs are great for inspecting running systems though. I mean, I think even if you're not hot patching them, you can still debug them and that kind of stuff much faster than you can do with log files.
00:40:58
Speaker
We still use this pattern, actually. So, what we have is we have special nodes where developers can sync their code and they can start a REPL against production data stores, all the production data stores. And then they can do whatever they want on that. And it's a really quick way to look at data, analyze data.
00:41:16
Speaker
and write migrators or write data requests, fulfill data requests by just making those queries against production. And we trust our developers to be careful. It's a double-edged sword. You have to be careful with it.
00:41:31
Speaker
So what are the dark side of, you know, such a large closure code base it being in closure? Oh, so there is any, so many. So many, oh my God. So many problems. So this rebel driven development, right? Oh, I'm sorry.
00:41:49
Speaker
This is closure propaganda. You can't say bad things about closure. Oh my god. Some challenges, you know. One major problem with REPL-driven development is that without discipline, nobody ends up writing tests, right? Because you just do it in the REPL, it works in the REPL, you move on. I don't know what you mean.
Clojure Tooling and Open-Source Contributions
00:42:12
Speaker
Yeah, so we have like large parts of code which have no tests against them simply because somebody wrote it sometime and Didn't do anything about it afterwards. And it's a real it's a real pain. So that's one example another is What you said we share it like this lispers tendency to take a running system and continuously build on top of it yeah, that leads to like really weird domain specific languages and Nobody other than the person who actually wrote it can understand it six months down the line, right?
00:42:42
Speaker
Even the person who wrote it cannot understand it if he has done a bad job there. The way I used to talk about it in Office, the way we discussed it was, as you're learning Closure, your mind tends to be continuously blown with all the new things that you're learning. So first you learn about higher order functions and then, oh, this is great.
00:43:05
Speaker
Then you learn about macros and then everything you write is a macro. And then someday they bite you really bad in the ass and then you go back to writing functions. And then you're like, okay, the right thing to do is to use macros in the tiniest bits and make sure that you test them and debug them properly.
00:43:25
Speaker
But then because of that, every person who's learning Closure, we have to be especially careful to make sure they're not introducing macros left, right, and center. And this comes from like having existing code bases, which have a lot of bad macros in them. I think it's like, you know, first rule of macro club, isn't it?
00:43:51
Speaker
But it feels like, you know, it's very powerful. That means suddenly you feel like you have this infinite amount of power to do everything. And every problem looks like I can solve this by code writing code, you know, like it's amazing. And at least in Clojure you have some limitations, right? I mean, you, you cannot go all the way like a common less power SBCL, for example.
00:44:12
Speaker
The macros that I see, every time I read this book called Let Over Lambda, that's like a mental book. Every time I'm like, where exactly am I in this stack? I have no clue anymore. It feels like I'm high and hallucinating and this is the maze of code generating code. I have never actually gotten through Let Over Lambda. I have never been able to complete it because it just
00:44:38
Speaker
goes way over my head that like, trust me, I mean, I keep reading it again and again to understand it better every time. But it's at least in enclosure, what I see is that we don't have that level of, you know, quote unquote power that you have in, in, in LISP. Is it like the, like the, the VEDA?
00:44:57
Speaker
of uh yeah it's impenetrable recursive we know macro land that once you get in you cannot get out sort of thing but it's a it's a really nice book though i mean i can i can recommend uh if you want to have some sort of a mind-bending macro magic
00:45:14
Speaker
you know macromancy if we can call that but it's a it's fun anyway but that's that's nice with closure right i mean you you can't go to that level that that you can you can do plenty damage it's it's pretty bad so you don't need to go to that level to write bad
00:45:35
Speaker
code. I mean, one more, the thing is, so what happens is that these libraries, right, not just macros, like even if you take libraries like say code or async or even component for that matter, right? People, if they come from different programming languages, I mean, I still don't understand lots of parts of Closure, right? I still, like if I read Joy of Closure, I'll find something which I like, which will click in a different way today because I'll be like, oh, finally I get this.
Microservices vs Monolithic Architecture at Helpshift
00:46:06
Speaker
So, they come with their own idea of how to write code, and they don't really understand the complexities of these libraries, and you end up with bad code. So, unless you have really enlightened people reviewing stuff all the time, there's a high tendency that these things, specifically I have seen it with Cora Sync and Component,
00:46:30
Speaker
you can have really bad code in there. It just messes up the whole thing and makes it really hard to debug, really hard to reason about it under scale and very confusing stuff. And how do you contain these things? Because obviously, these are tools. These are very powerful and
00:46:50
Speaker
you have to have a sort of a discretion to figure out when to use this one. So how do you encourage people to reduce their enthusiasm and then use the right tool for the right thing? So common patterns are really important.
00:47:10
Speaker
So, we have these weekly talks in the office where somebody will talk about some small problem that they have solved. And the intention behind that is just to highlight good patterns. So, then what you do is you kind of figure out a way to put all this magic stuff, like if you're going to do real magic with KoraSync or with Kafka Streams or whatever.
00:47:35
Speaker
contain that into as small an amount as possible of your code base and test that part really well. And then make usable interfaces to do these things that other people can use. And they can treat them as libraries or they can treat them as recipes which are already available to them and use them.
00:47:56
Speaker
And be very strict about, OK, if you're going to step out of this pattern, you need to involve some people. Don't just write what comes to your mind. This is a set pattern. If you genuinely have a use case which does not fit in this pattern, we need to have a discussion and understand what the next step to take there is. So that is something that we are doing to go back and fix all the things that are problematic.
00:48:25
Speaker
Nice. So how does that actually work in practice? Do you have like a kind of like, uh, what should we say? Like a closure elders council that, uh, you know, where you kind of have the grit and the good of help shift that can like, like the Jedi of closure, you know, go out there and help to solve the problems.
00:48:47
Speaker
So we had a monolith code base. We had one which became a giant code base. Today it stands at 500,000 lines, just shy of 400,000 lines, some 485,000 lines or something like that, of closer code. And then at one point in time, we started building new services. We started saying, okay, this thing will be a new microservice.
00:49:14
Speaker
And then the first few microservices that we built, we would just blindly copy code from the monolith. We'd just say, okay, these are things we have solved in there. Let's just copy it, put it in there, and get on with our lives. And then eventually, we got to a point where we were like, okay, if we want to fix these patterns, we need to abstract them out into libraries and things like that, which all these microservices can use. And we need to think about breaking that monolith up into microservices if we want to make it faster or more agile.
00:49:41
Speaker
So, today the approach we take is we don't have too many microservices because they have their own problems and that we discovered those as well because we said let's do microservices. Extreme operational problems. So, today we do a modularization
00:50:02
Speaker
within our monolith. So we have this tooling that we have built to say that, OK, this is how you define a module, and this is how you contain code within that module. And this is how you expose an API for this module that other modules can use. And this is a strict dependency graph within these modules that only this type of module can depend on this other type of module and things like that. And this is all enforced by external tooling that we have written.
00:50:31
Speaker
That is the happy middle part that we have found. It isn't easy to pull microservices out of the monolith because there's too much work involved. If you're starting new microservices, then we have some libraries that we're using and that we are saying, okay, here are our common patterns. For example, for doing logging, for doing settings, for accessing Kafka. If you're writing Kafka consumers, here are all the patterns you need to know.
00:50:57
Speaker
right? And use these libraries. And within the monolith, here is this modularization technique and use that, right?
Testing Challenges and Codebase Management
00:51:07
Speaker
So that's basically, I propose the monoliths because I mean, in my experience of kind of like looking at monoliths, the biggest problem with monoliths usually is they have one database and everyone's doing all kinds of shit on it. Or, you know, so it's basically,
00:51:23
Speaker
You have readers and writers inside of the monolith and it's kind of like impossible to pull it apart. But if you're doing kind of like event driven services, haven't you kind of got the tools to start to pull it apart because you have Kafka in the middle so you can kind of like.
00:51:43
Speaker
So we are basically at 30 services, 30, 35 services right now. And that's basically the approach we have taken. Like I said, we used to have a giant future. Now everything inside that future is going out into its own service, basically. But there are two, three problems. One is middleware. So for request response services, which majority of our services inside the monolith are, they all have a common middleware stack.
00:52:09
Speaker
So part of it is first you have to pull the middleware out into its own library, which is a non-trivial problem. Then you have authorization and authentication. So that is a common stack that people are using. And then if you pull all of that out, then you have to think about how these tokens are going to pass between different services and solve that problem.
00:52:30
Speaker
Then we have common utilities for the way that we do audit trails and the way that we do events. These are all common things which everything in the monolith can just use. But to pull it out into microservice means it has to be something else. So that's one aspect of it. Another aspect of it is that with so many files of closure code, badly written monolith code means that
00:52:55
Speaker
a change in one file can potentially affect lots and lots of other places. Because you have hundreds of files which are each depending on each other in a very badly organized way.
00:53:09
Speaker
This is something that we kind of surfaced that we kind of saw when we decided to fix our test timelines, right? So our integration test started taking a lot of time to run. So he said, OK, let's fix it. And the first optimization that we thought about was that let's only run the tests for the files which are modified, right? So now you so we wrote a little bit of utility with said, OK, here are the files which are modified in the commit. Find all the transitive dependencies and only run those tests.
00:53:36
Speaker
Then you discover that this one file which you have causes you to run all the tests because it's used everywhere. You can read those signals and see work for yourself. Those are great refactoring points actually. Those are the right places where you need to be refactoring and rewriting your code.
00:54:03
Speaker
Yeah, that's great. So how do you do that incidentally? I mean, you know, you said you've written a bunch of tools because, you know, that's kind of interesting. How do you, how do you do that? How do you kind of like come to build these tools? Because obviously these are tools for yourself, for your engineering team. They're not like for the customers. So, so how do you kind of like, how do you motivate yourself to write these tools and how do you justify to yourself?
00:54:30
Speaker
A lot of people just write them and say, I've written this thing, it's better. Well, honestly speaking, actually, that has happened quite a few number of times where people are just like, hey, I have done this and it solves this problem and please use it. I mean, this is horrible. And I'm glad that that happens. That's really a good thing.
00:54:53
Speaker
The thing with tooling is that once the problem becomes bad enough, then everybody's up in arms. Then they're like, hey, I don't want to wait three hours for my test run. We have allowed it to get to three hours. That's the first thing that we have. We shouldn't have done, but we have. Now you have to fix it. Then that pressure builds to say, okay, we really need to put one engineer aside for one quarter and get that person to just focus on this problem and make some improvements there.
00:55:23
Speaker
And because it's a visible productivity gap, basically, so you can justify it at that point. Yes, absolutely. You can say that, hey, look, these these features are going to ship faster because of this, because people are like, you know, they're not going to lose context, which is the worst thing that can happen. Yeah. So we had this pattern emerging where people would push their commits into review before going home and then go home because the test took so long.
Community Support and Growth for Clojure
00:55:48
Speaker
Right. And that's really bad. That's that's a disaster.
00:55:52
Speaker
So what are your, speaking of tools then, what are your workhorses so far? There must be a lot of libraries that you're using in your code base, right? I mean, there are some things that were not there 10 years ago, for example, because Closure Ecosystem has evolved at a rapid pace, I would say. There are new things coming in.
00:56:14
Speaker
new ways of doing things coming in every now and then. So if you see the current stack that you have, current code base that you have, so what would be the ones that you are really dependent on and how they are helping you, you know, running HelpShift?
00:56:31
Speaker
Initially, we wrote a lot of the libraries ourselves. One of the things I feel really bad about is we never open source any of this work. We just wrote enough to solve our problem, and we moved on. I think this is another thing that a lot of people in the Closure World do. They'll just solve their own tiny problem and move on.
00:56:49
Speaker
So also the reason why we have so many reimplementations of the same thing instead of like something I've observed in other programming communities is that people they rally behind one framework or they like something gains critical mass which I don't think happens in closure. There are certain things aren't like ring that does that but I agree you know a lot of people will because it's I mean it comes back to the cursive list that we talked about earlier on you know
00:57:19
Speaker
Because it is relatively straightforward to implement these things, people don't necessarily want to be owned by someone else's code. And in fact, there's almost a culture around that of saying, I don't take on the dependency, don't use someone else's code. And even these days, in his recent months, the software supply chain bullshit that's coming out,
00:57:44
Speaker
Everyone's like in the closure world. It's like, yeah, we told you about that. Don't take other people's code. Yeah. But then that, that's the problem. Like it stops things from being full featured. Yeah, that's right. Yeah, absolutely. So yeah. So we wrote those kinds of things, but I mean, the ring is something that we, we cannot, I can't imagine my life without. Yeah. Yeah.
00:58:12
Speaker
Same with, so we only have Closer on the back end. I don't have any experience of Closerscript. When Closerscript came out, our front-end engineers evaluated it and they were like, no, we're not going to do it. I think this was in the very initial version of Closerscript. Well, fair enough at that point. I think now you have Shadow CLJS and stuff like that. The tooling is a lot better, but it was a hard sell, I think.
00:58:36
Speaker
Yeah. And also with reframe, there is, as you were mentioning, like there is a kind of a critical mass around reframe and this kind of development now. And because there was a time where there was like all these weird ways of wrapping react, like there are like mushrooms, like there are 20 different libraries showing up. Everybody's thinking, yes, you know, we're doing it slightly differently than, than other folks. And, um, um, that's, that's something kind of gravitated towards one. Now, uh, we have reframe and.
00:59:03
Speaker
know, reagent in the back end, well, back end of the front end. So I think that there's kind of a consolidation happening there. But rest of the places, I think it's always, yeah, I mean, there is still no, just as you're mentioning, like, you know, there is no Django, there is no Rails that in our entire community is just putting writing plugins and, you know, following the same pattern everywhere. So there is always
00:59:28
Speaker
Oh, you're between integrant or slash duct and then you're between yada and then something else. And there is always a choice available, which is a good thing and which is a bad thing. It's a difficult balance to achieve.
00:59:43
Speaker
Yeah, we we got stuck with component which. Honestly, I don't enjoy very much, but that's something that we did and. I am like we're looking into integrant now, but component is something that we just have too many things around, so we wrote more protocols that component should have by default and then each of our components implements those protocols. So the change is quite significant for us. Yeah, yeah.
01:00:12
Speaker
I think that's what, as you mentioned before, once you have the product fit, then it is very difficult to justify rewriting code because there is business, there is serious stuff running on top of the code base.
01:00:28
Speaker
There is not much happening. We're pretty much, I'm pretty sure it's like past midnight in India. Well, we started past midnight already. Almost 2 AM. We don't want to keep you back forever. Just a few things before we wrap up. I see that you have a FoundationDB library.
01:00:50
Speaker
Do you guys use foundation DB in production because I heard a lot of good stuff about it, but you know, there is not enough, you know Reason for me to use it yet because still feels like kind of a key value store for me
01:01:02
Speaker
It is, it is. It's a key value store with like full asset transactions, which is a huge thing. It's amazing. I love FoundationDB. I wish we would use it in production. So we made the giant mistake. I mean, I can only say this in hindsight. It was great for us to get it. Yeah, of course. When you're doing it, you don't know that, okay, we are going to make a nice mistake today. So we invested heavily in MongoDB.
01:01:30
Speaker
And we did that during Paisa time. So Paisa's architecture was stock trades coming in. So it was just one after the other stock trades, things like that that are happening. And MongoDB made sense in that context. But then we did this, we moved into this in App CRM space, and that is a fully relational layout schema.
01:01:56
Speaker
but we stuck with MongoDB. Then we didn't see the problems until we scaled out, until we actually started having real customers. Ever since we've been trying to move away from MongoDB and giving up on it, like, oh, there's just too much work, it's fine, we'll just stay with what we have. One of those was foundation. One of the things that I had explored was foundation DB. The primary reason for doing that was that it has a fully mongowire compliant API.
01:02:26
Speaker
In theory, you can just swap out MongoDB with FoundationDB, and it should just work. By that time, we had been bitten enough by... The majority software that we have, we have Mongo, we have Postgres, we have Elasticsearch, Kafka, Redis. On the product side, this is the majority. On the data side, we have Link and Spark.
01:02:53
Speaker
So there we had been bitten enough number of times by not having enterprise support. So one of the requirements that we had at the architecture level was that anything we choose should have enterprise support. And FoundationDB doesn't have enterprise support. So that's pretty much the reason why we didn't go ahead with that.
01:03:13
Speaker
But I use it for my personal project. So I have a personal passion project that I do at home for managing my finances. It's a stupid thing. It doesn't need FoundationDB for sure. It could be finance. You won't have scaling problems when you become a gazillionaire, you know? It could have been this. It could have been a sequelized thing, you mean?
01:03:41
Speaker
SQLite is also pretty fancy. It could have just been files. Just to wrap up then, I know there is this enclosure happening. What is it? Is it the Closure Conference in India? Yes. How do you guys participate in the community? Do you have any plans to open source? Because it's one of the
01:04:08
Speaker
I can say that it's one of the most mature closure companies. So you have lots of practices to bring in. You have lots of ideas to bring in. How do you see things like closures together and all these community things happening? Because you have vested interest in having closure longevity. You want to have closure programs available. So how do you see this? And how do you want to participate? Or how do you participate already?
01:04:32
Speaker
So my little rant that I wanted to make on this podcast is you have had so many guests. You should ask them why they are not contributing to Cider and see a close risk together. I mean, I don't get it. We are a really tiny company out of India and we are the top contributors on Cider as a company. We have given them the most amount of money. Why?
01:04:55
Speaker
Why are there not people working like cider at is definitely worth that like they deserve that money
01:05:02
Speaker
And Closure is together also. I mean, Closure is together has a lot of people funding them for sure, but it could do with more. And that's something that should be done at the very minimum. I mean, if you're doing open source work, then you're already putting your time and whatever. You're already contributing in a different way.
Upcoming Clojure Events in India
01:05:21
Speaker
Yeah. Yeah. So in Closure, we organize with Nilenso. Nilenso and us have been organizing it for the few years that it has been.
01:05:29
Speaker
happening. It's a very tiny conference at the moment, but we plan to continue doing it. In coronavirus, that has completely knocked us out. It didn't happen in 2021. It won't happen in 2022, I think, but hopefully it will restart in 2023.
01:05:49
Speaker
Do we get a standing invitation to come and podcast from closure? Oh, absolutely. Live from enclosure. Exactly. You know, it'd be great, you know. That'd be amazing. I think that'll be amazing. I think me and Ray will be showing up there and Ray and I, I don't know how you say that. Is it Ray and I or me and Ray or Ray and I? Ray and I, yeah. Okay. So he's the king of Indian closures, so you have to be very careful with your grammar.
01:06:21
Speaker
I think in the films it was the king and I. Yeah, totally. And then we're gonna eat, what's that, the modak again? Yes, ukriti modak. Ukriti modak. And then eating that one, you know, people can listen to our ASMR eating, you know, Indian sweets and then enjoy the podcast from there. So hopefully, you know, things are gonna get better. Things will always get better, you know, as we say in India, all is well. If it is not at the end, then it is not well.
01:06:51
Speaker
It's not the end yet, if it is not well. There is certainly bright light at the end of the tunnel. Anyway, on that happy note, thanks a lot Vadang for joining us in this crazy hour and walking us through all this building a company around closure, one of the first companies.
01:07:13
Speaker
um, you know, and adopting it. And then also, you know, I'm gonna, uh, double down on helping people to shift into closure. You know, I like that kind of thing. That's nice. Right. Maybe is what we should do. We should learn, take a lesson from this and you know, we don't prepare very much, but we should like, like write down some like standard questions. What was your journey like VGLX to do? You know,
01:07:43
Speaker
But also we should say, why the fuck aren't you paying more money into cider? And why the hell aren't you paying more money into closures together? And why? Why are you not using emacs? What the fuck? So we'll be using your spirit in future podcasts for dang that for sure. Certainly. Yeah.
01:08:06
Speaker
And a special thanks to Aditya Athalye for looping you in and poking us and hopefully Aditya you're listening. Thanks a lot for bringing Vedang into the loop. So this has been an amazing episode and it's really nice to hear from you.
01:08:27
Speaker
Hopefully, there'll be more and more closer opportunities showing up in India. And that will give us a chance to come to India and then eat some Indian sweets, as they say. On that happy note, this is Abzun Amrati. And thanks again, Vedang, for joining us. It's been amazing. All right, thank you, guys. Yeah, it's been great. Thank you. Yeah, thanks.
01:08:49
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dullert. I'm pretty sure I butchered his name. Maybe you should insert your own name here, Dullert.
01:09:06
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulip or just at us at Deafened Podcast on Twitter.
01:09:35
Speaker
Enjoy your day and see you in the next episode.
01:10:02
Speaker
you