Jeff Kao

Like, they still need to understand these concepts to some extent, but you have to be really, really upfront and, like, be very almost...

very, very strict about these things.

So that would require significant like senior engineering talent within that had like CNC plus plus knowledge, which we didn't

I guess specifically for how you mentioned Elasticsearch, actually one of the things that also sort of bit us and also why we decided not to use a JVM language was the fact that we did have to maintain an Elasticsearch cluster to power geocoding with our old iteration of the geocoder.

And we realized we just had to put everything on one machine, which is still the case.

But we didn't even use really the sort of distributed aspect of Elasticsearch because of the nature of the workload.

It would just end up, you know, essentially fanning out all the queries to all the nodes, even though they're sharded.

So at that point, we just essentially just got one really like fat box of

all the shards of the Elasticsearch cluster just lived on one box.

So it almost defeated the purpose of that.

And so, you know, maybe this is more of a design thing, more so than Rust.

But, you know, that motivation of, you know, Elasticsearch was, you know, contains, let's say, a bunch of geodata and like addresses and places and things like that.

And there were a couple of other microservices that we had powering our old geocoder.

What we really wanted was not just like a deployment story that was simple for essentially the binary, but our data assets as well.

And so what that meant was that it would be much simpler where the old world is essentially, oh, hey, I want to do a migration.

And developers deal with this all the time.

If you want to do a database migration, you essentially have to reason about what's the existing state of your database.

Do I want to introduce a column?

You got to make sure that maybe everything can handle null to begin with.

And then maybe you have a state change.