Community

Built in the open, from Myanmar.

LukeLang is a small project with a long argument behind it. Everything — the strategy, the scorecard, the things that are still parked — is written down in the repository, so you can disagree with a decision by reading the reasoning first.

Who builds it

LukeLang is designed and developed by Kaung Myat San. It is Myanmar's first official programming language: a compiler, a reactive runtime, a standard library, editor tooling and a test suite, developed in public from the first commit.

The project has one beachhead — reactive full-stack web — and says so plainly. Mobile, game and canvas tracks are parked until the first one is won. That decision, and the eight others like it, are recorded in strategy.

Contributors

People who have helped, credited by name in CONTRIBUTORS.md.

  • Kaung Myat San

    Creator — language design, compiler, reactive engine, Live Graph, standard library.

  • Lin Aung

    Installed gdb in GitHub Actions so the debugger checks (debug_break_step, debug_inspect) can run in CI. #35

Where to ask

  • GitHub issues

    Bugs, compiler errors that look wrong, and anything reproducible. A failing .luke file is the best possible report.

  • Discussions

    Design questions, "should the language do X", and ideas that are not yet a bug.

  • Pull requests

    Fixes and features. Small and reviewable beats large and heroic.

How to contribute

Get a green baseline first, so you know any failure afterwards is yours:

git clone https://github.com/lucasdmarshall/LukeLang.git
cd LukeLang/vm && make
make test

Then read the contributor guide for the repository layout and where each subsystem lives. In short:

  • vm/src/ — lexer, parser, lowering, C code generation, LSP and DAP
  • vm/stdlib/ — the standard library, written in LukeLang
  • vm/runtime/ — the C runtime headers the generated code links against
  • examples/ — the acceptance suite; new behaviour arrives with an example
  • docs/ — the canonical documents, checked by scripts where possible

The bar for a change

There is no second reviewer on most days, so the automated gates are the review. That is deliberate, and it is why they are strict.

  • It runs

    make test is green, including the Play VM and Build paths.

  • It is pinned

    New behaviour arrives with an example under examples/ that CI compiles and asserts on.

  • It is written down

    If it changes the language surface, the specification changes in the same commit — the spec is machine-checked against codegen.

  • It is honest

    Anything provisional is labelled provisional, in the document and in the scorecard.

Where help is wanted

  • Platform coverage

    Building and running the suite on macOS, BSD and less common Linux toolchains.

  • Editor integrations

    The language server already speaks LSP — clients for editors beyond VS Code are wide open.

  • Migration grind

    Conversational forms the v2 migrator still marks TODO(migrate) instead of translating.

  • Documentation

    Worked examples for the standard library, and prose for anything you had to read the source to understand.