ragingHungryPanda

I just started reading this and it's freaking hilarious

There isn't a universal one. A fun fact is that Activity pub, the protocol that lets these applications communicate on the backend, also has a front-end spec for this exact purpose, but no one has implemented it.

Agreed, that's what I was trying to say but I'm not great at writing. I've seen this in rust and other languages long before llms

I actually disagree, because I've both seen it everywhere and I also work mainly in dotnet, and when I've talked to people about option and result types, the first inclination is to have a .Value, but that defeats the purpose. I've done quite a few code reviews where I was essentially saying "you know this will throw, right? Use .Match or .Map instead".

I think the imperative programming backgrounds encourage this line of thinking, since one of the first questions I've gotten is "how do I get the value out of an Option? I'm 100% sure it's there." And often, surprise, it wasn't.

I feel like I've seen an insane number of error messages in various apps and websites around the unwrap method.

But this is on a result type, right? I'd figure the point would be that you would match on it and that the unwrap itself, which if my assumptions are correct, is more like get value or throw, should either not exist or take a default value. You shouldn't be able to directly get the value of a monad.

I'm so out of the loop on history (ie, an american)

I'm not sure what you mean, it's just an rss link to an xml file. Oh, do you mean if you want to be tracked? It has a newsletter you can sign up for.

The same way I did - steal from others

That's next cloud and the news mobile app

I need to make a proper list. Since I'm on mobile, it's easier to screenshot.

Based on old memories since I've been working in mongo lately, after making the UDT on the db side, you make a data table that has the same name, namespace (ie dbo/public), and the same schema as the UDT (better if that could be generated) and populate it in code. Then you execute the db query with the UDT type as a parameter.

This is better for a few reasons, including not building up a string, but also having the same text means that each query didn't need to be re-parsed and can reuse execution plans. If the query text isn't an exact match, it gets that whole pipeline each time.

Create a user defined table type and use that as a parameter. I'm not sure what the postgres name of that is.