Intro
Artem Barmin: In the era of AI assistants, agents, and everything else, Clojure still gives the biggest performance boost for me, especially for backend tasks.
Jeremiah Via: I think the benefits of Clojure, just being a very practical language, being able to leverage JVM libraries, was extremely useful.
Artem Barmin: Have you connected to the production using REPL?
Jeremiah Via: I think partly the pay to do it is that you have to create the job yourself. 
Artem Barmin: So was Clojure officially sanctioned when you started to build the system in it, or was it operated a bit under the radar?
Jeremiah Via: Oh, that’s a good question.
Artem Barmin: If you were tasked to build a new system today at the NYT, would Clojure still be a first choice?
Jeremiah Via: Super Bowl moments for us.
Artem Barmin: Hey, everyone! Welcome to the new episode of our podcast series “Clojure in product: would you do it again?”
Vadym Kostiuk: And this time, we're shifting our focus to explore how Clojure survives and thrives inside the large-scale companies. And our first guest is Jeremiah, a Staff Software Engineer at The New York Times.
Artem Barmin: And Jeremiah has spent nearly a decade working on The New York Times' search system, building Clojure libraries for semantic search, entity recognition and query rewriting that powers the core search experience across the whole platform.
Vadym Kostiuk: Yeah, we'll talk about how Clojure has found its place in a six-thousand-person organisation, and what it’s actually like to maintain critical infrastructure in such a polyglot stack.
Artem Barmin: Let’s begin map over questions and macro-expand them into a real-life Clojure experience.
The main part
Vadym Kostiuk: Hello, hello, Jeremiah. Thank you for joining us.
Jeremiah Via: Hello. Thank you for having me.
Artem Barmin: Hello.
Vadym Kostiuk: Yeah. So, Jeremiah, thanks for joining us on the podcast, on “Clojure in product”. Especially for telling us about Clojure in large organizations like the New York Times. So I would like to start maybe from talking about your journey, your background, and if you could share how you first got into Clojure and what made it stick for you.
Jeremiah Via: I was first exposed to Clojure during university. I had classes with Prologue and Common Lisp, and I thought those were a lot of fun. From there, I think I was just kind of learning more about Lisp and ran into Clojure that way. A lot of my other coursework was in Java. So being able to continue writing Lisp on the JVM was a huge appeal in school. And I just kept using it all through undergrad, through grad school, and in industry once I graduated.
Vadym Kostiuk: Nice. So you've been with Clojure since then, yes? Since that time.
Jeremiah Via: Yeah, since like 2011, I think.
Artem Barmin: Can you tell a bit more about how you found a job in Clojure? Because that's a really interesting question — especially for newcomers — about how it's possible to find, maybe, a lease, per Clojure or anything else, any fancy technology.
Jeremiah Via: Yeah. You know, I think partly the way to do it is you have to create the job yourself. I was lucky that the manager who hired me was also a fan of Clojure, although we weren't using Clojure at the time. 
And when I joined the team, the services we had were in PHP, Erlang, Python, Java. So it was kind of an iterative process of consolidating all these systems into Java systems. And then from there, starting to make Clojure systems. And it wasn't exactly a fast journey, but it was worth it in the end, cause I get to write Clojure all day, every day.
Artem Barmin: So, were you the person who introduced Clojure in the New York Times?
Jeremiah Via: Yeah.
Artem Barmin: Can you tell a bit more of the process? So why did you decide to use specifically Clojure? Why not other LISPs or maybe Common LISP Scheme? I don't know, Prologue, you mentioned.
Jeremiah Via: I think the benefits of Clojure, just being a very practical language and being able to leverage JVM libraries, were extremely useful. In a large enterprise, there are a lot of things that a company pays for, like Datadog or Sumo Logic, which are paid services, and they have great first-party Java libraries; it’s very easy to integrate into all these things. 
Had we chosen something like Common Lisp, I think it would have been significantly more effort on our end to share telemetry with the rest of the services in our company.
Artem Barmin: Can you tell a bit more about the first task that you've solved in Clojure and how this journey of Clojure inside NYT started?
Jeremiah Via: Yeah, that's a good question. It's been a while now. So I'm pretty sure the way this happened was just kind of starting on the periphery, writing tests, not unit tests, but I think I was dabbling with like the property-based testing and using that to help a migration. So we had the kind of schema contract for an API and I'm just like, okay, let me turn that into Clojure spec, do property-based testing against that, and just kind of like generate thousands of combos because this API had a lot of knobs. So just the sheer surface area of combinations was pretty high.
Being able to generate, you know, thousands of tests was useful for that and surfaced a lot of bugs, which is great. But that built some confidence, and then I started writing things that were very well suited to Clojure. Some data processing, Kafka-to-Kafka kind of data transform code. And then just, it slowly took over the world and on our team.
Artem Barmin: And can you tell how Clojure is used now? I'm curious, even the percentage of the code base, how big the Clojure influence is right now in your...
Jeremiah Via: So my team is the search team at the New York Times. So we build the search systems. We build the systems that let the other teams build search systems. There's a number of different searches at the New York Times. And then there's everything that sits behind that, which is all the data-oriented code of something is published, we need to transform it into something that is indexed. A lot of steps happen in there, like denormalizing the data, putting denormalized data into Kafka so that we can index or re-index as fast as possible. 
So yeah, our code is, I don't know, it's kind of sprawling. I think our team has 40 or 60 repos, but that's just historical cruft. We have a main repo now where we've consolidated all the main stuff.
It's not the biggest code base just because Clojure is so concise. Like that was the nice thing from migrating these systems from Java to Clojure, we cut out so much of the raw physical source files. Yeah.
Artem Barmin: All these Java bins with getters and setters.
Jeremiah Via: Yeah, all the Spring stuff.
Artem Barmin: Yeah, so it's kind of an internal system for the New York Times, so it's kind of external facing to the customer?
Jeremiah Via: All of it, yeah. So if you go and search on the New York Times, that's our system, the Elasticsearch index. But then, under the hood, a lot of sections of the site are actually powered by search as well. So if you visit politics, that stream of articles is a search query. The different tabs that the things recommended for you based on your interests are searched under the hood. So Clojure is powering a lot of parts of the site under the hood.
Artem Barmin: I see. I can imagine this kind of task requires some natural language processing or something like this, like collaborative searching, or some machine learning algorithm. Do you implement all these things in Clojure or do you connect to other kinds of services, microservices, to do, for example, a search of related articles?
Jeremiah Via: It's sort of a mix. We try to do a lot of stuff in the process and embed it directly. So we have that for. Kind of entity detection, entity extraction code. Other stuff we try to push into the database layers, in this case, Elasticsearch. We do all the vector embeddings, kind of AI stuff you're seeing now. We push into Elasticsearch itself. And that's just for performance reasons.
Artem Barmin: Of course. And the next question, I'm really curious. So was Clojure officially sanctioned when you started to build systems in it? Or was it kind of operated a bit under the radar? Has the internal status of Clojure changed over time?
Jeremiah Via: So yeah, to start, definitely more under the radar. You know, experimental hack projects, that kind of stuff is how it started. I think now it's definitely more usable or more blessed as a language. But it is still, you know, the odd one out. It's, you know, it's the only non-imperative non-place-oriented language at the company.
Artem Barmin: But you've mentioned Erlang, that it was also used in the system. Was it replaced or removed? 
Jeremiah Via: That system was decommissioned. When I joined the team, someone had written an Erlang load balancer, I guess, prior to elastic load balancing being a thing. Um, so like an early day system. Um, yeah, but no, we don't need that anymore. So unfortunately, yeah.
Artem Barmin: I see, I see. That's interesting.
Vadym Kostiuk: I actually was wondering, like looking back, what have been maybe some of the unexpected benefits or perhaps drawbacks of using Clojure at the NYT? Can you think of any?
Jeremiah Via: So I guess maybe one thing that is perhaps unexpected is we, whenever our company is moving to a new paid provider of some service, a, you know, paid telemetry through Datadog or paid feature flags – that kind of like service. I think we are the team that can typically do that the fastest because Clojure code is easy to iterate on, and there's always like a really good Java library that they provide. So pulling that in tends to be pretty quick. It puts us more on the leading edge internally for adopting new services.
Artem Barmin: Interesting. And maybe some drawbacks?
Jeremiah Via: I don't think there are any unexpected drawbacks. I think that's the thing you might typically hear, where the language is less common and less familiar to people. So that just kind of is scary. It can be scary to other engineers or to leadership.
But so far, hiring hasn't been hard and onboarding people to Clojure hasn't been hard. Now with AI stuff, it's, I don't know —we'll see what it's like with onboarding, because people can be productive very fast without understanding it, using a Cursor and tools like that.
It remains to be seen like what that will do to the mental model of learning to understand how Clojure, like the way to think in Clojure. So I don't know. I have no judgment on how that will work.
Artem Barmin: That's an interesting point. I’ve also noticed that AI has decreased a lot of the learning curve for newcomers. And usually, if people have experience with software engineering for five years, maybe in JavaScript or Java, for them it's really easy to transfer to Clojure. So that's unexpected benefit of AI development.
And you talk about the team, the onboarding, the hiring. Can you tell me a bit more about your current role and the scope of your responsibilities? So we will be able to ask you a bit more about your point of view, the management point of view of Clojure.
Jeremiah Via: Sure. I'm currently a staff engineer at the New York Times. So I'm not on the... I'm just purely on the technical side, and I'm like the technical lead for the search stuff at the New York Times.
Artem Barmin: And what is the size of your team?
Jeremiah Via: Um, think now is, I don't know, we are moving around. So it's a little in flux, but, uh, I think we will be five at the end of all the moving around.
Artem Barmin: And what is the progress? Was the team been stable for years or was it reduced a bit or was it increased?
Jeremiah Via: We've been pretty stable at about three to four engineers for a long time. One thing that I think is nice about our team is that we've had very long tenure. I think the engineers on our team have tended to stay like four, five, six years. And that is great to have that kind of continuity of product understanding.
And I, you know, I'm going to chalk it up to just Clojure being fun to program in.
Artem Barmin: There's also a very common thing to Clojure projects because we have people that work 10 years in our company and that's only Clojure engineers to stay for so long. I don't know how it's connected. Maybe that's because of the fun you mentioned. So it's a pleasure to work with it.
Jeremiah Via: Yeah, daily joy.
Vadym Kostiuk: And you partially answered this question, but I wanted to ask: even so, not every month do you have a new engineer who isn't boarding onto the team. However, when you do have new engineers, can you please tell us how do you normally handle this process when you bring a new person to the team, especially maybe without the Clojure experience before? How do you ensure the onboarding goes smooth and like you try maybe to ramp up the process a bit. How does it work?
Jeremiah Via: So to be honest, the Clojure part, don't even think is the hard part of the onboarding. The rest of the search system is much more complicated. And thinking in search is, I think, a lot harder to get people into. For Clojure, it's usually like how to set up your editor, some tutorials, one of the great many books that are around to like understand it. There's also the Clojure course, Eric Norman's Clojure course. I've had good success using that to onboard beginningClojure engineers. And then, you know, we spend time, you know, the things that are hard for people to transition to in Clojure, I think are like, the functional aspect, the immutable aspect, and then the REPL-driven development. 
And so I always make sure to spend a lot of time on that. Like, here's how our code base works. Here's how you can edit the functions on the fly to change the behavior. You don't have to, like, tear it down, compile it, and run it. It's a living entity that you can modify. And I think once that breakthrough is main like people understand that part of Clojure, they start to move a lot faster. And I think that's a lot where the fun comes in because you can really, I don't know, it's, it's, it's just fun to edit the running system. And when you're doing your tickets, it's so much faster.
Artem Barmin: Have you connected to production using REPL? 
Jeremiah Via: No. Yeah, we can deploy so quickly that there isn't like a huge benefit for that. Yeah, and we might get like a call from our security team.
Vadym Kostiuk: Yeah, and just to complete this topic about the team, you mentioned that it's been kind of a challenge to find Clojure engineers. Not at all?
Jeremiah Via: I guess, let me say this, we typically don't find Clojure engineers. And because I don't think that's the, that's not the hard part. I don't think that's like, I don't typically look for Clojure experience. I think finding someone who's interested is good. And then finding someone, we're looking more often for the kind of search background. Cause I think that's the much harder aspect.
Artem Barmin: I'm curious if we can finish on the topic about the team. Have you compared the size of your team to the neighborhood teams? So I heard the stories when one Erlang guy can overperform a team of 20 Java engineers and just drink coffee and do some relaxing stuff while they are hardly working.
Jeremiah Via: Yeah, it's hard to say because teams have such different portfolios. I think we do have a pretty small team, especially given the services we maintain and their impact on the company's functionality. Yeah.
Artem Barmin: I see. OK, so let's talk more about the architecture, complexity, and technical usage of Clojure. And I'm curious, what strategies help your team keep code-based clarity, especially with the Clojure power and expressiveness? And the question is why I'm asking this, because I've seen some projects, not every project in Clojure like this, but some projects used to overuse some macros, domain-specific languages. So, not building the product, but building DSL to build the product in this DSL. So I'm curious: do you have any problems with this part of Clojure?
Jeremiah Via: Well, I'm happy to say our code base is pretty boring. We just have functional components that are instantiated and run. But I think keeping that clean over the long term does require discipline. It's pretty easy, you know, Clojure is so malleable that you can inject anything anywhere almost. I think there's a guard-intending aspect to it, where you should always be incrementally improving the codebase between major tickets. So I think those things are definitely what help us keep it tidy and organized. 
We don't use many macros. Still pretty boring in the code base there. We just get by with functions almost all the time. However, we do have a DSL for doing some query rewriting. So I guess that aspect is a macro, but it's very targeted for transforming a user search query into a different search query to better express their own search intent. And so we use that to put in, like, New York Times specific kind of search domain rules where someone types something and we want it to mean something else to match the intent of the query, but when there isn't necessarily a string that has no reason to match that result, particularly.
Artem Barmin:I see, I see. Hmm, very interesting. And is this DSL large in terms of lines of code?
Jeremiah Via: No, not really. That one is open source. It's  a wrapper around another. So we've repurposed this query rewriter plug-in for Elasticsearch into a client-side query rewriter. So yeah, that exists now. If you're doing search and you want to rewrite queries today in Clojure, can do that. We have that. It's open source.
Artem Barmin: So if we want to generalize your answer, you haven't met with any over-engineering or anything like overusing Clojure power and systems that lead to problems. Am I right?
Jeremiah Via: Yeah, I think that's right. We've been pretty tame in our usage.
Artem Barmin: Yeah, and another technical topic that I'm really curious about is the performance side of Clojure because I can imagine the volume of the traffic for the New York Times, the surge, especially. It's pretty heavy on the load because we need to scan a lot of indexes, extract documents,  do preparations, all these things. So, tell me about your experience —basically, how Clojure performs in this environment.
Jeremiah Via: So collision is very performant and hasn't been a struggle to scale. We have two parts of our workload that can be challenging, like bulk data ingestion. So that can be kind of heavy. Lots of documents and memory, you know, we're like consuming from Kafka as fast as possible. So we'll have like 10,000 documents a second flowing through that, and as you can imagine, it consumes a lot of memory. That's where we had to tune some like sizing there. We just want to hold as much as possible—like a big payload and memory— so we can index as fast as possible. 
On the API side, so much of the work is happening in Elasticsearch. So the API is pretty thin. You know, there's like the query writing, extracting entities from the query, and injecting all that stuff to make a richer query. But then, you know, once we've done that, we kind of hand it off to the database. And it does all the heavy work. 
So scaling has been pretty easy. We run three nodes in Kubernetes, or, rather, a three-node deployment or three-replica deployment. They're each kind of big, like eight, I don't know, six or eight gigs of RAM for those. But that's more than enough. And we have that in two regions. So there's an active-active, two, three-node replica sets deployed. And that's been enough. I mean, that takes us through elections. We've got it down to a science now.
Artem Barmin: And are you using native Clojure data structures for these kinds of tasks or using some maybe custom Java-built specific data structures for handling documents? Because from my experience, sometimes I see that people tend not to use persistent data structures because they have a penalty on the performance, the size of the memory, and they use some maybe mutable Java-based, JavaScript-based structures.

Jeremiah Via: We do use all the immutable default Clojure data structures. It has been fine. But we kind of do write our final document in one pass, more or less. So I think we're not doing tons of transformation — writing and editing the same map over and over. The query rewriter does use its own mutable data structure under the hood. It's like... well, it's three trees, the T-R-I-E-S one. That's right. I don't know. However you want to say it.
Vadym Kostiuk: And I have a question. The question is about Clojure in the company, as a matter of, I mean, a question of existence. Basically, we've seen a lot when Clojure sometimes faces pushback, not only in large companies, but also in small companies. Due to various reasons: it can be hiring, it can be maintenance, or it can be just a strategic direction. So someone just goes from the top and tells, yeah, what are you doing? Why Clojure? Why not JavaScript? Let's rewrite. Have you encountered maybe any such moments in the NYT?
Jeremiah Via: Not really, not in terms of the like, let's rewrite it. Sometimes, you know, when a new executive joins, there might be some curiosity about why. But I, it's never gone past, like the interest or the kind of question of, you know, similar, like, what made you choose this? I think whenever we've explained our rationale, it's been pretty well received. 
But I think the things I like to focus on with the practicality, the living on the JVM, the code that will work in 10 years, unchanged aspects of Clojure. I think those are the real superpowers for enterprise programmers.
Artem Barmin: Yeah, that's true.
Vadym Kostiuk: Yeah, definitely. So yeah, just to summarize, there haven't been any serious discussions about it. So just a curiosity from the top, yes?
Jeremiah Via: Yeah, just curiosity. I think that kind of migration would be so much effort that you could actually spend all that time improving the product. I don't know if the investment would be worth it.
Artem Barmin: Cool.
Vadym Kostiuk: Yeah, definitely. Just wondering because we've seen such cases when a really big chunk of the system is just being rewritten in another language, not because of some technical reasons or some real factors or objectives, just because someone tells, okay, it's not the mainstream. We don't need it. We don't want it. So I'm glad it's not the case at the NYT. It's really great.
Jeremiah Via: And I wonder if the kind of AI-assisted programming will change that argument for people, or that kind of ceiling for peopl,e where you can still be productive in whatever language, learn it with the assistance.
Artem Barmim: From my personal experience, even in the era of AI assistants, agents and everything else, Clojure still gives the biggest performance boost for me, especially for back-ends tasks.
And just to clarify, your team, the single Clojure team in the New York Times? Because, as I understand, in overall, you have 600 plus engineers in a company.
Jeremiah Via: Well, not it's not 600 engineers is 600 in the like tech org. So that includes all product management, program management, data, —those people as well. Yeah, other teams use Clojure. So we also build frameworks for building search systems at the company. And other teams that have search products, like cooking or audio apps, have their own custom searches tuned to their vertical. Those use the libraries that we build. Their search backends are all Clojure as well.
Artem Barmin: Interesting. Because the next question I'm going to ask is about team collaboration. And how do you collaborate with other teams? Did you have some problems? Because as I understand this library's written in Clojure itself, do you provide just compile jar files to them and just say you can take it or some other collaboration?
Jeremiah Via: The way those collaborations work, I think they're more like consultant-based. And that's not for the Clojure part, but is for the search part. Because I think the search part is the harder part, and the harder part to wrap your head around mentally. How do we transform our data into a series of signals that can be matched against like user queries?
So helping, like when teams first start building their search with us, we sit down and talk about what are the important signals in your domain, user interactions, things like that, that we could pull out. And we help them build that system. So there is kind of like a, I guess, a long onboarding and co-creation process of these search systems.
But the teams that have done this, they have been able to iterate on their own. And they're pushing the boundaries. They're adding more Clojure stuff and just making the business logic for their search system more and more complicated and sophisticated. So they've been able to pick it up very well.
Artem Barmin: Cool, cool. Do you have some kind of documentation, tutorial on board, you know, it's just face-to-face conversations, yeah?
Jeremiah Via: Yeah, we have the tutorials on running Clojure projects, how to connect your editor to it, and then different demos for examples of the technology we use. We use Pedestal a lot for our main server libraries we use, documentation on how to like, or what interceptors are, how to think about that kind of stuff, how they compose. And then, similarly, we have a lot of internal libraries that are ⁓ specific for building search systems. Those also have, yeah, you need a lot of documentation.
Artem Barmin: Yeah, that's cool. That's cool because in startups, documentation and passing the knowledge is usually a big problem. And okay, and to summarize all the previous conversation that we had about Clojure and if you were tasked about building a new system today at the New York Times, would Clojure still be your first choice?
Jeremiah Via: Absolutely. Yeah. I couldn't  dream of doing it in anything different.
Artem Barmin: Cool.
Vadym Kostiuk: And I was wondering from your perspective, is the current Clojure ecosystem as of 2025 strong enough to support new product development at a company like the NYT? So for instance, I don't know, Google or maybe Amazon, should they be worried about picking up Clojure or it's good enough to use it?
Jeremiah Via: I think it's great to use. I think we have the advantage that there's always a great Java library for anything —whether it's from any cloud provider or a random open-source thing you need to touch, there's a Java library there for you, something you can lean on.
I think one area where things are a little weaker probably is the natural language processing part. The Java NLP feels kind of old school. It's not very, well, it's actually just hard to use. Or, you know, it's not a business-friendly license, so it's not something that we can use at the company. It is hard to compete with the Python NLP ecosystem there. There's just so much, in general, data science stuff. That's where I would love to see more stuff. And I guess that's where I need to start making that for myself, I guess, to adopt there. 
Artem Barmin: You know, one of the goals of this podcast series is to show people that don't use Clojure in their production environment, that it's not so scary and that it's manageable. And the next question is, can you say something to the engineer leaders in large organizations who are considering Clojure, who are interested in it, maybe using for hobby projects, but want to try to use it in a production environment. And particularly when it comes to long-term maintainability, team scaling and onboarding and everything else.
Jeremiah Via: Yeah, I guess, my first thought is just do it. I think it you'll if you take the plunge, you'll see it. It's worth it. I find Clojure very easy to deploy, mean, especially in the world of like deploying Docker images. But, JVM deployments are pretty simple. You know, especially we're not doing like wars or anything. It's, it's just a simple jar, you know, Java jar run your thing and then you're good to go. And especially with the more recent versions of the JVM, like the Docker integration is better. 
We don't get like paged very much. Like, don't even want to say annually. Because we've been able to like harden the system through so many elections. You know, those are the real Super Bowl moments for us. 
So, we've got another point. I think that's the nice thing about Clojure is you can build these systems that run well, they run stably. The ecosystem isn't going to move underneath you. So next time you want to make a change, it's not going to be like getting back into a node project where you're apparently 15 versions behind and nothing compiles anymore. We have some Clojure code that I haven't touched for half a decade. go and have to make an update and great, works. It's older, it's using Leiningen  In, where most of our other stuff has moved on to depths, works great. Not going to touch it, just going to do the update, deploy, and move on with my life.
Artem Barmin: Yeah, it's not abandoned, it's complete. It's cool.
Jeremiah Via: Exactly.
Vadym Kostiuk: Yeah, and we are at the moment of the podcast where we normally have a topic that's called Chain of Questions. So previously we had a podcast with Kemp Sol, who's a founding engineer and chief architect at the company called Metabase. And he left an extensive question for the next guest. So it's passed on to you.
And here is quote. So the question is, where would you like to see Clojure and the Clojure community in the next few years? So if you would imagine that you have a time machine and like you took it for one, three, maybe five years in the future, what would you hope to see? So what should change in Clojure and the Clojure community, and what should remain the same in your opinion, your imagination? How do you see this?
Jeremiah Via: So, in the core Clojure, I don't feel like a lot needs to change. Fewer engineers about stack traces and stuff, but I have fully internalized that, so it's fine for me. I think purely selfishly,  I would love to see robust NLP libraries for Clojure and in Clojure, not wrapping Java things. Ideally, just like that data model from the ground up, the Clojure model.
Better ways to do, you know, vector and tensor stuff, where, you know, it's still a little like hard and there are dozen competing libraries in Clojure. I know there's like work towards that going like ongoing. So I hope, I hope that continues and is successful. And in three to five years, there is a compelling ecosystem that can take a bite out of the Python data science ecosystem.
Artem Barmin: Interesting. Do you think it's really a possible way? Because Python is not reading libraries because it's just using the C version of libraries, the FFI. Do you think we will achieve someday this kind of support?
Jeremiah Via: Like the performance. Well, you know, there's the Project Panama stuff in JVM. So this is where it's going to get like the portrait low-level Java-Clojure of like writing FFI code and other very low level things. But I think it's worth it to me, at least as someone who does this in to be able to consume that would be great.
And I think it would be, I imagine it's possible. And I think it's easier to maintain and deploy, I mean, that's still such a nightmare with any of the Python stuff we ever do.
Artem Barmin: Yeah, definitely. I agree. 
Vadym Kostiuk: Okay, good. And another question I have is: how have you envisioned and imagined this podcast? Because coming on this podcast, you maybe had some topic in mind that you wanted to discuss or maybe some questions that you wanted to answer, but we haven't asked. So what questions we should have asked you, but haven't? 
Jeremiah Via: You know, I think you guys asked me just about everything, you know, relevant to Clojure at my job. Yeah, I think you've out covered everything.
Artem Barmin: Thank you. It's pleasure to hear. Yeah. Okay. Okay. So I think we can finish because we are done with the questions. So Jeremiah, thank you. It's been a pleasure to talk to you today and hear your answers and hear your experience and all this, you know, technical and management insights, how it really works in large organizations. So thank you for sharing. That was really insightful.
Jeremiah Via: Yeah, thank you for having me on.
Vadym Kostiuk: Yeah, thank you, Jeremiah. And also a big thanks to the audience. Subscribe to New York Times. They use Clojure. Support Clojure.
Artem Barmin: Yeah. And once again, thank you, Jeremiah, and thank you to our listeners, of course, and see you next time. Bye.
Vadym Kostiuk: Until next time.