rustfst

Library Listed

Library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs).

Checked · Sources

Downloads
24,531
Dependents
10
Stars
192
Forks
26
Contributors
20
Commits
1,874
Latest release
1.3.1 ·

About

From the project README ·

Rust
Python

Rust implementation of Weighted Finite States Transducers.

Rustfst is a library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs). Weighted finite-state transducers are automata where each transition has an input label, an output label, and a weight. The more familiar finite-state acceptor is represented as a transducer with each transition's input and output label equal. Finite-state acceptors are used to represent sets of strings (specifically, regular or rational sets); finite-state transducers are used to represent binary relations between pairs of strings (specifically, rational transductions). The weights can be used to represent the cost of taking a particular transition.

Read the full README

FSTs have key applications in speech recognition and synthesis, machine translation, optical character recognition, pattern matching, string processing, machine learning, information extraction and retrieval among others. Often a weighted transducer is used to represent a probabilistic model (e.g., an n-gram model, pronunciation model). FSTs can be optimized by determinization and minimization, models can be applied to hypothesis sets (also represented as automata) or cascaded by finite-state composition, and the best results can be selected by shortest-path algorithms.

fst

Overview

For a basic example see the section below.

Some simple and commonly encountered types of FSTs can be easily created with the macro [fst] or the functions acceptor and transducer.

For more complex cases you will likely start with the VectorFst type, which will be imported in the [prelude] along with most everything else you need. VectorFst<TropicalWeight> corresponds directly to the OpenFST StdVectorFst, and can be used to load its files using read or read_text.

Because "iteration" over an FST can mean many different things, there are a variety of different iterators. To iterate over state IDs you may use states_iter, while to iterate over transitions out of a state, you may use get_trs. Since it is common to iterate over both, this can be done using fst_iter or fst_into_iter. It is also very common to iterate over paths accepted by an FST, which can be done with paths_iter, and as a convenience for generating text, string_paths_iter. Alternately, in the case of a linear FST, you may retrieve the only possible path with decode_linear_fst.

Note that iterating over paths is not the same thing as finding the shortest path or paths, which is done with shortest_path (for a single path) or shortest_path_with_config (for N-shortest paths).

For the complete list of algorithms, see the [algorithms] module.

You may now be wondering, especially if you have previously used such linguist-friendly tools as pyfoma, "what if I just want to transduce some text???" The unfriendly answer is that rustfst is a somewhat lower-level library, designed for implementing things like speech recognizers. The somewhat more helpful answer is that you would do this by constructing an acceptor for your input, which you will compose with a transducer, then project the result to itsoutput, and finally iterate over the paths in the resulting FST.

References

Implementation heavily inspired from Mehryar Mohri's, Cyril Allauzen's and Michael Riley's work :

The API closely resembles that of OpenFST, with some simplifications and changes to make it more idiomatic in Rust, notably the use of Tr instead of Arc. See Differences fromOpenFST for more information.

Example

use anyhow::Result;
use rustfst::prelude::*;
use rustfst::algorithms::determinize::{DeterminizeType, determinize};
use rustfst::algorithms::rm_epsilon::rm_epsilon;

fn main() -> Result<()> {
    // Creates a empty wFST
    let mut fst = VectorFst::<TropicalWeight>::new();

    // Add some states
    let s0 = fst.add_state();
    let s1 = fst.add_state();
    let s2 = fst.add_state();

    // Set s0 as the start state
    fst.set_start(s0)?;

    // Add a transition from s0 to s1
    fst.add_tr(s0, Tr::new(3, 5, 10.0, s1))?;

    // Add a transition from s0 to s2
    fst.add_tr(s0, Tr::new(5, 7, 18.0, s2))?;

    // Set s1 and s2 as final states
    fst.set_final(s1, 31.0)?;
    fst.set_final(s2, 45.0)?;

    // Iter over all the paths in the wFST
    for p in fst.paths_iter() {
         println!("{:?}", p);
    }

    // A lot of operations are available to modify/optimize the FST.
    // Here are a few examples :

    // - Remove useless states.
    connect(&mut fst)?;

    // - Optimize the FST by merging states with the same behaviour.
    minimize(&mut fst)?;

    // - Copy all the input labels in the output.
    project(&mut fst, ProjectType::ProjectInput);

    // - Remove epsilon transitions.
    rm_epsilon(&mut fst)?;

    // - Compute an equivalent FST but deterministic.
    fst = determinize(&fst)?;

    Ok(())
}

Differences from OpenFST

Here is a non-exhaustive list of ways in which Rustfst's API differs from OpenFST:

  • The default epsilon symbol is <eps> and not <epsilon>.
  • Functions and methods follow Rust naming conventions, e.g. add_state rather than AddState, but are otherwise mostly equivalent, except that:
  • Transitions are called Tr and not Arc, because Arc has a rather different and well-established meaning in Rust, and rustfst uses it (std::sync::Arc, that is) to reference-count symbol tables. All associated functions also use tr.
  • Final states are not indicated by a final weight of zero. You can test for finality using is_final, and final_weight returns an [Option]. This requires some care when converting OpenFST code.
  • Transitions can be accessed directly as a slice rather than requiring an iterator.
  • Semiring operations are expressed as plain old methods rather than strange C++ things. So write w1.plus(w2) rather than Plus(w1, w2), for instance.
  • Weights have in-place operations for ⊕ (plus_assign) and ⊗ (times_assign).
  • Most of the type aliases (which would be trait aliases in Rust) such as StdArc, StdFst, and so forth, are missing, but type inference allows us to avoid explicit type arguments in most cases, such as when calling [Tr::new], for instance.
  • State IDs are unsigned, with [NO_STATE_ID] used for a missing value. They are also 32 bits by default (presumably, 4 billion states is enough for most applications). This means you must take care to cast them to [usize] when using them as indices, and vice-versa, preferably checking for overflows
  • Symbol IDs are also unsigned and 32-bits, with [NO_LABEL] used for a missing value.
  • Floating-point weights are not generic, so are always single-precision.

Benchmark with OpenFST

I did a benchmark some time ago on almost every linear fst algorithm and compared the results with OpenFst. You can find the results here :

Spoiler alert: Rustfst is faster on all those algorithms 😅

Documentation

The documentation of the last released version is available here : https://docs.rs/rustfst

Release process

  1. Use the script update_version.sh to update the version of every package.
  2. Push
  3. Push a new tag with the prefix rustfst-v

Example :

./update_version.sh 0.9.1-alpha.6
git commit -am "Release 0.9.1-alpha.6"
git push
git tag -a rustfst-v0.9.1-alpha.6 -m "Release rustfst 0.9.1-alpha.6"  
git push --tags

Optionally, if this is a major release, create a GitHub release in the UI.

Projects contained in this repository

This repository contains two main projects:

  • rustfst is the Rust re-implementation.
    • Crate available on crates.io here
    • Documentation available on docs.rs here
  • rustfst-python is the python binding of rustfst.
    • Package available on Pypi here
    • Documentation available on Github Pages here

License

Licensed under either of

  • Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
  • MIT license (LICENSE-MIT) or http://opensource.org/licenses/MIT)

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Runs on
GPU support unknown
What shows it
  • no dependency or feature matches a backend row
Native code
None found
  • No native code found
Python bindings
No Python binding crate found
License
Apache-2.0 OR MIT

Compare with similar projects

Order: strongest tier first, then most downloads, then name, with unmeasured values last. A library counts downloads over 30 days. An app counts binary downloads per release. An app with none counts its crate downloads over 30 days. ML Rust runs this catalogue, so its closest project always gets a row.

rustfst beside the projects that share a topic with it
ProjectDownloadsDependentsStarsLatest releaseRuns on (GPU)Native codeLicense
rustfst This page Listed

Library for constructing, combining, optimizing, and searching weighted finite-state transducers (FSTs).

24,531 downloads over 30 days 10 192 1.3.1 GPU support unknown No native code found Apache-2.0 OR MIT

Inverse Text Normalization (ITN) — convert spoken-form ASR output to written form

3,608 downloads over 30 days 2 48 0.2.2 GPU support unknown No native code found Apache-2.0
any-tts Listed

A Rust TTS library with Candle backends and runtime adapters for modern open TTS models

3,404 downloads over 30 days 2 23 0.2.0 CUDA, Metal No native code found Apache-2.0 OR MIT
whisrs App Listed

Voice for the Linux desktop: dictation, read-aloud (TTS), and voice-driven LLM commands, with Groq, OpenAI, Deepgram, and local Whisper backends

61 binary downloads per release Not applicable 149 0.2.0 CUDA, Vulkan Binds native code: alsa-sys, mac-notification-sys, wayland-sys (feature overlay), whisper-rs-sys (feature local-whisper) MIT

Rust implementation for the CohereLabs/cohere-transcribe-03-2026 speech-to-text model. Includes a CLI and an OpenAI-compatible API server.

0 downloads over 30 days 0 101 0.1.1 CUDA Binds native code: torch-sys (feature tch-backend). Build uses a native toolchain: cmake Apache-2.0
voxr New

Audio and speech on boostr: compressed-audio decode, resampling, DSP and grapheme to phoneme, with speech synthesis (Kokoro, VITS), voice cloning (VoxCPM2), transcription with word timings (Whisper), voice activity (Silero) and audio-text scoring (CLAP), on CPU or CUDA.

642 downloads over 30 days 2 2 0.9.1 CUDA No native code found Apache-2.0
sherpa-rs Archived

Rust bindings to https://github.com/k2-fsa/sherpa-onnx

9,888 downloads over 30 days 4 313 0.6.8 CUDA Binds native code: sherpa-rs-sys. Build uses a native toolchain: bindgen, cmake MIT
Why ListedNo archive, New or Featured rule places it, so it is Listed.

What it lacks for Featured

  • It has 5 active dependents and 4 new dependents in 365 days. Featured needs 11 active dependents or 9 new dependents in 365 days. The repository route reads 192 stars, 26 forks and 20 contributors. It needs 4,539 stars, 434 forks and 79 contributors together.

What else the check found

  • The last activity is on 21 Apr 2026, 202 days ago. The rules expect an update within 365 days. Dormancy rule

Exact rules: Listed, Featured library. The check on applied thresholds version 9.

Every rule outcome, as the check records it
  • expected-interval: version 1.3.1 base 300, raised to the 365-day floor: E = 365 days
  • dormancy: last activity 2026-04-21, 202 days ago, E = 365: active
  • featured: not featured: active_users 5 < 11 and new_adopters 4 < 9 and repository route stars 192 (needs 4539), forks 26 (needs 434), contributors 20 (needs 79)
  • listed: listed: no archive, new or featured rule applies
Crates2 crates

Measurements and sources

Each signal row shows the raw value, its source and the fetch date. The Sources list gathers every distinct source on this page. Movement needs more history.

Sources6 sources
Adoption5 active dependents, 4 new dependents in 365 days1 not measured
Adoption measurements
SignalValueSourceFetchedCounts
Active dependents5crates.io database dumpYes
New dependents (365 days)4crates.io database dumpYes
Peak active dependents4.5crates.io database dumpYes
Active dependents as a share of the peak1crates.io database dumpYes
Binary downloads per releaseNot measuredYes
MaintenanceLatest human commit: 6 months ago3 not measured
Maintenance measurements
SignalValueSourceFetchedCounts
Latest human commit2026-04-21GitHub repositoryYes
Latest release2026-04-21crates.io database dumpYes
First release2018-10-22crates.io database dumpYes
Latest version1.3.1crates.io database dumpYes
Days the oldest outside issue waits for a reply2119GitHub repositoryYes
Maintainer replies over 365 days7GitHub repositoryYes
Repository archivedfalseGitHub repositoryYes
Repository gonefalseGitHub repositoryYes
Release commit or manifest in the repotruecrates.io packageYes
Published docstruecrates.io database dumpYes
Latest release fails cargo checkNot measuredYes
Build check dateNot measuredYes
Build check toolchainNot measuredYes
SecurityUnpatched vulnerabilities: none
Security measurements
SignalValueSourceFetchedCounts
Unpatched vulnerabilities past the grace windownoneRustSec advisory databaseYes
RustSec unmaintained advisorynoneRustSec advisory databaseYes
Deprecation noticenonecrates.io database dumpYes
Deprecated requirementnonecrates.io database dumpYes
Distribution59 releases, 24,531 downloads over 30 days5 not measured
Distribution measurements
SignalValueSourceFetchedCounts
Releases59crates.io database dumpYes
Downloads over 30 days24531crates.io database dumpYes
Binary downloads over the last 3 releasesNot measuredYes
Homebrew installs on request over 365 daysNot measuredYes
Repology repository familiesNot measuredYes
Docker pull growth over 90 daysNot measuredYes
Docker pulls at the growth baselineNot measuredYes
Every version a prereleasefalsecrates.io database dumpYes
Every version 0.0.xfalsecrates.io database dumpYes
Every version yankedfalsecrates.io database dumpYes
Crate deleted from crates.iofalsecrates.io database dumpYes
Repository192 stars, 26 forks, 20 contributors, 1,874 commits. Stars alone never qualify a project.
Repository measurements
SignalValueSourceFetchedCounts
GitHub stars192GitHub repositoryYes — one part of the repository route
GitHub forks26GitHub repositoryYes — one part of the repository route
Contributors with a GitHub account20GitHub contributorsYes — one part of the repository route
Commits on the default branch1874GitHub repositoryNo
Repository's main crate left out of the entrynonecrates.io database dumpYes
Facts that never count
Facts that never count measurements
SignalValueSourceFetchedCounts
LicenseApache-2.0 OR MITcrates.io database dumpNo
Runs on, from listed crates and their direct dependenciesGPU support unknowncrates.io database dumpNo
What shows each backendno dependency or feature matches a backend rowcrates.io database dumpNo
Native code, from listed crates and their dependenciesNo native code foundcrates.io database dumpNo
Python bindings, from direct dependencies of listed cratesNo Python binding crate foundcrates.io database dumpNo
Crates that depend on a listed crate directly10crates.io database dumpNo

Corrections and review history

Report a correction

No correction applies to this entry.

Judgments

A judgment enters only through an approved issue and a merged pull request.

No judgment applies to this entry.