wey-gu

Interestingly i had been building a terminal in rust and libghostty(with Linux and windows supported too) with built-in agent that understands terminal, too.

And the motivation was warp is doing a little bit more than a terminal.

https://con.nowledge.co

Glad to see now warp is open-sourced

I had been building con for a few weeks, it’s built in rust(GPUI) and libghostty, plus rig, the rust agent framework.

It’s built for the old-school terminal users, who, still do lots of work within terminal(not tui only), yet, with ai harness to help with your workflow anytime, and take over on our own , also any time.

I spent some efforts on:

- the harness, how can we abstract the state, structure that’s best for harness to control, leverage and manipulate the native panes, SSHed and/or TMUXed panes, or TUIs when needed, so that we can actually count on the agent to do things, like you create your own release workflow as a skill, effectively and smoothly. The way to do so was in a benchmark driven, self-evolve approach that’s inspired by the auto-research and Ralph loop way, with, both benchmark infra, cases and judges etc AND the harness env design in the evolve loop, and each loop are ChatGPT 5.4 120min runs, and interestingly I made it in a shape that’s acceptable as 0.1 beta in a few days.

- ensure it’s an elegant terminal, I am still working on this, but this process takes heavy me in the loop when we are using rust on ux improvements and performance tuning :) - supports windows, well, I cannot stop doing it, although there are some many missing pieces out there and till today, windows version is runnable, still needs perf tune and refactorings, and in the meantime I am still working on the Linux desktop version!

And now, I decided to share it first before any landing page or blogs/tweets on hacker news!

Amazing work!

toad is next level in many ways

I was reading an article earlier today, and it brought me back to a question I’ve heard over and over again in real data/infra teams: Do we just accept vendor lock-in because it’s convenient, or do we take the pain and build an open, multi-engine metadata stack? For context (not my product, just what triggered the thought): https://medium.com/p/35cc5b15b24e I’m not trying to argue Gravitino vs. UC here — I’m more interested in the architectural mindset behind these two approaches. On the vendor-integrated side, the upsides are obvious: smoother UX one place for lineage/policies fewer moving parts But so are the downsides: cost keeps creeping up you end up tied to one engine/format migrations basically don’t happen in real life And on the open/composable side: Spark/Trino/Flink/Ray all first-class Iceberg/Hudi/Delta can actually coexist Metadata isn’t tied to compute But again: inconsistent metadata models everywhere no unified governance layer someone eventually owns a pile of glue code forever So I’m curious: what actually works in practice? If your company had to make this choice: Did you go all-in on a vendor, or build something open? Did the decision age well after a year or two? Has anyone actually avoided metadata sprawl without getting locked in? Where do lineage, ACLs, policies, and the “source of truth” actually live in your setup? Really interested in what folks think, especially if you're juggling multiple engines, table formats, and clouds.

I was reading an article earlier today, and it brought me back to a question I’ve heard over and over again in real data/infra teams: Do we just accept vendor lock-in because it’s convenient, or do we take the pain and build an open, multi-engine metadata stack? For context (not my product, not promotional — just what triggered the thought): https://medium.com/p/35cc5b15b24e I’m not trying to argue Gravitino vs. UC here — I’m more interested in the architectural mindset behind these two approaches. On the vendor-integrated side, the upsides are obvious: smoother UX one place for lineage/policies fewer moving parts But so are the downsides: cost keeps creeping up you end up tied to one engine/format migrations basically don’t happen in real life And on the open/composable side: Spark/Trino/Flink/Ray all first-class Iceberg/Hudi/Delta can actually coexist Metadata isn’t tied to compute But again: inconsistent metadata models everywhere no unified governance layer someone eventually owns a pile of glue code forever So I’m curious: what actually works in practice? If your company had to make this choice: Did you go all-in on a vendor, or build something open? Did the decision age well after a year or two? Has anyone actually avoided metadata sprawl without getting locked in? Where do lineage, ACLs, policies, and the “source of truth” actually live in your setup? Really interested in what folks think, especially if you're juggling multiple engines, table formats, and clouds.

Yeah, so sad as a contributor and downstream user.

Hopefully they will ship cool new things.

Unsloth/Denial is amazing.

the backend is down now?

AIRI is underrated.

Airi is amazing

by yetone author of avante.nvim

Thanks~

ha, thanks, make sense

Thanks! This is the ultimate shape I am going to pursue!

Haha yeah, I put a (I know) in the readme

> Effortless Setup: No PostgreSQL install needed—just Node.js(I know)!

Was just to have kind of SQLite dx in 1 hour thus did so.

And then I thought why not open source it?

Maybe in v2 I could abstract actual binary with same dx

wow thanks! Should I use bun instead of node now?

I think the ultimate version in such use case would be carefully wire-up the baremetal one with ad-hoc in-mem-disk or tempdir :), this could be a future backend of py-pglite(planned in v2).

For now, it's more accessible for me to hack it in hours and it works.

yeah, w/o py-pglite attempt this should be the only approach, the pglite ideally could make it more flexibly/lightweight in unittest cases, but as you mentioned it's never felt slow, it should be fine to working on it.

And actually, more e2e cases I think it's way better to not use the lite backend.

the non-container solutions would do more like the lifecycle mgmt/isolated env prep/tear-down with elegantly designed abstractions. While I think similar abstractions could be done on top of containers.

Maybe we ideally could have unified abstractions on both container-based, wasm evantually to boost dx yet with different expectation of speed vs compatibility.

Thanks, duno this before and it looks like the ultimate shape py-pglite in js world~~

the target would be just baremetal binary with some changes needed and the purpose was just to be python dx optimized

wow, thanks! it should be feasible! and as I recall there are such thing from some databases(chromadb, milvus-lite) in the py-first communities.

we could think big to someday do that within py-pglite project actually.

let me put it as the roadmap of v2(much more work to do!)

This is also an option(verifies data schema, query in some way) with SF SQL translated to duckdb SQL and testing it.

https://www.reddit.com/r/SQL/comments/10s4608/comment/j722e1...

aha, SF is pure managed service, thus 100% local/or even lite-local of SF seems not feasible, maybe clickhouse/databend could be consider to enable such flexibility of lightweight testing?

Roadmap of v1

https://github.com/wey-gu/py-pglite/issues/4

I need this in my use case, so built it after downstream e2e verified working!

Too real, can’t stop clicking

I am an paid cursor user for almost one year, still I use GitHub copilot(thanks to the open source work)just because of nvim, when I need to open single file rather than a project, and I need to ensure I am still handy with nvim.

ISO-GQL

@Yetone is working on bringing a cursor-like experience to the Neovim community.