Our great sponsors
-
sqlx
🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite. (by launchbadge)
-
ripgrep
ripgrep recursively searches directories for a regex pattern while respecting your gitignore
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
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.
[0]: https://github.com/launchbadge/sqlx
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, https://github.com/BurntSushi/ripgrep/blob/master/crates/sea...
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.
[0]https://www.techempower.com/benchmarks/
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.
[1]: https://puzzlepanda.com
[2]: https://github.com/jakedeichert/mask
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).
[0] https://crates.io/crates/structopt
[1] https://yew.rs/
Admittedly I work for a very opinionated team - we even have our own style guidelines (https://github.com/G-Research/fsharp-formatting-conventions) 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.
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: https://github.com/lunatic-solutions/lunatic
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] - https://sr.ht/~pierrenn/ripgrep/
[2] - https://github.com/intel/hyperscan
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."
https://github.com/rust-lang/foundation-faq-2020/blob/main/F...
While not official, there is at least one or two Amazonians working on https://github.com/rusoto/rusoto which is a pretty great Rust AWS SDK.
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 :)
[1]: https://github.com/sfackler/rust-postgres
[2]: https://twitter.com/jakedeichert/status/1205230350160539650