About this listing
TOLK - Next-Gen FunC for Smart Contracts is a Telegram channel listed on TeleHub. View its description, category, member count, and Telegram join link.
TelehubDive into TOLK, the next-gen language for TON smart contracts! 💻🔥 Following fun syntax like TypeScript, but keepin' it fierce with optimizations. Join us!
TOLK - Next-Gen FunC for Smart Contracts is a Telegram channel listed on TeleHub. View its description, category, member count, and Telegram join link.
Welcome to TOLK lang! 🚀 We're pushing the boundaries of smart contract programming with Tolk — "next-generation FunC" tailored for the TON blockchain. This channel is your go-to spot for updates, releases, and insights into our exciting journey as we evolve this powerful language! Here's a sneak peek at what you can expect: 📅 Recent announcements: Launched at the TON Gateway in Dubai back in November 2024, Tolk forms its groundwork on principles familiar to users of TypeScript while prioritizing effective low-level optimizations. Our latest version v0.7 has just dropped and includes significant improvements: - Refactored compiler internals enhancing semantic analysis 🛠️ - A new static typing system that outshines Hindley-Milner. 🗺️ Big vision: We're charting an ambitious roadmap aimed at making programming more efficient while avoiding tedious manual types and complexity associated with ABI generation. We also provide handy links including documentation 📖, GitHub access 🌐 under ton-blockchain repo, IDE plugins integration 🎮 (TON for JetBrains & Tolk for VS Code), and engaging interviews discussing Tolk’s roadmap. Curious about compiler design or have ideas? Let’s transform those thoughts together! 🤝💡 Join us today — engage in discussions about compilers, smart contracting features, bugs fixing or simply meet fellow developers who share your passion! #TolkLang #SmartContracts
Loading recent Telegram analytics…
TeleHub helps users discover Telegram communities, but users should review each community before joining. Report misleading, unsafe, or inappropriate listings.
Report a listingClick the join button to open TOLK - Next-Gen FunC for Smart Contracts on Telegram.
No, TOLK - Next-Gen FunC for Smart Contracts is not marked as NSFW. Users should still review the community before joining.
TOLK - Next-Gen FunC for Smart Contracts is listed under Programming, Blockchain, Smart Contracts, Developer Community on TeleHub.
Statistics updated October 17, 2026
Post frequency is estimated from the latest 30 stored public posts and may undercount activity.
🫧 Tolk v1.5: break/continue in loops, smarter compiler, and the road to v2.0 This release is not about one big feature. It's about removing a lot of small restrictions left in the language because the compiler simply wasn't ready for them yet. Subtle, sometimes artificial, mostly unnoticeable — while the compiler underneath is getting more mature and complicated. ✅ Notable changes in Tolk v1.5: 1. break/continue in loops — finally for TVM 2. @inline functions with multiple returns 3. Type aliases as directional subtypes 4. Reorganized purity concept and dead-code removal 5. Colorful compilation errors with multiple locations and hints 6. Preparing the kernel for Tolk v2.0 PR on GitHub with detailed info. ✔ break/continue in loops Looks and feels as expected: while (true) { val ch = bytes.loadUint(8); if (ch == 0) { break; } if (blacklisted.exists(ch)) { continue; } bits += 8; } Both work in all loops, including nested ones. The compiler correctly tracks control-flow rejoins, stack layout, and other low-level details. The most interesting part: break is SIMPLER than continue. TVM has machinery with RETALT in loop continuations, but provides nothing to emulate continue. Instead, continue is implemented like another feature that seems to have nothing in common at first glance: ✔ Inline with early/multiple returns Since Tolk v1.0, the compiler supported auto-inlining simple functions, but capitulated on early returns: // not inlined earlier // inlined since Tolk v1.5 fun checkPositive(x: int) { if (x <= 0) { return; // this prevented inlining } ... } Why? Because inlining returns-in-the-middle is hard. Even C++ compilers used to struggle with it. The algorithm I developed transforms a function into if-else chains: fun demo() { if (cond1) { return } if (cond2) { xxx; return } else { yyy } zzz } gets translated to fun demo() { if (cond1) { } else { if (cond2) { xxx } else { yyy; zzz } } } And now the surprise: not fun+return, but loop+continue — works exactly the same way! loop { if (cond1) { continue } if (cond2) { xxx; continue } else { yyy } zzz } gets translated to :) loop { if (cond1) { } else { if (cond2) { xxx } else { yyy; zzz } } } ✔ Much better compilation errors Errors can now point to multiple locations at once — the call site, declaration, type mismatch, inlining failure, and so on. The compiler explains not only where something went wrong, but also why and what actions should be taken. error: too many arguments in call to `calcSum`, expected 2, have 3 --> /some/file.tolk:6:30 | in function main | 6 | return calcSum(100, 200, 300); | ^^^ note: function declared here --> /some/file.tolk:1:5 | 1 | fun calcSum(x: int, y: int) { | ^^^^^^^ And they are now colorful! ✔ A more predictable and mature compiler Bug bounty hunters sent over 200+ tickets, which look lots of my time to analyze — only to turn out to be non-issues. As a result, I had to reconsider some deep questions: - directional subtypes in the type system - user-written code removal by the optimizer - purity concept and @pure keyword You can read more in a traditionally detailed PR. ⚙️ Preparing for Tolk v2.0 This summer, I experimented with a new compiler backend (for Tolk v2.0). That backend will fully replace the old FunC kernel still living with us, and eliminate the need of Fift. These experiments exposed a lot of places where the current compiler is still shaped around the old architecture. 🌳 Tolk v1.5 has removed most of this historical baggage. It was purely internal work — not affecting how you use Tolk today. But it's the part I like the most. It opens the road to Tolk v2.0: a new backend, a new assembler, and direct bytecode generation. This is what I am starting to work on now.
🫧 Introducing new tools beyond smart-contract development In May, we released Tolk v1.4 and Acton — a new toolchain for building and testing TON smart contracts. Since then, we've been working on the next part of the problem. Writing a contract is only the on-chain part of dApp development. Once the contract is ready, you need an environment to work with the network, inspect transactions, verify deployed code, and run E2E scenarios — including the off-chain part. So we've been extending Acton in that direction. 🔍 Actonscan A developer-focused explorer built around Tolk ABI. Messages, get-methods, errors and storage are displayed in human-readable format instead of raw bytes. You can inspect transaction flows, emulate messages, call get-methods, explore storage mutations and network configuration. Actonscan is based on an open-source ABI catalog with 200+ frequently used contracts, so even deployed FunC bytecode can be described through Tolk types. Visit: actonscan.com and the ABI catalog. 🧪 Acton Studio A local workspace for developing the off-chain part of a dApp. Use TON Center and LiteAPI, test off-chain integration and cross-chain bridges, and check that an indexer correctly parses transactions. Two environments are available: Simulator — a fast, controllable local network. Start in 0.1 sec, fork mainnet, modify state of any account, mint jettons, time-travel blockchain.now, create snapshots, and reproduce scenarios locally. Localnet — a real TON network running actual C++ validators, liteservers and APIs in Docker. Both can be used from the CLI, making them suitable for automation, E2E tests, CI, and agents. Studio also provides UI for faucets, an embedded Actonscan, state/blocks/config view, and debugging transactions directly in the browser — for any local environment. Try: acton up and follow the docs. 🔐 TON Verifier revisited The new Verifier connects deployed code back to its source using code hash. It provides the source code, ABI, and source maps. There is no IPFS involved — contract sources are kept on GitHub and served by a dedicated backend. This means an explorer automatically understands a newly deployed contract once it's verified — showing human-readable traces and allowing failed transactions to be debugged step by step directly from the browser. Visit: verifier.ton.org. 🌳 From contracts to dApps Tolk is a language for smart contracts. With its auto-generated ABI, it provides the standard interface for external tools. Acton covers the entire on-chain development lifecycle: testing, debugging, publishing, and everything around the contract itself. Acton Studio extends that workflow to the off-chain layer of dApps — local networks and APIs, snapshots, and E2E integrations. It's the natural next step: not just developing smart contracts, but building the applications around them.
🫧 Tolk v1.4.x: internal progress and maintenance Since the v1.4 release we've published Tolk v1.4.1 and v1.4.2. Most of the work is not visible from the outside: * tightening language semantics * improving diagnostics * handling weird edge cases discovered by fuzzing * and keeping the whole toolchain aligned with ecosystem changes such as the TON → GRAM migration: // before: 50000000 nanotons val amount = ton("0.05"); // now: 50000000 nanograms val amount = grams("0.05"); 🛠️ Our new toolchain — Acton — has also reached several intermediate milestones. It now comes with improved external message testing, BoC contract support, library publishing safeguards, formatter and debugger improvements, and a broad documentation refresh. 🌳 This kind of work rarely makes headlines, but reliability is built exactly this way. Meanwhile, we are also working on a larger update that we'll share soon.