One concern I have is that this async/await approach is not "AOT"-enough like the Triton approach, in the sense that you know how to most efficiently schedule the computations on which warps since you know exactly what operations you'll be performing at compile time.
Here with the async/await approach, it seems like there needs to be manual book-keeping at runtime to know what has finished, what has not, and _then_ consider which warp should we put this new computation in. Do you anticipate that there will be measurable performance difference?
Doing things at compile time / AOT is almost always better for perf. We believe async/await and futures enables more complex programs and doing things you couldn't easily do on the GPU before. Less about performance and more about capability (though we believe async/await perf will be better in some cases, time will tell).
If you can tell deterministically whether an 'async' computation is going to be finished, you can most likely use a type-system-like static analysis to ensure that programs are scheduled correctly and avoid any reference to values that are yet to be computed. But this is not possible in many cases, where dynamic scheduling will be preferable.
UI and user ergonomics continues to be Zulip's biggest blocker to wider adoption. I understand that to many people not having E2EE and truly independent self hosting (e.g. push notification issues) is a deal breaker, but for many organizations the current level of openness from its values is enough.
I really wish Zulip could find someone to re-design the interface around the channels/threads model to make it easier to use and more friendly to beginners. I am personally never bothered by the design and got used to its interface quite quickly, but I know many many people who got turned away by its design or uses it in a Slack/Discord way by posting everything into "general chat".
I am one of these people. I remember liking the concept a lot, but just couldn’t stand wading through the UI (or telling anyone else that I expect them to).
We've been using Zulip for our company chat for 2 years now. It does what we need it to do — while letting us control where it's deployed and where the data is stored (!!). But the UI is dated and awkward. The general feeling I get is that everyone at our company is okay with Zulip, but no one loves it. It just has that air of mediocrity about it. It's "okay".
> 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.
reMarkable just open-source your display drivers and E-ink render stack please. I'm pretty sure the pressure curve issue can be solved just by tuning a few parameters in the code. I appreciate reMarkable for adhering to GPL and giving us trivial root access to the machines, but while you're there I really don't see why you don't just do it fully.
Even with the limited amount of usability, the community has already made some amazing additions, for example KOReader. Imagine how far we'd get if we can just write any app we want for reMarkable. I would completely get a typefolio and ditch my laptop if I have the ability to *easily* write my own app on the reMarkable without going through the loops of binary patching and other quirks.
The display driving code is part of their "xochitl" binary, which is not GPL (and might not be allowed to be, eink-the-company is rather protective of their tech and waveforms). ~All modding happens by reverse engineering the binary to call into that code, either to change behavior (rmhacks) or to act like a display driver for other software: https://github.com/ddvk/remarkable2-framebuffer
The rest has been released a few times, though last I checked it was quite out of date. Far from ideal, but still significantly better than most companies: https://developer.remarkable.com/
I often suffer from having too many things I want to work on, plus impulsive tasks (e.g. I saw an issue on GH that I happen to know how to solve) that I go on and spend 3 hours to do right away, causing delay in everything else more important. I force myself to only spend time on tasks on the "Active" view (minus a very small set of exceptions). All other impulsive thoughts go into "Backlog" status. Every night I review the "Backlog" view and move issues that I actually decide to do in the "Active" view. Also obviously you have to periodically clean up "Backlog".
That is the most important value Linear brings to me. There are other tools that can achieve similar effects, but I learned how to do it with Linear at work so I stuck with that. On top of this, Linear has priorities, deadlines, task blocking relations, etc., that naturally reflect how I prioritize issues in life. This is the same as how I prioritize tasks to do at work. Once again there are tools to do this outside of Linear, but none of them are as polished to use and just work.
I really applaud your discipline. It took me a long time to realize that the todo system you use is almost meaningless if you don't execute on the items that you prioritized.
Haha thank you, I must admit I can't make it always work out, but writing (typing) them down and forcing myself to look at the view to remind my brain is a lot better than juggling all the priorities around in my head. I really really hate planning tasks, I just want to do things and write code, so Linear is a good way for me to offload these computations and just focus on clearing the list.
I'm not OP, but heres how I connect Claude Code [1] to Linear MCP [2]. This allows CC to run a natural language type standup with your tasks when you type "standup". Other than that, I use Linear basically in the way they make it, using Projects to track long term initiatives and trying to honor my "in progress" list.
I'm trying to make a Chinese Hanzi variant of Wordle called Handle 汉兜 [0] available as a Discord activity/app so my Discord groups can have fun solving puzzles just like we've been having with NYT's official Wordle Discord app[1]. A Discord app is just a webview or iframe embedded inside Discord that you can launch.
> There is third approach, established by a group in Minnesota [1], which is to design languages and tools which are modular and extensible from the get-go, so that extensions are more interoperable. They do research on how to make this work using attribute grammars.
MLIR [1] has entered the chat :P
I know I know MLIR is an IR and not a programming language, but MLIR does give me the feeling of "an IR to rule them all" (as long as you're ok with SSA representation), and the IR itself is quite high-level to the point it almost feels like an actual programming language, e.g. you can write a MLIR program that compiles to C using the EmitC dialect that feels a lot like writing C.
Here with the async/await approach, it seems like there needs to be manual book-keeping at runtime to know what has finished, what has not, and _then_ consider which warp should we put this new computation in. Do you anticipate that there will be measurable performance difference?
reply