Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#76 - The Desi Episode with Kartik Gupta and HariOm Gaur
17 Plays3 years ago
defn has turned Desi with 2 Indian Clojurists! Kartik and HariOm join us to talk about Indian food and spiced up our discussion with Clojure and Ziggurat (https://github.com/gojek/ziggurat) and more!
Recommended
Transcript
Introduction of Hosts and Guests
00:00:14
Speaker
Cool. Welcome to Dafn. This is episode number 76, the so-called Desi episode of Dafn. Finally, as if everybody got tired of hearing to, you know, one Indian listening to one Indian, we bought two more into the podcast. So this is Vijay from Holland. And then we have Ray from Belgium.
00:00:39
Speaker
And we have two awesome guests from all the way from India. I think almost it's midnight there. Thank you for joining us. Please introduce yourself, guys.
Meet Karthik and Harioum
00:00:49
Speaker
OK. I'll go first. So my name is Karthik. I'm in Bangalore. I work for Gojek. So currently, I'm building an observatory platform for Gojek. Nice. Come on, Harry. You're next.
00:01:06
Speaker
Cool. So yeah, my name is Harioum. I have been anglicizing his name. Oh. Yeah, you could call me. Sorry, that's how I fuck up, you know. I'm pretty sure that's what you said earlier on, you know. God damn it. OK. Sorry, go ahead. Yeah, hurry. Not Harry. Oh, what's the difference? OK.
00:01:34
Speaker
Yeah, you could say Hari is Indian for Hari. You could say that. So yeah, so my name is Hari Hom. I didn't expect this to play here so funny. Whenever I speak my name and introduce myself as Hari Hom in India, what happens is usually people greet me back because it's also greeting. Hari Hom is also a greeting. So at times I introduce myself as Hari Hom and people are waving back at me and say Hari Hom.
00:02:02
Speaker
And then I unearth the fascinating fact that it is my name and not a greeting. So I am also working in Gojek and I come from Rajasthan. Right now I'm in Jaipur. It's an interesting place to be, India. And I'm glad that I'm here with you folks talking about India and Goja. Yeah.
00:02:32
Speaker
That's pretty much it. Yes. Yeah.
Indian Culture's Influence
00:02:36
Speaker
So we should say Haryom Haryom as this, as you know, saying hello and your name as well. Is it like a formal greeting Haryom or is it like a slang? It's a pretty formal one, but a bit reserved into
00:02:57
Speaker
areas where you are more into right wing and religious books. So, but yeah, pretty formal one. Right. Okay. I think it's pretty much Hindu religion thing. So I think other castes, other, sorry, other religions, they probably won't use that one to read. So it's a literal name of God. So you're just saying, you know, whatever something. Anyway, on that. That's going to be our greeting from now on on deaf end.
00:03:27
Speaker
There's already becoming proper desi ocean now. We should just switch to Hindi now and there's going to be like a Hindi episode now. I mean, really, you know, given the fact that the majority of people in the world, certainly more people are Indian than English. So, you know, this is the proper, probably the right balance of Indian people versus English people in the world. Yeah. Yeah. We're doing something right today. Yeah.
00:03:55
Speaker
I think we are, we are hitting like 2 billion demographic now. So our, our, you know, listening rating is going to be like, number of place are going to reach skyrocketing today. Now, after this episode, like there is 2 billion Indians going to listen to this shit. And they're like, wow, this is amazing. You know, we are the vegetarian closure podcast. Number one vegetarian closure podcast. So that should appeal to a lot of demographic in India, I think. Yeah, I'm already appealed. I think we should.
00:04:26
Speaker
You're already into this. But Karthik, you are a vegetarian as well, or you're non-vegetarian.
Indian Cuisine and Preferences
00:04:32
Speaker
Vegetarian. Oh, nice. Okay. I think Hariyam is also vegetarian. I think it's like the biggest vegetarian podcast ever now, including number of guests. Yeah. Yeah. Nice. There is one common thread across UK and India now. This is the proper, this is the proper, really, in some respects, this is like home for this, for this podcast. Yeah.
00:04:55
Speaker
Closure and vegetarianism and English and the colonial France. What is your colonial France? Please speak colonial France.
00:05:16
Speaker
Oh my God. Let's start with the food then, you know, because we're Indians. Right. Yeah. So what's, what's your favorite vegetarian? Well, what's your favorite dish? Maybe hurry. Yeah. I'll definitely go for power.
00:05:31
Speaker
Oh, it's one of my favorite. Oh, buddy. Nice. Yeah. So Ray is basically some curry with all the veggies available in our market, local market. And then you have this bun and it is you you basically grill it with some butter and make it. It's very delicious. And you find the best around the street at the corner. Like some vendors sell not in the malls or anything.
00:06:01
Speaker
You must try it. Yeah, like a proper street food. I know. Well, I'm hoping to come out to India, you know, after the pandemic, after the Delta is all done. So it would be really nice. And you, Karthik, what's your favorite dish? So mine is curry chowal. It's very specific to Ajasathya. So it's a curry of chickpea flour and curd.
00:06:30
Speaker
Yeah. And rice. Yeah. Yeah. Sounds good. Pretty big. No, no, just a yogurt curd. Okay. Yeah. Yeah. I think we use curd more in India than yogurt. I think yogurt is more American sounding thing for the same thing. Yeah. Because we also culture it, right? Because we keep it in, in like boiled milk and then we culture it ourselves.
00:06:56
Speaker
You make yogurt curd. It's a nightly routine in every Indian household. And there has been an old saying that you only want to live in a society or in a place where you can borrow curd from each other. Like it is okay for you to borrow curd from each other. Because it's a nightly ritual. If you let's finish your curd today, how will you culture it for tomorrow? So you might have to borrow curd. Just be ready for that.
00:07:27
Speaker
That's the first time I'm hearing this. Now you can see how Indians are, how different from each other. A lot of people are hearing this for the first time. Yes, yes. I think it's like a big deal. If you travel somewhere, you don't have your, quote unquote, curd at home. So when you come back, you always go to your neighbor and then bring the starter for the rest
00:07:56
Speaker
for the next day or something. So that used to be a thing when I was living there as well. Anywho, speaking of Kurt, I think we can move to C2C. Wow. Wow. This is such a terrible constitution. This is like one of those, you know, the Batman episode, Batman, the comedy one on the TV. The old one.
00:08:22
Speaker
Yeah, the old one with the guy. Bruce Wayne. Yeah, Bruce Wayne. No, this one is the Batman. Bruce. It'll come. Anyway, so. Wait, you guys did not tell us about your favorite food. Oh, yeah, right. Ray, go ahead. Well, I mean, my. Well, OK, I just got favorite food full stop of favorite foods, favorite Indian food.
00:08:46
Speaker
I think I think both. Yeah. Well, my wife is she is half Guyanese and she was from the father was Guyanese Indian. So she makes quite a nice chickpea curry, which is yeah, that's really delicious. Lots of different spices and herbs and things like that. So that's always a treat when we have that. Yeah.
00:09:13
Speaker
And I'm actually like a vegan now, so I've gone crazy here. I went more than vegetarian. So we're starting to... You're upgrading yourself. Yeah, I'm upgrading. I'm downgrading. I don't know. But we're sort of like trying out different things. So recently I'm getting into ramen. So we have some... There's a thing called golden ramen, which is really delicious. Lots of different... A nice broth, lots of different kinds of things you can throw in there.
00:09:42
Speaker
Yeah, so I'm enjoying that a lot as well. Nice. So how about you, Vijay?
00:09:48
Speaker
me my most recent one is we recently discovered that we can add like charcoal smoke to whatever we are cooking. So now we're making dal makhani and then you know dal makhani is a lentil thingy with with a bit of butter and all that stuff and then we now smoke it with charcoal and ghee so it tastes delicious so that is my recent favorite thing actually i just made it like 10 minutes ago
00:10:17
Speaker
but this time with Moongdao. I don't know how many people who are listening to this, you're like, what the fuck is this? What are you talking about? Yeah, but we need to open people's minds. That's good. It's all good. Yeah. Yeah. Look, we're all doing food on our plates. Closure is now pointing us to food anyway. It depends on the fact about Indian food in Belgium, actually.
00:10:41
Speaker
is that it's really bad. In England, if you have Indian food, there is a diaspora, so there's lots of people in England that make good Indian curries and good Indian food. Probably not exactly like you would have in India, but
00:10:57
Speaker
But it can be spicy and strong and fiery, or it can be mild. So you've got a good range. Whereas in Belgium, everything is kind of watered down. All the spices are taken out. It's a very emasculated sort of curry over here. So that's why we end up making our own at home. And a lot of the Indian folks that come on the IT gigs and stuff like this, they all do it all at home. And they're bringing the boxes in every day for lunch. When I used to work in office, that was
00:11:27
Speaker
So we're always queuing up for the microwave. That's one of the things that's true if in India, India, India, but the people take a lot of like home cooked food to work or is it is it sort of just when you when you're in the West? There is still, I think, a culture of cooking food at home. Although, although in places like Bangalore,
00:11:56
Speaker
because of Swiggy and because of our collective laziness. A lot of people are ordering out. But you won't die in places which are very fine because, as you mentioned, the curry is very creamy and all. You don't get all the spices. It doesn't hit your balance as well as your homemade food.
00:12:23
Speaker
Yeah. Look at us talking about curries. I think we can continue talking about Indian food podcast, I think. Maybe if we could move from currying in the food to currying in the functional programming. That's a bad transition. Come on. Come on. No way. The transition shouldn't make any sense. Partial to a bit of currying? That's not bad. Come on. Yeah, yeah. Fair enough.
00:12:51
Speaker
Okay, let's talk about your journey into Closure, guys. Like, where did you start? And then, you know, how did you end up in a Closure company in India? Because, you know, I'm super curious about how Closure is taking over India. Well, I imagine you've got two different, like, stories to get there. Yeah. Maybe as we start with Karthik. Yeah. Okay. So I can start. Yeah. So, uh,
00:13:20
Speaker
So I'll tell you a little bit of history first.
Gojek's Tech Evolution: Go to Clojure
00:13:26
Speaker
We haven't got that long. No joking. Carry on. Yeah, please. So Gojek is an app where people order food or order caps, and we get them drivers or something. So there was an internal system which was written in Go, which used to find drivers for our customers.
00:13:51
Speaker
Now, due to our limited knowledge of Go, we wrote some code which was functional, which was just running. It worked, yeah. It was very difficult to maintain. Adding new things was pain and stuff. So we decided, since this system has very business logic and stuff,
00:14:19
Speaker
Why not use a functional language for it? So people from Nilenso were with us at that time. They helped us basically architecting that system and get started on Flutter at that time. Yeah. When you say, like, why not use a functional language? I mean, I think a lot of people would say, why the fuck use a functional language?
00:14:47
Speaker
because like, you know, domain driven architecture and object orientation, that seems like, like in the culture of like IT at least, it seems like a more natural fit. So I wonder what where you got the idea from? Was it like from your friends in the lens? Or was it like in the group? What was because it seems like the sort of like, like the general culture is
00:15:12
Speaker
the more object oriented. So I'm still, I'm fascinated why you thought functional would be, I mean, I agree with you, but why you thought specifically? So, uh, for me, I was a fresher at that time, so I didn't really understand functional language. Right. So people, uh, in Gojek were experienced with functional language and specifically closure. Right. So that's why they recommended, Hey, let's start building the system in closure. Right.
00:15:41
Speaker
So that's how I got onboarded to Closure. So we started writing, we started replicating code from Go to Closure. And in three months, we built that system and replaced it with our Go system. Okay. Oh, you meant the Closure? Wow, that's pretty fast. In three months, we migrated from Go system to our Closure system.
00:16:09
Speaker
Closest. But they didn't change the company name from Gojek to Closetjek. Yeah, exactly. Gojek to Closetjek. Yeah, I'm disappointed. Nice. So after that, I got well versed with Closet. Then I built an experimentation platform into that service.
00:16:40
Speaker
so that you can A-B test your bookings and stuff, A-B test your business logic and all this stuff. And that's how, then to increase basically knowledge in a company, we started taking bootcamps of Flosher. Basically people would use to read Brave Flosher and come and discuss like one, one chapter of Brave Flosher and discuss like what they understood.
00:17:10
Speaker
and all these stuff. Okay. So that is like an internal study group. Yeah, internal study group. To gain more closure knowledge. Yeah. Yeah. So that's how closure started gaining traction in Go check. Like they saw the system, the internal, like that system was kind of main system, which worked very well. Right. So people saw the advantages of it and started learning closure.
00:17:39
Speaker
So how many people were on the project at that time, Karthik? I think at that time, six people were there on that project. So we built a couple of services regarding enclosure basically. Then I got moved on to a transport product for reliability.
00:18:09
Speaker
There we saw that there is a lot of use case of event-driven applications. And we were using Kafka for events and stuff. So we started writing a framework enclosure, which was a wrapper around Kafka streams.
00:18:38
Speaker
Plus, we built a platform where you would get monitoring, alerting for that framework, like inbuilt already. Monitoring, alerting, and deployment also. Basically, whenever you create a service with that framework, you will get the infrastructure as well. So that framework is called Ziggurat.
00:19:08
Speaker
We started building it. And so currently in Coject, we have around 200 services based on that framework. And that framework is open source also. Yeah. We'll talk about that in a minute, because it's a fascinating idea to make that framework. But we've got to get Harry on. We've got to get him. We've got to get his story. Yeah.
00:19:38
Speaker
Okay, so I worked on Ziggurat till we open-sourced it, then Haryo took over that part. That's a nice transition. So how did you end up in Clojure then? Coming to this one now. Just by the time Karthik was working on the allocation systems, which was one of the first Clojure services at Gojek.
00:19:59
Speaker
I happen to join GoPay, which is the payments. So Gojek is like multiple products in one app, right? It's a super app. And it's a whole payment side of it, which is like, you might think of it as PayPal.
00:20:15
Speaker
When I moved there, before that I was pretty much working with Ruby on Rails and JRuby and some React here and there. I had also used various languages in my college projects, but professionally I was mostly using JavaScript and Ruby.
00:20:33
Speaker
When I moved to Gopay, I got the exposure to write services in various programming like this. The team was small, everybody was trying to explore different things of their interests, and there was this service called User Service. So Gopay had their own user profiles to manage depending on the KYC and the kind of compliances you will need in the payments domain. So this service was written in Clojure, and this was the first service I got to interact with and work on which was in Clojure.
00:21:03
Speaker
So that's how I started working with Closure. And soon after that, I got an opportunity to build applications using Kafka Streams, again in a parallel universe. Karthik was also working on something similar in other teams. So I initiated a couple of applications and we were basically processing business entities as events and doing some sort of operation on top of them.
00:21:31
Speaker
As and when we receive those events and soon after I got to know that a team was working on a framework to do this again and again and I realized how important was that at that point of time in project because when I was writing those services in go pay it used to take us at least a month to.
00:21:51
Speaker
get us that application into some shape to take it into broad or serve some particular use case well and Karthik's team's goal at that point of time was to reduce that time to five minutes or so by building a framework which would set up such applications with these four developers. So that's how I transitioned to that team and
00:22:15
Speaker
did a lot of conversations on why we were doing that in the first place, enclosure, and why were we building a platform around it, and eventually ended up working on the same framework as well. So yeah, two different streams eventually merged and diverged again. So now I work on the overall event platform for Gojek. We work on application tooling to both produce and consume events and process them on some schedules or asynchronously and
Adopting Functional Programming
00:22:44
Speaker
whatnot.
00:22:44
Speaker
as Karthik goes ahead and builds the observability platform of our reads.
00:22:55
Speaker
So how was the transition for you? Because if I heard you correctly, you were doing Ruby on Rails and a bit of other languages, and then you picked up Clojure, and then how easy was it for you, or how much your brain has changed to pick up Clojure? Because there is a certain level of difference between writing Ruby versus Clojure, right?
00:23:17
Speaker
If I can be frank, it was daunting at first. And I think I will credit a lot of time that I took in writing that first application to this dauntingness. And if I didn't have any people who had exposure to writing closure before, it would have been months, if not years, to build that first service. Because the paradigm was very different.
00:23:43
Speaker
I had gotten accustomed to thinking in a certain way. Thinking of looking at the real world around me and modeling it as is into the code and making it as transparent and flexible as the real world. So that has been the key to build software till then. And then suddenly changed from that to think about data as a primary thing.
00:24:10
Speaker
and operations on data like as your functions. And I derived a lot of help from all the community things that we were doing at coaching. So we used to have these internal talks and discussions on like, why first class functions are important or why will you need them? What can you achieve with them?
00:24:30
Speaker
And those things definitely helped. Participating in those discussions helped me open my mind a little. But I still consider myself as a newbie. I think I'm still exploring how I could approach the functional domain in a more coherent fashion. And I won't say I have gotten it as used to as I had gotten to the object-oriented world, because it had been some years, and I think it will take me some years to learn all that and think purely in a functional way.
00:24:57
Speaker
But I am really liking the journey, because it gives me another perspective to look at the code base. And I definitely like the concise this in the code base, which comes with a listy taste and this bit touch. And just the fact that everything is a form and you don't need to. And for you, sorry. So, so as Hari said that code base is very precise and stuff, right?
00:25:23
Speaker
So when we did a presentation at Euroclosure, we show a slide where our Go version of that code was around like 100 lines of code. But then we translated that into cold closure that was like around eight or nine lines. And that was our
00:25:46
Speaker
main logic basically that was an algorithm to find and filter drivers and that at that time our product manager just like would just open the code and see what algorithm is running right now. So it was that simple.
00:26:03
Speaker
Nice, but how was your before going into the detail of this one because I'm curious about your Closure learning journey as well. So so when you started there were no closure people at gojek or there were some some people who are Already experimenting with closure, but not not in production. Is that right or there was something in production at that time? it's gojek there was nothing in production at that time in closure as far as I know but
00:26:31
Speaker
We got a help from Nilenso and Nilenso at that time was our CTO. He was very well-versed with closures and function programming. So he helped us, Nilenso guys helped us. So I used to pay a program with them and learn how to write idiomatic closure code and stuff. They would review my PR and leave some hundred comments.
00:27:01
Speaker
So I just used to go Google search and see how can I do better this enclosure. So like if I remember my first task was to implement his tricks in our API calls. Yeah, Netflix. Netflix is basically a circuit breaker. Yes. So like
00:27:27
Speaker
it was very hard for me. I like it took around 10 days to just wrap around these closure things, right? Like, what is deaf and like, how does it work? How can I write a wrapper over it? So it was like, earlier, it was very hard. But then Abhinav from Linzwa helped me a lot. He played program with me. And then he explained me this, this, like,
00:27:57
Speaker
this thing worked that way and stuff. So that's how I got it. So basically thinking enclosure. Yeah, thinking enclosure. That's the one. Yeah, yeah. What was the biggest change though? Because the thing for me anyway was the idea of immutability was the trickiest part. Because I think you can kind of get what map does and what filter does. But the concept of immutability was like this. I mean, it seems obvious now, but at the beginning, it wasn't very obvious.
00:28:29
Speaker
So for me, immutability part was OK. I could understand it. But for me, it was like I was coming from very Java-ish background. You will throw exceptions. You will catch somewhere and then write offense. So that was a very hard part for me. How will I add more conditions to this thing?
00:28:59
Speaker
So at that time, those were very hard problems. But now, these are very trivial things. Now, I know how to write them. Those are very simple things to write. What kind of things? You mean like flow control or pipelines or what? Flow control. Sorry, I'm not getting the flow control and pipelines part. Can you please explain that?
00:29:29
Speaker
What you were saying, it was you wanted to add more constraints and accept. And you were struggling with how to do constraints and how to manage exceptions and stuff like that. Yeah, it was kind of very basic problems, not that very hard. Those are basic problems. Yeah, because you're trying to match your previous ones and then trying to use the same kind of things in enclosure, initially. Yeah.
00:29:59
Speaker
That was a hard question. Yeah, I think I understand what you mean because I think I used to have the same thing when I was writing Java a lot, I think almost for seven years or 10 years. And then you start with Clojure and like, OK, I'm used to writing a class for everything. I'm used to write, you know, accessors and getters and setters and all that shit for everything. And then you start with Clojure and like, OK, where do my classes go? You know, that is the first thing. Because every other language basically is trying to do the same thing, right? JavaScript has somewhat quote unquote classes and then
00:30:28
Speaker
You know, Ruby has classes and well, has classes and everything. All the mainstream languages have the same similar concepts, but coming into closure, like, Oh, there is no class. And it's super confusing. Like, where do I start? And I think that is the, probably the biggest change for me as well, to, to shift into closure mindset. Nice. So what is your stack by the way? Yeah. Sorry. Go ahead. One more thing was like a lazy evaluation. Yeah.
00:30:57
Speaker
It was hard. That was one thing I was struggling to understand how this will work. Yeah. So what does your stack look like right now? Because you said almost there are 200 plus services running in Clojure right now. So what kind of libraries that you guys use and what is your stack?
00:31:26
Speaker
Hari, you want to take that? Yeah, many different things. Like, first of all, I think I should mention that 200 is just a very small part of our whole ecosystem. There are way, way more number of applications and the number of developers we have. It sounds very heretic after we think about, and it's still, after we think about that, it was just a Java monolith when it started. And now it's like,
00:31:56
Speaker
this whole bunch of services. So we use various libraries and tools. Most of the times it is line engine profiles based development environment. And we do use a lot of Java libraries, to be honest. For example, Kafka Streams is a Java library. And one of the primary reason, if not the most important reason,
00:32:27
Speaker
to pick closure to build this framework was the capability of direct interaction with Java. Because if you think about writing applications on top of Kafka events themselves, Kafka Streams, which is the Java library put out by Confluent, is pretty much all you need if you want to do something on top of Kafka events.
00:32:54
Speaker
in a stateful manner or maintaining distributed state or whatever. So yeah, a lot of Java applications or libraries apart from them we use. For HTTP we use ring. We have ring gaze routers and we do use a couple of things that we have written on our own to wrap on top of a popular.
00:33:23
Speaker
The third-party dependencies, we do use Sentry for error reporting. There's some sort of wrapper on top of it, some sort of wrapper for New Relic, some sort of wrapper for a Stash team matrix. So there are a couple of those libraries, and definitely not to forget something like Langor, which is a wrapper for Rabbit and View Connections. It's a very popular global library. I don't think it just saves the day for us because a lot of logic for retrying events
00:33:53
Speaker
works on top of RabbitMQ. So yeah, that comes to rescue. I think there are a lot more that Karthik can add to the list. Yeah, so Carmine for Redis. Yeah, yeah. And Cheshire for serializing, deserializing. Yeah. Well, maybe the more interesting question is like,
00:34:18
Speaker
uh because like you know like you say probably a lot of libraries but um in terms of like event driven architectures
Event Handling with Kafka and RabbitMQ
00:34:27
Speaker
it seems like you're already you're already looking at like three possible event driven models because Redis is event driven or it could be um you know it's got that possibility with the subscriptions etc you've got RabbitMQ you've got Kafka so how do you play with all of those things you know uh because that seems like it's a bit of a
00:34:48
Speaker
It seems a bit confusing to me because I always think that you should have some canonical event stream rather than, you know, a variety of multiple, multiple, you know, I'm a simple minded person. So tell me, educate me. So, uh, we use Kafka as our primary event, uh, streams, right? Then, uh, we use RabbitMQ for retrying purposes, right?
00:35:16
Speaker
So I'll explain you. So Kafka has some partitions. And even if you don't commit a message, the next message you will not get. So suppose if you get a message and our framework processes it, and somehow that messages is not able to process because of some downstream service failure.
00:35:43
Speaker
So we would not want that other message to get delayed. What we would do is we would commit and put this message into RabbitMQ. Then that can be iterated later so that we don't have lag in the Kafka queue. OK, so your consumer is not just blocked by unprocessable messages. So you can continue moving the offset in the consumer group so you can consume the messages better. Yeah, correct. Exactly. OK.
00:36:12
Speaker
And RabbitMQ is for your retrying mechanism. So you take, if it fails, then you're going to use RabbitMQ for retry. Yeah, retry, retry after 15 minutes, after 20 minutes. All these are, like, you can configure all these stuff. Yeah, so let's say you also wanted to go. So where does the Redis thing come in to picture them? Maybe we'll come to that. But on top of RabbitMQ, you could also do some sort of delay processing, right?
00:36:36
Speaker
So let's say you have a filter on top of your incoming event stream, right? And you want to say, these particular type of messages, I only want to process after 10 minutes after I see them. Because maybe there is some sort of implicit delay in the business process, which takes 10 minutes to happen. Like, for example, some manual KYC update or something.
00:36:55
Speaker
So you could do synchronous processing using RabbitMQ. You could channel those messages, as we would call it in the framework, for later. So that is another use case we use RabbitMQ a lot for. And also exponential backups, maybe, or linear backups. So just a quick question, though. Why do you use RabbitMQ and not just another partition or another channel on Kafka? Interesting bit.
00:37:24
Speaker
In Kafka, it's the obvious question. Yeah, I think that's a pretty good question as well. So in Kafka, I think you cannot control the delay part. Yeah. Right. In RabbitMQ, it can be handled by RabbitMQ easily. So that's why we went ahead with RabbitMQ instead of one more topic or partition.
00:37:47
Speaker
Yeah. And also, I think in RabbitMQ, the streaming semantics, the default ones are a bit different. Because if one consumer connects and then it consumes message, then other consumers won't get that one. Because in Kafka, everybody can. Because Kafka is storing those messages. But RabbitMQ, by default, so far, I think that it is a new version now to keep the messages anyway. If you pick up the message, and then it's gone from RabbitMQ. So it's way more important. But doesn't it cause problems in terms
00:38:17
Speaker
Like, well, you designed the system like diagnosing when things went wrong because you have to look in two different places. Hmm. Yeah. I think it's, it's not your question. No, I'm talking about rabbit MQs, technical things. I don't know the domain, you know, what they're, they're dealing with. It's like, it's like when you are doing.
00:38:42
Speaker
like off-piste transactions as it were, you know, on anything, whether it's a database or an event system. Having to look in two places is always like more problematic, I think. I mean, it can be for good reasons, but as far as I know Kafka has batching, but you know, maybe I don't know well enough. I don't know as well as you do, but okay. So you pick it for this particular reason, but then when you retry things and it goes wrong, you have to do diagnostics. How do you like,
00:39:12
Speaker
How do you counter, how do you do transactions that reset things? Because it seems like you have to do it in several places. If you found there's a downstream thing. How do you reprocess that? Yeah. Because you say you're committing them and you say it's worked, but then it hasn't really worked.
00:39:36
Speaker
You're making more complexity because you're sweeping it under the rug a little bit. Yeah, so two things Ray. I think the two semantics that really come into play are, first of all, we leverage a lot of item potency. So we recommend the systems, the downstream systems or upstream systems, which
00:40:03
Speaker
which are even processing calls after receiving a message to be idempotent in the first place. Why we do that is because, let's say, in the Kafka pipeline itself, let's say there was no RabbitMQ. I could have picked up a message, processed it, but there could have been a failure to commit the offset back to Kafka, so I would have processed it again when the development really starts. So idempotency is definitely something which we recommend highly to all the users of our framework.
00:40:32
Speaker
Another thing is the semantics basically go about at least once guarantee and not just exactly once guarantee. So it's not that strict. So we are OK if we can process the message more than once in some cases.
00:40:51
Speaker
but we are not okay with the loss of message. So I think that's basically where the answer to your question lies, that with those two concepts and like semantics baked in, we rely a lot on the downstream or upstreams to basically do or maybe like maintain item potency or not do repeated transactions.
00:41:16
Speaker
Yeah, that makes total sense, yeah. So where is the Redis thing coming into the picture? No. This King on the side. Redis is everywhere at both ends. So that seems like adding one more, it all sounds like Indian masala, you know, like to make it spicy.
00:41:36
Speaker
No, no, I think we use this just for cache. Okay, caching, okay. So you're not using it like a stream processing? No. It's not basically part of the framework, but it's basically a first primary extension in most of the use cases.
00:41:54
Speaker
So we don't actually provide any Redis management into the framework. But if you look at the 200 applications, I think 80% or 70% of them would have some use case to maintain some sort of key value store or just cache, maybe persisted or non-persisted for their state. Yeah. Makes sense. Yeah. So the framework that you released as open source, can you explain it like I'm five or?
00:42:25
Speaker
Um, so what, what can you do with it? So what, what, what is the idea behind it? Yeah. Okay. So, uh, earlier, uh, so as I told you, right, that, uh, we, we saw that, Hey, there is a lot of use case of, uh, even different things like booking, create it, send a notification booking, create it, find a driver, right.
00:42:53
Speaker
So one part of the framework is like you can consume events and act on those events. And one part of the framework is serving HTTP requests. So if suppose there is a system which consumes a driver location,
00:43:19
Speaker
driver pinks, basically. And it persists into its DB and you can put some APIs on top of it. And then you can show on your customer app. Basically these are the drivers which are nearby your location. Yeah. So, uh, like thinking of these all use cases, we, we, we basically have two main parts of our framework. Basically one is HTTP part and another is event consuming part. Yeah. Like any,
00:43:49
Speaker
Like if you're consuming event, you can also, there is one part, there is one small part which helps you to produce the event as well. Back to Kafka. Yeah. So basically the, like two major parts, basically event processing part and one HTTP part. Okay. Yeah. So why are the two things related? Because, you know, are you, are you kind of like, are you using Kafka as a kind of like,
00:44:17
Speaker
mechanism for producing like asynchronous results on the HTTP layer. Got it, got it. A lot of friends. A lot of friends, yeah. While it also works as a source for a lot of business data, there are a lot of processes which are just enqueued for the later processing or batch processing as well in Kafka. So do you use this like async version of ring?
00:44:45
Speaker
to do that or are you doing it somehow or that? No, we don't do the async version of sync. Okay. So how do you get the answer then? You have some sort of like request players in Kafka and some sort of response players in Kafka, you do some sort of correlation ID or
00:45:09
Speaker
Yeah, we do some sort of correlation ID. Basically, if for an instance, like I gave an example of drivers and showing drivers on customer app. Basically, here the reference is location. We store driver by location and then customer apps ask that, hey, give me driver for these locations. So location, basically longitude and latitude comes as a reference in this scenario.
00:45:37
Speaker
And other things, they are a customer ID, booking ID and all this stuff. But that seems like, like, so, so you're treating with the Kafka streams, you're treating Kafka as a database, essentially. That's really the kind of idea. Yeah. So it's not like you're putting like for the customers, you're not putting, uh, uh, you're not putting like, uh, maybe as you are putting a request on Kafka, but you're answering it by the K streams. Okay. SQL.
00:46:07
Speaker
Not a lot of times. We are not actually yet evolved to using kstreams a lot. Certainly not using ksql a lot. Although we have started building on some use cases of doing stateful joins on kstreams. But a lot of times processing happens outside kstream. And kstream gives us possibility to react real time on top of events rather than to
00:46:36
Speaker
manage stateful operations in real time. I think those use cases, although are very common, but they don't come as naturally to developers as, like, first-class functions don't come as naturally to object-oriented developers. If I can take that leap of faith into it. Sure, sure. But what I'm trying to think of is, like, the driver locations are changing all the time. And the customer is, like, usually staying pretty, pretty, I mean, maybe they couldn't move, but they're pretty, they're pretty static, I guess.
00:47:06
Speaker
So as the events come into the system with a new driver's location, one can imagine that that would just be a stream of events out to the client to say, here are the new locations. But it seems like, are you doing HTTP or WebSockets at that point? A lot of time, gRPC as well. It's a hybrid model. We have WebSocket, gRPC, and HTTP.
00:47:31
Speaker
So I've seen the whole clickstream architecture at Project, right? A lot of part of it is also open-sourced. So we have this whole mobile analytics or mobile best-based event processing, which works on top of WebSocket connections between mobile and Kafka backend. There is a user library that we have written in open-sourced inside data engineering team at Project.
00:47:56
Speaker
which goes ahead and builds that long-term connection for you. While at other places, between back-end systems and the Kafka, we have a GRPC-based long-running connection on which you produce real-string of data to Kafka directly. So it's a hybrid model. Earlier, it used to be a plain HTTP-based model, which we have replaced with GRPC-based model. So are you guys looking at, like, HTTP2 as well? Yeah. Not in the raw form, but with GRPC most of the time. Yeah, yeah.
00:48:27
Speaker
Interesting. So is closure only with the stream processing level or is it used for front-end stuff? Is it used for mobile things as well at Gojek? Not much. There are a lot of places where it is...
00:48:46
Speaker
sometimes for credit as well, which I've seen practically happening at some places. But if you see most of the closure adoption at Gojek happened because of the Zugrat framework that Karthik and his team started and then I also worked on. So the majority of closure applications are these Zugrat based applications. These are a very opinionated set of applications which we call actors because they act on those events.
00:49:12
Speaker
Apart from that, they are very... That's a confusing name for it. I won't disagree. As long as you don't have Akka or Actors in the system or in the head length, people come from all that. It's like, whoa, dude.
00:49:32
Speaker
or Acre or Scala people. If you don't have them, then, you know, the only... Yeah, let me drop another bomb. Yeah, let me drop another bomb and say the whole platform of which we built this framework and utilized it with was called Lambda. So, I'll tell you, it was kind of an inspiration, like you just write business events, business functions. We will handle everything, basically monitoring, alerting, all the deployment,
00:50:00
Speaker
So that's why we call lambda at first. We envision it to be just a closure function for the lambda. Yeah. It's a nice idea, I think. To answer a previous question from Ray, sorry to interject. I just wanted to go back to one question that Ray asked before. You mentioned how would you go about
00:50:27
Speaker
looking at various transactions which are distributed and wouldn't it be painful to trace different parts of the transaction and go back to like what was the original source of what happened.
00:50:40
Speaker
As Karthik mentioned, we wanted to do a lot of things out of the box for developers at GoCheck. We wanted to provide a lot of things out of the box. So we have a metric contract with Ziggurat. So each application, when it starts and processes messages, they will emit certain metrics by default. For example, if the message was processed with success or retry or failure, if there was, let's say, some sort of
00:51:08
Speaker
exhaustion of retries. So all those things basically, as soon as you create an application or an actor, you get a dashboard out of the box, which has all these numbers put up. And you can definitely go ahead and correlate with the logs at that point of time.
00:51:29
Speaker
We were also working on tracing support with those applications so that we can have a correlation ID floating across, or a tracing ID floating across the logs and the metrics. Although that is still in alpha, and we haven't tried it at scale yet. Like the New Relic type stuff. Yep. Yeager type stuff, basically. Say that again. Yeager, basically open tracing.
00:51:57
Speaker
Open telemetry base. Yeah, that makes sense. So that's what you're talking about. It comes with the traceability included in the framework. So you can just deploy it and then you get all these features by default. And without that platform side of it, the lambda side of it, I don't think road adoption would have kicked off that easy as project. Because people who are not very familiar with it,
00:52:27
Speaker
They are pretty much scared because of the syntax when they look at it for the first time. But when you give them a dedicated place or let's say an editor window where you just have to write a function, it comes off a little easy. And given all the platform features on top of it,
00:52:48
Speaker
But the management becomes that easy. So you are pretty much more inclined towards using the reusable components. And I think without that, it's tricky. That's how you sell closure by basically having a lot of value-minded services on top of it. So then the people have to come to closure in order to consume. Yeah. And the primary asset. How big is the team right now, by the way?
00:53:16
Speaker
sorry, the whole framework team or... Sorry, go ahead. Can you come again? No, sorry, go ahead. You said you're talking about the... Yeah, no, please continue. You're talking about the primary asset. I'm interested in primary asset. Oh, yeah. I think the primary asset that we were trying to save was time. As I mentioned, it used to take us two to three months to build such an application before, right?
00:53:41
Speaker
And another important fact, I think, a story I should mention is we had this whole Ruby on Rails microservice, which was becoming a pain in the ass at the moment. And it had so many dependencies that every time on Friday afternoon, it would start going into a crazy load. And one of the dependencies will start faltering. And there will be this huge cascading effect across project applications.
00:54:10
Speaker
suddenly in five minutes, like 50 of them are down and we don't know which one started what. And at that point of time, we didn't have a lot of tracing into the picture. We didn't know how it started until unless we could actually go back to a correct metric, which will point us to the start of the event.
00:54:26
Speaker
So we wanted to reduce those dependencies for write service which is the OMS for the transportation which is one of the main businesses of project. We wanted to reduce those dependencies and when Karthik and team started writing the first replacement for one of the dependencies
00:54:44
Speaker
They saw that it took a couple of months to get it out in the production. And to replace 17 more dependencies like that, it would have been taken like 34 more months.
Ziggurat Framework Capabilities
00:54:55
Speaker
And we wanted to bring it down to 34 days. And that's the primary thing that we saved by making this framework and without the platform side of it. Yeah. The first use case was sending notifications to drivers and customers. Yeah. Yeah. Yeah.
00:55:13
Speaker
Yeah, that's a good one. Yeah. So how many maybe I asked the team size and now I'm also wondering what is the size of amount of people who are using Gojek app right now? Crazy crazy numbers. Because you're now helping, you're delivering stuff to so many users, right? That is the biggest metric that Closure is bringing the value to.
00:55:43
Speaker
They can say, OK, you're processing billion messages, but they're actually turning into functionality for end users who are doing things like transactions, ride hailing, whatnot, and everything. Basically, we have around more than a million drivers in the system. Wow. OK.
00:56:10
Speaker
And I really don't know about how many customers we have. It will be more than driver act.
00:56:21
Speaker
Yeah, I think that the scaling, the scale is different in the market that you're playing right now, right? You're serving. So it started in the Philippines, but now you said it's expanded to other countries as well now. Indonesia. It started in Indonesia, then we expanded to Thailand, Vietnam, then we went to Singapore.
00:56:42
Speaker
OK, so if we ever land in any of those countries, the first thing that we should do is install the super app from Gojek. Gojek, yeah. Makes sense. To get from A to B, to pay for food, to eat, and I don't know, to breathe air, everything is from the super app. To get your grocery medicines, to have like massage or something. Wow.
00:57:11
Speaker
OK, nice. So do you guys use things like spec or Mali or something to validate your interfaces or in the code, the data validation, anything like that? We use a lot of spec part. No, OK. Or API request validations and stuff. OK. Yeah. I see. I guess that's how you manage
00:57:41
Speaker
like the event messages are as well? Or do you use some of the format of data? For event messages, we have a protobuf defined for every event log. Right, OK. So that's your schema. That's our schema. Yeah, that's our schema for any event. OK, nice. Yeah, protobuf and closure don't play very nicely, though.
00:58:07
Speaker
Yeah, you're right. I had a hard time figuring out some bug. I don't remember it right now. It took me a week or something. Yeah. I think it was not built. I think Closure plays well with Transit and Eden and all that stuff, obviously, and Jason, I think. Rotobuf is more a go-level thing, rather than some guessing. It's rather mild to go this far. Yeah.
00:58:35
Speaker
It's all very static, isn't it? That's really the problem. Yeah. Interesting. So we've been, as we say in India, I think I should use Hindi now. No, I don't want to. We've been praising closure. I have to say, like, gungan, something like that in Hindi. So what are the challenges that you face? Like, OK, these are the things that are
00:59:03
Speaker
you know, making our life difficult or made your life difficult using closure. So first part was basically knowledge gap, right? Only few people knew closure and they would become a drug factor. So first part was learning, obviously.
00:59:31
Speaker
So that's why we started our internal book club, or you can say boot camp for Floyer so that more people are aware of this stuff. And rest to be honest, you can Google and learn that language, right? You can Google and learn that. The learning curve was very steep for this one. And spreading it across growth was
01:00:00
Speaker
tough job, but Ziggurat helped us to scale in logic. So yeah. Nice. So you still find like Harry was kind of like hinting at that there's some resistance still, you know, that they're a bit scared or a bit nervous. There are some developers out there that aren't like first love is closure. A lot of people who have used Polar, I don't think that Polar has become their first caveat.
01:00:31
Speaker
So they are still writing a lot of their applications in Golang, at the same time that they are writing a lot of these Google applications. So there is still a diverse tech stack at Google, employed at various teams having their own choices, some still writing a lot of Ruby and various boards, a lot of them writing Java code, some of them writing Elixir, some of them are very heavily in the lab, like Golang. So very, very wide variety of stuff happening all around.
01:01:01
Speaker
But resistance has come down a little bit. But it has come down for sure because of the adoption that has happened in recent last three years. It has come down a lot because people who had never written it before now have deployed applications in production and that there is nothing better to boost your confidence than deploying some piece of code to production. So yeah.
01:01:31
Speaker
Like it just take only 10 minutes to deploy a simple hello world into production. So how do you achieve that part? How do you achieve that part? I mean, are you like all on the cloud or do you have a specific like ISP or some sort of like DevOps thing that's like making this super fast?
01:01:56
Speaker
As as I told you right as Harry also told that we have built framework plus platform, right? Basically framework will help you to write code faster. Platform will help you to deploy monitor right? These all stuff so DevOps part is also there. In adoption, basically I would say that because deploying things. Like there is a.
01:02:24
Speaker
If you write code and don't deploy, then there is no use, right? So DevOps also played an important role there. How do you do that, though? Is it integrated with some sort of terraform stuff? Or how are you actually doing the deployment integration with Kafka or enclosure and all these things?
01:02:50
Speaker
Okay, I think I think you should definitely talk about the image management at the deployment pipeline. Sure, sure. So basically, so there is a command lambda actor new. When you type it into the console, you will get basically a service service bootstrapped with a ping API already. Right.
01:03:20
Speaker
and there is a Gitlabs here if I'll already put it. And all the linting is also taken care of. So in Gojek, we heavily rely on tests. So test framework is also, we bootstrap test framework as well into the framework. Basically, you can just modify the function
01:03:50
Speaker
make test pass. So when you upload, when you check in your code, we have internal GitLab posted. When you commit your code there, GitLab CI takes over that part. It takes care of limiting, it takes care of your test cases, it takes care of your
01:04:18
Speaker
packaging of applications, pushing it to the Docker or Debian artifact tree basically. Then when you deploy, we create VMs or Kubernetes based on a customer's choice, basically developers. We create VMs for those particular
01:04:43
Speaker
And then to create VMs, we use Terraform and to orchestrate things on VMs, we use Chef. The deployment is on your own data center then. It's not on cloud. It's totally on cloud. It's totally on cloud, GCP. Oh, OK. But you schedule your own EC2 instances. Not EC2.
01:05:13
Speaker
Compute Engine Instances. Basically, it is similar to EC2 Instances. Like there is part of the company which is a product. Yes.
01:05:31
Speaker
Yeah, I can imagine when you're such a big company, then there'll be different teams using different text tags usually. And especially because Gojek has evolved a lot as startups. So at one point in time, I have looked at Gojek operating as 20 different startups. And over the years, we have acquired a lot of different companies as well and merged with different companies as well.
01:05:58
Speaker
So we have inherited their tech, their stacks, and their cloud networks. So it's a pretty much amalgamation of all things. One important aspect that goes a little beyond the development lifecycle, but comes very handy in deployment lifecycle, is config management.
01:06:18
Speaker
So because when we started, we wanted it to be all productive, right? Like developers to be very fast and like flash and making their applications and deploying them. We build a very simple command like lambda actor new or lambda config. So with framework you would, as soon as you create the application, you will get same full defaults with the application.
01:06:42
Speaker
ready, baked in. And you could just tweak some of them depending upon your environment of your choice. If you wanted to set, let's say, some top machine that's found to one in integration, you could just do that with that command. And that has come pretty handy as well, because on the CLI itself, you could manage your configuration, and then just after saving the configuration, you could just hit Lambda actor deploy and be done with it. Yeah. Yeah, that's nice. Yeah.
01:07:13
Speaker
Sorry, go on. I was going to say, one thing about, because it's like interesting you chose Kafka, because I guess again, you're looking at doing things that are like cloud, portable, portable across different clouds, because, you know, Google and Amazon both have their own kind of, you know, they have KSS, Amazon, and they have, I think, I don't know what the what the Google thing is called, but they have all kinds of streaming architectures. I know that much.
01:07:43
Speaker
Yeah, Google functions. I'm not sure on GCP if they ask. I don't think they have anything like Kinesis, any AWS Kinesis. No, they do. They definitely have a whole framework to do event management. Yeah, PubSub thing. Google PubSub thing. Yeah, it's nice. We were talking about challenges a little, right? One of the challenges I think that has been very prominent is
01:08:13
Speaker
We have built Ziggurat as an internal open source. We've had a central small team, but we always went to the developers at different product teams, worked with them in collaboration and build features. In the process, we got more than 30 people to contribute to this framework from different product functions. In this process, to keep code very idiomatic and
01:08:43
Speaker
to keep it more fresh to the eyes has been a little tricky. Now, at this point of time, after three years working on it, it feels like it could have been a much more composable set of libraries than just one overarching thing. So that has been a challenge to how to design both as a library and as a framework.
01:09:12
Speaker
to power applications at scale, but as well as to keep it handy for people who don't want to totally fully leverage the framework, to keep it composable as well as more encompassing. I think that has been also a challenge. And I think we are seriously looking at redesign at this point of time. For which we could definitely use something. I think it's not the case.
01:09:40
Speaker
Yeah, like when you have an organic thing like that, obviously it's had success. But like you said, you want to have continued success and continued adoption. And if you've got so many people contributing to it, you've probably got all kinds of new ideas as well in the last year or two. Yeah. For example, Karthik and me both had very different ideas on how we wanted to do multistreams.
01:10:08
Speaker
So yeah, it has evolved into a lot of days. Do you want to fight everyone here? Fight it out and then decide. We had the fight two years ago. You heard it here first Fox. So I did not want multi streams. Basically consuming from one or more topic. I want it to be very simple.
01:10:34
Speaker
But as use cases grow, there are more services than developers in project. So to manage that also, we had multi-stream and there was several use cases where you have to join two Kafka topics and make some things out of data. Those use cases started coming, those
01:10:58
Speaker
requirements started coming in from developers that, hey, we want this, we want that. So that's how we built multi-stream into that. So I think we are almost in a one and a half hour now. I think we are keeping you off on a pretty much late midnight. I also have one more question about closure and I'm curious about the state of closure in
Clojure's Rise in India
01:11:25
Speaker
India. Like, you know, what is the
01:11:27
Speaker
How is the community there? Because I know a little bit about what is happening in Western Europe, because I'm involved in closure stuff here. We keep hearing a lot about closure in the US, obviously, because that's where our Church of Closure or the Vatican of Closure is in the US. So we know that. But in India, I think it's... So what is the situation there? How many companies? Yeah, where is the Temple of Closure in India? Well, I don't know about the temple, but the temple is definitely high.
01:12:00
Speaker
I have seen people around who are writing blogs on Closure. In my team, a couple of folks are actively starting to write about Closure and their blogs and their personal websites. There is an active Bangalore community which hosts a meetup every month. I recently went and gave a talk about secret in that as well.
01:12:26
Speaker
There are certainly more companies than before who are actively writing project code in production. A couple of them we started to talk about in the beginning, right? There are a few more, I think. Fraction, I think, seems to be increasing, but not as much as you would expect.
01:12:48
Speaker
Yeah. Yeah. I think it's, it depends on, it's like a catch 22, right? More jobs, more people learning closure. And then, you know, then it becomes like a cycle of, uh, you know, kind of that they're feeding into each other. Oh, but I think already is that what I find interesting about your stuff to some extent is that, you know, you're, you're making your own decisions. And I get the impression that a lot of, and a lot of like,
01:13:17
Speaker
larger consulting companies, they don't get the choices, you know, they're essentially, they're, they're, they're working on prescribed architectures. Whereas, you know, you've got the chance to own your own architecture, and reflect on those things and make your own decisions. And I wonder if that's a difference, or if it's just like the, like, just the ingrained nature of all in the community.
01:13:44
Speaker
Is that how you have seen things as well Vijay? Because in my experience, I have always seen consultants to come with their own prescriptions and their own recommendations. When I was a consultant myself six years back, I have seen my team coming with their own recommendations. Although there were some constraints put up by how legacy the systems were at a particular target company.
01:14:12
Speaker
But we never shied away from recommending tools. For example, we recommended a lot of DevOps practices to companies, right? I was in a DevOps consultancy before. So I do this with the chef or NC Bellarm puppet, go change this whole deployment pipeline on Jenkins. So although Gojek has provided that open environment a lot, I think consultants have played a vital role in
01:14:44
Speaker
So there are closed evangelists going and then telling people that there are better ways to do this stuff. And then converting them into the church of Richeki.
01:14:59
Speaker
Nice, so I think it's a that's a good way to conclude the episode But I'm thinking you know that the last question probably that the really last question because we started with favorite foods And I'm wondering like what is your favorite sweet thing you know like the in India everybody eats sweets a lot obviously So we should do like what is your favorite sweet dish? How is that is it? My favorite is
01:15:28
Speaker
or the Bengualist would call it Rosabola. So it's basically a sweet dumpling, dipped in sweet chashni. I don't know what we'll get started. We don't need to reduce, you know, the simplest words to explain such a complex dumpling. No, it's not.
01:15:55
Speaker
It is something which doctors recommend you, if you are... Deep fried, deep fried though. Deep fried sweets, doctors recommended. But there's no purposes only.
01:16:07
Speaker
So actually, if you have some upset stomach or something, you would just wash a rasgulla with room temperature water and have it. And because it's made of something called chana and it's so soothing to your intestines, it actually helps you with the digestion. So yeah, it's a good sweet. I think it should be made religious or something.
01:16:36
Speaker
Always in indigestion. Mine is also on similar lines. I like raspolite. Sweet dumpling. But it is in saffron milk. It is dipped in saffron milk. Yeah.
01:17:00
Speaker
I think I would I would need something called Mysore Park. I think it's more south thing. The chickpea solid chickpea sugar brick chickpea flour sugar brick pretty much. I think that's the one. Dumpling is still better than a brick. It's not sugar dumpling, unfortunately.
01:17:24
Speaker
It's a solid block of sugar and chickpea flour. And gee. Plenty of gee, I think. Yes, exactly. It's amazing, man. I love it. And for you, Ray, you have to pick some Indian sweets now. I don't know any Indian sweets. But not enough. I think the Indian sweets are very sweet to my taste. Oh, yeah, they are.
01:17:53
Speaker
It's a shock to the system to me. I'm not really that familiar. I like licorice.
01:18:01
Speaker
That's how it's more like a Japanese sweet. Yeah. Because we were just talking over the dinner, like, you know, like in India, there is a state called Gujarat and they're very much into sweets. Like they eat only most of the dishes are sweet. And we're just wondering, how did they survive? I think they evolved to process sweet and the people who didn't evolve, they just died off. And then now they can they can tolerate so much sweet in everything.
01:18:28
Speaker
But any Gujarati people listening out there, I apologize for insulting your people. But I know. We love your sweets, too. Anyways, on that bombshell. So you haven't asked your favorite question yet, Bijan.
01:18:43
Speaker
Yeah, yeah, we're getting there. That's my next or the final one, because now we have two people here. So I think we'll start with Harium then. So Harium, you know, Emacs or some other shit. Oh, what do you use? Oh, I was waiting for this one. So I heard some of your podcasts before joining in today. And one of the parts of the podcast that caught my attention was this last part, where you would ask them Emacs or not.
01:19:13
Speaker
There are no Emacs for me. I am pretty much a VM user. I have been a VM user for the last six years. I heavily rely on Firebase to do my closure work. Although I'm not against Emacs, I don't have anything against Emacs. I keep trying it on and off, but I never got used to it. So I just stick to them for my coding purposes.
01:19:42
Speaker
But maybe next time we meet, I might get my answer. You're not people, and you're not ways of doing stupid shit. I know. Now I'll introduce the divisions in India and all. People up north doing BIM and other random shit. And we people in the south, we know better. We use EMACs in India and south. Anyway, I'm not Indian anymore, but I can complain loudly. A new Karthik.
01:20:11
Speaker
I use cursive. It's Bangalore city boys. You might have more Indians on the podcast.
01:20:23
Speaker
You are Emacs users, so you're fucked up on the podcast. Well, we're going to find them. We're going to find all the Emacs users in India. So earlier, when I started writing clothing, I used to pair with Ned from Milan. So she was a very heavily Emacs user. She tried to teach me that, but I could not wrap my head around it. So I shifted to cursive.
01:20:52
Speaker
Hey, you should start eating idli sambar and then you get emacs. That's what they say. Now, if you're in parathas and rotis, then no emacs for you. But anyway. Parathas and roti, that's for sure. That probably explains things. That's why you stick to cursive and then, you know, paratha and roti, not idli sambar.
01:21:19
Speaker
Anyway, I think it's been a pleasure having you guys. Thanks a lot for joining us at such a late hour. I think it's almost like 1 AM for you right now. Yeah, it was fun. Thanks for taking time and explaining all the stuff. It feels like...
01:21:33
Speaker
I feel like I'm back in India. It's really nice to have that feeling, talking to Indians and then talking about all the Indian stuff. Finally, you are returning back to your roots. Exactly. Returning back to my roots. Because I got sick of Ray's stupid English accent. I can understand proper English. That's true.
01:22:00
Speaker
We love to make this joke though. Indian English is the most popular English, so it should be the canonical English, really. Exactly. If you just provide the numbers. If you provide fewer numbers, Indian English wins by a mile. Then a lot of standards in the world will be screwed with all of that. We might as well start driving on the left side.
01:22:29
Speaker
Anywho, on that bombshell, thanks again for this amazing Daisy Deffen. And hopefully, you guys will continue making Ziggurat as the only framework for Gojek, the super framework. And I'm sure your colleagues will listen to this. And they'll be like, oh, if we are not using Ziggurat, there is something wrong.
01:22:52
Speaker
they should they should use it and then eventually you will change your company name to Clojak as we suggested and you can send us there are you know revenue and royalty whatever so we are ready for that you know all we need is just five percent of Gojek revenue and we are happy you know contributing the new name
01:23:10
Speaker
So it's really nice to sort of hear success stories as well from India because like VGS says, it seems a bit, it's been a bit quiet over there, but it's good to hear that it's burgeoning and that the world is being spread and obviously it helps if you've got good frameworks and libraries. So thank you guys for doing the good work there. Yeah, thanks a lot. Just one thing. I'm surprised you didn't ask the meeting for Ziggurat or something.
01:23:40
Speaker
Yeah, I thought it's a Persian Mesopotamian thingy, right? Yeah, it's not an Indian word. Yeah, it's a base of a temple, basically. Yeah. So basically, it's a base of our applications. Nice, nice, nice. So it's the foundation of all your monumental applications built on top of. Nice. Awesome.
01:24:05
Speaker
So yeah, maybe there is one last question. We hope to see you in person, I think, soon, I guess. Yeah, sure. Would like would love to meet you folks. I must call it out that I really felt like home.
01:24:24
Speaker
Before joining, I had some jitters, to be honest. But I totally felt like home talking about all this stuff with your books. And I hope you were able to, I was able to get my ideas across and would love to discuss ideas more. Yeah, yeah, certainly, certainly. Yeah, in the future. I was very nervous joining this. You guys are really smooth, actually. You fooled us all.
01:24:53
Speaker
Exactly, yeah, yeah. Everything was perfect. I think we... I learnt a lot, you know. I never looked into Ziggurath yet, but so I'm gonna give that a try. And obviously, you know, now I know... As you said, it's like returning back to my roots. As you said. As you do that, don't forget to start the report. Food and everything. Yeah, as you do that, don't forget to start the report and get up.
01:25:22
Speaker
Yes, go ahead, check it out. It's in Gojek repository. We'll post the links on the show notes as well as on Twitter.
01:25:33
Speaker
Yeah, we are really good at that. And sometimes we do post them, but, you know, if you don't, I'll just, just search for Gojek open source and it's all, there are plenty of other projects, um, as well, uh, apart from this open source contributions that I see from your GitHub repo. Uh, so they're doing a lot of great work contributing back to the community as well. So thanks guys. Thanks. Uh, thanks a lot for joining. So I think that's it for us for today. Like, is there like.
01:25:58
Speaker
Haryom is hello. What about the goodbye? Do you have any colleagues with goodbyes in there? Namaste. We just need to have them. I think in your company there is one Haryom and there is like Namaste or whatever. The good thing about Haryom is you could use it both for greetings like welcoming someone. Exactly. Okay, perfect. On that bombshell. Namaste and Haryom.
01:26:28
Speaker
Yes. Wow. We're carpet bombing today. Thank you for listening to this episode of Deaf Hand. 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:26:56
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 Zulep or just at us at Deafened Podcast on Twitter.
01:27:25
Speaker
Enjoy your day and see you in the next episode.
01:27:53
Speaker
you