pascahousut

My first encounter will likely be the opposite, i.e. a call that will only produce a Result::Err if anything, and never a Result:Ok. I've made programs where there are a bunch of continuously running jobs that should never terminate in the happy scenario. If any of these jobs terminate, it'll be due to some sort of failure, and so Result<!, MyError> seems like a reasonable return type for such job. I think I've already used the Infallible in there but I think this being part of the language now makes the code feel more correct or clean or something like that.

I assume it's common and understandable to dislike LLM generated content and therefore anything that resembles it regardless of origin. For those who happen to write in a similar way it's a pity.

I've noticed some people on the internet dismiss content just by its length too now. I assume this is because they're not used to the idea of a human producing long form content (as opposed to the short form rewarded by popular feeds). I wrote a post (other forum, other handle) where I included some markdown tables and detailed explanations in an attempt to be thorough and help others answer my question and got accused of having LLM generated it despite writing it myself. Maybe the usage of markdown tables or the length of the post was the issue. Anyway, it's not nice being dismissed as AI slop when no AI was involved. I also don't see how there could ever be a reliable way of identifying origin of digital content such as text on a forum.

I see red when I read this kind of comments.

Is the linear algebra of machine learning more complicated than that of graphics?

My understanding is that it is a common and sad phenomenon of the cloud era that systems are unnecessarily complex and costly relative to the actual computational requirements mandated by the actual volume at which the system is realistically going to be used. For example, it is very easy to have more microservices than users because bootstrapping complicated systems has never been as easy as it is now, but architecting good systems and finding the correct problems to solve is just as hard as it has ever been.

And the K&R reference is useful too. It's a small book about a small language that does not have many features and maps to very basic concepts on hardware that really only does very basic things.