scottmessinger

I love Zed and have been using it for years. I’ve been especially excited about multi-agent support—it feels like it could be a genuinely powerful model.

That said, the current UX is pretty confusing.

There’s a mismatch in visual hierarchy: selecting an agent in the sidebar appears to change the entire editor’s worktree/branch, but the worktree/branch selector lives in the window titlebar, which strongly implies it controls the whole window. So it’s unclear which is the source of truth—the agent or the window.

That ambiguity shows up in the workflow too. If I want to create a new branch/worktree and then start an agent on it, I can’t do that directly. I have to:

1. create an agent 2. start a conversation (to instantiate it) 3. then switch the branch/worktree

That ordering feels backwards—I’d expect to define the context first, then start the agent.

Even basic navigation is unclear. If I switch the branch in the titlebar, does that affect the current agent, or the whole window? If I want to return to a previous worktree, is that tied to the agent or not? I still don’t have a solid mental model.

It feels like there are two competing concepts:

* agents as independent workspaces * the window as the workspace

Right now they overlap in a way that’s hard to reason about.

The feature has a lot of promise, but the current UX makes it difficult to predict what’s going to happen, which makes it hard to rely on.

I couldn’t find the pricing page on the website. It might be because I’m looking at it on my phone and the nav item doesn’t show on small screens?

Is the pricing transparent and, if so, what is it?

Thanks! Followup question: After you "eject" the app and start paying AWS directly but continue using porter, is the experience more like the archived repo? Or, is it still Porter Cloud just with different billing underneath?

Very cool! As someone pointed out, your github repo says it was archived: https://github.com/porter-dev/porter-archive Naively, I would think Porter cloud would just be a managed version of your porter-dev/porter-archive. Could you talk about how it's a different product than before? Did the code base change significantly?

FWIW, I've been using Elixir in production since 2016 and haven't found I've needed to learn any erlang. For context, we use Elixir for our backend and serve around ~100/rps over websockets. We've integrated Elixir into Stripe, Segment, Google, and Xero and haven't found we've needed Erlang libraries for any of those integrations or any of the other parts of our code base.

> Elixir when they invariably stumble across the things in erlang — libraries and the like. I'd hoped I could avoid it myself, but it's too interdependent.

This hasn't been true in my experience. I'd be curious to hear which Erlang libraries the OP has been using.

We had looked into Quill but decided to use Threads.com. Considering how inconsiderate Quill's shut down was, it was a good decision for that reason alone.

For anyone looking at alternative for threaded messages and find Slack's threads insufficient, our team loves Threads. We looked at a few others (Zulip, Twist) and landed on Threads about 2 years ago. Since then, the product has gotten better and better.

Also, haven't posted to HN much -- is this an appropriate thing to post on a thread like this?

We adopted it 4 years ago and love it.

As for training people, I taught my non-technical co-founder Elixir for some backend scripts he needed to write. He found it much simpler to pick up then Javascript or Ruby and his code was idiomatic rather quickly.

As for the IDE support in VSCode, I've found ElixirLS[1] great. I do have to restart it sometimes (delete the .elixir_ls folder), but that's a small cost to pay for a pretty great experience.

After spending years in RoR in multiple code bases, I find Elixir code bases to be easier to debug and libraries easier to grok. Without the mutable state of OOP, I don't find myself asking, "Where is this state coming from and when/how was it set?" Of course, macros can be hard to follow, but I still find an Elixir library more straight forward than a Ruby one.

We've also experience the great performance and reliability shared by others on this

We haven't had difficulty finding the right libraries even though the ecosystem isn't as mature as Ruby or Javascript.

[1] https://marketplace.visualstudio.com/items?itemName=JakeBeck...

I'm glad to hear this! Using Remirror worries me because it injects an abstraction between our code and PM.

However, when I look at your docs, it's not clear it's a different in approach from Remirror. The imports are all from bangle.dev which makes it seem like the same approach.

I would love to see a doc explaining the "API overhead" and how to use PM directly. I want to feel confident I can easily drop back down to PM if Bangle doesn't have a feature I need or implements it in a way that won't work for our use case.

Really excited to see this approach! Shared PM plugins are a great idea!

Looks interesting! I'd love to see a link to a demo.

I had a similar experience with Atlas. At least 1.5 years ago, Atlas felt like a enterprise company trying to do a SaaS. They used the same sales person driven approach I associate with enterprise sales. mLab just felt far more developer focused.

We also left compose but left to move to mLab. When Compose was still MongoHQ, we were really impressed by their support. In the last few years, we became incredibly unsatisfied. mLab has been awesome and responsive. I hope the move to Atlas doesn't cause their support to change.

In the comments, you mention how Quill is extensible. Does Quill's extensibility enable the creation of a hierarchical level that resembles an HTML <section> element? From what I can tell, Quill/Parchment divides documents into block blots, inline blots, and embedded blots[1]. If I wanted to create a group of block blots, could that be done with Quill? In HTML, this would look something like:

    <section>
      <h1>First Section</h1>
      <p>Text...</p>
      <p>Text...</p>
    </section>

    <section>
      <h1>Second Section</h1>
      <p>Text...</p>
      <p>Text...</p>
    </section>

[1] https://github.com/quilljs/parchment#block-blot

What are the performance characteristics of realtime push? Does the performance of inserts slow down with the number of subscriptions to change feeds? Or, is insert performance unrelated to subscriptions? Also, does the change feed only show the before/after or does it also show the query that was used to transform the data?

Congrats on releasing Quill! I've been following the development since it was called "Scribe" and I'm excited it's released.

I noticed there seems to be support for block level formatting (e.g. "h1"), but it doesn't look like it's been implemented yet. What's your plan for handling bullets, headings, block quotes, and other block level formatting options?

It appears as if rank is stored as a float. The rank can quickly get to be a very, very small number. It seems at some point, float precision might be an issue and/or length of the rank key. Have you run into this and/or do you have solutions?

Brandon Keepers wrote about trying this idea in Ruby http://opensoul.org/blog/archives/2011/09/06/sortable-lists-... and ran into a float precision issue (see comment).

I like it's elegance, but it looks seems similar to using an Ember.js view and Handlebars templates. http://j.mp/reactiveinember

I've also shipped an Ember app and a Knockout App. To me, there's no comparison: Ember development was easier and produced a faster app and a better organized code base.

Once my app grew complex, Knockout grew increasingly hard to reason about how it's view updating was working. It also grew slow.

Also, Knockout lacks any legitimate data laye (knockout-mapping isn't a data layer). Ember has ember-data.