dhamidi

> So an engineer who knows your codebase and tests can sneak in malicious code/backdoors because you're high trust.

What is the alternative? Bumping a dependency in a PR and getting a LGTM can also introduce a backdoor.

That's another form of high trust: your trusting the publisher of the dependency.

High trust comes with high responsibility, which is easier to enforce when the trusted party is an individual on your team with generally aligned incentives, rather than an organization or unpaid individual on the internet serving many.

Working at Amp

We...just read the commits, and talk to each other.

We're also pretty trigger happy with the Huddle button in Slack.

Nobody on the team would go back to mandatory PRs

HTMX is great, Hypermedia and HATEOAS are great, HTML-string-templates are not great.

For some reason they are still popular.

A fun experiment is to use a JS runtime with React but render the component tree on the server onto a Writeable stream.

Very easy to understand, no useEffect footguns, great composability.

You can swipe the Termux special ribbon to the left and then get a native text input where dictation etc all work.

This:

    node + npm + vitest + vite

Turns into:

    bun

That's the benefit

I understand the sentiment. Rails was my introduction to hypermedia and it was convenient and easy, so experiencing friction when building with Go/HTMX came as a surprise.

After a few attempts I learned that abstractions are important :D

Without a component builder and reversible router is indeed pretty painful (and Rails just ships with these things so you didn't have to worry about it).

The biggest benefit for me personally is that computation and data live in one place, which carries you very far. Also, machines like hypermedia: LLMs are great at using and testing hypermedia apps because they are self-contained and the cycle time is lower because you don't need to wait for JS.

And yes, no easy off the shelf component library makes starting harder.

Disclaimer: I'm part of the team building it

That's what Amp is built around!

By default conversations are shares in your team (you can also make them private), and the agent has access to them.

So you can do things like "how would $teammate think about this" and the agent will read your colleague's conversations with Amp to get a feel for that and evaluate your work based on that.

Or just figuring out what everyone is doing at the moment is much easier that way

I know it's in vogue to bash Bash but I feel that criticism is unfair.

Shell scripting is a victim of its own success: it is _so easy_ to get started that most users get value out of knowing the first one percent and never bother to actually learn the rest.

There aren't many who have read the Bash manual, or know what zsh can do that Bash cannot, etc.

"Shell scripting is a hot, slow mess" is the same hot slow mess that you get wherever the barrier to entry is extremely low (e.g. early PHP, early JavaScript/frontend development, game development with a game engine where you can just click around in the editor, etc).

Maybe useful inspiration from TCL: there are many commands that define new variables, which makes modeling the stack unnecessary.

For example:

  lappend responses [dict status 200 body ...]

Appends a new dict to the list held in the variable responses, creating the variable if necessary.

I can see that being an attribute:

  <request-send url="..." as="greeting" />
  <response-text response="greeting" as="text" />
  <selection-set-text text="text" />

Thank you!

> Are you doing a mostly one-to-one port, or something more novel?

Step 1 is a one-to-one port of all the non-I/O, non-OO stuff. I've got it down to a single skill for Opus 4.5 and now it's just a matter of turning the crank and keeping an eye on it.

Step 2: add more functionality for interactive use for humans/agents. Things like defining the syntax of commands, a completion engine, a help system. Essentially all the things you'd expect from a modern shell experience, but with a bring-your-own-UI approach.

> but man is reference counting a pain in the neck or what.

Maybe this is a bit more novel: since the only use case is embedding, and the host language already has dicts, lists, and other data structures, I'm just leveraging those. In the Go version of Feather, dicts are Go maps; in the JavaScript version they are backed by lists of pairs (to preserve insertion order)

Not affiliated, just have been following development closely: Phrasing leverages existing content, e.g. subtitles from your favorite shows.

The quality depends on the source material you choose to give it.

This is great, I was literally looking for something like this yesterday to embed TCL into a Go application without needing CGo