Readit Newschuckhend commented on Replacing Protobuf with Rust pgdog.dev/blog/replace-pr... · Posted by u/whiteros_e
Great work Lev!
IMO, Python rode some of the growth from the data and scientific computing computing. It was lower friction for many people partially due to the amount of blogs, and open source projects that were available. Pandas and Numpy made it quite easy to get up and running with a lot of analytics. pytorch and tensorflow were also there to facilitate this, made people able to get the benefits of the optimized C code but most users did not have to learn C. Eventually FastAPI came out for those looking to build products out of their data, and FastAPI had fantastic documentation and guides, which helped these same folks coming from data/scientific compute build working software. I suppose what I am describing are some of the network effects.
chuckhend commented on How to think about durable execution hatchet.run/blog/durable-... · Posted by u/abelanger
Helpful read, thanks for sharing! We have been (slowly) working on some fairness related queueing features over in pgmq for a bit too https://github.com/pgmq/pgmq/pull/442. It does get complicated on Postgres IMO.
Love SQLx for my Rust projects. I would like to figure out a great way to use the compile time checks in python or js projects, but haven't explored it yet.
chuckhend commented on Show HN: Any-LLM – Lightweight router to access any LLM Provider github.com/mozilla-ai/any... · Posted by u/AMeckes
> LiteLLM: While popular, it reimplements provider interfaces rather than leveraging official SDKs, which can lead to compatibility issues and unexpected behavior modifications
with no vested interest in litellm, i'll challenge you on this one. what compatibility issues have come up? (i expect text to have the least, and probably voice etc have more but for text i've had no issues)
you -want- to reimplement interfaces because you have to normalize api's. in fact without looking at any-llm code deeply i quesiton how you do ANY router without reimplementing interfaces. that's basically the whole job of the router.
LiteLLM is quite battle tested at this point as well.
> it reimplements provider interfaces rather than leveraging official SDKs, which can lead to compatibility issues and unexpected behavior modifications
Leveraging official SDKs also does not solve compatibility issues. any_llm would still need to maintain compatibility with those offical SDKs. I don't think one way clearly better than the other here.
Very relevant talk if anyone is interested in learning a bit more about how the project is so fast.
https://www.youtube.com/watch?v=gSKTfG1GXYQ