Coming from JavaScript

The most visible change, and the one that takes the most adjustment. Every call is [function arg1 arg2], not function(arg1, arg2). No commas, no semicolons, no precedence rules to keep in your head.

; JavaScript: Math.max(a + b, c * d)
; Loon:
[max [+ a b] [* c d]]

The syntax feels foreign for about a day. Then it clicks, and the uniformity starts to feel like a relief. Everything is a function call. No special syntax for operators, no line between methods and functions, one shape everywhere you look.

In JavaScript, const freezes the binding, not the value. You can still push to a const array or set fields on a const object. In Loon, a value is genuinely immutable unless you declare it mut. Data structures hold still. There is no array.push() on an immutable vector; you derive a new vector that carries the extra element.

JavaScript has two kinds of nothing: null and undefined. Loon has none. When a value might be absent, you name that possibility with Option, which is either [Some value] or None. The compiler makes you handle both cases, so Cannot read property of undefined never reaches runtime. That whole family of bugs has nowhere to live.

Coming from JavaScript, this is the least familiar idea. In JS you create objects and the garbage collector reclaims them eventually, on its own schedule. In Loon, each value has exactly one owner, and its memory is freed the moment that owner leaves scope. The compiler manages most of this for you, though now and then a "value moved" error appears when you reach for something already consumed.

JavaScript leans on async/await, which introduces the function-color problem: async functions can only be awaited from other async functions, so async-ness seeps through the whole codebase. In Loon, IO, errors, and concurrency all flow through algebraic effects. No coloring. No Promise chains. No await you forgot to write.

No if (x !== null && x !== undefined) guards salted through your code. Option and pattern matching make absence explicit and compiler-checked. Forget the None case and the code does not compile.

No "" == false surprises. No [1] + [2] quietly becoming "12". Loon is statically typed and converts nothing on your behalf. What you wrote is what runs.

No this, no bind, no arrow-versus-regular-function gotchas. A function is a function. It closes over its environment, and nothing more is asked of you.

No colored functions. No unhandled promise rejections. No await you meant to write. Effects handle concurrency uniformly, and the compiler will not let an unhandled effect slip past.

No TypeError: x is not a function in production at 3am. Every type error is caught at compile time, and you write no annotations to earn it.

Pattern matching folds if/else chains, switch statements, and optional chaining into one construct. You destructure a value, and the compiler checks that every case is handled. No accidental fallthrough, no branch left behind.

[match result
  [Ok value]  [println [str "got: " value]]
  [Err msg]   [println [str "error: " msg]]]

ADTs do the work you split across objects, classes, and TypeScript union types. They define a closed set of variants, each carrying its own data. Think of an enum whose every case can hold fields of its own.

[type Shape
  [Circle Float]
  [Rect Float Float]
  [Point]]

Effects gather callbacks, promises, async/await, and try/catch into one composable mechanism. Think of them as structured side effects the type system tracks and handlers implement. Code that performs an effect never learns how that effect is served, which is precisely why it is easy to test.

Coming from a garbage-collected language, this is the genuinely new idea. A value has one owner and is consumed when passed along. The compiler infers borrows where they are safe, so most of the time it stays out of your way. The curve is real, but far gentler than Rust's, because you never write a lifetime annotation.