astronautas

cool!

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?

Interesting, will check it out.

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 explicitly.

see my reply above

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.

How about "A UV feature that intrigues me most"?

uh, thanks I guess.

Indeed, you're right ;).

Neat!

Fair points!

call to external db, and then to llm with retrieved context.

also business rules, no?

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.

can't disagree (a tradeoff).

agree, it depends, always benchmark, but my question is rather generic i.e. I am looking for a perspective.

Sure, but what about non AI / business logic pre and post? Think RAG calls, guardrails, ...? Or do they fly compared to LLM inference itself?

Good perspective. No-GIL should make things better (shared memory parallelism), but it's not bulletproof.

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, Rust is another story though.

Cool! Thanks for the investigation.

Thanks, so it's connectors, nice differentiators. Seamless integrations are harder than it seems.

How does this compare to Vespa? If the key difficulty in scaling search is infra as you say, Vespa is an interesting alternative.

Data infra?

Not a catalog though, still need to input s3 path...

This

I am confused...

It's a cool example, but really an antipattern. Nowadays everyone gets analysts want access to raw data, since they know which aggregations they need best, whereas data engineers stay away from pre-aggregating and focus on building self-service data access tooling. Win-win this way.

How about building a duckdb accessible catalog on top of s3? Like instead of read_parquet, you would select from tables, which themselves would be mapped to s3 paths aka external tables.

I've been recently toying around with dynamically switching between DuckDB and BigQuery on query time. So you have a layer of standard SQL in front, which uses sqlglot to translate it to compute-specific SQL. So e.g. you can use DuckDB for development or low to medium-sized datasets, and switch to BQ for big datasets.

In theory, it sounds great, but in practice you indeed lose database-specific operators, you should restrain from using database-specific optimisations, etc...

True!

Cool, thanks for sharing!

Write a blog post then about this! I can tell you it is hardly a solved problem.

eh, awesome! Seems this one, right? https://github.com/galeone/tfgo. Quite many stars.