# Release: comrak (CommonMark/GFM compatible parser in Rust)

**URL:** <https://talk.commonmark.org/t/release-comrak-commonmark-gfm-compatible-parser-in-rust/2410>\
**Category:** Implementation\
**Created:** [April 15, 2017, 9:48am UTC](https://talk.commonmark.org/t/release-comrak-commonmark-gfm-compatible-parser-in-rust/2410 "2017-04-15T09:48:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![kivikakk](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/kivikakk/32/3341_2.png) [@kivikakk](https://talk.commonmark.org/u/kivikakk)\
**Post date:** [April 15, 2017, 9:48am UTC](https://talk.commonmark.org/t/release-comrak-commonmark-gfm-compatible-parser-in-rust/2410/1 "2017-04-15T09:48:34Z")

</div>

(Semi-crosspost from [The Rust Programming Language Forum](https://users.rust-lang.org/t/release-comrak-commonmark-gfm-compatible-markdown-parser/10340))

Hi all! I’m [kivikakk](https://github.com/kivikakk), one of the engineers who worked on [GitHub’s transition to CommonMark](https://github.com/blog/2333-a-formal-spec-for-github-flavored-markdown). I’ve also done a lot of work on our fork, [cmark-gfm](https://github.com/github/cmark), of the reference CommonMark implementation [cmark](https://github.com/jgm/cmark).

The work I did there made me interested in pushing CommonMark adoption in general — [pulldown-cmark](https://github.com/google/pulldown-cmark) is great (and fast!), but is currently lagging behind the spec. I did a more or less straight port of cmark-gfm from C to Rust, resulting in [**comrak**](https://github.com/kivikakk/comrak). It’s [available on crates.io](https://crates.io/crates/comrak) now.

The relative advantages of comrak are that it’s based on a 1:1 translation of the reference cmark implementation, meaning upstream spec changes can be translated and adapted with relative ease — the parsing strategy is identical, so the risk of a spec change being difficult to adapt is extremely low. Further, it’s based on the exact code we run in production at GitHub, including the extensions to CommonMark (table/strikethrough/autolink/etc.), so it’s guaranteed to e.g. render your [README.md](http://README.md) the same way we do.

The relative \_dis\_advantage is that it’s a little slower than the competition. Raph reported pulldown-cmark ran faster than cmark in [this discussion](https://users.rust-lang.org/t/new-commonmark-parser/1690) — comrak runs at about 1.9x the runtime of cmark. This still places it immediately behind cmark itself in the [cmark benchmarks](https://github.com/jgm/cmark/blob/12501f1000f592ff67cca98b6733f0bfa3115f9f/benchmarks.md).

I’m also pleased to report that it’s now being used for rendering Markdown in [docs.rs](https://docs.rs) as of [`onur/docs.rs#117`](https://github.com/onur/docs.rs/pull/117)! 🎉

Thanks for reading!

kivikakk

---

<div class="post-metadata">

**Author:** ![jgm](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\
**Post date:** [April 15, 2017, 10:05am UTC](https://talk.commonmark.org/t/release-comrak-commonmark-gfm-compatible-parser-in-rust/2410/2 "2017-04-15T10:05:18Z")

</div>

That’s neat. As I recall, part of the speed of  
pulldown-cmark came from its lack of allocations;  
where cmark creates an AST with strings copied from  
the source document, pulldown-cmark just returns  
offsets into the source document.

So one thought I’ve had for a better implementation  
of cmark would be to have the AST include offsets  
into the source document where it currently has  
raw strings.

This would require quite a few changes, but it’s  
possible rust’s type system would make this easier.

---

<div class="post-metadata">

**Author:** ![kivikakk](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/kivikakk/32/3341_2.png) [@kivikakk](https://talk.commonmark.org/u/kivikakk)\
**Post date:** [April 15, 2017, 10:10am UTC](https://talk.commonmark.org/t/release-comrak-commonmark-gfm-compatible-parser-in-rust/2410/3 "2017-04-15T10:10:30Z")

</div>

> [@jgm](#):
>
> pulldown-cmark just returns offsets into the source document

I’ll have to see how possible it’d be for me to do something similar in comrak!