TalkTalk is a programming language that looks a little like Swift or Rust. It checks your code before it runs, but tries to figure out most types for you.
This manual starts with small programs and works up to TalkTalk's more unusual features. The language is experimental and still changes quickly. Source files use .tlk, and the command-line tool is called talk.
Start here
- Getting Started
- Syntax
- Values and Types
- Bindings and Functions
- Data and Patterns
- Generics and Protocols
- Effects
- Ownership and Memory
- Collections and Text
- Modules and Packages
- Macros
- Concurrency
- Testing
- The Standard Library
- The Toolchain
- Unsafe Code and Interop
Reference appendices
Reading the examples
TalkTalk source is fenced as tlk; shell commands and terminal sessions are fenced as sh. In a command-only block, every line receives a prompt. A session writes $ before commands and leaves output lines unprefixed. On the website, an ordinary tlk block is editable and runnable. Each runnable block is a complete program unless the text says otherwise.
A block marked norun is displayed as source without interactive controls. It may describe an API boundary, depend on files not shown, or deliberately show only part of a program. A block marked accumulate(name) shares source with earlier blocks in the same named group. Running a later accumulated block also includes those earlier declarations.
Examples normally use the core library, which source files import automatically. A first line of // no-core disables that import for compiler and core-library work. Standard-library modules such as task, fs, and dict still require an explicit use.
Comments after expressions sometimes show expected output or explain a compile-time error. Placeholder text such as ... is explanatory and is not valid TalkTalk unless the surrounding text explicitly defines it.
Shell commands that name repository paths assume the repository root. Commands without paths usually assume the current directory is inside a package. The manual calls out commands that behave differently outside a package.
The language changes quickly. The manual describes the supported source model; editor hover and public declarations in Core or the standard library show the exact current signatures. Compiler implementation documents under docs/ explain design decisions but are not a second language specification.
The short command reference built into the compiler is also useful:
talk llm