Language overview

Forst extends familiar Go syntax with structural typing, constraints, and narrowing. Most .ft files look like Go. Where they differ, types behave like validated API schemas.

Aligned with Go

Ordinary Forst programs look like Go. A minimal executable is identical on both sides:

Forst
Generated Go

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

// forst build
package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

Use .ft files with the Forst CLI. The plain Go subset builds with go build. Forst extensions transpile to Go for production.

Structural typing

Forst types are defined by shape. Inheritance trees are not used. Function parameters and return values use record syntax:

Forst
Generated Go

type User = {
	name: String,
	email: String,
}

func greet(u: User): String {
	return "Hello, " + u.name
}

// forst build
type User struct {
	name  string
	email string
}

func greet(u User) string {
	return "Hello, " + u.name
}

Anonymous records work at call sites:

Forst
Generated Go

placeOrder({
	stockKeepingUnit: "ITEM-1",
	quantity:         2,
})

// forst build
placeOrder(PlaceOrderInput{
	stockKeepingUnit: "ITEM-1",
	quantity:         2,
})

Explicit where it matters

Forst embraces inference in clear cases (return types, obvious locals) but requires explicit annotations where ambiguity would hurt reliability:

Function parameters always declare types
Struct fields always declare types
Nil initializations need an explicit type

Control flow you can trace

Forst steers away from exceptions and implicit jumps. Errors are values. Validation uses ensure and is. Success and failure paths stay explicit. See Ensure and narrowing and Errors and Result.

Packages and imports

Forst uses Go style packages and import paths. You can also import Go packages and call qualified functions (fmt.Println, etc.). See Go interop for current limits.

File layout in a typical backend

A mixed Forst and Go service often looks like this:

my-service/
├── go.mod
├── handlers/
│   ├── orders.ft      # validated API handlers
│   └── catalog.ft
├── internal/
│   └── legacy.go      # existing Go code
├── ftconfig.json      # generate / dev discovery
└── generated/         # forst generate output (often gitignored)
    └── types.d.ts

Caveats

Forst is not a full Go clone. Several areas are experimental or intentionally different.

No panic / recover / try / catch as language features. Generated Go may still call panicking third party code.
Go import loading is partial. See Mix with Go packages § Caveats.
Validation and narrowing have real limits. See Shapes and constraints, Ensure and narrowing, and Errors and Result.

Shapes and constraints

Types as schemas with validation and less boilerplate.

Ensure and narrowing

Runtime checks tied to the type system.

Providers (DI)

Declare shared services with use and wire them at entry points.

Overview

Getting started

Data validation

Behavior

Interop

Workflow

Language overview

Aligned with Go

Structural typing

Explicit where it matters

Control flow you can trace

Packages and imports

File layout in a typical backend

Caveats

What to read next

Shapes and constraints

Ensure and narrowing

Providers (DI)

​Aligned with Go

​Structural typing

​Explicit where it matters

​Control flow you can trace

​Packages and imports

​File layout in a typical backend

​Caveats

​What to read next

Shapes and constraints

Ensure and narrowing

Providers (DI)

Aligned with Go

Structural typing

Explicit where it matters

Control flow you can trace

Packages and imports

File layout in a typical backend

Caveats

What to read next