Choreographic programming is well-known within the programming languages literature, which is the audience this README is intended for. The level of detail here is fine, not everything is written with being posted on news.ycombinator.com in mind.
To explain it briefly though, choreographic programming is a method of writing distributed programs that communicate in some message-passing fashion by -- rather than writing separate programs that communicate with send/recv and must be very intentionally designed to be in sync -- you have /one/ unified messaging primitive. In a typical distributed system, you might have something like A.send_to(B) / B.recv_from(A). In a choreographic system, you'd rather have something like A ~> B, where send_to and recv_from are /projected/ from ~> into separate programs during the process of compilation.
You might want this kind of abstraction for various reasons, but the biggest is that many choreographic systems offer a guarantee of deadlock-freedom. This isn't without tradeoff. At the moment, choreographic systems (and session types, another distributed abstraction) are very bad at handling any kind of failure / degraded performance over the network. There is active work within the PL community on resolving these issues, but for now, choreographic programming is primarily useful for prototypes, rather than production systems.
> not everything is written with being posted on news.ycombinator.com in mind.
The creator of this posted it here, though. So maybe if someone is posting something here we can ask that they include sufficient context for the intended readers to understand it.
Thanks for elaborating, I knew already what it is and is actually adequate architecture for some cases. I just complain at how is explained in an exclusive abstract level instead of an approachable dance of balancing definitions with real word examples to give our brains a break and let them breath bits of real world.
Burroughs Large System (aka B5000-B8500) still (virtually) exist as Unisys Clearpath MCP. You could download a VM if you wanted to try it (I assume you still can).
BiiN and i960 are sorta the same thing to the extent that Intel took the BiiN work after that project died and commercialized it as the i960. Unfortunately, except for the early i960MC, XA & XM versions, Intel was busy stripping feature out of it to make an embedded processor instead of making use of the really cool parts. What might have been...
Alongside updated manuals for NEWP, one of the very first (almost) memory safe systems programming languages, and probably the one that introduced the concept of unsafe code blocks (JOVIAL doesn't seem to have had them).
Location: Curitiba, Brazil (UTC−3)
Remote: Yes (only) — 10+ years remote with US / Canada / EU teams
Willing to relocate: No
Technologies: Rust, agent harnesses / LLM product engineering (not research)
Résumé/CV: https://sebastiansastre.co/cv · https://www.linkedin.com/in/sebastiansastre/ · https://github.com/sebastianconcept
Email: sebastianconcept@gmail.com
Looking for a remote mid or senior IC role with real ownership and preferably Rust-first backends. Distributed systems, fintech/crypto okay, AI infra / agent platforms; open to strong equity on early-stage.
A record that matters: between 2009 and 2015 I was a tech founder. Last nine years, three different teams, three different tech stacks, zero production incidents on the high-scale systems I owned. Many of these from zero to prod.
A good explanation is not a fix but is a good starting point to a good diagnosis which is the foundation of a good fix.
The issue is when the calls and urgency are raised before making some mental space to even verify that there is enough clarity on what happen and these interrupt the clarification and remediation planning process.
Saying you shouldn't ask "Why did this happen?" and you should ask "What we're changing?" instead is wanting to jump the gun and pretend a required step doesn't exist.
It does exists, is just the executive anxiety reasonable in terms of wanting to be protective of the business but as protective as a family member of a patient wanting a good outcome from the surgeon during the surgery.
Only worst because the surgeon's boss is this anxious family member, and she has a laboral gun pointing to the doctor's neck.
Yeah, I disagree with SVP's approach in this story. First, get the current issue understood, resolved and remedied. Then, thank the team for their good work in fixing this issue, and do a post-mortem to see what process improvement could have prevented the issue from rising in the first place, or at least detected and mitigated it more quickly.
Can you add a "why?" / "why now?" section?
Don't be another project that is a bunch of how that is leaving out to explain why it exists or exemplify what classes of problems it unlocks solutions for (applicability).
It sort of goes over the "why?"/"why now?"; but TLDR; Wanted to use Godot & Rust in personal project(s) (no pressing need for it) I saw Cate & wondered whether I could use this tech. stack to replicate, instead of web tech. So that's where it all started. I know that if you want to live in the terminal, there's tmux and herdr, and I'm not (also can't) compete with them. But I can surface a terminal that then lets TUI folks stay in their preferred apps. The residual why/why now are largely shaped by what I want (feature-wise) to put into the tool.
And the next big feature I want is a personal knowledge management. Maybe it looks like a complex beast; but the core idea driving my features are what I want on a daily basis without switching context as much. Sorry, I know it's not a great answer, bit rambly.
reply