# Tolk vs TL-B (https://docs.ton.org/llms/tolk/from-func/tolk-vs-tlb/content.md)



Experienced developers coming from FunC tend to ask questions like:

* *"What's the analogue of XXX in TL-B?"*
* *"How do I generate a TL-B schema for a Tolk structure?"*
* etc.

Such questions lead in the wrong direction — because the Tolk type system is designed as a replacement for TL-B in smart contracts. There is no need to "provide a TL-B schema for a contract". Every Tolk `struct` is **already** a schema.

## Why TL-B [#why-tl-b]

TL-B is widely used in TON because contracts written in FunC are not declarative. They are low-level imperative programs that manually parse cells and slices.

TL-B exists to compensate for this — to provide a declarative description:

* which inputs are valid,
* what shape is expected,
* how storage is structured, etc.

TL-B is excellent for describing blockchain internals like `block.tlb` — but not for contract APIs or interaction models. All tooling around Tolk will **not** involve TL-B.

## Why Tolk [#why-tolk]

In Tolk, messages and storage are described directly in structs. This description is **exactly** what TL-B used to provide, except that in Tolk it is serialized automatically.

<Callout type="tip">
  ABI and TypeScript wrappers for Tolk can be generated with the [Acton toolchain](https://docs.ton.org/llms/contracts/acton/content.md). Source maps and debugger integration also rely on them. TL-B is not involved in any of these processes.
</Callout>

## Type system differences [#type-system-differences]

The type systems of TL-B and Tolk are **not equivalent**, even if they look similar at first glance.

Similarities include:

* `intN`, `uintN`, `bitsN`
* `Maybe` (nullable), `Either` (a two-component union)
* multiple constructors (declared structs + prefixes + unions)
* cells and typed cells

But the differences are essential.

TL-B supports the following, which is not expressible in Tolk:

* `~tilde`
* `{conditions}`
* dynamic `## n`

Tolk supports the following, which is not expressible in TL-B:

* type aliases
* enums
* inline unions (autogenerated prefix trees)
* tensors
* custom `packToBuilder` and `unpackFromSlice`
* `address?` as "internal or none" (not "maybe T")
* other language improvements, such as namespaces or modules

The page [Overall serialization](https://docs.ton.org/llms/tolk/types/overall-serialization/content.md) describes how each Tolk type relates to TL-B. Notice the presence of imperative serialization rules there, which is fundamentally different from declarative TL-B schemas.