Rust Foundation: Hello, World

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • OPS - Build and Run Open Source Unikernels
  • SonarLint - Deliver Cleaner and Safer Code - Right in Your IDE of Choice!
  • Scout APM - Less time debugging, more time building
  • GitHub repo sqlx

    🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, SQLite, and MSSQL. (by launchbadge)

    hmm, no. While compile-time type check[0] for SQL queries changes your whole experience of how you do SQL, at the end of the day creating an webapp in rust is not as easy or mature as any of the other languages more suited for the task. If you want to learn, then its fine. But if you are newish to rust and want to do your next CRUD app at work in rust, I don't think its going to a good experience.


  • GitHub repo ripgrep

    ripgrep recursively searches directories for a regex pattern while respecting your gitignore

    ripgrep's src/ contain both library code and unit tests. The grep source code appears to use different tests/ and src/ directories.

    ripgre's source code files appear to be between 1/3 and 1/2 unit tests, in the few samples I checked. For example,

  • OPS

    OPS - Build and Run Open Source Unikernels. Quickly and easily build and deploy open source unikernels in tens of seconds. Deploy in any language to any cloud.

  • GitHub repo

    website for Rust Foundation

  • GitHub repo FrameworkBenchmarks

    Source for the TechEmpower Framework Benchmarks project

    actix-web seems really interesting, just from some cursory reading. Also, from a performance standpoint, it seems to be _really_ good.[0]

    I have no experience in Rust whatsoever, but I feel inspired to try it out.


  • GitHub repo mask

    🎭 A CLI task runner defined by a simple markdown file

    I mentioned elsewhere in this thread that I built a jigsaw puzzle website [1] with a Rust API backend and I launched it last week. It definitely took longer than if I had used Node, but I enjoy working with Rust much more.

    Apart from that website, I have also open sourced a Rust CLI task runner [2] which uses markdown files as a command definition format. This is probably the most important tool I've ever written, as I have used it every single day since.



  • GitHub repo structopt

    Parse command line arguments by defining a struct.

    I've used Rust to write a couple of personal projects: a compiler for a language I've designed (it's really good for that because of its great ADT and pattern matching support) and a small CLI which I wanted to be very fast. Rust is great for that. The `structopt`[0] crate makes writing CLIs almost as easy as on a high level language.

    The other project is a web app and I use Rust to compile to WASM. Because I had to use several web APIs (DOM, WebCrypto) I used the JS interop heavily, and that's still very painful to use if you use the low-level interop (js-sys and web-sys)... however, I am aware of several efforts in this area, like Yew[1], which should make things better.

    The language is very hard to learn, but once you get past a certain threshold (depending on what you know already, that may take weeks to several months) it's really nice to use (though certain things are still hard to write because managing lifetimes can be very tricky).



  • GitHub repo fsharp-formatting-conventions

    G-Research F# code formatting guidelines

    Admittedly I work for a very opinionated team - we even have our own style guidelines ( which are often in direct contradiction to Microsoft's, and my team strongly skews towards writing explicit type annotations on all function signatures. I can certainly see how there would be a problem if one defaulted to omitting type annotations.

  • SonarLint

    Deliver Cleaner and Safer Code - Right in Your IDE of Choice!. SonarLint is a free and open source IDE extension that identifies and catches bugs and vulnerabilities as you code, directly in the IDE. Install from your favorite IDE marketplace today.

  • GitHub repo lunatic

    Lunatic is an Erlang-inspired runtime for WebAssembly

    You are right, but this project, or a similar one, who uses WASM based rust nano processes has the potential to leave Go and Erlang in the dust:

  • GitHub repo hyperscan

    High-performance regular expression matching library

    ripgrep author here.

    No, you're trolling because you're being disingenuous and unnecessarily inflammatory. Your LOC counting, in particular, radically misses the mark for a number of reasons.

    Firstly, as others have pointed out, the features in GNU grep and ripgrep are radically different. GNU grep, for example, doesn't have anything that the `ignore` crate provides. So on this point alone, a simple LOC comparison falls flat. For example, does more lines of code imply that code complexity is higher? Not necessarily. Try reading and understanding the code itself. Obviously I'm biased, but I think folks would have an easier time with ripgrep than with GNU grep.

    Secondly, ripgrep does a lot more than GNU grep does in order to make more searches faster. This ranges from parallelism, to differing search strategies (mmap vs standard read calls) to pattern analysis for better literal optimizations and more involved SIMD algorithms and better performance in the face of Unicode. (In addition to supporting a lot more of Unicode than GNU grep does.)

    Thirdly, the way in which you counted lines is weirdly arbitrary. For example, GNU grep uses a lot of code from gnulib, including but not limited to, an entire regex engine. (It used to be part of GNU grep proper, so if you had done this analysis a few years ago, your LOC count would be at least double than what you came up with.)

    Fourthly, I made a decision to make a lot of ripgrep's internals generic over both the regex engine and the search strategy. This was to make it possible for others to use those libraries, but also to make it easier to support plugging other regex engines into ripgrep. The official ripgrep distribution, for example, comes with both Rust's regex engine and PCRE2. But it goes beyond that. Someone even maintains a fork of ripgrep[1] that uses Hyperscan[2] to make it faster in some cases. The fact that this is even plausible to do is only because much of ripgrep's core is, in fact, generic. Making things generic tends to require more code and more complexity.

    Fifthly, your LOC counts include a ton of tests, where as your GNU grep LOC count presumably does not. For example, about half the LOC in the `printer` crate are tests. And that's just at a library level. Does GNU grep even have library level tests at all? A cursory glance suggests it does not.

    There are probably more reasons why your comparison falls flat, but this is what I could come up with quickly before going to bed. Your analysis is shallow, and the lack of self-awareness of this fact combined with your inflammatory marks and seeming certainty are why you are a troll.

    [1] -

    [2] -

  • GitHub repo foundation-faq-2020

    Have questions on the Rust Foundation? Ask here!

    They have an unhelpfully generic answer to that in their FAQ: "After spending a significant amount of time researching potential umbrella organizations, we decided that our best option was to incorporate an independent entity. Rust is a technology and community that is value driven and we simply didn’t find an organization that we felt was aligned with our community goals. This does mean more work for us, especially upfront, but we think the tradeoff is worth it."

  • GitHub repo Rusoto

    AWS SDK for Rust

    While not official, there is at least one or two Amazonians working on which is a pretty great Rust AWS SDK.

  • GitHub repo rust-postgres

    Native PostgreSQL driver for the Rust programming language

    I just launched a jigsaw puzzle website last week that has a backend API written in Rust and uses the postgres crate [1].

    Since this is a side project for me, there wasn't much risk if it ended up being a bad decision. Multiple times throughout the project I got frustrated with the DX of existing http frameworks I tried and ended up building my own [2] on top of hyper. However, after launching my site and seeing how it performs in production, I could not be happier with the result! I had a bit of Rust experience before the project but learned a lot more through building this.

    For you and others, I think it really depends on the situation. Building a Rust CRUD app will likely take longer than the other languages you're used to as the ecosystem is under heavy development, especially with async/await. So if you or your team are in a rush, I'll just echo that you should build with the tools you already know. If you have time and budget to experiment like I did, it might be worthwhile and I can promise it will be fun :)



NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts