 Well, I had made it two weeks. I was smoking all these fucking things, and that's not working out all that well, but At the very least as long as I stayed down, that's better than nothing. While I was downstate, I had gotten up to about a quarter of a pack a day. I've been. This would be my second one today, one yesterday. It's not too bad. It's a lot more spaced out. Try to make it really long after the next pack, but that's that's not really what I want to talk about. There's The last video, the one I had uploaded earlier today, I had described a lot about the future plans, which I just covered in another video too, but just in much more detail, but also what I had, what progress I had made so far and stuff like that. So What I want to talk about is those changes. There's some pitfalls with some of them. Pitfalls in that one of the major reasons for going with net was its notion of CLS compliance. There's others, of course, the net core framework did too, but both of those virtual machines have string interning, which is actually really important for performance, although hilariously by using spans don't really need string interning that much, but it's still it's still useful. The patterns engine makes some rather extensive use of it rather hidden away, but definitely makes use of it. So I There's an issue with that. See F sharp, F sharp pipeline and everything it everything and F sharp exists as a generic like literally everything but a huge amount of the stuff in F sharp exists as a generic. That's how it works. And the issue with that and span span is a restruct. You can't use restructs as generic template parameters because you run into the possibility of persisting the object into the heap. If it exists its entire lifetime in the stack frame, it can't be in the heap. And as a special precaution to help with the situations that restruct was designed for it explicitly cannot be boxed. So unlike the more traditional struct, it can't be put into the heap. You can't box it. So therefore, you can't risk using it as generic type parameters. That is an issue for using it in more traditional F sharp situations. So what are the, what are the options that it's kind of tricky? See, Visual Basic runs into a superficially similar, but entirely different internal reason for why it can't use the span type. Microsoft sort of dropped the ball when it came to updating Visual Basic. And you can't use restructs in it anymore, even though Visual Basic already has support for ref parameters. So in both languages, you can't use restructs. And that's a problem if I'm using restructs extensively as a form of optimization. What are my options with regards to any kind of bindings for those? Because at this point I have to do bindings. I can't rely on CLS compliance. Visual Basic literally cannot work with them. And F sharp only can in very specific contexts that you literally lose all of the functional programming stuff that F sharp offers. Do I provide visual basic bindings and F sharp bindings that work with a different type that do it as a, I don't know, read only memory of care instead of read only span of care? That's a little less than optimal, but it's more optimal than allocating an entirely new string every time. I'm not really sure what my options are. And I do know that in either instance, it is going to mean a performance hit. It's a little less than ideal. But you wind up with, I don't know, I don't know. In either case, the bindings would require a new allocation, whether every single function returns a car array internally that is made to be viewed as a read only span, read only memory of car, or actually just creates a new string entirely. I don't know. Realistically, this may mean the end of any support for visual basic and F sharp, which is unfortunate. I want to be able to support them. That, again, is a big appeal in going with the .NET ecosystem in general, because of the notion of CLS compliance, because of the notion of, hey, write anything that is CLS compliant and it'll work across any CLS consumer. Which, according to Microsoft, these types are CLS compliant. But I think that was an error of omission. So I don't know. Let me know what you guys think. Is it worth it? Even if it means that it's going to be slower in those languages, allocate more memory in those languages, is it worth being able to say that, hey, even though this is a little bit slower, I still support you. Here's what the reasons are. F sharp, due to the way it works, I don't have to provide a unique F sharp namespace, but visual basic would require that. This means duplication of a lot of things just for visual basic, which is less than ideal. That also, I mean, even as it was already, it does mean that anybody looking to contribute to these projects, they have to implement what, now it's looking like the core C sharp implementation of visual basic binding and an F sharp binding. Is it worth it? I'm not. I don't know. I don't know.