Yeah, I can understand. I mean, trying to figure out if things are going to be perfect for a while is definitely not going to be easy to do. Yeah, that's why you have 2.0 and you seen with Russ right, Russ is still one die, whatever, but we keep having this, I forgot what that's called the change in the syntax, but still not change in the actual stuff. You know, like, when we went to like 2018 and 2021, I think, editions. Yeah, the edition. Yeah, that's right. It's kind of like a maybe this is too crude to say, but kind of like a little bit of a hack where it's like, all right, we're not 2.0, we're not 3.0, we're, you know, we just changed the edition. Everything is still the same. It's like, okay, fine. Technically, yes, you have that just kind of like edition changing, which is interesting. Nobody can predict the future, right? Like you said, you didn't expect to be working on pollers. It's kind of a byproduct that got sidetracked. And I think you're pretty happy where you are, right? What keeps you working on pollers? What is it that keeps you attracted to it? Because there is people who do walk away for different reasons. One is, you know, maybe they lose interest. I think the guy who started Russ is not really obviously working on it so much. I don't think he still uses it or not, but you know, you also have what's his name, but the guy created Python, I forgot his name now, your compatriot. He stepped away from, yeah, he stepped away from doing the BDFL, right? I think he's still a Python developer. I think he calls himself a normal Python developer now. He's out of it,

right? He's still very much involved. But the open source or being the one making the decisions, it's got two things. It's great. I mean, I've been able to build something and you get a lot of gratitude from people to say, oh, this made my life so much easier. This made stuff so much faster. I love the API or that's super too experienced. On the other side, open source can also be draining because sometimes you make a decision because you think it's the good thing for the project and people can be pretty harsh. And I think that can be draining for people. And of course, the amount of information you need to process. If you only want to follow the issue tracker, you can keep up at a certain point. If I look to myself, I'm just someone who loves to code and that keeps me into the project. First and foremost, we also got funding. So there's a second reason that keeps me into the project, but that's only since this year. I just love working on pollers and I love having my ideas. I've got a ton of ideas and bringing them to fruition. And that's the most important stuff. Though sometimes you wish you could have a bit more clean slate and you missed the day you missed the days programming where you could just do what you wanted instead of having all the bugs, all the issues. Changes are not that easy anymore. It's not only a playground anymore. Most open source developers experience some sort of flavor of these things and maybe some different things as well.

I think I have a pretty good idea kind of where pollers is and if I should or should not be using it for any kind of problem I run into. Is there anything I didn't touch on today that you think people should know about? For instance, we've covered about the you're looking at releasing 1.0 and what that actually means. Is there some features that you think we should be on a lookout for that you think are really exciting that people should know about?

What I'm really happy about lately, I've been talking a bit about the amount of features we have, the amount of code we have and I've been thinking okay how can we grow with pollers as a library without bloating? And for me a distinction for instance, we also have nested types and array type which we will make better. In this type you will have nd arrays. So you have a column with nd arrays which can represent the tensor for machine learning model. Though I don't think machine learning algorithms should be in pollers. I think that's a distinction, a boundary where we say okay this is too specific, distance functions, machine learning algorithms, etc. all kinds of feature engineering. But I do think it's very natural to work with them in a data frame library with our expressions, with our API. So what I wanted was being able to make a pollers machine learning library or any other something that doesn't fit into the pollers main engine, main library, but something that would fit if we would not care about bloating. So we started something new which is called plugin system and with this you can create your own functions sort of UDFs in Rust and you can tag them with a Prok macro and then they will be exported as an expression. And when you're in Python you can compile your own library, you can publish it on pypied, Python package manager, the package repository. Your own binary can be linked into the pollers engine, into the pollers main library. And this way you can build your own custom tooling, your own specific logic, which should feel native. It feels very really native within pollers. So I hope this way we can have an answer to the feature problem where we want a lot of features into this engine, but we don't want to compile everything in the static library we haven't lost. That's good

to hear. This is a side question I think I mentioned to you before that I talked to somebody here who is in data science and they were talking about pollers. He actually has a specific question for you I thought I would ask. He says, is there any plans to make pollers work with Postgres PG store, the standard vector store in Postgres using PGRX, the embeds rust in Postgres? I'm not sure if that makes sense to you or not.

It's an overly specific question. Well, he's

got he's working on an idea that involves this stuff. So that's why I guess.

All right. I am not familiar with the embedded Postgres store. So I cannot really answer this right now. I shouldn't first know what it is before I can say if voters will integrate with it. Saying no would always age very badly. Sometimes I said we will not do this and then later it seems to fit. So I don't know. Yeah, I

think that's kind of what hospitals and groceryers do right. You're never supposed to say no. It's bad for the hostage. So probably good to say we'll look into that rather than give an answer a negative answer, right? It's kind of maybe a horrid reply, but yeah, I understand what you mean. Things change, right?

Yeah, though I would say an open source, it's important to say no to keep true to the core of what you want to do. Otherwise you will end up with API bloat. You will end up with stuff that just doesn't fit. I think it's one of the most important things to say no. But sometimes my no didn't age well. I think I

know what you mean. I've been following some programming languages in the creator will kind of say no, because he has to. Like you said, it's easy to put things in, but to take it out is really difficult if you need to. Yeah. And I think it's what you're talking about mostly, right? Or supporting something long term.

Yeah, if it doesn't fit the architecture, your building of it doesn't fit the way you want things to work. And it will hurt people's intuition or you have a sort of a model of your API. And for parties, we have a DSL, which is sort of a super small programming language. And it should work following adhering those rules. And I don't think we should make exceptions on those rules, because there would be strange. There would be, I will people learn this or how. And sometimes it doesn't fit the architecture, or you're not there yet. Or sometimes it doesn't fit the paradigm you're building. I think in Rust, it's also very common. The Rust language also, I think Rust does very well keeping things unstable when they're not certain about it. As we see, it can be, can take five years for something to stabilize, because we're just not certain. And you can work around it in the meantime.

Yeah, that's true. I've been using nightly to build something that I use in production, or something else. So it's just, it is interesting that even if you need to, you can always use nightly or the beta. Yeah, it was good to have you on, good to know more about pollers and to understand more about what a data frame is, and if I should be looking at using pollers for anything, thanks again for coming on, and hopefully, I'll have you get in the future.

Yeah, thanks for having me. And until next time.