TOLK about the Future: How Aleksandr Kirsanov Makes TON Blockchain More Accessible for Developers
Aleksandr Kirsanov is a developer with an impressive background and the successor to the development of the KPHP compiler. Now, he joins the TON Core Team, where he is working on TOLK — a next-generation language for writing smart contracts on the TON blockchain. TOLK is designed as an evolution of FunC, introducing familiar syntax similar to TypeScript, but leaving all low-level optimizations untouched.
Created by the Durov brothers, TON is recognized as one of the most advanced blockchains, known for high scalability and a thoughtfully structured architecture. The main language for creating smart contracts — FunC — is a powerful tool but has often been challenging to master due to its unique syntax, especially for developers coming from more widely-used languages.
Aleksandr seeks to address these challenges by creating TOLK, which he announced at The Gateway 2024 in Dubai. TOLK aims to ease the learning curve and make development on TON more accessible to a broad range of developers, all while preserving FunC’s performance advantages. This approach combines TOLK’s simplified syntax with the functional depth and security of FunC, accelerating the development of robust smart contracts.
In our interview, Aleksandr shared his insights on the challenges and potential of FunC, the TOLK development process, and the obstacles he plans to overcome in creating a groundbreaking language for TON.
— What were your professional responsibilities prior to joining the TON Core team?
— I had quite a unique, but very related experience in developing programming languages. I was a leader of KPHP development. KPHP is a language, initially created by Dr. Nikolay Durov and his team. By people who created TON. The purpose of KPHP is to have essential performance to be used in very high-load projects. When Telegram was founded, I maintained KPHP for many years. My goal was to make it comfortable to use by hundreds of developers. I implemented language design, type system, and syntax features. I worked on compiler, runtime, and tooling. Today, millions lines of code are written in KPHP, it's widely used and actively supported.
— What are you working on now at TON Core, and how did your experience lead you to the blockchain field?
— Well, given that I managed to take a language originally created by Dr. Nikolay Durov and his team to a significantly different level, I thought — why not take on another language by the same authors? Only now, on a global scale. That's the foundation on which we connected with the TON Core team. The primary language in TON for writing smart contracts is FunC. Like many things deep within TON, it was designed and coded by Nikolay. Will I be able to apply my past experience here, in TON? We'll see soon enough.
— TON’s ecosystem is partly built on FunC, a language that many developers find challenging to learn and use. What are the main difficulties in working with FunC, and what limitations do you see in its current version?
— Yes, many developers find FunC difficult. But I’d even say the word "difficult" is inaccurate. The right word is "peculiar". You know what FunC stands for, right? No, it's not "funny C", as many believe. It's "Functional C". Well, FunC is for real ninja. If you know Lisp or Haskell, you'll enjoy it. But if you come from JavaScript / Go / Kotlin, here’s where the trouble starts. A lot will seem unfamiliar. And the problem is that this struggle with the syntax can undermine your motivation to dive deeper into TON. However, if you push through, you'll of course understand why everything is done the way it is.
We could, of course, discuss "limitations", but that would be off-topic because it would require us to delve into how it differs from higher-level languages. Here, it's not about that, but about the "challenges", which, in fact, are just the unfamiliarity combined with its low-level nature.
— You decided to create TOLK — a fork of FunC — and work on its improvements. Tell us, what key changes do you plan to make in this version to better adapt it for TON and make developers' lives easier?
— Ah, the fork is interesting. Initially, the idea was just to develop FunC itself. In fact, I even created a large PR for FunC v0.5.0 and drafted a roadmap for things that could be improved in the language, compiler, tooling, and TVM.
And that's when we realised that our goal was to create a language that looks more like mainstream languages than a functional or C language. Keeping all the beauty and complexity inside, without violating Nikolay’s original ideas — while, where possible, breaking down the language barrier and easing the entry point.
So we decided not to touch FunC. We'll leave it as it is, the way it has always been. But we'll make a fork and develop it under a new name. It took me almost two months to come up with the name TOLK. So the immediate goal is to create a more familiar syntax (similar to TypeScript) without changing the core. To remove most of the syntactic traps that unprepared newcomers tend to stumble upon. I’ve made significant progress in this direction by the time of The Gateway.
Oh, I almost forgot. The first release of TOLK will be version v0.6 — a metaphor for the missed FunC v0.5.
— How will TOLK fundamentally differ from KPHP, which you’ve worked with before? What from your experience with KPHP will help you in your current work, and what will be completely new?
— KPHP and TOLK shouldn’t be compared; they exist on different planes. If the former is a high-level language with an integrated runtime designed for real-time request processing in high-load projects with maximum hardware utilization, FunC/TOLK is a low-level domain-specific language targeted at the TVM. Essentially, everything about them is different. Except for the letter K :)
But still, some experience will be reused. Specifically — in understanding what languages are and what they are for. Because I love languages. I'm obsessed with languages. And I make them for myself. I did a lot of coding in PHP and created KPHP to make it easier for myself. Here, once I cover the obvious needs, I also want to dive into the issues around writing asynchronous contracts overall — and how I’d like to see it.
— How will your work on TOLK change the development process for those building applications and decentralised services on TON? Where will developers feel real improvements?
— This question kind of mixes concepts. Language is a small part of a big technology. And "knowing the language" for a developer is just a small part of a big task. Let me explain what I mean. To develop on TON, you need to learn how data is stored, how fees are calculated; what addresses are, and how they are generated; about sharding and the asynchronous nature of TON — basically, all these architectural things. In regular Web2, we spend years learning to design architecture, but when you come to TON, all of this hits you like a ton of bricks.
The language is secondary. It's just a means of expressing thought. And to do that, you need to understand what you want to express :) In all decentralised services, 95% of the work is designing and working outside the code. Just like in high-load applications.
Therefore, real improvements can only be felt by descending to a level where the language actually matters. This is either a routine process (when you already know it, but want it faster) or for beginners (when you don’t know it yet but are trying — most cases in TON). In the first case, semantics are more important; in the second, syntax. Initially, my focus is on the latter. Once we cover the primary pains, it will shift to the former.
(And with a little footnote: everything above remains true until the language begins encapsulating parts of the technology).
It came out a bit philosophical. But okay, looks solid enough :)
— What feedback have you already received from TON developers? What, in your opinion, is the main request from those who want to work with the TON blockchain?
— Given that I worked on TOLK in complete isolation for several months, I received exactly zero feedback :) Well, I'll get it soon enough, and plenty of it.
But let’s talk seriously now. And again, not about the language, but about the entry barrier. This is a major stumbling block for many newcomers to TON.
As a newbie, you'll always make mistakes. It doesn’t matter if it's TON or not. So, it's crucial to guide the newcomer through these errors — so that they understand their cause and how to fix them. Let’s say you call a function with two arguments instead of three — made a mistake —it happens. And if the compiler tells you that you have two arguments instead of three, you'll immediately understand what went wrong. But if the compiler points to a different line and says "type unification error for tensors of different dimensions", you'll just stare at the screen in confusion. FunC often has this issue. Technically, it's correct because the error is indeed there — and a functional programmer would understand right away what's wrong, but most likely, you’ll feel lost.
Or, take TVM as an example. Let’s say I write code, it compiles, and it runs. But I accidentally read 64 bits from a slice instead of 32, which leads to a runtime error. I run the contract and see: "TVM exception 9: cell underflow". And that's it. What does this mean? Where do I look for the error? It's not clear. What I’d really want to see is the line number in the FunC file where it failed, a stack trace showing how control got to that point, etc.
That's why it's important to handle errors comprehensively throughout the user’s journey. TOLK needs to generate human-readable errors (right now, that's mostly not the case, as FunC is running under the hood). We need debug symbols, stack traces in TVM, a debugger to step through code from an IDE, and so on. I understand this well — and I plan to dive into it. Note, this isn’t about the language itself — it's about tooling and the entry barrier. And from my experience with KPHP, that takes just as much time because it's just as important.
This, in fact, is one aspect of "turning technology into a product".
— How do you see the new language interacting with existing tools and libraries for TON? What steps are planned to ensure compatibility?
— Actually, it's pretty simple; I'll answer briefly. Remember, TOLK is "FunC under the hood but looks like TypeScript on the outside". Both TOLK and FunC compile into Fift code (which is later translated into TVM bytecode). So, for the virtual machine itself, it makes absolutely no difference what the contract is written in, as it operates solely on bytecode. You could even write it in Fift if you wanted. I know at least one person who's capable of that. At most, I think it's only one. And everyone knows him :)
As for tooling, we already have:
- blueprint, which supports TOLK alongside FunC and Tact;
- a WASM wrapper called TOLK-JS;
- an extension for VS Code;
- a JetBrains plugin that also supports TOLK alongside other languages;
- and even a converter from FunC to TOLK.
— What's the destiny for FunC?
— We decided not to touch FunC. It remains carved in stone, exactly as Nikolay Durov envisioned it. If there are critical bugs, of course, we'll fix them. But there are no plans for active development. All contracts written in FunC will continue to work, naturally. And it will forever be available to use.
But since TOLK allows you to do the exact same things without the gas overhead (and it should allow this with all future updates), we'll gradually onboard newcomers to TOLK. FunC will soon be deprecated to avoid confusion.
— How do you plan to develop the new language in the future? Do you have a long-term vision of what it should become in a few years?
— This seems like the last question, so let’s summarise what we’ve got so far.
The immediate goals are syntactic. A lot has already been done. Then, there are a few obvious points (type system, compilation errors, stdlib). There are also a few less obvious points (structures with automatic packing into cells, true methods, TL integrations). Work on the entry barrier continues beyond the language itself (TVM, TL/B, plugins, toolchain).
And in one of the responses above, there’s a little footnote, in the style of Isaac Asimov, "everything above holds true until the language begins encapsulating parts of the technology". Under that footnote lie long-term, still somewhat vague, goals. Today, I'll leave it without specifics. Otherwise, I'll make promises here, and then I'll have to follow through :) Although, alright, I guess I have no choice. That's why I'm here.
And on that note! I’d be thrilled to connect with those who have written complex, interconnected contracts in FunC to absorb their pain points (more high-level than syntax) and discuss how things could be done differently.
The TOLK project, launched by Aleksandr Kirsanov, marks a new chapter in the development of the TON ecosystem. Building on his years of experience with high-load systems, Aleksandr is creating a language that brings the TON blockchain closer to developers by removing the barrier of FunC’s peculiar syntax. But it's not just about simplifying the process — TOLK retains the full power of the original language, making it accessible for both newcomers and seasoned experts.
TOLK is already supported by popular development tools and promises a level of flexibility that previously seemed out of reach for a low-level blockchain language. If it accomplishes its goals in the near future, TOLK will create opportunities for more complex and ambitious projects on TON, capable of competing with any solution in Web3.
The demand for a language combining technical depth with ease of learning has been present in TON for a long time, and it seems TOLK is ready to answer that call. So, let’s TOLK.