We converted Asterisk to Rust

My son and I got a chance to sit down, and he could introduce me properly to AI via Claude. I was impressed. We wrote a simple command-line version of solitaire (actually, we convinced Claude to do this), and Claude generated it in seconds. Wait. How about a windows GUI form? Done. OK, my son typed in, give me a list of 25 desireable upgrades we could perform on this code, and it gave them, which included a top scores list, retract a move or seven, replay those moves, even play music in the background while you play the game. He said, go ahead and implement them. It did, in a few seconds. On my laptop, I played the game. The improvements worked. I was impressed some more. Then it hit me. He seemed to be on a plan that had plenty of tokens. I suggested we do something more challenging… convert Asterisk from C to Rust.

So he commanded it. It complained that Asterisk had 1.6 million lines of code. It was a huge project. Was he serious? Of course he was serious, and he commanded, ā€œProceedā€. It broke up the task into smaller pieces, and it did it. Took some minutes. It self-verified the new code worked, and wrote some of its own tests. Ryan (my son) commanded it to find all the tests. It came up with a thousand tests. He had it ensure that all those tests passed. And to correct the code or the test so it would work. That took a few hours. Then there were the CVE’s active against Asterisk. It displayed a table of all the CVE’s filed, and solved, and half of them were not possible in Rust. Then he had it do a performance comparison between the C and Rust versions. In the SIP processing, it declared with a table, that Rust was 2x to 5x faster than C. It gave a long list of reasons for the performance increase. After thinking about the scope of the project, and the fact that the PJproject code would have to heavily involved in the process, I asked what it had done to the pjproject code. It said, basically, that it had re-written it and didn’t really need the pjproject code. Of course, Asterisk was probably not using a fairly substantial part of pjproject… so, why not just fill in the functions yourself? Well, my son then got going, and had it fully generate a pjproject Rust equivalent, a snap-in replacement for pjproject, with the full API presented, which it did, fairly quickly. Then he had it pull in all the regression tests, and guarantee that every test passed. This took a while longer. A few times, getting late into the evenings, he ran out of tokens, but they renewed the next morning, so we/he kept going. It skipped some channels, some apps, etc. but it gives a fair view of Asterisk in Rust.

Uploaded to Github: GitHub - ryanmurf/asterisk-rs: Asterisk PBX rewritten in Rust — 2-5x faster, memory-safe Ā· GitHub

Now, I won’t even begin to discuss the far-reaching ramifications of what we did. I don’t know how many man-months of coding, debug, and testing were performed in about maybe 3 days by Claude at our request, but my estimate is like at least 2-6 months of by-hand crafting, and my Rust capabilities are very near nil. As far as I can tell, there are possible legal, financial, moral and ethical issues represented here, also economic, social, political, and maybe even religious issues. But also, AI, in my opinion is a tool for the average coder to improve his productivity by who-knows-how-many-hundreds of percent over what he can do without. Especially if you end up trying to maintain old code. I later did an experiment where I converted fail2ban from Python into C and Rust with Gemini, and got it to run 170x faster than the python it is currently available in, with the final numbers like 300,000+ lines of log file sifted for multiple patterns per SECOND, and that again, by the Rust version, fully feature compatible with the current version, reading the same config files, banning and lifting bans as requested, and passing all the regression tests. Sometimes, we need to do experiments, and see what might help our organizations to shave off some CPU cycles from processes running on heavily loaded systems. Sometimes, our packages are written in the wrong language for an operating environment. And, as far as I can tell, Claude and Gemini can handle languages like C, Python, PHP, Rust, Julia, autoconf ansible, and even Wolfram. I’ll wager C++, perl, Ruby, Java, SNOBOL, make, cmake, autoconf, and hundreds of others. Ooooops! I expounded enough.

Enjoy.

You should share these wide-eyed discoveries on /r/Claude instead. You seem very excited.

Interesting but it doesn’t actually run

RUST_BACKTRACE=full sudo -E ./target/release/asterisk -f -c -g
======================================================================
  Asterisk 22.0.0-rs
  An open source telephony toolkit
======================================================================


thread 'main' (1295412) panicked at crates/asterisk-cli/src/main.rs:2067:40:
Cannot block the current thread from within a runtime. This happens because a function attempted to block the current thread while the thread is being used to drive asynchronous tasks.
stack backtrace:
   0:     0x559d5244ab4a - <<std[e28293b1aa0f68bd]::sys::backtrace::BacktraceLock>::print::Display Backtrace as core[c1f1a4ba060b9bfa]::fmt::Display>::fmt
   1:     0x559d5246435a - core[c1f1a4ba060b9bfa]::fmt::write
   2:     0x559d524513c2 - <std[e28293b1aa0f68bd]::sys::stdio::unix::Stderr as std[e28293b1aa0f68bd]::io::Write>::write_fmt
   3:     0x559d524291cf - std[e28293b1aa0f68bd]::panicking::default_hook::{closure#0}
   4:     0x559d524428f1 - std[e28293b1aa0f68bd]::panicking::default_hook
   5:     0x559d52442b6b - std[e28293b1aa0f68bd]::panicking::panic_with_hook
   6:     0x559d52429288 - std[e28293b1aa0f68bd]::panicking::panic_handler::{closure#0}
   7:     0x559d524209e9 - std[e28293b1aa0f68bd]::sys::backtrace::__rust_end_short_backtrace::<std[e28293b1aa0f68bd]::panicking::panic_handler::{closure#0}, !>
   8:     0x559d5242a1cd - __rustc[b7974e8690430dd9]::rust_begin_unwind
   9:     0x559d52464c1c - core[c1f1a4ba060b9bfa]::panicking::panic_fmt
  10:     0x559d52464974 - core[c1f1a4ba060b9bfa]::option::expect_failed
  11:     0x559d51f8681c - tokio::sync::rwlock::RwLock<T>::blocking_read::h69f5f83e5e2d4a4b
  12:     0x559d51fa1463 - tokio::runtime::park::CachedParkThread::block_on::h92647bd0aa90a23a
  13:     0x559d51f5cee5 - tokio::runtime::runtime::Runtime::block_on::h368f225c0a26e2bf
  14:     0x559d51f55f2a - asterisk::main::h784366bfa9464e9a
  15:     0x559d51fa9ce3 - std::sys::backtrace::__rust_begin_short_backtrace::hbf9f1a46a72d6ed6
  16:     0x559d51f9c4b9 - std::rt::lang_start::{{closure}}::h39c463489fccebab
  17:     0x559d524417a4 - std[e28293b1aa0f68bd]::rt::lang_start_internal
  18:     0x559d51f56005 - main
  19:     0x7f5e27c75681 - __libc_start_call_main
  20:     0x7f5e27c75798 - __libc_start_main@@GLIBC_2.34
  21:     0x559d51eee9a5 - _start
  22:                0x0 - <unknown>

Oh, who cares for such trifles, ye of pedestrian concerns and nitpicks. It’s a spray-bukkake avalanche of LLM-generated Rust! How can you not share in the excitement?!

poetry

If you intend to push forward on this in earnest I would suggest renaming the project sooner than later to avoid trademark issues with the Asterisk name.

I tried this about 2 years ago when tokens were cheap and had to build a conversion harness for a long running local process to individually pull in each module and build up in Rust. Called my version Rusterisk, abandoned it after a couple of weeks because the process needed a lot of hand holding, testing and validation. However I still prefer asterisk (albeit with a preference for the cert- versions)

Unless the entire community migrates to some other alternative, I don’t see myself switching out asterisk for some other toolkit.

On Sat, 20 Jun 2026 at 10:17, seanbright <notifications@asterisk.discoursemail.com> wrote:

Someone replied to a topic you are Watching.

seanbright
June 20

WyoMurf:

I suggested we do something more challenging… convert Asterisk from C to Rust

If you intend to push forward on this in earnest I would suggest renaming the project sooner than later to avoid trademark issues with the Asterisk name.


Visit Topic or reply to this email to respond.

You are receiving this because you enabled mailing list mode.

To unsubscribe from these emails, click here.

What a cringelord of a post. Imagine even conceiving running a vibe coded AI slop version of asterisk.

Claude wants real money to do this kind of project nowadays. And the code produced is ugly thus it isn’t supportable unless you use Claude to support it. So you basically end up dependent on Claude and sooner or later the AI is going to write you into a corner that it can’t get out of, and you will have to actually learn how to code in Rust. And you will go screaming into the night trying to understand what the AI generated and why it’s failing.

There’s nothing wrong with the idea of recoding a project from C into Rust. A lot of people are looking into doing this these days. But do not forget Rust as a language was invented for the purpose of keeping human coders from making mistakes that shoot themselves in the foot. the reason companies like Microsoft want to recode Windows from C to Rust is because they want to use cheaper coders who make these kinds of mistakes in C but won’t be allowed to by Rust. They still want the Rust code to be human-readable and human-maintainable.

Rust is a supposed memory safe language, while C is not. However, a properly written AI should be able to write all C code memory safe - thus that removes the point of switching to Rust in the first place. If the goal is to move to AI coding then Rust is unnecessary, and you could have asked Claude ā€œconvert Asterisk from badly written C to better written Cā€ and gotten these gigantic speed benefits you keep attributing to Rust and since the AI would write safe C code all these CVE’s wouldn’t exist in the output, either.

I have found AI to be helpful explaining fixes for older open source projects that are not maintained and throw tons of errors up when an attempt is made to compile them on current gcc which upchucks errors at older code that makes assumptions. It’s handy to be told ā€œok you are missing this header definition which some jackanape moved the function you want out of the normal header it’s existed in since time immemorial to this new definition nobody knows aboutā€ and stuff like that. AI is good for that. Of course, it would be better if people would just stop moving stuff around in new distributions but that ship has sailed.

But I think this effort is nothing more than an effort to throw a rock though a window and it’s kind of sad you didn’t put the effort into improving the current code instead of advocating for replacing it.

100%

Rust is not special. Period. If anything, Rust just promotes lazy programming by taking a lot of responsibility.

One could argue this is how we got in to that mess to start with.

Rust is not any faster than C…it’s not anymore safe. From what I’ve seen…malware written in rust is 1000x more difficult to detect and figure out what it’s doing because the decompiled code is just impossible to read.

I’ve been using Claude for about 10 months. It is quite good at writing code. It’s not great at software engineering. This is a problem…because by giving a repository and saying ā€œconvert this to Rustā€ā€¦it’s going to play that role. It’s not going to do it properly…or the way a human does.

But mostly…there’s no reason. Why do we need everything converted to Rust? It’s not a magic language. It’s been pushed as this magic bullet and it’s not. I remember someone bragging because they wrote a video driver with ā€œno experienceā€ and that ā€œRust was greatā€. Except that person had to have had some low-level knowledge because…a newbie who’s never worked low level was going to get that done.

This is what I tell people who use Claude Code: you probably aren’t qualified to actually use it. If you don’t know how software works…you don’t need to be building with Claude because it will be vibed garbage. By giving it a repo and saying ā€œconvert it to thisā€ā€¦you’ve used it in a way it’s not fully capable. If you give it one prompt and expect an app…then you’re not qualified. You still need to be a bit of a software engineer; you need to have an understanding of how programs work, are built, execute, interact, etc.

No…I don’t think this was a valid use of Claude and I don’t think this is needed. Asterisk does not have memory problems.

just don’t make an incompatible split of an open-source project. language is no reason to fork and lift away that bifurcates the thing. This exists because of the legacy and continuum not the language, fix things here - don’t split.

I 'm not convinced that the original article was true, but to the extent that Claude is able to translate from a language which allows vulnerable code to one that doesn’t, it needs to understand the vulnerabilities in a way in which it could translate into a version in the original language that was also safe.

In particular it needs to understand the real world use of the code, or else it may ā€œfixā€ things in ways the break the code functionally.

C actually became dominant in the face of type safe languages, and a reluctance by managers to allow such low level access to the machine, so languages that protect the coder are not a new thing.

Yes, please do this. Not just from a trademark perspective but from a confusion perspective. Despite a statement that it’s not related to us the name alone can cause confusion.

Glad to hear this, though I disagree. :smiley: I’m sure there’s memory issues around, though substantially reduced from the olden times.

I don’t think we are going to try to do anything with what we did. It was a fun exercise, we will check out the crash that gjoseph reported, tho. I suggested we change the name to something else to Ryan, and he reported that he will.

Dewdude, (and jtayler), I have to agree with you on a lot of your reasoning. The major takeaway is that I’m glad I did the experiment-- it told me that we can get 2x to 5x better sip performance in the Rust version. Now, if I were an Asterisk developer, rather than get distracted about the language involved, etc, I might rather get very interested in WHY this conversion showed that much performance improvement, and wonder how the C code could be modified to raise performance. But, if no-one needs better performance from Asterisk, then hey, it’s a dead issue to start with. At one point, I WAS an asterisk developer, and I did give it a shot at improving performance. Didn’t finish the effort, but I was giving it thought. Claude told us exactly why we got that performance increase. To me, it was worth the effort. I learned something. Maybe, just maybe, some of those points could be fixed in C. Maybe not. But AI might be able to help with even that, I would not be surprised.

An LLM can say many things, it doesn’t mean they’re true or that what it did to accomplish it is actually valid or reasonable in reality. Things have gotten better at not telling lies, but they can still lie. I’m sure I could make the SIP stuff go a lot faster, but at the expense of either actually working, being RFC compliant, or countless other things.

I’ve been working on performance for the past year, quantifying things and improving them:

https://www.asterisk.org/taskpool-a-hunch-turned-performance-improvement/

https://www.asterisk.org/taskpool-pjsip-has-landed/

So I’ve got a pretty good idea of what areas actually have an impact on users. PJSIP isn’t one of them. It’s actually pretty fast, to the degree that you wouldn’t really notice a 2x to 5x performance bump. It would move the needle very little. The areas when it comes to PJSIP where things are felt are generally realtime, and that’s not because of the implementation but generally deployment choices.

Other aspects of Asterisk have a much larger impact and some of those you can only improve to a point because after that point you’re violating how it works for people.

Now… could AI help? Possibly, but so far it’s been iffy at best. What we think, and what it spits out, to improve performance and how much just doesn’t always match reality.

@jcolp same hardware, no config changes, just upgrading to 20.20: 170% more registered extensions, significantly more concurrent channels, and a 20-core CPU holding steady at 10–14 load average under full production traffic realtime included.

This isn’t a synthetic benchmark, this is live production. A year of focused, methodical rewrite in C, no AI shortcuts and the results speak for themselves. The kind of improvement most people assumed wasn’t possible without throwing out the codebase.

If you haven’t upgraded yet, just do it. The numbers will surprise you.

jcolp–

Glad to hear of your work and improvements. benphone’s supporting testimony makes it all very impressive. I am still quite new to AI, and I will take everyone’s observations, and be aware of possible pitfalls. As an addition to the programmer’s toolchest, it can be quite useful at certain tasks, and quite useless at others. Thanks to all for tempering my enthusiasm!!