A new community-built sorting package has landed for Motoko developers, offering a cleaner and faster way to handle ordering logic inside canisters. The library, simply called sort, is now available via mops and brings several well known algorithms together under one roof, with an emphasis on performance and modular design.
The initial release bundles bucket sort, radix sort and merge sort, all implemented for keys of type Nat32. Each algorithm operates directly on VarArray inputs and performs in-place sorting, avoiding unnecessary allocations. According to the benchmarks shared by the contributors, these implementations use fewer instructions and less memory than existing Motoko sorting options, which will matter for developers watching cycle usage closely.
The package reflects a practical split between counting-based and comparison-based approaches. Bucket sort and radix sort rely on keys with bits and are therefore limited to Nat32 for now. Merge sort, while comparison-based, is also currently restricted to Nat32 within this package. The maintainers say support for other key types such as Nat64, Int32, Int64 or Blob is planned, with priorities guided by developer demand.
There is also a wider context worth noting. A related pull request in motoko-core proposes replacing the existing VarArray.sort with a merge sort adapted from this package and rewritten to accept a generic comparison function. That proposal reports roughly double the speed and around half the memory usage compared with the current core implementation. While still under review, it highlights how community work is feeding back into the language itself.
Choosing between the algorithms depends largely on data characteristics. Radix sort offers predictable performance because its running time does not depend on how values are distributed. That makes it suitable when worst case behaviour needs to be tightly controlled, including situations where an adversarial input is possible. Bucket sort, by contrast, tends to run faster when keys are spread fairly evenly, making it attractive for average-case performance when distributions are known in advance. Merge sort sits at the other end of the trade-off, generally slower but using the least memory.
Developers do not need to manage every edge case themselves. Both bucket sort and radix sort automatically fall back to merge sort for small inputs, which simplifies decision-making and reduces the risk of misusing the algorithms.
While the package is still focused on a single key type, its extensible structure leaves room for expansion. For teams building data-heavy canisters, it offers another option to fine-tune performance without reinventing common primitives. At the same time, the benchmarks and proposed core changes will likely invite scrutiny from the wider Motoko community, which is healthy for a tool that aims to become part of everyday development.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
🪙 BTC Wallet: bc1pp5kuez9r2atdmrp4jmu6fxersny4uhnaxyrxau4dg7365je8sy2q9zff6p
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
