wlamartin

I think in a language designed around FP ergonomics and expectations there's a lot to like about it.

In your second example, as a retrofit, I find myself asking "when does MapErr stop consuming the input list?", "which error gets returned if multiple errors could be returned?", "is it a errors.Joim situation", "if there are multiple errors how do I map them to the failed elements in parsed", "if I did want each parse to have either success or fail (think Result type) how would I represent this generically in a language that favours multiple return types"

There's a lot going on with that example that a for loop makes explicit and flexible for other choices.

My memory is that once you begin using the alternate screen, you need to turn on mouse reporting, and then you lose native copy. Different terminal emulators also act totally differently when in this state.

I don't think people in this thread aren't really confused about MCP. They are confused that you claimed, or at least insinuated that an LLM might skip the schema validation portion of an MCP tool call request/response, which was originally demonstrated via Claude Code. Hopefully you can understand why everyone seems so confused, since that claim doesn't make any sense when the LLM doesn't really have anything to do with schema validation at all.

I'm not sure whether you're confused, or I'm just having a horrible time understanding your point. The MCP server really does just serve requests with responses via a mechanism that satisfies the MCP spec. The MCP hosts (e.g. VSCode) work with an LLM to determine which of those tools to call, and ideally work with users via confirmation prompts to ensure the user really wants those things to happen.

What am I missing?

I do believe there's more that the MCP Server could be offering to protect users, but that seems like a separate point.

I've been using your app for the last 3-4 months very successfully. There are a few niggles here and there but overall it's been exactly what I needed, and I'm very grateful for it!

Just as a note, the GitHub CLI doesn't use bubbletea itself right now, though it does use other charm libraries such as lipgloss and glamour. That said, it's quite likely that at some point we will use huh for our prompting library, which does use bubbletea.

I'm a maintainer for the GitHub CLI. When our prompting dependency became unmaintained, the folks from Charm reached out to us looking to collaborate on a replacement (collaborate is a strong word for the amount of work they actually did compared to us).

While we haven't yet been able to prioritise using this package, our discussions with them were great and I think that in typical Charm fashion, they've created something really awesome here. In particular, we mentioned to them our desire to have accessibility as a first class experience and I think they really took that on board.

Recently, I've been toying with including asciinema in automated tests. Spinning up a TUI or richer CLI experience, sending it keystrokes, asserting on the output, all wrapped up in asciinema so that if it fails I can see what went wrong via the playback.

Jury is still out but it's been an interesting experiment.

When recording finishes you are given the option to upload or save to local file.

Northern Irish, living in the Netherlands, commenting on hacker news, there must be severals of us!

Years ago when I was starting to interview for Uber in Europe I went through some data structure exercise which I failed at horribly. When I asked the hiring manager whether this was representative of the job, because I would probably not be good at it they said "no", and to follow up, when I asked why we did it they said, "in the next round my colleagues in the USA are going to ask you something similar".

I guess this wasn't entirely without sense but sort of seemed to be missing the point.

I don't follow this. My assumption for the repository interface is something like (language, error and domain agnostic):

   interface Repository<T> {
      FetchAll() T[]
      Fetch(id) T
      Persist(T) id
   }

Why would the SQL statements be reflected in the behaviour that the interface is providing?