The thing lets you create a single CLI for any number of APIs following OpenAPI v3 or JSON Schema. I've tested if with our self-hosted Grafana and it does work, though I am not sure if it is as good as the Grafana MCP.

Anyway, it seems perfectly positioned for the CLI over MCP push, while sitting at 1.2k GitHub stars which is tiny by AI standards. So I am wondering if there is more nuance in CLI over MCP here or if other solutions exist?

(Note: I am not in any way affiliated with the project, I just think its neat and interesting)

Comments URL: https://news.ycombinator.com/item?id=47445145

Points: 2

# Comments: 1

(1) Are there any plans to make this compatible with the ducklake specification? Meaning: Instead of using Iceberg in the background, you would use ducklake with its SQL tables? My knowledge is very limited but to me, besides leveraging duckdb, another big point of ducklake is that it's using SQL for the catalog stuff instead of a confusing mixture of files, thereby offering a bunch of advantages like not having to care about number of snapshots and better concurrent writes.

(2) Might it be possible that pg_duckdb will achieve the same thing in some time or do things not work like that?

(1) https://companiesmarketcap.com/automakers/most-profitable-au...

I mean VS Code, Discord, Slack and Obsidian are all in very widespread use and work perfectly fine for me.

Are there alternatives to Electron that require less resources? Tauri seems to be proof that there are.

But I think there is real value in large communities and backing. Electron seems to work perfectly fine to me for everyday use as is evident by the applications mentioned above. I would personally choose Electron over Tauri even for greenfield projects, simply because Electron seems to power applications that are in much more widespread use.

Is that more in the nuances or is there a fundamental difference between these two (referring to the terms and not their specific implementations in Symbolics.jl and Coq respectively)?

Or is this question unreasonable to ask in the first place?

If I am reading things correctly with Kafka the workflow equivalent to what's written in the article would be to have your producer produce via hash-based-round-robin (the default partitioning algorithm) based on the key you are interested in into some topic and then your consumer would just read it and your data would already be sorted for the given keys (because within a partition Kafka has sorting guarantees) and also be co-partitioned correctly if you need to read some other topic in with the same number of partitions and the same logical keys produced via the same algorithm. No?

It's not Lisp but Scala so may not be the authors language of choice however it can be used as a Shell: https://ammonite.io/#Ammonite-Shell

I am personally using it and compared to a classical shell like Bash it's really nice for more structured data related tasks (exploring some API, checking some data, creating a bunch of PRs at once, ...).

It also makes use of Scala's adjustable syntax and functional concepts so you basically get shell piping but in a strongly typed fashion (e.g. `ls.! |? (_.ext == "txt") | (os.read)` would produce a list of strings representing the contents of all files ending in .txt of the current directory).

Also I am curious what people think of PowerShell which as of PowerShell Core is usable on all platforms as well.

Well I guess the thing is left unanswered for now is why the quota management reduced the capacity for Google's IMS in the first place.

Maybe we will know someday :)