astronautas

6 ms·

1.
by astronautas 11mo ago
cool!
2.
by astronautas 11mo ago
indeed, I was thinking about the same. How do you even escape the hatch with e.g. Atlas if your migrations folder is autogenerated? What if you modify /migrations but not your entities?
3.
Declarative database schema migrations – yay or nay?
1 points by astronautas 11mo ago|4 comments
4.
Should we replace Spark with DuckDB?(valatka.dev)
6 points by astronautas 2y ago|0 comments
5.
FOSDEM 2025 has exceeded my expectations(valatka.dev)
20 points by astronautas 2y ago|0 comments
6.
Wheel - a surprisingly good model package format(valatka.dev)
2 points by astronautas 2y ago|0 comments
7.
by astronautas 2y ago
Interesting, will check it out.
8.
by astronautas 2y ago
Hey, I actually made a silly mistake in my post, indeed you first activate the environment and then install stuff in it. Fixed! I disagree though it is activated immediately, or at least to me with venv I always have to activate it explicit
9.
by astronautas 2y ago
see my reply above
10.
by astronautas 2y ago
Sorry dang, didn't know the practice + got a bit emotional haha. I agree with the remark above, my message is rather on how easy it is to run python scripts with dependencies (without mutating the state.
11.
by astronautas 2y ago
How about "A UV feature that intrigues me most"?
12.
by astronautas 2y ago
uh, thanks I guess.
13.
by astronautas 2y ago
Indeed, you're right ;).
14.
by astronautas 2y ago
Neat!
15.
Uv's killer feature is making ad-hoc environments easy(valatka.dev)
502 points by astronautas 2y ago|417 comments
16.
Where async-io cripples, and the promise of No-GIL(valatka.dev)
2 points by astronautas 2y ago|0 comments
17.
by astronautas 2y ago
Fair points!
18.
by astronautas 2y ago
call to external db, and then to llm with retrieved context. also business rules, no?
19.
by astronautas 2y ago
I agree Python is hardly replacable. Btw, I only mean inference, not training. Training imho should stay pure Python, you can achieve mega throughout with it for batch processing.
20.
by astronautas 2y ago
can't disagree (a tradeoff).
21.
by astronautas 2y ago
agree, it depends, always benchmark, but my question is rather generic i.e. I am looking for a perspective.
22.
by astronautas 2y ago
Sure, but what about non AI / business logic pre and post? Think RAG calls, guardrails, ...? Or do they fly compared to LLM inference itself?
23.
by astronautas 2y ago
Good perspective. No-GIL should make things better (shared memory parallelism), but it's not bulletproof.
24.
by astronautas 2y ago
Indeed, my point was that Go and Rust could lead optimizing the non-AI code, which often begs to be coupled with AI code (think guardrails). Also, what's the benefit of Python then in this case? Ergonomically, Go isn't shabby, Rus
25.
Ask HN: Do you think Python will disappear for LLM inference?
2 points by astronautas 2y ago|19 comments
26.
by astronautas 2y ago
Cool! Thanks for the investigation.
27.
Why I am excited about No-GIL (and skeptical about asyncio)(astronautas.github.io)
3 points by astronautas 2y ago|0 comments
28.
by astronautas 2y ago
Thanks, so it's connectors, nice differentiators. Seamless integrations are harder than it seems.
29.
by astronautas 2y ago
How does this compare to Vespa? If the key difficulty in scaling search is infra as you say, Vespa is an interesting alternative.
30.
by astronautas 2y ago
Data infra?

More ›