Salam Language, inspired by the word salam (سلام), meaning peace, is engineered for exceptional efficiency, reliability, and modern software development. Designed from the ground up to balance low-level control with developer productivity, Salam eliminates the unnecessary syntactic friction often found in systems engineering. By prioritizing a clean, scannable, and intuitive architecture, it lowers the cognitive barrier to entry, fostering an accessible and inclusive environment for building high-performance software.

• English: Fully supported and ready for use.
• Persian (فارسی): Fully supported and ready for use.
• Arabic (العربية): Currently under development. We need contributions from native Arabic speakers to complete support.

• 🌍 Localized for Persian and Arabic Speakers: Write and read code in your native language.
• 🧑‍🎓 Beginner-Friendly: Salam makes programming approachable for everyone, including students and new developers.
• 💻 Powerful Tools: Easy to use, but with robust capabilities for all your coding needs.

• ✏️ Intuitive scripting and code compilation.
• 🚀 Docker support for seamless development.
• 🔧 Linting and code checks for best practices.
• 🔄 Built-in commands for versioning and updates.

Install the official Salam Language extension from the Visual Studio Code Marketplace for syntax highlighting and language support.

Salam is statically typed and compiled. The general language transpiles to C and is built to a native executable; embedded layout: blocks compile to HTML/CSS/JS.

Requires a C compiler. tcc is the default backend (bundled math, fast); gcc/clang also work.

The compiler lives in compiler/ (a self-contained subproject: src/, std/, tests/, tools/, Makefile, CMakeLists.txt). Build it from there:

cd compiler
sh tools/bash/build-compiler.sh   # quick build with tcc  ->  ./salam
# or, with CMake (out-of-tree build, then run the test suite via ctest):
cmake -B build && cmake --build build && ctest --test-dir build
# or just: make            # (release build via the Makefile -> ../salam at the repo root)

There is no separate runtime library: salam build emits the small C runtime (print/strcat/pow/alloc and optional bounds checks) inline into the generated C, so compiled programs are self-contained and link only -lm (-lmsvcrt with tcc).

# general language -> native executable
salam build app.salam --output=app.exe         # then ./app.exe
salam cli build app.salam --keep-c             # optional 'cli' prefix; keep generated C
salam obj app.salam                            # compile to .o only

# layout DSL -> website
salam layout build page.salam                  # page.html + page.css + page.js
salam layout build page.salam --inline         # one self-contained page.html
salam layout build a.salam b.salam             # per-page html + merged style.css/script.js

# inspect any stage (general or layout)
salam app.salam --emit-tokens-xml | --emit-ast-xml | --emit-symbol-xml
salam app.salam --log-level=trace
salam build app.salam -DDEBUG                  # preprocessor define

# format source in place (auto-detects nothing - pass --lang=fa for Persian files)
salam fmt app.salam                            # reformat one file
salam fmt                                      # reformat every .salam under the cwd, recursively
salam fmt compiler/src/ examples/              # reformat given files and/or directories
salam fmt --check                              # report files that need formatting (exit 1 if any)
salam fmt app.salam --tabs                     # indent with tabs (convert spaces to tabs)
salam fmt compiler/src/ --indent=2             # indent with 2 spaces per level
salam fmt page.salam --lang=fa                 # Persian source

# REPLs
salam cli       # general
salam layout    # layout

Hello, World:

func main {
    println("Hello, World!")
}

The compiler ships a multi-stage Dockerfile and a docker-compose.yml built on Alpine Linux (musl, the lightest practical base). The build context is the compiler root (compiler/). The image includes everything the compiler needs: a C compiler (gcc + tcc), the LLVM 22 backend (clang-22, llc-22, opt-22, lli-22), and make, no CMake required.

The compose file lives in compiler/docker/; pass it with -f so you can run from the repository root. There are two modes:

The compiler tree is bind-mounted and ./salam is recompiled automatically on every change to src/ (powered by entr, see tools/bash/docker-dev.sh):

docker compose -f compiler/docker/docker-compose.yml up dev   # build, then watch & rebuild

Edit any file under compiler/src/ on your host and the container rebuilds ./salam incrementally. To get a shell inside the same environment:

docker compose -f compiler/docker/docker-compose.yml run --rm dev sh

The production stage runs COPY . then make && make install, baking a fully built, self-contained compiler into the image. salam is the entrypoint, and the repository root is mounted at /work so shared examples/ are reachable:

docker compose -f compiler/docker/docker-compose.yml build prod
docker compose -f compiler/docker/docker-compose.yml run --rm prod build examples/en/basics/hello.salam --output=hello
docker compose -f compiler/docker/docker-compose.yml run --rm prod layout build page.salam --inline
docker compose -f compiler/docker/docker-compose.yml run --rm prod --help

Build with compiler/ as the context (so the Dockerfile's COPY . picks up the compiler tree):

docker build --target prod -f compiler/docker/Dockerfile -t salam:prod compiler   # production image
docker run --rm -v "$PWD":/work salam:prod build app.salam --output=app

docker build --target dev  -f compiler/docker/Dockerfile -t salam:dev  compiler   # dev image
docker run --rm -it -v "$PWD/compiler":/app salam:dev                             # live-rebuild loop

The LLVM and Alpine versions are configurable build args (--build-arg LLVM_VERSION=22, --build-arg ALPINE_VERSION=edge). LLVM 22 currently lives in Alpine's edge repositories, which is why edge is the default base.

We welcome contributions from the community!

• 📖 Read our Contributing Guide.
• 🌟 Follow our Code of Conduct.

Together, let’s make coding accessible to all.

Everyone is welcome — and encouraged — to participate in code reviews. You do not need to be a core maintainer to review a pull request. In fact, reviewing PRs is one of the most impactful ways to contribute to Salam, and we want to make it as approachable as possible.

💡 Code review is harder than writing code. Reading someone else's work, understanding their intent, spotting edge cases, and communicating feedback kindly and clearly takes real skill. If you are doing it, thank you — it matters enormously.

Open any pull request, then click the Files changed tab to see a diff of every file that was modified.

1. Hover over any line number in the diff — a blue + button appears.
2. Click it to open a comment box for that specific line or block.
3. Write your thought, then click Start a review (not "Add single comment") so all your notes are batched together.

Inside an inline comment you can propose an exact replacement using a fenced suggestion block:

```suggestion
your replacement code here
```

The author can accept your suggestion with a single click — no manual editing required.

When you have finished reading all the files:

1. Click the green Review changes button (top right of the diff).
2. Write an overall summary comment.
3. Choose one of three outcomes:
   • 💬 Comment — share thoughts without formally approving or blocking. Great for questions, first-timer feedback, or discussion starters.
   • ✅ Approve — you are satisfied with the changes. This is the green tick that moves a PR toward merging. Only approve if you have read the changes carefully.
   • 🚫 Request changes — something needs to be fixed before the PR can merge. Be specific and constructive.
4. Click Submit review.

• A simple comment is perfectly fine. If you are new to reviewing, just leaving a thoughtful question or noting something you learned is genuinely valuable. You don't have to approve or block.
• Be kind and specific. Point to the exact line, explain why something may be a concern, and suggest an alternative when you can.
• Assume good intent. The author put effort into this. Phrase feedback as questions ("Could this be…?") rather than commands ("Change this to…").
• First-timer PRs deserve extra warmth. If a contributor's bio or commit history shows they are new, a short encouraging note goes a long way.
• Approve when you mean it. The green checkmark signals trust. Reserve it for changes you have genuinely read and feel confident about.

Consistent reviewers and contributors are noticed. Active participation in reviews, issues, and discussions is how community members become trusted collaborators. Over time, standout contributors may be invited to join the Salam core team and take on additional responsibilities:

• 🏷️ Triage role — help label, categorise, and prioritise incoming issues and pull requests.
• 🛡️ Discord / Telegram moderator — help keep real-time channels welcoming and on-topic.
• 🔑 Maintainer access — merge PRs, manage releases, and help shape the roadmap.

The Salam core team lives in our real-time channels. Join us to ask questions, share ideas, discuss reviews in progress, or just say hello:

These spaces are open to everyone — from curious newcomers to experienced systems programmers. The more voices the better.

© 2024-2026 Salam Language Team