Adopting a New Massively Parallel Language
April 26, 2022

Adoption noteOriginally posted 2022-04-26; rewritten here around the engineering adoption problem.

Included: emulator-first adoption, syntax, examples, concurrency semantics, debugging, runtime boundaries, and the Erlang/Elixir reference point.

Article focus: what a new massively parallel language has to make concrete before another builder can use it.

The Adoption Problem

A new parallel language is not adopted because the idea is large. It is adopted when another builder can run it, read it, debug it, and connect it to a real machine.

The 2022 post was written around Cartilage and the need for an emulator engine. The durable point is narrower: a language for massively parallel work needs an executable surface before its syntax can matter.

What Has To Be Concrete

Why Erlang And Elixir Were The Reference

Erlang-like systems are useful references because they made adoption possible around a runtime model, not only around notation. Processes, messages, supervision, failure isolation, and upgrade behavior are part of what the language means.

A new parallel language has the same burden. If the system asks people to think in many active places at once, it has to give them practical handles for communication, restart behavior, placement, ordering, and support.

The Useful Path

The first useful deliverable is not a manifesto for a language. It is a small emulator with examples that can be run, changed, and inspected.

From there, the language can earn each additional layer: syntax, type or capability rules, statecharts, object-capability boundaries, hardware-region mapping, SerDes and clock-domain behavior, and eventually a bridge to real fabric or FPGA implementation work.

Original Post Context

The original post was an early recruiting and adoption note for prototyping the Cartilage emulator engine.

The durable claim is this: adoption for a parallel language starts when the runtime behavior is visible enough that a second person can run examples and see where the work, state, messages, and failures live.