I imagine the actor model implemented on top of a stable core (eg. Erlang/Elixir on BEAM) might be a natural fit for a "society of mind" like zoo of agents bustling around, working asynchronously, communicating with each other other and with the user(s), etc. Personally, I'm also excited to see how Spritely Goblins shapes up, esp with because of its support for object capabilities -- which should hopefully be an excellent security model for agentic architectures.
Google Chat is definitely a product that could use more love, but it is situated in a specific internal landscape, and grows out of it. Slack is built for a very different context, and I doubt Google would build something like that. Google simply doesn't see the world the way someone who likes Slack would (and I also doubt a large co like Google could operate out of Slack).
Such as who? And are most of their employees actually using Slack or are a few white collar employees using it while 90% of their workforce has no idea?
> It instead is a chat where a thousand group chats are open, and no once wants to read any of them.
Do you mean people are happy to post on a thousand different threads, but no one reads posts from anyone else?
Why do you even have so many different active threads? Why not just let "resolved" threads be, and funnel conversations into fewer threads? (esp if you want ephemerality i.e. conversations to expire with time)
> 300+ members in a makerspace
If you have 300+ people discussing a wide variety of things, how do you ever expect to maintain your sanity with only channels and without threads? Won't every channel be quickly flooded and really hard to resurface anything useful from past discussions?
> I cannot [...] unless I have elevated access
Is your complaint that your Zulip space is not moderated well and that it would be helpful to ad-hoc decentralize some of the maintenance work across more participants?
> my entire team hates them and anyone trying to post important stuff in topics gets ignored lol we can't help it our brains just don't want them in our lives.
I have a theory for why some people love Slack and others love Zulip (Completers -vs- cultivators) which I shared in a sibling thread.
> UI and user ergonomics continues to be Zulip's biggest blocker to wider adoption [...] many people who got turned away by its design or uses it in a Slack/Discord way by posting everything into "general chat"
Having thought about this a bit, I propose there is an underlying dichotomy between "completers" and "cultivators"
## Completers
Prioritize "velocity" and closing open loops. Limiting context means that they can act with focus. Close tabs often. Communication appends to the task queue; each conversation is an open ticket to be closed. Anything that scrolls off screen is implicitly marked as done. The ephemerality of the stream allows them to "process" a conversation and move on. Zulip might cause anxiety because threads/discussions linger without closure.
## Cultivators
Communication as externalized cognition. Messages are nuggets to be filed / incorporated into a larger schema. Wants a "dashboard" to maintain sense of control; fears something falling through the cracks more than they fear clutter. Don't care to "finish" a chat; want to keep the context organized and accessible for deep work / future decisions.
## Problems
Zulip defaults to assuming that all chat is valuable and taxes every interaction with a little bit of up front effort. Slack assumes most chat is of ephemeral value and doesn't see the point of taxing 90% of the interactions for the 10% that might be valuable. Slack forces cultivators to become completers and Zulip nudges completors to act as cultivators.
Completers preferring who prefers Slack/Discord/etc are implicitly adopting the the fragmentation of multi-system setup -- chat for ephemeral communication, and anything longer term must move to docs/wikis/Jira/whatever (which now begs for dozens of "integrations"). Understanding the state of anything now requires forensic archeology. (cue [Charlie Pepe Silvia meme]) Complicated acrobatics in channel names such as `#team-proj-blah` are attempts at combating the fundamental entropy of treating everything ephemeral.
The challenge is that, ultimately organizing is also real work and ignoring it in a short-sighted drive for efficiency hinders longer term effectiveness.
## Potential solutions?
1. The chat platform could offer two different views: a triage flavored mode for completers, and a dashboard flavored mode for cultivators. Even one person could toggle back-and-forth between the two as necessary.
2. Better UX for organizing incrementally, eg. UX improvements for manual clustering, and AI-assisted clustering / topic naming. Wouldn't it be great if people could continue chatting in the stream but the same message would simultaneously get filed under a topic? Technology might now enable such a product experience.
3. Slack needs to stop pretending that search is an effective replacement for organization (esp when search is crappy). I haven't used Slack in a while (preferring Zulip with catchall topics as a good balance) but I get the impression that Slack [Canvas](https://slack.com/intl/en-in/features/canvas) is an attempt to combat this problem.
I don't think slack or discord are optimised for completers. They are optimised for dopamine stimming. Sure, not every chat has much value. But it all has a cost.
I don't know zulip, so I can't comment on whether it's better. The most effective org I worked for didn't use messaging: email, or in person only.
This is super interesting framing. I’m definitely a completer, not that I like much about Slack. Probably useful to have this kind of discussion before/while making knowledge management decisions in startups.
You could literally drop this into Claude Code or Codex and point it at a local fork of Zulip and have it build your bimodal version with triage and grazing styles.
Topics are otherwise incredibly useful even with a small number of people, if you want to carry out parallel & wide-ranging conversations on different timescales. Implicitly designing for a single topic per channel forces chats to be ephemeral and makes it very hard to have long timescale discussions.
Eg. If I'm discussing buying a house or a career change (personal) or a new business strategy for my company (work) I don't want all conversations dumped into a single river. Slack's model of threads within a channel feels too schizophrenic; Zulip's model of multiple conversations arranged loosely by theme (and accessible from the sidebar) is much better.
Catch-all topics are good for the ephemeral stream of chatter.
Some might say that chat should be only for ephemeral stuff, but then that is basically avoiding the essential complexity (of long term conversations) which must live somewhere to enforce some Procrustean simplicity on the chat platform.
I wish Zulip (and other apps) provided an inbox instead of just ephemeral notifications that disappear once a message is viewed. Lack of inbox means that I have to use unread messages as a way to manage my inbox -- because the moment I click on a notification / take a quick peek at a message there's no easy way to mark it for coming back to later.
----
+100 for Zulip though; by far the sanest messaging experience for this kind of context.
I just had a look. I can absolutely understand parent. I’d want an option to include read messages in the inbox, not avoid marking as read. I want a history of stuff in my inbox, the same way discord, my RSS reader, and my email client work. All those have a read and unread state, but I can still see the read ones.
(And administrators can set it to be the default for new users in their organization, if the way your organization communicates is such that it's a better default than inbox).
I heavily use Discord for fan works stuff (I run some major annual fan works projects, like a big bang, charity fundraiser, zine, etc.).
That's how I know Discord has this feature! Top right corner has an @ and it's the "mentions", which is a list of every notification. I couldn't do all the managerial/administrative work on these projects without it.
Another feature you can use in Zulip for this workflow is starred messages; just star messages that are not done, and then you can browse the starred messages view when you've got some time to follow up on things.
The early printing press was probably focused on short few page documents (an increasing scale), and it wouldn't be surprising if page numbers were a solution to help printers not mix up pages.
Your hypothesis does not match history, because the early printing was focused on things that had a potentially large market, which at that time meant books like The Bible, with a lot of pages.
The parent article mentions that binding the pages of the first bibles in the correct order, in the absence of page numbers, was an extremely tedious work.
That is why page numbers have invented many years later, exactly as you say, "to help printers not mix up pages".
> it wouldn't be surprising if page numbers were a solution to help printers not mix up pages.
It's an interesting idea. Remember they printed large sheets containing many 'pages', I think even in different orientations, which were then folded and the ends cut to produce a nice orderly codex for the reader. They were printing in a different order than the one you read in.
I do think they numbered the large sheets or similar, and you can find old books that retain that number, but I don't recall what it is called.
Hindsight is 20/20 , lol. There are so many obvious, effective constructs and functions in modern English, we kinda miss the absolute janky mess of hacking and tradition and arbitrary rules and facepalm moments that went in to the last 1500+ years of development, let alone the tens of thousands of years prior.
Not necessarily harder, just add 'jdk25' to home packages. If you really don't want to use JVM you can use Babashka to start clojure and use it like you would bash.
Well, it makes it much harder to build the system from a simple assembler.
Guix is AFAIK the only distro with a well-paved bootstrap path from a simple assembler to a fully-working distro[0]. Adding the JVM or even GraalVM (which is what Babashka is based on) makes the bootstrapping that much harder.
reply