That last part is the whole problem. go test -race finds the race your test happened to schedule, on the interleaving it happened to get, on the machine it happened to run on. It is a sampling instrument pointed at a nondeterministic process. The races it misses are not exotic ones — they are the ordinary ones that needed a slightly different timing to show up, which is also a fair description of the races that reach production.

Seven releases have landed since the last of these posts, 0.63 through 0.72.2. The one that changes how the language feels is this: a value that isn't safe to share across goroutines is now a compile error. Not a warning, not a lint, not a runtime sampler. A build failure, with a caret pointing at the capture.

The rule

A data race needs two goroutines touching the same memory with at least one writing. The cleanest way to make that impossible is to guarantee the value is deeply immutable: if nobody can ever mutate it, any number of goroutines can read it concurrently with no synchronisation and no race.

So GALA's rule for crossing a goroutine boundary is exactly one sentence:

Only deeply-immutable values may cross.

The interesting question is not whether that rule is sound — it obviously is — but whether a language can adopt it without making concurrent code miserable to write. In most languages this rule would be intolerable, because most values in most programs are mutable.

GALA can afford it because the language already pushed everything the other way: val over var, collection_immutable over collection_mutable, Option/Try/Either over nil and naked error pairs, immutable struct fields by default. Most values a well-written GALA program shares are already shareable. The check is therefore silent in the common case. It only speaks up when you try to send something genuinely mutable.

That's the design bet: the safety check is cheap because the language spent three years making immutability the path of least resistance.

What it looks like when it fires

A concurrency boundary is a parameter typed Sendable[F]. concurrent.Future uses one; so does FutureOn; so can your own library. Here is a boundary and a closure that captures a var:

package main

func run(body Sendable[func() int]) int = body()

func main() {
    var counter = 0
    Println(run(() => counter + 1))
}

That program does not compile:

error[GALA-E0037]: closure crossing a concurrency boundary captures reassignable var "counter" — a data race, because the enclosing scope may reassign it while the goroutine runs
  --> var_capture.gala:7:23
  |
7 |     Println(run(() => counter + 1))
  |                       ^^^^^^^ snapshot it into an immutable `val` before the boundary
  |
  = hint: snapshot it into an immutable `val` before the boundary (e.g. `val counter = counter` outside the closure) so the goroutine captures a stable copy

The closure never ran. No scheduler had to cooperate. There is no flaky-test phase where this reproduces on CI one time in forty.

Four shapes trigger GALA-E0037: capturing a reassignable var; using a val whole when its type isn't deeply immutable (a collection_mutable value, a struct with a var field, a Go-interop handle, a bare slice/map/pointer); reading a field path that passes through a var field; and capturing a bare func value, whose type says nothing about what it closed over.

That last one matters more than it looks. A func() int parameter is an opaque promise — you cannot see its captures, so you cannot vouch for them. Typing the parameter Sendable[func() int] is how the guarantee propagates: the caller vouches, and the callee may forward it into a further boundary.

What counts as shareable

The predicate is deep, transitive, and structural. It looks through wrappers, collections, tuples, struct fields, and sealed variants until it hits a primitive or something it must reject.

Shareable: the value primitives; string; every collection_immutable structure (Array, List, HashMap, HashSet, TreeMap, TreeSet) when their type arguments are; Option/Try/Either and tuples when theirs are; immutable structs and sealed types all the way down.

Not shareable: anything from collection_mutable, structs with a var field, raw Go slices, maps and pointers, and opaque Go-interop references.

Which means this compiles, and every capture in it is checked:

val xs = ArrayOf(10, 20, 30)
val f = Future(xs.Size())
Println(f.Get())

Future(expr) is by-name thunk sugar — it desugars to Future(() => expr), so expr is the async closure, and its captures get the same treatment as an explicit lambda.

Field sensitivity, and the limit that's actually left

A whole-value check would be annoying enough to route around. If sharing a struct required the struct to be immutable in its entirety, every Future would open with a stanza of snapshot locals.

So the check is field-access-sensitive. It records how the closure uses each capture, and a capture read only through immutable field paths is accepted even when the struct as a whole is not shareable:

struct AppModel(team string, statuses Array[int], var attempts int)

val model = AppModel("qa", ArrayOf(1, 2, 3), 0)

// ACCEPTED — reads only the immutable `team` / `statuses` fields, even though
// AppModel is unshareable as a whole (it has a `var attempts` field).
Future(() => project(model.team, model.statuses))

// REJECTED — reads through the `var` field.
Future(() => model.attempts + 1)

Calling a method on a field you just read works too. The receiver's own type decides, so the common shapes real code writes are accepted:

// ACCEPTED — `team` is a `string`, unconditionally shareable.
Future(() => model.team.Size())

// REJECTED — the receiver field's own type is mutable.
Future(() => model.buf.Size())    // buf: collection_mutable.Array[int]

That last part is newer than the rest of this post. When I first wrote it up, model.team.Size() was rejected — a method call ended the field-path run and collapsed the whole capture, so a string that could never race got refused. It was sound but wrong-feeling, and it landed on a shape you write constantly (model.name.Size(), model.items.Map(...)). It's fixed in 0.72.1: a trailing method call on a field path defers to the leaf's shareability. Indexing and chained calls stay conservative and still mark the capture whole.

Which is roughly what you want from a check this young — the sound-but-annoying direction is the recoverable one, and it got recovered in a point release.

One more scope limit worth stating plainly: this is not a general race detector. It guards declared Sendable[F] boundaries. Reach around them — hand a pointer to hand-written Go, share state through a Go library — and you are back to go test -race, exactly as before. It makes the safe path checkable, it does not make the unsafe path impossible.

The rest of the month

Structured concurrency and cancellation. Future gained real cancellation with scope semantics: linear combinators inherit their parent's token, so a derived stage shares its scope, while a fresh root opens a new one. Cancellation is API-level — there's no body-token escape hatch to misuse.

Stack traces name your .gala lines. A panic now reports GALA source positions, not positions in generated Go:

panic: runtime error: integer divide by zero
main.divide(...)
	foo.gala:4
main.main()
	foo.gala:8

This rides Go's own //line mechanism — the transpiler stamps each statement with its originating GALA line, which the Go compiler and runtime already honor. No source-map file, no runtime cost. Imported GALA packages map too, so a single trace can span library and application source with each frame pointing at real .gala code. It's approximate inside constructs that lower to several Go statements or to an IIFE (match, if-expressions, bind/also) — right file, line possibly off by a few.

Diagnostics got a frame. Errors now render Rust/Elm style, with a source excerpt, a caret span, an inline label, and a hint:

error[GALA-E0035]: bare Go builtin "len(...)" is not part of GALA's surface
  --> bare_len.gala:4:13
  |
4 |     val n = len(s)
  |             ^^^ use `.Size()`
  |
  = hint: use `.Size()` (logical size — characters for strings) or `.ByteSize()` (raw bytes) instead of `len(...)`

Guaranteed tail-call optimisation. A self-tail-recursive function with an if-expression body compiles to a loop, so deep recursion runs in constant stack space. This:

func factorial(n int, acc int) int = if (n <= 0) acc else factorial(n - 1, n * acc)

becomes exactly this Go:

func factorial(n int, acc int) int {
	for {
		if n <= 0 {
			return acc
		} else {
			_tmp_1 := n - 1
			_tmp_2 := n * acc
			n, acc = _tmp_1, _tmp_2
			continue
		}
	}
}

Note the temporaries: both arguments are evaluated against the old parameter values before either is reassigned, which is what makes factorial(n-1, n*acc) mean what it says. The scope is deliberately narrow — plain functions (no receiver), expression bodies, genuine self-tail-calls. Non-tail recursion like n * factorial(n-1) is left alone rather than silently mis-transformed.

use, and closing the escape hatches. Scoped resource binding arrived, and bare defer, bare go, and bare Go builtins were removed from GALA's surface — routed through use, the concurrent package, and go_interop / go_builtins respectively. Which is the same instinct as E0037: if the language offers a checked path, the unchecked one shouldn't be the one that's easier to type.

A subprocess package, with a goroutine-safe Process handle — async line reads, async stdin writes, kill-after-timeout, all returning Futures.

Where this leaves things

The pitch for GALA has been "the type system Go is missing." Sum types, exhaustive matching, Option instead of nil — a compiler that rejects the programs you didn't mean to write.

Concurrency safety is that same pitch aimed at the bug class Go developers actually lose days to. Go's answer to data races is a runtime tool you remember to run. GALA's answer is that the program doesn't build. Not because GALA is cleverer, but because it spent its immutability budget early and can now cash it in for something a mutable-by-default language can't buy at any price.

The check is young, and it guards declared boundaries rather than every goroutine — reach around it and you are back to go test -race. Within those boundaries it is still a different category of guarantee than sampling a schedule and hoping.

gala.fyi has the reference for concurrency safety and the full GALA-E0037 writeup, or you can try the language without installing anything in the playground.

In May, GALA hit 0.50.0 with sealed types, exhaustive pattern matching, a real monad stack (Option, Either, Try, Future, IO), and a functional standard library — all transpiling to plain Go. The one thing that stack was still missing was a decent way to write against it.

You had Map and FlatMap, which are great for a single linear pipeline and get ugly the moment a step needs a value from two steps back. Every intermediate value is trapped inside a closure, so the "graph" shape — where a later step reads an earlier one — pushes you into a staircase of nested FlatMap calls.

The headline of the June work (0.56 → 0.62) fixes exactly that. GALA now has bind / also — monadic do-notation, the piece that makes "Scala on Go" actually feel like writing Scala. Here's what shipped.

bind: the flat version of a FlatMap chain

Take a small order pipeline. Fetch an order, validate it, charge it, build a receipt — where the receipt needs both the original order and the payment. With combinators, that last cross-reference forces nesting:

fetchOrder(id).FlatMap((o) =>
    validateOrder(o).FlatMap((valid) =>
        chargePayment(valid).FlatMap((payment) =>
            Success(Receipt(o.Id, payment)))))   // `o` survives only via nesting

With bind, every binding is a normal immutable local that stays in scope for the rest of the block:

func processOrder(id int) Try[Receipt] {
    bind o       = fetchOrder(id)
    bind valid   = validateOrder(o)
    bind payment = chargePayment(valid)
    Success(Receipt(o.Id, payment))    // `o` still in scope — no nesting
}

bind name = expr unwraps the monad, binds the success value, and short-circuits the whole block on the first Failure — so processOrder(0) stops at the first bind and returns that Failure unchanged. This isn't Rust's ? or Zig's try: it's not a hidden return that hijacks the enclosing function. The block is an ordinary expression of type Try[Receipt] — you can name it, return it, or pass it around. It just desugars, mechanically, to the nested FlatMap chain above.

If you've written a Scala for-comprehension or a Haskell do block, this is the same idea with a keyword that tells you it can short-circuit, instead of a <- you have to learn to read.

also: independent binds, and why the keyword earns its keep

Not every step depends on the one before it. Validating a name, an email, and an age are three independent checks. Sequencing them with bind is a lie about the data flow — and it throws away everything except the first error.

also marks a bind as independent of its group:

func sum2(x string, y string) Option[int] {
    bind a = lookup(x)
    also b = lookup(y)      // independent of `a`
    Some(a + b)
}

A leading bind plus one or more also clauses form a product group. The clauses may not reference each other — and that non-dependence is exactly what licenses the compiler to do something smarter than sequencing. What "smarter" means is decided by the type:

One keyword, three behaviors, no annotations — the block's type picks the semantics.

Validated: collect all the errors, not just the first

Fail-fast is wrong for form validation. If a user submits a blank name, a blank email, and a negative age, you want to tell them all three things at once, not make them fix them one round-trip at a time. That's what the new Validated[E, A] type is for — it's a distinct sealed type (Valid / Invalid), kept deliberately separate from Either's fail-fast semantics.

import . "martianoff/gala/validation"

func vName(s string)  Validated[string, string] = if (s != "") Valid(s) else InvalidOf("name required")
func vEmail(s string) Validated[string, string] = if (s != "") Valid(s) else InvalidOf("email required")
func vAge(n int)      Validated[string, int]    = if (n >= 0)  Valid(n) else InvalidOf("age negative")

func makePerson(name string, email string, age int) Validated[string, Person] {
    bind n = vName(name)
    also e = vEmail(email)
    also a = vAge(age)
    Valid(Person(n, e, a))
}

Because the clauses are also (independent), the group lowers to Validated.Zip3(...).FlatMap(...), and Validated's Zip pre-collects every clause's errors before combining. So makePerson("", "", -1) doesn't stop at the blank name — it reports all three:

val bad = makePerson("", "", -1)
Println(s"errors: ${bad.GetErrors().Size()}")   // 3

Note there isn't a single explicit type argument in that code. Valid / Invalid fix their phantom type parameter from the declared return type, and InvalidOf infers its instantiation from context — implicit typing all the way down, the way GALA code is supposed to read.

also over Future: structured concurrency for free

The same also over Future runs the clauses concurrently:

import . "martianoff/gala/concurrent"

func total() Future[int] {
    bind a = compute(2)
    also b = compute(3)    // these three
    also c = compute(4)    // run in parallel
    Future[int](a + b + c)
}

The group lowers to Future.Zip3(...), which starts every future and joins them — so the block waits on all three in parallel instead of threading each through the next. Concurrency is visible in the source: sequential binds stay sequential, only an also group runs in parallel. The transpiler never auto-parallelizes consecutive binds behind your back.

(While we were in Future, the async constructor got simpler too: Future(...) is now the way to start an async computation, and the old FutureApply spelling is gone.)

The part I'm proud of: it works over your monads

Here's the design constraint that made this interesting. GALA's standing rule is that the standard library gets no special treatment — Try, Option, Either, Future have to resolve through the same mechanism a third-party type would. And Go's generics can't express a higher-kinded Bindable[F[_]] interface, so GALA doesn't fake one.

Instead, bind/also are resolved structurally, at transpile time, on the block's concrete type — before Go ever sees the code. A type becomes bindable by providing exactly one method:

func (m M[T]) FlatMap[U any](f func(T) M[U]) M[U]

That's the whole contract. Here's a user-defined Step monad with no relationship to the standard library, and bind works over it identically to Try:

sealed type Step[T any] {
    case Go(Value T)
    case Stop(Reason string)
}

func (s Step[T]) FlatMap[U any](f func(T) Step[U]) Step[U] = s match {
    case Go(v)   => f(v)
    case Stop(r) => Stop[U](r)
}

func pipeline(n int) Step[int] {
    bind a = start(n)
    bind b = twice(a)
    Go(a + b)          // `a` still in scope; a `Stop` anywhere short-circuits
}

The short-circuit behavior lives entirely inside the author's FlatMap — the desugaring never inspects, and never hardcodes, which variant is the "zero." Supply a Pure/constructor and you also get auto-lift of trailing plain values and sequential also; supply a custom Zip and you get concurrency or error accumulation. A brand-new user monad gets bind and sequential also for free. This is the OCaml let* / and* model, resolved structurally instead of lexically. There is no built-in list of "blessed" monads.

The rest of June

Beyond bind/also, 0.56 → 0.62 was mostly the unglamorous work that a compiler needs to actually be trusted:

• Zip up to Zip10 on the product types, so also groups can be wide.
• By-name thunk sugar for zero-argument function parameters — pass an expression where a func() is expected and it's wrapped for you.
• Race-free concurrent parsing. Multi-file packages now parse in parallel with a per-parse prediction cache, so the parser is safe under concurrency.
• A stack of type-inference fixes: inferring a generic method's result type from a lambda's return under type-parameter name collisions; inferring "phantom" return-only type parameters from the expected type; inferring lambda parameter types in typed contexts (and rejecting truly-untyped ones instead of silently widening to any); statement-position match dispatch with a guarded wildcard before the default.
• A standard-library cleanup pass applying GALA's own best practices across std.

Every one of those inference fixes shipped with a permanent example test, per the project rule that a transpiler bug becomes a repro before it becomes a fix.

What's still rough

Same honest list as always:

• Package registry. Dependencies resolve — Go and GALA, including third-party Go modules — but there's still no first-class public registry for publishing and discovering GALA libraries. It remains the top open roadmap item.
• bind ergonomics at the edges. Heterogeneous binds (binding an Option inside a Try block, say) need a resolvable Lift, and lifting a "zero" type into an error type makes you supply the error explicitly. That's by design — no silent coercions — but it's a sharp edge you'll meet.
• Maturity. GALA is six months old. It generates readable Go and runs real software — a TUI framework, a multi-agent orchestrator, this project's own tooling — but it hasn't been load-bearing in a large team's production system for a year. Use it with eyes open.

Try it

bind/also is the feature I most wanted GALA to have, because it's the one that turns a pile of good combinators into something that reads like the functional languages it's borrowing from. If you've missed for-comprehensions or do-notation in Go, this is the part to try first.

Try it in your browser — no install — or grab a binary from Releases and gala run main.gala.

I wanted to know if GALA passes that test today, so I did the honest thing: started in an empty directory with nothing but the gala CLI, Go, and Bazel on my PATH, and tried to build a program that imports a Go module through Bazel and rules_gala. No copying an example repo, no insider shortcuts. This post is the actual transcript, friction and all.

The short version: it works, the types come out concrete, and the whole thing is about four small files you write by hand plus two generated ones. There's exactly one wiring detail the main docs get wrong, and I'll show you the version that actually works.

The goal

A program that imports github.com/google/uuid — a real third-party Go module, not stdlib — generates a UUID, and prints it. Built and run entirely through Bazel with rules_gala. The interesting part isn't the UUID; it's whether GALA can read a third-party Go package's types well enough to produce concrete, compiling Go.

Versions used: gala 0.53.1, Go 1.25.5, Bazel 8.

Step 1 — Initialize the module and add the Go dependency

gala mod init example.com/hellouuid
gala mod add github.com/google/uuid@v1.6.0 --go

Initialized gala.mod for module example.com/hellouuid
Fetching github.com/google/uuid@v1.6.0...
Added github.com/google/uuid@v1.6.0 (Go dependency)

The --go flag is the whole story of GALA's dependency model: it marks a requirement as a Go package — fetched and linked, never transpiled — as opposed to a GALA library, which is fetched as .gala source and transpiled at build time. The resulting gala.mod is deliberately Go-mod-shaped:

module example.com/hellouuid

gala 0.53.1

require github.com/google/uuid v1.6.0 // go

No go.mod in your project yet, and that's intentional — GALA projects are driven by gala.mod.

Step 2 — Write the program

package main

import "github.com/google/uuid"

func main() {
    val id = uuid.New()
    Println(s"Fresh UUID: ${id.String()}")
}

That's the entire program. uuid.New() is a Go function returning a uuid.UUID; id.String() is a method on that Go type. Println and the s"..." interpolation are GALA built-ins — no fmt import needed. The question is whether the transpiler knows what uuid.New() returns. Hold that thought.

Step 3 — The Bazel wiring

Four files. The .bazelrc selects the rules_gala registry and passes the Go SDK through to the transpiler:

common --enable_bzlmod
common --noenable_workspace
build  --enable_runfiles

common --registry=https://raw.githubusercontent.com/martianoff/rules-gala/main/
common --registry=https://bcr.bazel.build

build  --action_env=GOROOT
build  --action_env=PATH

MODULE.bazel is normal bzlmod — the GALA toolchain, Go rules, and the Gazelle extension:

module(name = "hellouuid", version = "0.0.1")

bazel_dep(name = "rules_gala", version = "0.1.3")
bazel_dep(name = "gala", version = "0.53.1")
register_toolchains("@gala//tools/toolchain:gala_toolchain")

bazel_dep(name = "rules_go", version = "0.50.1")
bazel_dep(name = "gazelle", version = "0.39.1")
bazel_dep(name = "gala_gazelle", version = "0.2.5", dev_dependency = True)

go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(go_deps, "com_github_google_uuid")

And the root BUILD.bazel — this is the one line that matters:

load("@gala_gazelle//gala:defs.bzl", "gala_gazelle")

gala_gazelle(name = "gazelle")

The one gotcha. If you reach for the plain gazelle(name = "gazelle") rule from @gazelle//:def.bzl — the one you'd use in a pure-Go project — Gazelle only knows the Go language. It greets you with unknown directive: gazelle:gala_prefix and generates zero GALA targets. The fix is the gala_gazelle macro above: it builds a composite Gazelle binary that embeds both the Go language and the GALA language, plus a toolchain-driven import helper. Use it and BUILD generation covers Go, GALA, and mixed packages in one pass.

Step 4 — Generate, build, run

gala mod tidy notices the project is now a Bazel project (because MODULE.bazel exists) and emits a portable go.mod/go.sum carrying just the Go dependencies:

gala mod tidy

Then Gazelle writes the build target for you:

bazel run //:gazelle

It appends a gala_binary to BUILD.bazel, with the Go dependency already resolved to its Bazel label — I didn't type this:

gala_binary(
    name = "hellouuid",
    srcs = ["main.gala"],
    deps = ["@com_github_google_uuid//:uuid"],
)

Build and run:

bazel build //...
bazel run //:hellouuid

A real UUID, from a real Go module, through the full Bazel pipeline.

The part that actually matters: the types are concrete

Anyone can make interface{} compile. The test of "Go interop" is whether the transpiler understood the third-party type. Here's the Go that GALA generated for main.gala:

// Code generated by GALA transpiler. DO NOT EDIT.
package main

import "fmt"
import "martianoff/gala/std"
import "github.com/google/uuid"

func main() {
    var id = std.NewImmutable(uuid.New())
    fmt.Println(fmt.Sprintf("Fresh UUID: %v", id.Get().String()))
}

uuid.New() is called directly and its concrete uuid.UUID result flows into id.Get().String(). There is no any, no type assertion, no reflection. If the transpiler had failed to resolve uuid.New()'s return type, id would have been any and .String() would not compile — the build would have failed, not silently degraded. It compiled, so the type resolution is real.

This is the capability that landed recently: GALA reads the Go SDK at transpile time to resolve function signatures, struct fields, and method sets from third-party modules — not just stdlib. That's why the .bazelrc passes GOROOT and PATH into the build actions. It's also why (T, error) returns from Go functions get auto-wrapped into Try[T] at the call site: the transpiler can see the shape of what it's calling.

Was it genuinely simple? An honest scorecard

Yes — with one caveat I won't paper over.

What you write by hand: main.gala (6 lines), .bazelrc (~8 lines), MODULE.bazel (~18 lines), BUILD.bazel (3 lines + a directive). What's generated for you: go.mod/go.sum (by gala mod tidy) and the gala_binary target (by Gazelle). The dependency label resolution — the part that's tedious and error-prone in hand-written Bazel — is automatic.

The friction, named honestly:

• The Gazelle wiring. The working recipe is the gala_gazelle macro from @gala_gazelle//gala:defs.bzl, documented in rules-gala's gazelle/README.md. If you follow only the main repo's dependency-management doc, which shows the plain Go gazelle rule, you'll hit unknown directive: gazelle:gala_prefix and produce no GALA targets. This is the single thing most likely to trip up a newcomer. (It's a doc gap, not a tooling gap — once you use the macro, it just works.)
• Order of operations. gala mod tidy only generates go.mod once MODULE.bazel is present — it detects "Bazel project" by that file. Run the Bazel scaffolding first, then tidy.
• Cold build cost. The first bazel run //:gazelle builds the GALA toolchain and the Go SDK from the registry — about a minute and a half on a cold cache here. Every build after that is single-digit seconds. This is ordinary Bazel behavior, not a GALA quirk.
• Bazel-first. This is the Bazel path. For a quick single binary you can skip all of it and use gala build / gala run directly; the Bazel story is for projects that want reproducible, registry-pinned, polyglot builds.

None of these are blockers. The worst case costs you one web search to find the right Gazelle macro. After that, adding another Go dependency is two commands — gala mod add … --go then bazel run //:gazelle — and the BUILD file updates itself.

Why this is a bigger deal than a UUID

The reason "import a Go module" is the make-or-break test is that it's the entire value proposition of a transpile-to-Go language. If GALA's interop were shallow — stdlib only, or types collapsing to any at the boundary — then every time you reached for the Go ecosystem you'd fall out of the type system that made you choose GALA in the first place. You'd be writing Go with extra steps.

That's not what happened here. A third-party module dropped in, kept its types, and built through a production-grade Bazel toolchain with generated BUILD files. The recent work — third-party Go type inference, the extraction of rules_gala into its own registry-published module, and first-class Gazelle support — adds up to a build story where the polyglot seam is close to invisible. You get sealed types, exhaustive pattern matching, and Option/Try/Either on the GALA side, and the entire Go module ecosystem on the other, with concrete types across the boundary.

Try it before you commit to anything: the GALA Playground runs in the browser with no install. When you're ready for a real project, the steps above are the whole recipe — and rules_gala plus Gazelle make sure the build is the part you stop thinking about.

The last few releases have been about fixing that. GALA 0.51.0 extracted the Bazel rules into a standalone, registry-published module — rules_gala — sitting behind a proper Bazel toolchain. GALA 0.52.0 added first-class Gazelle support, so the BUILD files that wire everything together are now generated instead of hand-authored. This post is about that direction: turning GALA's build tooling from "works on the maintainer's machine" into something production-grade and reusable across modules.

The problem: rules welded to the language

When the build rules ship inside the language repo, every consumer loads them straight from it:

load("@gala//:gala.bzl", "gala_library", "gala_binary", "gala_go_test")

This looks harmless, and it works. But it quietly couples three things that should be independent:

1. Your project's build logic depends on the internal layout of the language repo. The @gala//:gala.bzl path is an implementation detail, not a stable API. If the compiler repo reorganizes, your BUILD files break.
2. The rules hardcode where the tools live. The transpiler binary, the stdlib filegroup, the test runner — every rule reached for them with a fixed Label("//...") pointing back into the language repo. There was exactly one way to assemble a GALA build, and it was the language repo's way.
3. Versioning is muddled. "Which version of the rules am I on?" and "which version of the compiler am I on?" were the same question. You couldn't upgrade your build logic without upgrading the transpiler, or vice versa.

None of this matters when the only consumer of the rules is the language repo itself. It matters a lot the moment you have several GALA projects — a server library, a TUI framework, an application — that each want to pin versions and evolve independently. The rules needed to become a real, separately versioned dependency.

rules_gala: a registry-published Bazel module

GALA 0.51.0 split the build stack cleanly in two.

The language repo keeps what only it can provide: the transpiler binaries, the standard library, the test framework, and a small set of toolchain bindings.

Everything else — the rule definitions, the bzlmod extension, the repository rules, the library/binary/test macros — moved into rules_gala, which is published through its own Bazel module registry.

Consuming it is two lines in .bazelrc to select the registry (order matters — the custom registry must come first so it wins for rules_gala):

common --registry=https://raw.githubusercontent.com/martianoff/rules-gala/main/
common --registry=https://bcr.bazel.build

and a normal bazel_dep in MODULE.bazel:

bazel_dep(name = "rules_gala", version = "0.1.1")
bazel_dep(name = "gala", version = "0.51.0")

register_toolchains(
    "@gala//tools/toolchain:gala_toolchain",
    "@gala//tools/toolchain:gala_bootstrap_toolchain",
)

The load path now points at the rules module, not the language internals:

load("@rules_gala//gala:defs.bzl", "gala_library", "gala_binary", "gala_test")

gala_library(
    name = "mylib",
    srcs = ["mylib.gala"],
    importpath = "example.com/mylib",
    visibility = ["//visibility:public"],
)

gala_test(
    name = "mylib_test",
    srcs = ["mylib_test.gala"],
    deps = [":mylib"],
)

This is a breaking change — load paths and macro names both moved — but it's the kind of break that buys you a stable surface afterward. The rule set that rules_gala exposes is small and deliberately boring:

While extracting the rules, the test surface also got a naming cleanup that had been overdue. The canonical "discover and run TestXxx functions" rule is now simply gala_test; the stdout-diffing rule became gala_exec_test:

- gala_go_test   # discovers TestXxx functions
+ gala_test

- gala_test      # diffs stdout against an expected file
+ gala_exec_test

There are no compatibility aliases. That's a deliberate beta-era choice: rename every call site once, at upgrade time, rather than carry two names for the same thing forever.

The piece that makes it reusable: a toolchain

Moving files around doesn't make rules reusable on its own. The real change in 0.51.0 is how the rules find their tools.

Instead of hardcoding Label("//cmd/gala:gala") and friends, every rule in @rules_gala//gala:defs.bzl resolves its tools through a Bazel toolchain — @rules_gala//gala:toolchain_type. The language repo registers an implementation of that toolchain backed by its in-repo binaries, stdlib, and test framework. But because the rules only know about the toolchain type, anyone can supply their own implementation:

load("@rules_gala//gala:toolchain.bzl", "gala_toolchain")

gala_toolchain(
    name = "my_gala_toolchain_impl",
    gala_binary      = "//path/to:gala",
    gala_worker      = "//path/to:gala_worker",
    gala_bootstrap   = "//path/to:gala_bootstrap",
    test_runner      = "//path/to:gala_test_runner",
    test_gen         = "//path/to:gala_test_gen",
    all_gala_sources = "//:all_gala_sources",
    go_mod           = "//:go.mod",
)

toolchain(
    name = "my_gala_toolchain",
    toolchain = ":my_gala_toolchain_impl",
    toolchain_type = "@rules_gala//gala:toolchain_type",
)

This is the standard Bazel toolchain pattern — the same idea behind rules_go's Go SDK toolchain. The rules describe what to do with a GALA source file; the toolchain provides which binaries do it. You could build against a locally-built transpiler, a pinned release, or a patched fork without touching a single BUILD file.

There's one subtlety worth calling out, because it's the kind of thing that bites you in a transpiled language. The stdlib itself is written in GALA and has to be transpiled — but the main toolchain's worker embeds the stdlib. If stdlib targets depended on the main toolchain, you'd have a cycle: stdlib → toolchain → worker → embeds stdlib. So gala_bootstrap_transpile resolves through a separate bootstrap_toolchain_type carrying only the bootstrap binary, which has no stdlib dependency. The split is what lets the language build its own standard library hermetically. It's a small detail, but it's exactly the kind of thing that has to be right for the build to be reproducible from a cold cache.

Gazelle: stop hand-writing BUILD files

A clean rule set still leaves you writing BUILD.bazel by hand — listing sources, and worse, manually tracking the deps between GALA packages as imports change. For a Go project you'd never accept that; Gazelle generates and maintains those files for you. GALA 0.52.0 brought the same thing to GALA.

The mechanism is a small one, and it leans on something the compiler now exposes directly. GALA 0.52.0 added a parse-only subcommand:

gala imports --json path/to/file.gala

This walks the ANTLR parse tree and emits the package and its imports as JSON — no transpilation, no Go SDK required. It's deliberately cheap, because it runs once per file during BUILD generation. That subcommand is the helper the GALA Gazelle extension shells out to in order to resolve dependencies.

The extension ships from rules_gala as the @gala_gazelle Bazel module and is bundled together with Gazelle's Go language into a single gazelle_binary. The payoff is that one command maintains everything:

bazel run //:gazelle

That single pass generates and updates BUILD files for Go packages, GALA packages, and mixed GALA+Go packages together. You steer it with # gazelle: directives — most importantly gala_prefix, which sets your module's import prefix so generated deps resolve correctly:

Two things are worth knowing before you run it:

• The helper needs a gala on PATH new enough to support gala imports --json. An older CLI fails with unknown flag: --json and silently resolves no GALA deps. If your generated deps come back empty, check the CLI version first.
• Mixed hand-written .go + .gala packages are left alone on purpose. When Gazelle detects a package that mixes the two, it backs off rather than guessing at a gala_library — those stay on manual gala_bootstrap_transpile + go_library wiring. Generating the easy 90% and refusing to corrupt the hard 10% is the right default for a tool you run on every commit.

If you also want module dependencies resolved from a manifest, the bzlmod extension reads them from gala.mod:

gala = use_extension("@rules_gala//gala:extensions.bzl", "gala")
gala.from_file(gala_mod = "//:gala.mod")

What "production-grade" actually means here

Putting the pieces together, a GALA project's build now has the same properties you'd expect from a mature Go-plus-Bazel setup:

• Reproducible. Tools are resolved through a toolchain and pinned through the module registry. A cold-cache build pulls a known rules_gala and a known gala, not whatever happens to be checked out.
• Reusable across modules. Because the rules talk to a toolchain type rather than hardcoded labels, a server library, a TUI framework, and an application can each depend on rules_gala and pin their own compiler version.
• Independently versioned. Build logic (rules_gala) and the compiler (gala) now move on separate tracks. You can upgrade one without the other.
• One command for BUILD files. bazel run //:gazelle covers Go, GALA, and mixed packages — no hand-maintained dependency lists.

None of this is glamorous. That's the point. The best build tooling is the kind you stop thinking about, and the direction here is to make GALA's build invisible the way go build is invisible.

Honest limitations

This is beta tooling, and a few rough edges are worth naming:

• Mixed GALA+Go packages are still manual. Gazelle deliberately won't touch them, so you wire those by hand. If your project is heavily intermixed, expect to write some BUILD rules yourself.
• The Gazelle helper depends on a recent CLI. The version coupling between the gala on your PATH and the --json flag is a real footgun until the ecosystem settles.
• Bazel-first. This whole story assumes Bazel. There's a gala run/gala build CLI path for small programs, but the production build experience described here is Bazel-centric. If your shop isn't on Bazel, this is not yet for you.
• The API just broke. 0.51.0 moved every load path and renamed test rules with no aliases. That's the right call for a beta, but it means upgrading is a real, if mechanical, migration.

Try it

If you're starting a new GALA project on Bazel, the setup is the .bazelrc registry lines and the MODULE.bazel bazel_deps above, then bazel run //:gazelle to generate your BUILD files. The rule reference and directive list live in the rules_gala repository, and the migration checklist for existing projects is in the GALA 0.51.0 release notes.

To see the language itself before committing to a build setup, the GALA Playground runs everything in the browser with no installation. And if you just want to read GALA code, the main repository has the full language spec and a growing set of examples.

The language work — sealed types, pattern matching, type inference — is what makes GALA worth writing. The build work is what makes it worth shipping. Getting rules_gala and Gazelle right is how GALA stops being a clever transpiler and starts being something you can put in production.

In March I wrote up where GALA stood: version 0.25.2, a couple of months old, 46 releases deep, with a rich standard library, a zero-reflection JSON codec, and async primitives. I also said GALA was "still young" and named its roughest edge by name — complex generic type inference across package boundaries — and listed four near-term priorities: stability, cross-package generics, IDE support, and a package registry.

Eleven weeks later GALA is at 0.50.0. Another ~55 releases shipped in that window, which works out to roughly one a working day — the cadence from the first two months held. More interesting than the version number is what changed underneath it. Three of the four roadmap items landed (one of them more thoroughly than I'd planned), the standard library grew four new packages, the build system got a real caching layer, and — the part I keep coming back to — the one-line pitch changed.

We stopped calling it "the Go Alternative Language"

In March, the README led with the backronym: GALA, the Go Alternative LAnguage. Accurate, but it told you what GALA isn't (plain Go) rather than what it is. The tagline now reads:

Scala on Go.

That's a sharper, more honest claim, and it's the one people actually reacted to. GALA is a statically typed, functional-first language with sealed types, exhaustive pattern matching, immutable collections, and a real monad stack — Option, Either, Try, Future, IO — that happens to compile to readable Go and keep the entire Go ecosystem working unchanged. If you've written Scala, Kotlin, F#, or OCaml and then had to go back to Go, you know exactly the gap GALA is trying to close.

sealed type Shape {
    case Circle(Radius float64)
    case Rectangle(Width float64, Height float64)
}

func area(s Shape) string = s match {
    case Circle(r)       => f"circle area: ${3.14159 * r * r}%.2f"
    case Rectangle(w, h) => f"rect area: ${w * h}%.2f"
}

The rename isn't marketing varnish over the same code. It's a bar. "Scala on Go" sets an expectation — the type system should hold up across files and packages, the standard library should feel functional end to end, the tooling should exist — and the last eleven weeks were largely about earning it.

The March roadmap, item by item

1. Stability and the type-inference regression suite — done, and then some. In March the type-inference regression suite had 14 cases. The bulk of the ~190 non-merge commits since are fixes and the regression guards that lock them in: cross-package Try chains, two-parameter HashMap.ForEachKV lambdas, tuple-literal element types driven by the call-site expected type, statement-position match lowering, sealed-case widening in tuple match arms. The pattern was consistent — every reported bug became a permanent example test before the fix shipped, per the project's own rule of never working around a transpiler bug.

2. Cross-package generics — the rough edge, largely filed down. This was the honest weak spot in March, and it got the most attention. A few of the concrete fixes:

• Downward inference now flows into generic sealed-type case constructors across package boundaries.
• Cross-package Option/Try .Map type parameters are now driven by the call-site expected type instead of being guessed locally.
• Qualified type and function lookups are anchored to the qualifier's package, so multi-segment import paths resolve to the right symbol.

Alongside the fixes, GALA gained coded diagnostics. Cross-package symbols now require an explicit import, and you get a real error code — GALA-E0025 — instead of a vague resolution failure. Naming your errors is a small thing that signals a compiler growing up.

3. IDE support — shipped, and wider than promised. March promised "a GoLand plugin for syntax highlighting and navigation." What shipped is that plus a full LSP server:

• A GoLand / IntelliJ plugin with an ANTLR-based parser, a complete PSI tree, semantic highlighting, structure view, and 12 live templates — all working locally without the language server.
• An LSP server (gala lsp) that brings VS Code and Neovim along for the ride: real-time diagnostics (including match-exhaustiveness), hover with type signatures, go-to-definition across files, find references, type-aware completion, and inlay hints sourced from the transpiler's own VarTypes. It debounces analysis by 500ms so it stays quiet while you type.

4. Package registry — still in flight. This is the one item that didn't fully land. gala mod add handles Go and GALA dependencies today, including third-party Go modules, but a first-class public registry for publishing and discovering GALA libraries is still in progress. Calling it out for the same reason I called out generics in March: the honest list is the useful one.

Four new standard-library packages

The theme across the new packages is functional error handling reaching the edges of the library — the I/O-shaped corners that usually get a pass and return naked (value, error) or panic. In GALA they return Try.

crypto — hashing (SHA-256/512, SHA-1, MD5), HMAC (SHA-256/512), Ed25519 signing, X25519 key exchange, and CSPRNG helpers. Hashes return a Digest you can render however you need:

val digest = crypto.Sha256{}.Hash(data)   // data : Array[byte]
Println(digest.Hex())
Println(digest.Base64())

Crucially, the operations that can fail — random-byte generation, for instance — return Try[Array[byte]] rather than panicking, so a failed entropy read composes like any other fallible step instead of taking down the process.

yaml — a type-safe YAML codec that shares the exact same StructMeta[T] compiler intrinsic as the JSON codec. Same zero-reflection machinery, same builder API, no struct tags:

struct Project(Name string, Repo string, Port int)

val codec = Codec[Project](SnakeCase())
val text  = codec.Encode(Project("auth", ".", 8080)).Get()
// name: auth
// repo: .
// port: 8080
val back = codec.Decode(text)   // Try[Project]

fs — file operations with Try return types throughout: ReadFile/WriteFile, their string variants, ReadLines/WriteLines/AppendString for line-oriented work, and directory operations CopyFile, Rename, Walk, and Glob.

val saved = fs.WriteFileString("notes.txt", "hello", 0o644)
    .FlatMap((_) => fs.AppendString("notes.txt", "\nworld", 0o644))
    .FlatMap((_) => fs.ReadLines("notes.txt"))   // Try[Array[string]]

path — a thin, ergonomic wrapper over path/filepath. Plus the strings package was rebuilt into an ergonomic free-function form, and subprocess was reworked to return explicit Try values instead of panicking on failure — the same edge-hardening pass that crypto got.

Concurrency picked up one notable primitive too: Future.WithTimeout is a monadic timeout that completes with the original result if it arrives in time and a TimeoutError otherwise.

val result = slowCall().WithTimeout(Seconds(5)).Await()   // Try[T]

(It's honest about its limits: the timeout races the result, it doesn't cancel the underlying computation — the docstring says so plainly.)

The build system grew a memory

March's headline performance number was the 22x cold-compile speedup from batch transpilation. The work since has been about the second build and every build after it:

• A persistent-worker mode for the Bazel transpile action, so the analyzer process stays warm across builds instead of paying cold-start each time.
• A hand-rolled binary codec replacing gob for the on-disk analysis cache, with the cache busted automatically when the gala binary's content changes.
• Memoization of per-package analysis, resolver lookups, and fingerprints across requests, plus parallel parsing of sibling files.

The throughline is the same as the transpilation strategy itself: do the expensive analysis once, cache it honestly, and invalidate it correctly. We're also extracting the Bazel integration into a standalone rules_gala module so downstream projects can depend on it cleanly — that work is landing now.

Dogfooding got ambitious

In March the showcase was a web playground, a 7-file HTTP server, and a couple of demos. Two of the newer entries are a different order of magnitude, and both are written entirely in GALA:

• GALA TUI — an Elm-architecture terminal-UI framework: immutable widgets, a differential renderer, an async runtime, a fuzzy command palette, markdown rendering, mouse support, and themes. It leans hard on sealed types for messages and pattern matching for the update loop — exactly the workload GALA was built for.
• GALA Team — a multi-agent orchestrator where a Team Lead delegates to Engineers and QAs, reviews their work, and hands you a PR. A real concurrent program with real state, written in the language.

These matter because they're the difference between "GALA is used somewhere in this project" and "this project is GALA." Frameworks shake out a language's ergonomics in a way that example programs never do.

By the numbers

What's still rough

Same deal as last time — the honest list:

• Package registry. Dependencies resolve, but there's no first-class registry for publishing and discovering GALA libraries yet. It's the top open roadmap item.
• Generics across packages. Much better than March, not finished. The common cases are solid and guarded by tests; the long tail of nested generic inference across module boundaries still surfaces the occasional sharp edge — and when it does, it becomes a repro test before it gets fixed.
• Maturity. GALA is four months old. It generates readable Go and runs real software, but it hasn't been load-bearing in a large team's production system for a year. Use it with eyes open.

The philosophy hasn't moved

The thing I wrote in March still holds: the transpiler is honest about what it is — a source-to-source compiler that generates readable Go, with no special cases for its own standard library. What changed is the confidence behind the pitch. In March, "GALA is like Scala but for Go" was an aspiration. At 0.50.0 — with the type system holding across packages, an LSP in your editor, a functional standard library that reaches the I/O edges, and frameworks written in the language itself — it's closer to a description.

Try it in your browser — no install — or grab a binary from Releases and gala run main.gala.

Why Not Put Everything in One Place?

The obvious question: why not put all IDE features in the LSP server? Or all of them in the plugin?

Everything in the LSP sounds right until you type a character. The LSP server runs the full GALA transpilation pipeline -- parse, analyze, transform -- to produce type information. That pipeline takes tens to hundreds of milliseconds depending on file size and import graph depth. Syntax highlighting, brace matching, and code folding need to respond in under 5ms or the editor feels broken. You cannot debounce syntax highlighting. It has to be synchronous and local.

Everything in the plugin sounds right until you need types. The IntelliJ plugin has a PSI tree built from the ANTLR grammar. It knows the structure of the code -- where functions are, where braces match, what tokens are keywords. But it has no idea what type x is in val x = people.Map((p) => p.Name). That requires running the analyzer, resolving imports across packages, and executing the transformer's type inference. Reimplementing that in Kotlin would mean maintaining two type systems, and the transpiler's type system is the only one that matters because it produces the Go output.

So the split is forced by latency on one side and semantic depth on the other.

What the Plugin Owns

The plugin handles everything that can be answered by looking at tokens and the local PSI tree, without running the transpiler.

Syntax highlighting. The ANTLR grammar generates a Java lexer (Bazel patches -> skip to -> channel(HIDDEN) so whitespace tokens survive for the IDE). GalaSyntaxHighlighter.kt maps token types to IntelliJ's text attribute keys -- keywords get one color, string literals another, comments another. This is pure token classification; no parsing required.

Brace matching. Parentheses, braces, brackets. The plugin registers GalaBraceMatcher and IntelliJ handles the rest. Zero network calls.

Code folding. GalaFoldingBuilder.kt walks the PSI tree looking for block nodes (function bodies, sealed type declarations, import groups) and registers foldable regions. This is structural, not semantic -- you don't need to know what a function returns to know where its body ends.

Structure view. GalaStructureViewElement.kt extracts top-level declarations from the PSI tree -- functions, types, sealed types with their cases, vals, vars. This powers the sidebar outline and Ctrl+F12 navigation. Again, purely structural.

Keyword and basic completion. GalaCompletionContributor.kt offers keyword completions (val, func, match, sealed) and built-in type names (int, string, bool, Option, Either). These are hardcoded lists. They respond instantly because there is nothing to compute.

Live templates. Snippet expansion for common patterns. Local, instant, no server involved.

The common trait: all of these features are fast because they operate on data the plugin already has. No IPC, no analysis, no waiting.

What the LSP Server Owns

The LSP server handles everything that requires the transpiler's semantic model. The GalaHandler in server.go wraps the full pipeline: ANTLR parser, analyzer, and transformer.

Diagnostics. On every edit, the server runs analyzeFile -- parse the source, run the analyzer to resolve imports and build the RichAST, then run the transformer via TransformForLSP to catch type errors. Parse errors, semantic errors, and match exhaustiveness warnings all flow back as LSP diagnostics. The server uses a cancel-and-restart pattern with a 300ms debounce: each keystroke cancels any in-flight analysis and starts a new timer. Before publishing, it checks the document version to discard stale results. Old diagnostics stay visible until replaced -- no flicker.

Type-aware completion. When the user types a dot, completion.go resolves the receiver's type using the cached RichAST and the transformer's VarTypes map. If you type person., the server looks up the type of person, finds its methods and fields in richAST.Types, and returns them. This is qualitatively different from the plugin's keyword completion -- it knows that person is a Person struct with a Name field and an Age field. It also handles package-qualified dot completion (collection_immutable.Array), named argument completion inside constructors (Person(Name =), and match case completion with field destructuring for sealed types.

Inlay hints. For val x = someExpression, the server resolves the type of someExpression through the transformer and displays the inferred type inline. This requires the full type inference pipeline.

Hover. Ctrl+Q shows type signatures, struct fields, method lists, and sealed type variants. All sourced from the RichAST.

Go-to-definition. Cross-file navigation using the analyzer's resolved metadata. The plugin's PSI tree only knows about the current file; the analyzer knows the entire package graph.

The Sync Problem

Here is where it gets uncomfortable. The plugin has hardcoded lists:

// GalaCompletionContributor.kt
val DECLARATION_KEYWORDS = listOf("val", "var", "func", "type", "struct", ...)
val BUILTIN_TYPES = listOf("int", "string", "bool", "float64", "Option", "Either", ...)

The LSP server has its own list:

// completion.go
keywords := []string{
    "package", "import", "val", "var", "func", "type", "struct",
    "interface", "sealed", "embed", "if", "else", "for", "range",
    "return", "match", "case", "true", "false", "nil", "map",
}

And the actual source of truth is neither of these -- it is the ANTLR grammar (gala.g4) for keywords and types.go's IsPrimitiveType() for built-in types.

If someone adds a keyword to the grammar and forgets to update the plugin, keyword completion silently omits it. If someone adds a built-in type to the transpiler and forgets to update the syntax highlighter, that type name renders in the wrong color. These bugs are subtle, they don't cause test failures, and they erode trust in the tooling.

SYNC.md as a Contract

GALA's answer is a synchronization document (ide/intellij/SYNC.md) that explicitly lists every hardcoded data point, its authoritative source, and how to extract the current values. Nine sync points are documented:

1. Keywords -- plugin completion lists and highlighter vs. gala.g4 lexer rules
2. Built-in types -- plugin annotator, highlighter, and completion vs. types.go
3. Std auto-imported types -- plugin completion vs. std/*.gala sealed types
4. Std methods -- plugin postfix templates vs. std/*.gala method definitions
5. Importable package types -- explicitly marked as NOT in static lists (LSP-only)
6. Highlighter token mapping -- plugin when block vs. generated Java lexer constants
7. LSP completion keywords -- completion.go vs. gala.g4
8. LSP type inference -- inlay_hints.go vs. transpiler type system
9. LSP match exhaustiveness -- reads from RichAST at runtime (no hardcoded data)

Each entry includes the exact file paths and shell commands to extract current values. The document also specifies trigger conditions: sync after any grammar change, new std type, new collection type, or built-in type change.

This is not automated enforcement -- it is a documented contract. When you change the grammar, you know exactly which files to update because the document tells you. It trades perfection for pragmatism: a grep command you can run is more useful than a validation framework nobody maintains.

Trade-offs in Practice

Latency. The plugin responds in under 5ms for highlighting, folding, brace matching, and keyword completion. The LSP server debounces at 300ms and analysis can take longer. Users see instant syntax feedback but slightly delayed error squiggles. This is the right trade-off -- laggy highlighting is unacceptable, laggy diagnostics are tolerable.

Accuracy. The plugin's keyword completion will suggest match whether or not you are in a context where match is valid. The LSP server's type-aware completion will only suggest methods that actually exist on the receiver's type. Local is approximate; semantic is precise.

Portability. The IntelliJ plugin works only in JetBrains IDEs. The LSP server works in VS Code, Neovim, Helix -- anything that speaks LSP 3.17 over stdio. If GALA only had the plugin, two-thirds of potential users would have no IDE support. The LSP server is the portable foundation; the plugin is the premium layer for JetBrains users.

Maintenance cost. Two codebases in two languages (Kotlin and Go) with shared assumptions. Every grammar change touches both. The SYNC.md contract reduces the risk but does not eliminate it. This is the real cost of the split architecture, and it is worth paying because the alternative -- reimplementing type inference in Kotlin or accepting 300ms syntax highlighting latency -- is worse.

The Uncomfortable Truth

A two-process architecture is not elegant. It is a pragmatic response to competing constraints: the plugin must be fast, the server must be smart, and neither can do the other's job well. The synchronization contract is a maintenance burden that scales linearly with language complexity. Every new keyword, every new built-in type, every new sealed variant in std is a potential sync failure.

But the alternative architectures are worse. A pure-LSP approach makes the editor feel sluggish. A pure-plugin approach cannot provide semantic features without reimplementing the transpiler. A single-binary approach that embeds the transpiler in a JetBrains plugin locks out every other editor.

The split is the least bad option. SYNC.md is the acknowledgment that it has costs. And the 300ms debounce in DidChange is the number that makes it all work -- fast enough to feel responsive, slow enough to avoid burning CPU on every keystroke.

This post is about how we fake it.

The completion cascade

Before resolving any types, the handler needs to figure out what kind of completion the user wants. GALA's completion handler runs a context detection cascade -- four checks in priority order:

isDot := isDotCompletion(text, line, char)

if isDot && richAST != nil {
    receiverType := typeAtDot(text, line, char, richAST, varTypeMap)
    if strings.HasPrefix(receiverType, packagePrefix) {
        pkgName := strings.TrimPrefix(receiverType, packagePrefix)
        items = append(items, packageCompletions(richAST, pkgName)...)
    } else if receiverType != "" {
        items = append(items, typeSpecificCompletions(richAST, receiverType)...)
    }
} else if isNamedArgContext(text, line, char) && richAST != nil {
    // Constructor named args: Person(name = ...)
} else if isMatchCaseContext(text, line, char) && richAST != nil {
    // Sealed type case suggestions
} else {
    // Global: types, functions, keywords
}

Dot completion wins. If it fires, nothing else runs. This matters because a dot inside a constructor call (Person(address = city.) is both a named-arg context and a dot context. The dot takes priority because the user is actively accessing a member.

Detecting the dot

isDotCompletion does something deceptively simple: it walks backwards from the cursor position on the current line, looking for a . character. But there's a subtlety. When the user types order.ge, the cursor is after e, not after .. The partial identifier ge is what they've typed so far. We need to skip past it:

func isDotCompletion(text string, line, char int) bool {
    // ...
    if l[char-1] == '.' {
        return true
    }
    // Walk backwards past any partial identifier being typed
    i := char - 1
    for i >= 0 && isIdentChar(l[i]) {
        i--
    }
    if i >= 0 && l[i] == '.' {
        return true
    }
    return false
}

This handles both order. (cursor right after dot) and order.ge (cursor mid-identifier after dot). The partial identifier is irrelevant for type resolution -- we only care about what's to the left of the dot.

Resolving the receiver type

This is where things get interesting. typeAtDot needs to figure out what type order is. It has no type checker, no symbol table built from a full program analysis. What it has:

1. VarTypes -- a map[string]string populated by the transpiler during its last successful transform. Keys are scoped: "main.order" maps to "Order", "processItems.item" maps to "Item". The transpiler already resolved these types while generating Go code; we just reuse its work.

2. RichAST -- the transpiler's analysis output containing type metadata (fields, methods, sealed variants), function signatures, package information, and import aliases.

The resolution cascade in resolveReceiverType tries five strategies in order:

func resolveReceiverType(name, funcScope string, richAST *transpiler.RichAST,
    varTypes map[string]string) string {
    // 1. Transpiler's resolved var types (function-scoped)
    if typStr := lookupVarType(varTypes, funcScope, name); typStr != "" {
        return stripTypeParams(typStr)
    }
    // 2. Function call return type: GetOrder() → Order
    if fm, ok := richAST.Functions[name]; ok { ... }
    // 3. Sealed case constructor → parent type: Some(42) → Option
    for _, tm := range richAST.Types { ... }
    // 4. Package name → package marker
    for _, pkgName := range richAST.Packages { ... }
    // 5. Type name for static calls: List.Empty()
    if isExported(name) { if findType(richAST, name) != nil { return name } }
    return ""
}

The scoped lookup is important. lookupVarType tries funcScope + "." + varName first, then falls back to an unscoped lookup. If you have a val order = ... inside func main, it's stored as "main.order". The enclosing function is found by scanning backwards from the cursor for a func declaration -- crude, but effective for GALA's single-function-per-block structure.

The chain problem

Simple variable access is easy. The hard case is chains: collection.Map(transform).Filter(predicate).. The user expects completions for whatever Filter returns, which means we need to resolve the entire chain left-to-right.

typeAtDot handles this by detecting a closing paren before the dot. When it sees ), it walks backwards through balanced parentheses to find the method name, then checks if there's another dot before that name -- indicating a chain:

// Case 1: Closing paren before dot — expr.Method().
if i >= 0 && l[i] == ')' {
    depth := 1
    i--
    for i >= 0 && depth > 0 {
        if l[i] == ')' { depth++ }
        else if l[i] == '(' { depth-- }
        i--
    }
    // Extract the method name before '('
    name := l[nameStart:nameEnd]
    if i >= 0 && l[i] == '.' {
        // Chained: resolve receiver, then get method's return type
        receiverType := resolveChainType(l[:i], enclosingFunc, richAST, varTypes)
        if receiverType != "" {
            return resolveMethodReturn(richAST, receiverType, name)
        }
    }
}

resolveChainType is recursive. It peels off the rightmost segment of the expression, resolves its type, then uses resolveMethodReturn to look up what that method returns on that type. A depth limit of 10 prevents infinite recursion on pathological inputs:

const maxChainDepth = 10

func resolveChainTypeN(text string, funcScope string, richAST *transpiler.RichAST,
    varTypes map[string]string, depth int) string {
    if depth > maxChainDepth { return "" }
    // ...
    if text[len(text)-1] == ')' {
        // Walk balanced parens, extract method name
        if i >= 0 && text[i] == '.' {
            receiverType := resolveChainTypeN(text[:i], funcScope, richAST, varTypes, depth+1)
            if receiverType != "" {
                return resolveMethodReturn(richAST, receiverType, methodName)
            }
        }
    }
    // Plain identifier — resolve directly
    return resolveReceiverType(name, funcScope, richAST, varTypes)
}

So for collection.Map(transform).Filter(predicate)., resolution proceeds: resolve collection from VarTypes (say, List), look up Map's return type on List (say, List), look up Filter's return type on List (say, List), then show List's methods.

There's an obvious limitation: generic type parameters are erased. stripTypeParams drops [T] from List[int] before lookup, so collection.Map(toStr). still shows List methods, not List[string] methods. The method set is the same either way for GALA's standard library types, so this works in practice. It wouldn't work for a language where different type parameters produce different method sets.

The __package__ hack

When the user types http., they're not accessing a field on a variable -- they want the exports of the http package. But the resolution cascade would happily try to find a variable called http in VarTypes, fail, and return nothing.

The fix is a sentinel value. resolveReceiverType checks the RichAST's package list and import aliases. If the name matches a known package, it returns "__package__:http" instead of a type name:

const packagePrefix = "__package__:"

// In resolveReceiverType:
for _, pkgName := range richAST.Packages {
    if pkgName == name {
        return packagePrefix + name
    }
}
if richAST.ImportAliases != nil {
    if pkgName, ok := richAST.ImportAliases[name]; ok {
        return packagePrefix + pkgName
    }
}

Back in the completion handler, this prefix triggers a completely different code path -- packageCompletions instead of typeSpecificCompletions. Package completions pull from three sources: types belonging to that package, functions belonging to that package, and GoExports (a map of raw export names from Go-only packages that the transpiler has seen but not fully analyzed).

The alias handling matters. If the GALA source has import io = "collection/immutable", typing io. needs to resolve the alias io to the actual package name collection/immutable and show its exports.

Generating completions

Once we have a resolved type name, typeSpecificCompletions looks it up in the RichAST via findType and builds completion items from three sources:

Methods get full signatures and smart insert text. Zero-parameter methods insert () immediately; methods with parameters insert ( and let the editor handle the rest (which sets up signature help):

if len(m.ParamNames) == 0 {
    insertText = name + "()"
} else {
    insertText = name + "("
}

Fields show their type as the detail string. Sealed variants generate IsXxx() predicate methods. And every type gets a match keyword suggestion, because pattern matching is idiomatic in GALA.

findType itself is more resilient than you'd expect. It tries direct key lookup, std.-prefixed lookup (GALA's standard library), qualified-name decomposition (mylib.Animal matches a type with simple name Animal), and type alias resolution. This layered lookup handles the fact that the RichAST keys aren't always consistent -- sometimes they're package-qualified, sometimes they're not, depending on how the type was declared.

Edge cases: cursor position semantics

Different editors report cursor positions differently when the user triggers completion on a dot. Some place the cursor on the dot (before it), others place it after the dot. VS Code places it after, which is what isDotCompletion checks first (l[char-1] == '.'). But when the user has typed order.ge and triggers completion mid-word, the cursor is past both the dot and the partial identifier. The backwards walk through isIdentChar handles this uniformly.

There's also the question of what happens when the dot is at column 0 (nothing before it) or when the line itself is shorter than the reported cursor position. Both are guarded: char <= 0 returns early, and char is clamped to len(l) to handle editors that report positions beyond line length.

What we're actually doing

The core insight is that we never build a type checker. We mooch off the transpiler. Every time the document changes, the LSP runs TransformForLSP, which does a partial transpilation and dumps its resolved variable types into a flat map. The LSP's job is just text surgery -- walk backwards from the cursor, figure out what syntactic construct we're in, and look up the answer in pre-computed tables.

It's fragile in ways a real type checker wouldn't be. Chains longer than what the transpiler resolved break. Generic type parameters are erased. Completions after a syntax error on the same line might fail because the backwards paren-walk gets confused. But it's fast, it handles the common cases, and it was built in a fraction of the time a real type checker would take.

Sometimes the right engineering decision is to not build the thing you think you need.

GALA transpiles to Go. When a user writes val x = Some(42) in their editor, the LSP needs to know that x is Option[int]. But there's no Go source file to analyze yet -- the transpiler hasn't run. And even after it runs, the generated Go uses different names, wraps values in Immutable[T], and structures code in ways that don't map cleanly back to the original source positions. This is the type information gap, and every transpiled language has to solve it.

The naive approach: running go/types on the output

The first thing you'd try -- and the first thing we tried -- is to transpile the file, then run go/types on the generated Go AST. Go has excellent type-checking infrastructure; why not leverage it?

It works, sort of. You get types, but they're Go types, not GALA types. A GALA val name = "hello" becomes a Go name := std.NewImmutable[string]("hello"), and go/types tells you the type is std.Immutable[string]. Now you need a reverse-mapping layer to turn that back into string for display. A GALA Option[int] becomes std.Option[int] in Go. A sealed type variant with three fields generates a struct with a _variant uint8 discriminator. Every generated pattern needs a corresponding un-generation rule.

Worse, go/types needs complete, compilable Go code. If the user is mid-edit and the transpiler produces a partial or broken Go file, the type checker fails entirely -- no partial results, no graceful degradation. For an LSP that needs to respond to every keystroke, "all or nothing" is the wrong tradeoff.

We needed a different approach.

The solution: the transpiler already knows

Here's the insight that changed the design: the transpiler already resolves every type during transformation. When it encounters val x = Some(42), it infers that Some(42) produces Option[int], records that in its internal scope, and uses that information to generate the correct Go code. The type information exists -- it's just trapped inside the transformer's mutable state, discarded after the Go AST is emitted.

The fix was surgical. We added a parallel data structure to the transformer that records every variable's resolved type as a side effect of the normal transformation process. No separate analysis pass, no reverse mapping, no additional type checker. The transpiler does its job and the LSP reads the results.

The core of it lives in scope.go:

func (t *galaASTTransformer) addVal(name string, typeName transpiler.Type) {
    if t.currentScope != nil {
        t.currentScope.vals[name] = true
        t.currentScope.valTypes[name] = typeName
    }
    t.recordLSPVarType(name, typeName)
}

func (t *galaASTTransformer) recordLSPVarType(name string, typeName transpiler.Type) {
    if t.lspVarTypes == nil || typeName == nil || typeName.IsNil() {
        return
    }
    key := name
    if t.lspCurrentFunc != "" {
        key = t.lspCurrentFunc + "." + name
    }
    t.lspVarTypes[key] = typeName
}

Every call to addVal or addVar -- the same functions the transpiler uses to track variables for code generation -- now also records the type into lspVarTypes. The recording is conditional: if lspVarTypes is nil (normal compilation, not an LSP invocation), the function returns immediately. Zero overhead for the non-LSP path.

How types are scoped

The scoping scheme is deliberately simple. A variable inside a function is keyed as funcName.varName. A top-level variable is keyed as just varName. That's it.

The transformer tracks the current function name via lspCurrentFunc, set at the entry of each function declaration and restored on exit:

// In declarations.go, inside the function declaration handler:
prevFunc := t.lspCurrentFunc
t.lspCurrentFunc = name
defer func() { t.lspCurrentFunc = prevFunc }()

This means if you have a function calculateTotal with a local val tax = price * 0.1, the key in lspVarTypes is "calculateTotal.tax". A top-level val config = loadConfig() is just "config".

On the LSP side, lookupVarType mirrors this convention. It takes the enclosing function name (determined by scanning backwards from the cursor position for a func declaration) and tries the scoped key first, falling back to unscoped:

func lookupVarType(varTypeMap map[string]string, funcName, varName string) string {
    if varTypeMap == nil {
        return ""
    }
    if funcName != "" {
        if typStr, ok := varTypeMap[funcName+"."+varName]; ok {
            return typStr
        }
    }
    if typStr, ok := varTypeMap[varName]; ok {
        return typStr
    }
    return ""
}

This doesn't handle shadowing within nested scopes (a variable in an inner block with the same name as one in the outer function body), and that's a conscious trade-off. Full scope tracking would require mapping source positions to AST nodes, which adds complexity for a case that rarely matters in practice.

The LSP pipeline: from keystrokes to cached types

The TransformForLSP method is the bridge between the transpiler and the LSP. It calls the regular Transform, then copies out the accumulated lspVarTypes:

func (t *galaASTTransformer) TransformForLSP(richAST *transpiler.RichAST) (*transpiler.TransformResult, error) {
    fset, file, transformErr := t.Transform(richAST)
    // Always return collected var types, even on error (partial results)
    varTypes := make(map[string]transpiler.Type, len(t.lspVarTypes))
    for name, typ := range t.lspVarTypes {
        varTypes[name] = typ
    }
    return &transpiler.TransformResult{
        Fset:     fset,
        File:     file,
        VarTypes: varTypes,
    }, transformErr
}

Note the comment: "even on error (partial results)." If the transpiler fails halfway through a file -- because the user is still typing -- we still get types for every variable processed before the error. This is the critical difference from the go/types approach. Partial results are the default, not a special case.

The LSP server calls this inside analyzeFile, which runs on every document change (after a 300ms debounce). The returned VarTypes map gets cleaned up and cached:

if result != nil && result.VarTypes != nil {
    typeMap := make(map[string]string, len(result.VarTypes))
    for name, typ := range result.VarTypes {
        typeMap[name] = cleanGoTypeForDisplay(typ.String())
    }
    h.mu.Lock()
    h.varTypes[uri] = typeMap
    h.mu.Unlock()
}

The cleanGoTypeForDisplay function handles the impedance mismatch between GALA's internal type representation and what a user expects to see. It strips std. prefixes and unwraps Immutable[T] to T -- the generated Go uses Immutable wrappers to enforce value semantics on val bindings, but the user doesn't need to know that.

What this enables

With a single map[string]string per open document, the LSP gets:

Inlay hints. When the user writes val x = someExpression(), the editor shows : ReturnType as a ghost annotation after x. The inlay hint handler walks visible lines, matches val/var declarations without explicit types, and looks up the variable name in varTypes.

Dot completion. When the user types x., typeAtDot resolves x to its type via the same lookupVarType function, then looks up that type's methods and fields in the RichAST to build the completion list.

Hover information. Same lookup, different presentation -- show the type in a hover tooltip instead of a completion menu.

All three features share the exact same type resolution path. There's no separate type-checking logic for completions vs. hints vs. hover. If the transpiler resolves a type, every LSP feature sees it.

The trade-off

This design couples the LSP tightly to the transpiler's internals. If the transpiler changes how it represents types, every LSP feature is affected. But the alternative -- maintaining a separate type checker -- would mean maintaining two sources of truth that inevitably drift apart. For a language where the transpiler is the type checker, piggybacking on its results isn't coupling; it's architectural honesty.

The bigger limitation is that lspVarTypes only captures variables. Expression types (what's the type of list.Map(f).Filter(g)?) aren't in the map; those get resolved on the fly by typeAtDot walking the chain and consulting the RichAST's method signatures. That's a story for another post.

Next in the series: how dot-completion resolves method chains when the type of each step depends on the previous one.

The Problem

GALA transpiles .gala files to .go files. For single-file packages, this is fast -- parse, analyze, transform, emit. But real projects have multi-file packages. A server might have 7 files in the same package, each file needing to know about types, methods, and sealed types defined in the other 6.

Before 0.24.0, each file in a package was transpiled as a separate process invocation. The gala transpile command was called once per file, and each invocation:

1. Parsed the target file
2. Scanned all sibling files to extract type information
3. Analyzed the full dependency graph (imports, Go type inference, sealed type metadata)
4. Transformed the AST to Go
5. Emitted the output

For a 7-file package, step 2 and 3 happened 7 times, each time re-parsing the same siblings and re-resolving the same imports. The Go type inference step -- which shells out to go list to resolve return types and method signatures from Go packages -- was particularly expensive, adding hundreds of milliseconds per invocation.

The gala-server package (7 files) took 44.7 seconds. Most of that was redundant work.

Profiling First

GALA 0.24.0 introduced GALA_PROFILE=1, an environment variable that enables compilation profiling. When set, the transpiler emits timing breakdowns for every phase:

[PROFILE] Parse:     12ms
[PROFILE] Analyze:   340ms
[PROFILE] Transform: 85ms
[PROFILE] Emit:      3ms
[PROFILE] Total:     440ms

Running this across all 7 files revealed the pattern immediately: analysis dominated. Each file spent ~340ms in analysis, and the analysis for each file was doing nearly identical work -- re-parsing sibling files, re-resolving Go types, re-building sealed type metadata.

The profiling data made the optimization path obvious. Without it, we might have guessed wrong and optimized the transform phase (which was already fast) or the parser (which was negligible).

Lesson: always profile before optimizing. The GALA project enforces this as policy -- the memory file literally says "always profile with GALA_PROFILE=1 before optimizing."

Solution 1: BatchAnalyzer

The first optimization was architectural: share analysis state across files in the same package.

The BatchAnalyzer takes all files in a package at once. It parses each file, then runs a single unified analysis pass that:

• Extracts type declarations, method signatures, and sealed type definitions from all files
• Runs Go type inference once for the entire package's import set
• Builds a shared metadata cache that every file can read from

Instead of 7 analysis passes (one per file), there is now 1 analysis pass for the whole package. The analysis result is then distributed to each file's transformer.

The implementation required refactoring the analyzer's entry point. Previously, NewGalaAnalyzer accepted a single file and optional sibling file paths. The new NewBatchAnalyzer accepts all files upfront and returns a shared analysis context:

Before:  7 files x 1 analyzer each  = 7 full analyses
After:   7 files x 1 shared analyzer = 1 full analysis + 7 lookups

Solution 2: Disk Cache

Even with batch analysis, the Go type inference step (resolving return types, struct fields, and method signatures from Go standard library and third-party packages) was still expensive for the first compilation of a package.

GALA 0.24.0 introduced a disk cache at .gala/cache/. The cache stores analysis results keyed by content hash -- a SHA-256 of the file contents plus the contents of all its imports. If the file and its dependencies haven't changed, the cached analysis is reused.

The cache format is simple: JSON files named by their content hash. On a warm cache, the analysis phase drops from ~340ms to ~5ms per file, because no Go type inference or sibling parsing is needed.

Cache invalidation is content-addressed, so it is always correct: if any source file changes, its hash changes, and the cache misses. No timestamps, no file watchers, no stale cache bugs.

Solution 3: Batch Transpilation

The final piece was eliminating the process-per-file overhead. Before 0.24.0, the build system (Bazel or gala build) invoked the transpiler binary once per .gala file. Each invocation paid the cost of process startup, Go runtime initialization, and flag parsing.

Batch transpilation runs a single transpiler process for all files in a package. The process:

1. Parses all input files
2. Runs the BatchAnalyzer (one shared analysis pass)
3. Transforms each file using the shared analysis context
4. Emits all .go files

This eliminated 6 process startups (for a 7-file package) and enabled the shared analysis to happen in-memory rather than being serialized to disk and re-read.

Results

Benchmarked on the gala-server package (7 .gala files):

The warm-cache number is the steady-state experience during development: edit a file, rebuild, and the unchanged files hit the cache while only the modified file gets re-analyzed.

For single-file packages (like most examples), compilation time is unchanged at ~200-400ms. The optimization specifically targets the multi-file case where redundant work was the bottleneck.

Lessons Learned

1. Profile before optimizing. The profiling data pointed directly at analysis as the bottleneck. Without it, we might have spent time optimizing the wrong phase.

2. Shared state beats repeated computation. The batch analyzer is conceptually simple -- do the work once, share the result -- but it required restructuring the analyzer's API from "single file in, analysis out" to "all files in, shared context out."

3. Content-addressed caching is worth the investment. It is simpler than timestamp-based caching (no clock skew issues, no "did the file actually change?" ambiguity) and it is always correct. The overhead of computing SHA-256 hashes is negligible compared to the analysis it replaces.

4. Process startup costs add up. For a language tool that gets invoked hundreds of times during a build, the cost of spawning a new process each time is real. Batch mode amortizes this to one process per package.

5. The optimization was straightforward once the data was clear. There was no clever algorithm, no sophisticated caching strategy. The 22x improvement came from eliminating obviously redundant work that the profiler made visible.

Try It

GALA 0.24.0+ is available now. To see compilation timing for your own packages:

GALA_PROFILE=1 gala build ./...

The playground at https://gala-playground.fly.dev transpiles instantly (single-file), but for multi-file projects, the batch transpilation makes a meaningful difference in the edit-compile-run cycle.

The Challenge

Transpilers occupy an unusual spot in the compiler landscape. A traditional compiler owns the entire pipeline from source to machine code. A transpiler maps one language's semantics onto another language's type system, and any mismatch between the two becomes a bug.

GALA maps functional concepts -- sealed types, pattern matching, immutability, monadic types -- onto Go's type system. Go has no sum types, no pattern matching, no Option[T]. Every one of these features must be lowered into valid Go code that the Go compiler accepts. The type inference engine must reason about GALA's types (sealed variants, generic monads, lambda parameter inference) while also querying Go's type system (return types of os.ReadFile, field types of http.Request).

This two-language gap is where most of our bugs lived.

Categories of Bugs

Type Inference (35+ fixes)

Type inference bugs were the most common category. GALA's type system is richer than Go's -- it has sealed types, generic type parameter inference, lambda parameter inference from context, and Hindley-Milner-style unification for complex generic chains.

Chained method calls were a recurring source of issues. Consider:

val result = Some(42).Map((x) => x * 2).GetOrElse(0)

The transpiler must:

1. Infer that Some(42) produces Option[int]
2. Resolve Map on Option[int] with a func(int) int lambda
3. Infer the lambda parameter x as int from the method signature
4. Determine that Map returns Option[int]
5. Resolve GetOrElse on Option[int] returning int

If any step fails, the chain breaks. Early versions would lose the type at step 4, causing GetOrElse to resolve against Option[any] and generate incorrect Go code.

Void lambdas were another painful area. Go functions that take func(T) callbacks (no return value) need different treatment than func(T) U callbacks. The transpiler must detect when a lambda is expected to return nothing and avoid wrapping its body in a return statement. Getting this wrong produced Go code that failed to compile with "too many return values."

Block lambda return types required special handling. When a lambda has a block body:

val result = list.Map((x) => {
    val doubled = x * 2
    return doubled
})

The return type must be inferred from the last expression or explicit return statement inside the block. This interacts with generic type parameter substitution -- if Map is Map[U](f func(T) U) Array[U], the transpiler must unify U with the block's return type.

Code Generation (20+ fixes)

Code generation bugs produced syntactically valid but semantically wrong Go code.

Unused imports were a constant annoyance. GALA auto-imports the std package for Option, Try, etc. But if a file uses only Println (which maps to fmt.Println), the transpiler might emit an import "martianoff/gala/std" that nothing references. The Go compiler rejects unused imports, so the generated code would not compile.

The fix was an ImportManager that tracks which imports are actually referenced during code generation and only emits those. This sounds simple, but the original implementation had 4 separate import tracking subsystems that had grown organically -- one for explicit user imports, one for auto-imports, one for sealed type companions, and one for Go interop helpers. Unifying these into a single ImportManager was one of the larger refactoring efforts (covered below).

IIFE wrapping for if-expressions and match-expressions required careful handling. GALA's if and match are expressions that produce values, but Go's if and switch are statements. The transpiler wraps them in immediately-invoked function expressions:

// GALA: val x = if (cond) "yes" else "no"
// Go:
x := func() string {
    if cond {
        return "yes"
    }
    return "no"
}()

Getting the return type of these IIFEs wrong -- especially when the branches had different levels of type specificity -- caused type mismatches in the generated Go.

Cross-Package Resolution (15+ fixes)

Multi-file packages and cross-package imports introduced a class of bugs around name resolution.

Dot imports (. "package/path") bring all exported names into scope. The transpiler must know which names came from dot imports versus local definitions, because the generated Go code needs explicit package prefixes for non-dot imports. Early versions would sometimes lose track of a name's origin, generating json.Codec when the user had import . "martianoff/gala/json" (which should produce just Codec).

Sibling file scanning -- extracting type information from other files in the same package -- had to be carefully scoped. The scanner must extract type declarations, method signatures, and sealed type definitions from siblings, but it must NOT scan files from main or test packages when analyzing a library package. A bug where sibling scanning included main package files caused type corruption in library packages.

Build System (10+ fixes)

Bazel-specific bugs were their own category.

Symlinks and junctions on Windows caused issues with Bazel's sandboxing. GALA genrules need filesystem access to the Go SDK for type inference, requiring tags = ["no-sandbox"]. But Bazel still creates symlink trees for inputs, and Windows junction handling in Go's filepath.Walk behaved differently than on Linux.

Cache races in Bazel's parallel execution could cause two genrules to write the same cache file simultaneously. The fix was content-addressed caching with atomic writes (write to a temp file, then rename).

The Testing Infrastructure

Catching these bugs before users hit them required multiple layers of testing.

Compilation Gate Test

Every example in the examples/ directory (216 files as of today) has a corresponding expected-output file. The compilation gate test transpiles every example, compiles the generated Go, runs it, and compares the output. If any example fails to compile or produces wrong output, the gate fails.

This is the single most valuable test. It catches regressions that unit tests miss because unit tests test individual phases, while the gate test exercises the full pipeline end-to-end.

Type Inference Regression Suite

A dedicated test suite with 14+ cases targeting specific type inference scenarios that have broken in the past:

• Generic method chains with lambda parameter inference
• Sealed type pattern matching with nested extractors
• FoldLeft accumulator type inference from zero value
• Block lambda return type propagation through generic boundaries
• Void lambda detection for Go callback functions

Each case is a minimal .gala file that exercises one inference path. When a type inference bug is fixed, a regression case is added to prevent it from recurring.

Metadata Validation Pass

Setting GALA_VALIDATE_METADATA=1 enables a post-analysis validation pass that checks:

• All type references resolve to concrete types (no leftover NilType or any placeholders)
• All method calls resolve to known methods on the resolved type
• Sealed type variants have correct discriminator values
• Generic type parameters are fully substituted

This catches bugs where the analyzer produces metadata that looks plausible but is subtly wrong -- the kind of bug that only manifests as incorrect Go output or a confusing Go compiler error.

Battle Test Workflow

A CI workflow that builds and runs all examples, the standard library tests, and several multi-file showcase projects. It runs on both Linux and Windows to catch platform-specific issues (Windows path separators, symlink handling, GOROOT propagation).

Bug Stories

Void Lambda Error Swallowing

In version 0.22.0, we discovered that Go functions accepting func(T) callbacks could silently swallow errors. Consider:

val items = SliceOf("file1.txt", "file2.txt")
items.ForEach((name) => os.Remove(name))

os.Remove returns an error, but ForEach takes func(string) -- a void callback. The transpiler was happily compiling this, discarding the error return. In Go, ignoring an error return is at least visible in the code (_ = os.Remove(name)). In GALA, the void lambda made it invisible.

The fix had two parts. First, the transpiler now rejects void lambdas where the body expression returns an error type, producing a compile error: "void lambda discards error return from os.Remove; use Try or handle the error explicitly." Second, we added FromError(error) Try[Void] to the standard library, providing a clean way to convert Go error returns into GALA's type-safe error handling:

items.ForEach((name) => {
    FromError(os.Remove(name)).OnFailure((e) => {
        Println(s"Failed to remove $name: ${e.Error()}")
    })
})

This is a case where a bug fix led to a language feature. The Void type and FromError constructor exist because a real interop edge case demanded them.

ImportManager Unification

By version 0.22.0, the transpiler had accumulated four separate import tracking systems:

1. User imports -- explicit import declarations in the source file
2. Auto-imports -- automatically added for std, fmt, etc.
3. Sealed type imports -- added when pattern matching references companion objects from other packages
4. Go interop imports -- added when the transpiler generates calls to Go standard library functions

Each system maintained its own state, its own deduplication logic, and its own output formatting. Bugs would appear when two systems disagreed: the auto-import system would add "fmt" and then the user import system would also add "fmt", producing a duplicate import that Go rejects.

The unification in 0.23.0 replaced all four with a single ImportManager that:

• Accepts imports from any source (user, auto, sealed, interop)
• Deduplicates by import path
• Tracks actual usage during code generation
• Emits only imports that are referenced in the output

The refactoring touched 12 files and required updating every code path that previously used one of the four systems. The result was a net reduction of ~400 lines of code and elimination of an entire class of "duplicate import" and "unused import" bugs.

The 22x Performance Gain

The compilation performance story (covered in detail in the companion post) is also a reliability story. The file-at-a-time transpilation model was not just slow -- it was fragile. Each file's analysis was an independent computation, and if two files in the same package inferred slightly different metadata for a shared type (due to different analysis orderings or cache states), the generated Go files could be inconsistent.

Batch transpilation eliminated this class of bugs entirely by ensuring all files in a package see the same analysis result.

What Makes Transpiler Bugs Unique

Transpiler bugs differ from traditional compiler bugs in one important way: the error message comes from the wrong compiler.

When GALA generates incorrect Go code, the error is reported by the Go compiler -- not GALA. The user sees a Go error pointing at generated code they did not write. The mental model required to debug this ("GALA generated wrong Go, which means my GALA source triggered an edge case in the type inference engine") is harder than debugging a direct compiler error.

This is why GALA invests heavily in catching bugs before code generation. The metadata validation pass, the type inference regression suite, and the compilation gate test all exist to ensure that if something goes wrong, it fails in the GALA transpiler with a GALA-level error message, not in the Go compiler with a cryptic message about generated code.

Current State

As of version 0.25.2:

• 216 verification examples compile and produce correct output
• 14 type inference regression cases guard against known failure modes
• Full CI on Linux and Windows catches platform-specific issues
• Metadata validation available for development builds
• Zero known open bugs in the type inference engine (though new ones will certainly appear as usage grows)

The transpiler is not done. Complex generic type inference across package boundaries still has rough edges. The interaction between Go's type system and GALA's sealed types occasionally produces surprising results. But the testing infrastructure means that when bugs appear, they are caught quickly, fixed with a regression test, and stay fixed.

Try It

The GALA playground is at https://gala-playground.fly.dev. For local development:

gala build ./...
gala test ./...

If you find a bug, the best report is a minimal .gala file that fails to compile or produces wrong output. That becomes a regression test, and regression tests are how transpilers get reliable.

GALA (Go Alternative Language) is a programming language that transpiles to Go. It takes Go's runtime performance, static typing, and deployment simplicity, and adds the features that Go developers reach for repeatedly but never get: sealed types with exhaustive pattern matching, immutability by default, monadic error handling, functional collections, and type inference that actually works across generic boundaries.

GALA is not a new runtime or a managed language. Every .gala file becomes a .go file. Your existing Go libraries, tools, and deployment pipelines work unchanged. The goal is simple: write safer, more expressive code that compiles to the same fast binaries you already rely on.

Two months ago, GALA shipped version 0.0.1 -- a transpiler that could handle basic structs, val/var declarations, and simple pattern matching. Today, version 0.25.2 delivers a language with a rich standard library, a zero-reflection JSON codec, async primitives, and a compilation pipeline that processes multi-file packages in under 3 seconds.

By the Numbers

Since the first release on January 23, 2026:

• 46 releases shipped (roughly one every 1.5 days)
• 216 verification examples in the test suite
• 80+ bug fixes across type inference, code generation, and build tooling
• 19 standard library modules (std, collections, concurrent, json, regex, io, go_interop)
• 22x compilation speedup for multi-file packages (44.7s down to 2.7s)

This pace was only possible because GALA's transpilation architecture allows rapid iteration: change the transformer, run the examples, see real Go output. No bootstrapping a VM, no managing a garbage collector.

Highlight Reel

Sealed Types and Exhaustive Pattern Matching

Sealed types are GALA's answer to Go's lack of sum types. They define algebraic data types concisely, with the transpiler generating all the boilerplate -- parent structs, companion objects, Apply/Unapply methods, and discriminator checks.

sealed type Shape {
    case Circle(Radius float64)
    case Rectangle(Width float64, Height float64)
    case Point()
}

val area = shape match {
    case Circle(r)      => 3.14159 * r * r
    case Rectangle(w, h) => w * h
    case Point()         => 0.0
    // No default needed -- compiler verifies exhaustiveness
}

The standard library's Option[T], Either[A, B], and Try[T] are all sealed types. They use the same resolution mechanisms as user-defined types -- no special-casing in the transpiler.

Zero-Reflection JSON Codec

GALA's JSON codec is built on StructMeta[T], a compiler intrinsic that provides type-safe struct introspection without any reflection at runtime. The codec uses a builder pattern with naming strategies:

import . "martianoff/gala/json"

struct Person(FirstName string, LastName string, Age int)

val codec = Codec[Person](SnakeCase())
    .Omit("Password")
    .Rename("Email", "email_address")

val jsonStr = codec.Encode(person).Get()
// => {"first_name":"Alice","last_name":"Smith","age":30}

// Pattern matching on JSON strings
val result = jsonStr match {
    case codec(p) => s"Found: ${p.FirstName}, age ${p.Age}"
    case _ => "invalid JSON"
}

No struct tags. No encoding/json at runtime. The transpiler generates specialized, typed serialization code.

Functional Collections

GALA ships immutable Array, List, HashMap, TreeMap, HashSet, and TreeSet with full functional APIs:

import . "martianoff/gala/collection_immutable"

val nums = ArrayOf(1, 2, 3, 4, 5)
val doubled = nums.Map((x) => x * 2)
val sum = nums.FoldLeft(0, (acc, x) => acc + x)
val evens = nums.Filter((x) => x % 2 == 0)

// Collect: filter + transform in one pass
val evenDoubled = nums.Collect({ case n if n % 2 == 0 => n * 2 })

Sequence pattern matching works on any collection implementing the Seq interface:

val result = list match {
    case List(head, tail...) => s"First: $head, rest: ${tail.Size()}"
    case _ => "empty"
}

Monadic Error Handling: Try, Either, Future

Try[T] catches panics and wraps them as Failure, enabling railway-oriented programming without if err != nil chains:

val result = Try(() => riskyOperation())
    .Map((v) => v * 2)
    .Recover((e) => 0)

val msg = result match {
    case Success(v) => s"Got: $v"
    case Failure(e) => s"Error: ${e.Error()}"
}

Future[T] provides async computation with familiar monadic operations:

import . "martianoff/gala/concurrent"

val async = FutureApply[int](() => expensiveComputation())
val doubled = async.Map((v) => v * 2)
val value = doubled.Await().GetOrElse(0)

Default Parameters and Named Arguments

Functions support default values and named arguments -- the compiler reorders and injects them at the call site:

func connect(host string, port int = 8080, tls bool = true) Connection {
    // ...
}

connect("localhost")                // port=8080, tls=true
connect("localhost", tls = false)   // port=8080, tls=false

Named arguments also work with struct construction and Copy() method overrides.

String Interpolation

Two forms: s"..." for standard interpolation and f"..." for explicit format control:

val name = "world"
val pi = 3.14159
Println(s"Hello $name")        // Hello world
Println(f"$pi%.2f")            // 3.14

Auto-detected format verbs: %s for strings, %d for ints, %g for floats, %t for bools. No import needed for Println or Print.

22x Faster Compilation

Version 0.24.0 introduced batch transpilation, bringing multi-file package compilation from 44.7 seconds down to 2.7 seconds. The key insight: each file in a package was re-analyzing the entire dependency graph from scratch. Sharing analysis state across files in the same package eliminated the redundancy. See the companion blog post for the full story.

Retry Combinator

Version 0.25.0 added a retry combinator with pluggable backoff strategies:

import . "martianoff/gala/concurrent"

val result = Retry(
    maxRetries = 3,
    backoff = ExponentialBackoff(100),
    fn = () => fetchFromAPI(),
)

Three strategies ship out of the box: ConstantBackoff, ExponentialBackoff, and NoBackoff.

The Standard Library Today

Every standard library module follows the same rules as user code. There are no special cases in the transpiler for std types -- if you can build Option[T], you can build your own monads the same way.

Showcase Projects

Several non-trivial projects have been built with GALA during development:

• GALA Playground (https://gala-playground.fly.dev) -- a web-based editor with live transpilation, deployed on Fly.io
• gala-server -- a 7-file HTTP server package that served as the real-world benchmark for compilation performance
• State Machine -- demonstrating sealed types as state representations with exhaustive transition matching
• Log Analyzer -- a functional pipeline using Try, regex pattern matching, and collection operations

What's Next

GALA is still young. The transpiler handles a broad set of Go interop scenarios, but there are rough edges -- particularly around complex generic type inference across package boundaries. The near-term focus is:

1. Stability -- expanding the type inference regression suite beyond its current 14 cases
2. Cross-package generics -- improving type resolution for external GALA modules
3. IDE support -- GoLand plugin for GALA syntax highlighting and navigation
4. Package registry -- making it easy to publish and consume GALA libraries

If you write Go and have wished for pattern matching, immutability, or proper sum types, give GALA a try. The playground is at https://gala-playground.fly.dev, and the full language specification is in the repository.

The transpiler is honest about what it is: a source-to-source compiler that generates readable Go. When something goes wrong, you can always read the output. That transparency is a feature, not a limitation.