# Tact manifesto

Authors: cmxog, oleganza.


## Motivation

Fift and FunC programming languages, while powerful and capable languages for building TON smart contracts, lack the expressivity and readability that would lend to broader adoption of TON technologies among software engineers. TL-B, while concise and elegant, is also an entry barrier.

## Goal

Increase number of smart contract developers by 100x by giving them an easy and safe to use language for TON VM.

## Non-goals

* We do not attempt to build a general purpose programming language.
* We are not chasing fast compile times.
* We do not need better/cheaper assembly than FunC already does.
* Infinitely powerful type system and lambda cube.

## Audience

* TypeScript, Go and Rust developers who do not have experience with blockchains.
* Smart contract developers with experience in Solidity.

## Objectives

1. Compatibility with existing TON semantics and data types.
2. Familiar syntax for data types and message handling.
3. Generic and dependent types for precision and safety.
4. Strongly-typed message interfaces.
5. Using Tact as a specification language for collaboration within community.

## Deliverables

* Syntax & compiler
* Standard library
* Documentation
* Publication portal for specs and libraries.

## Selling points

1. Friendly and concise syntax.
2. Structured and type-safe message handlers reflecting actor semantics of TON contracts.
* Separation of data storage and message handling.
* Named and strong-typed message handlers.
3. Language helps with reasoning about fees and rent:
* in TON fees are implicit and have various modes,
* contracts need to send enough $$$ to fund other contracts;
* language may help with explicit declaration of gas requirements.

## Inspiration

Tact takes the best ideas from the number of languages

* Rust: ergonomic syntax for generic types.
* Zig: compile-time code construction and computation.
* Ada: subtypes and constraints.
* Erlang: actors and strongly typed message-passing.
* TypeScript and Swift: mainstream syntax.

## Areas of research

* Syntax and ergonomics: keeping it as approachable as reasonably possible.
* We are targeting JS/TS and Solidity developers.
* Expressive and ergonomic type system
* uniform data serialization framework,
* serialization optimization heuristics (auto layout),
* TL-B compatibility,
* dependent types
* Smart contract entry and exit points ergonomics (handlers and fallbacks)
* Strongly typed interfaces
* Integrated fee estimation / commitment primitives to help reason about rents and fees
* Tact makes gas commitments explicit in interfaces.
* Code reuse
* Tact's stdlib
* Opportunities provided by compile-time code execution (meta programming)
* Optionals,
* enums,
* const generics & constraints
* Language evolution
* Self-contained declarations and versioning
* Education
* Onboarding and progressive documentation: how do we teach Tact/TON?
* Using Tact as a specification language.

## Process

Multiple teams develop contracts for TON. It is important to ensure that the development of the language does not happen in a vacuum.

We need to establish a conversation with the existing teams where we can explore:

* Problem area identification (both research team and development teams initiated)
* Proposal iteration feedback loops so that every significant proposal can be tracked from its development to implementation (an informal RFC process for the sake of expedience)

This can be as simple as a problem statement and RFC discussions on GitHub, followed by iterations of implementation and further feedback collection in Pull Requests, similar to Rust's model and borrowing from some of their practices, while striving for transparency and self-explanatory nature of these interactions ("how do we make decisions? who makes calls? what is happening here?")

## Milestones

### 1. Foundational spec

* Syntax for data types
* Serialization framework
* Syntax for typed messages and interfaces
* Syntax for structured message handling

### 2. Extended spec

* Meta programming and constraints
* Fee/gas and asset safety features
* Interface verisioning and publication
* Data layout and serialization optimizations
* Contract testing framework

### 3. Spec v1

Extract base functionality from the foundational and extended specs.

This will be used in the actual implementation.

### 4. Compiler MVP

Compiler prototype that produces working Fift code.

### 5. Compiler v1

Clean library and CLI for the spec v1.

### 6. Portal for documentation and publication

Growing developer community around Tact early on.

### 7. Spec v2 / Compiler v2

Iterations on language evolution and compiler design.