1. 40
  1. 38

    I am tired of Rust users claiming their stuff is fast without providing any benchmarks comparing their tools/frameworks with the best-performing alternatives. The first version of https://this-week-in-neovim.org/latest was written in one of these Rust-in-the-browser frameworks (Yew, I think?) and was painfully slow (minutes to load on my computer). Having magic Rust dust in your software does not make it automatically fast.

    1. 18

      There’s a long tradition of claiming to be fast at handling HTTP requests, and I think most people have known for decades that the implementation language is rarely the bottleneck, compared to the data model / database powering it.

      I think a more interesting question is what the recurring pattern (optimizing for nonsensical benchmarks) says about our industry.

      1. 12

        I don’t know. We had a service in Python that was taking a protobuf request with an id, then joining 4-5 tables in mysql and sending the result back as a protobuf.

        Everyone thought mysql was the bottleneck, but it turned out to be cpu because (de)serializing protobuf is slow.

        1. 2

          Historically the Python protobuf libraries are unfortunately slow, mainly because C++ and other statically typed languages are the main use case at google. They just get more attention

          HTTP parsing is pretty much solved in Python, but you can definitely run into very slow libraries here and there

          1. 1

            Protobuf de-/serializing was slow? I mean, it’s Python, so it’s conceivable, but do you have any code/numbers to back that up?

            1. 2

              No, not anymore. It was a year ago and when we realized, I just rewrote it in Rust and that was that (I just checked in on it. It’s serving 30-40k req/min and hasn’t been touched for months. No err logs the last month either).

              I think @andyc is correct though. Parsing protobuf in Python is fairly slow because of lack of love. I forget what we use for it, but looking at the generated Python code I always get a feeling that it’s a bit much. The generated Rust I can read and understand. The generated Python is like 10x and completely impossible to parse for me (granted, Python is not my first language). Certainly not just a class with some typed fields as I would’ve liked.

          2. 4

            I strongly agree.

            Another thing this might cause is caring a lot of application side scalability (Cloud/Kubernetes/…), when the bottleneck tends to be the database or more precisely how it is used.

          3. 6

            I echo this sentiment from a different angle: fast to run is equally important as fast to write. I can throw together a webapp with React because the tooling is top notch and everyone uses it.

            Whenever I try one of these Rust libraries that’s ridden with macros there’s virtually zero feedback loop because the macros are just… macros. Sure, I can write some HTML-like tree structure into the macro and make it feel like React but if I make a typo or pass the wrong type and that’s not immediately obvious, that feedback loop will compound over the days, weeks or months I spend building a product and suddenly the value proposition isn’t as attractive and I’d rather spend a few more CPU cycles than a few hundred more human-hours that I could otherwise use doing fun things away from a computer screen.

            1. 9

              fast to run is equally important as fast to write.

              To me that Depends.

              If it’s just for myself, maybe. If I’m going to subject many people to it, many times, then absolutely not.

              1. 4

                Like everything in the software world, “it depends.”

                I wish I wouldn’t sound like a raving, unobjective, fanboy when I say this, but it’s 100% true: The code I’ve written in Rust tends to have far fewer defects than code I’ve written in other languages, including PHP, Kotlin, Java, JavaScript, TypeScript, and a few others. The amount of time I spend on bug-fixes on my Rust projects is at least an order of magnitude less than the other projects of similar size/scope. Rust saves me human-hours overall– without a doubt.

                Granted, writing async Rust with these frameworks is way more painful than it feels like it should be. I’ll give you that. In fact, every time I want to sit down and write a “middleware” for an Actix-Web project, I end up wanting to pull my hair out. And I also loathe macros 99% of the time.

                Everyone is different, of course, and we have different expertise in different languages and frameworks. But, I’m slow in every language–there’s no way I’m launching anything from scratch in an afternoon or two no matter the language or framework. Some people swear up and down that they can get a “prototype” up in a day or two, and I don’t know if I can honestly believe them because I can’t even usually finish naming my project, setting up a repository, and configuring my linter in a day…

                1. 1

                  Of course it depends, there’s a lot to consider and it’s likely impossible to meaningfully quantify.

                  That initial chunk of time required to get a project going likely pays off in the long run. But there’s also things like hiring and diagnostics to consider, if I can’t find any competent Rust engineers to bring on to a fast-growing product then that’s a real big problem.

                  That being said I am bullish, I think it’ll get there, async Rust will get easier to write and there will be more people in the job market. But in its current state, I wouldn’t pick it for anything other than a side project right now unless it was something that was really the bread and butter of what Rust is great at: low level systems programming (which it’s very good at)

              2. 2

                WASM tax is real. As of now the same code in JavaScript and WASM, JS will win. Also a fast lang can’t escape a poor paradigm.

                I listened to Rustaceans station podcast about Leptos and he talked a bit about why the approach used by yew and others is slower as it fundamentally has to do much more for each change in state.

              3. 9

                I’m using a Rust backend web framework (actix-web), and I really don’t care about the speed because … it’s always the database. What I do like is strong type safety end to end, so I get compile time checking of SQL queries (in fact that shows up in the lsp output as I type!) and templates (IDE integration isn’t as good, but still), which means by the time I’ve compiled there’s whole categories of bugs that don’t exist.

                Downsides: lack of libraries means I had to write some infrastructure myself.

                1. 5

                  I’m using a Rust backend web framework (actix-web), and I really don’t care about the speed because … it’s always the database.

                  Not always. I’ve worked on a couple of simple CRUDy apps where a significant amount of time was spent in JavaScript-land processing and validating incoming data, and then ORMifying it. In one particular case, I was able to increase the request-response cycle on the local network by several times by simply replacing the JS/Node endpoints with ones written in Rust. I initially just did it to see how much Rust web frameworks had matured and whether I’d like it, but when the Rust code actually improved the speed enough that it made a difference to the human users, we migrated the services to Rust for real.

                  1. 3

                    it’s always the database

                    … or, rather, the ORM, which trades constructing giant blobs of SQL in your code for terrible performance with any but the most trivial schema. Unless you’re willing to create ORM code which is at least as complex as the resulting SQL in order to bend it towards performance.

                    1. 3

                      Hear hear! I can’t believe that ORMs are still so popular. Granted, so-called “query builders” have been gaining in popularity over the last several years. But, there’s not nearly enough ORM hate, especially considering how much OOP hate there is- do people not realize they are spiritual siblings? I suspect we’ll collectively be laughing at ORMs in the next decade the way we are laughing at BeanFactoryAdapterVisitorFactory OOP today.

                      ORMs are the worst abstraction. It takes the parts of SQL that are already simple and makes them super-duper-trivial, while making the challenging parts of SQL even more challenging and error-prone. It’s the worst trade-off. And it’s a terribly leaky abstraction even in the good cases.

                    2. 2

                      Coming from Ruby I’m laughing all the way to the bank every time someone scareposts about minimizing heap allocations. If Ruby is fast enough for the web (and I believe it is) Rust is stupid fast enough.

                      1. 2

                        I don’t know who the quote is attributed to, but I remember reading once that “there is not such thing as fast code, just fast enough code.”

                        However, when it comes to “fast enough” for a web server, it obviously depends a whole lot on what we mean by “fast enough”. If “fast enough” means that it responds to the user within X number of milliseconds, then yeah, Ruby or Python or anything else is fine. BUT, what if meeting that goal requires your fancy AWS load balancer to spin up instances and scale out sooner and more frequently than some other language/stack? Does “fast enough” include consideration for our AWS bill? Of course there are competing tensions there, too. Maybe the AWS bill difference is less than the extra cost (salary) of waiting for Rust to compile all day while you work.

                    3. 8

                      Rust does not have a dominant framework at the level of Django or Rails. … Expect to put in a little bit of extra set up work to get started.

                      TBH when I see things like this I wonder if the author has ever used Django or Rails. The difference in how easy it is to set up a simple CRUD app in Rails vs. even JS is still huge. Then add in how easy it is to maintain a Rails app vs. a constellation of Rust libraries and there’s no contest.

                      The page recommends Diesel for an equivalent to ActiveRecord. But Diesel doesn’t even have automatically reversible migrations? And what if I want to store my credentials in an encrypted file. Looks like I have to roll that myself. In Rails I can add a hashed password to my model with literally one line of code: has_secure_password. In the first linked tutorial they roll their own hashing in a dozen lines with a comment that I shouldn’t use this in prod???

                      I love static types and am not a fan of Python or Ruby. But I feel huge cognitive dissonance every time I see totally unsupportable claims about parity with Rails and Django.

                      1. 4

                        As a Rails dev, strong agree.

                        I also worry about the cost of having 10 different libraries that randomly flame out and you have to spend time migrating off one to the other. I’m excited for Rust web dev, but I crave a bit more of a full stack framework solution.

                      2. 7

                        I’ve made a few side projects in rust now and I decided to give it a whirl with a recent web project:

                        What I disliked:

                        * Compilation/reloading.
                        * Traits as API is an extra cognitive tax with libraries.
                        * Stringifying types to make template work undoes type safety.
                        * Strings.
                        * Weirdly I found rust's error messages/suggestions to be frustrating.

                        What I liked:

                        * Type safety.
                        * Just copy a binary and some files to deploy. So nice.

                        At the end of the day I switched to sigh rails (queue “oF CoUrSe RUst iS WRoNg FOr THAT” replies). I just didn’t have enough time to make rust work for this particular project.

                        What I really want is for someone to write a nice framework for Terra. I feel like it hits the sweet spot for a language that would work really well for the web:

                        * small
                        * types
                        * very simple syntax (mostly Lua)
                        * great C interop
                        * static and dynamic (jit) compilation
                        * repl
                        * compile time code (roll your own generics, checks, etc)
                        * speed

                        It doesn’t give you anything that rust does but just throwing it out there to someone who might have more time on their hands.

                        1. 3

                          I’m really enjoying compiling Go to C++ lately (https://github.com/nikki93/gx). Getting the benefits of Go tooling and package system, along with C/C++ interop and portability. Also metaprogramming because hacking on the compiler is easy (it’s about ~1800 lines atm written over Go’s builtin parser and typechecker). It also outputs GLSL because I’m using it for gamedev. Compile times are about one second (both the Go and C++ pass) on my game project.

                          Def kind of just a personal tool and not setting it up for wide use at the moment, but maybe it would give some ideas / inspire for doing something similar. Go is a great starting point I’ve found.

                          1. 1

                            Very cool! I watched your video at the bottom. The edit-compile-run cycle was quite reasonable, and I particularly liked how easy it was to expose component fields to the editor via tags - that was a nice QoL touch.

                            I’m not sure if you’ve already explored it, but one suggestion that might help with debugging C++ compiler failures (and any C/C++ runtime assertions that use __FILE__/__LINE__), is to use the #line directive in the generated code.

                            1. 1

                              Thanks for checking it out! And yeah #line would be useful indeed. Probably a generalization of that is to get sourcemaps in some form so that it works in debuggers too. So far I’ve been fine with looking at the generated C++ because it generates it in formatted / readable form. You can see an example here, with the input code further down below – https://gist.github.com/nikki93/458852c50cd4822f2c9935ce0d41a2bc#file-example-gx-cc-L583.

                          2. 2

                            I’ve been keeping an eye on Terra for many years now, it’s one of the most exciting technologies out there for me along the system-level/high performance programming axis. I wish it were a Terra-like language and not Rust that captured all the C++ refugees.

                            That said, the last time I played with it (a couple of years ago), it felt very experimental. I kept getting segfaults while trying to run examples from the docs etc. To be fair, I was trying to play with its first-class jit features, but still…

                            I’d love to see it get some traction and its rough edges smoothed out.

                            1. 1

                              It’s a small project and it finally hit 1.0 in June. There are some more popular languages that get close to it but ultimately what I’d like is something much simpler which Terra really nails.

                              I wish it were a Terra-like language and not Rust that captured all the C++ refugees.

                              From my experience this seems like the group most actively against using rust. Maybe it’s just gamedevs?

                              1. 1

                                What makes terra good versus other jinja-like template engines? I’ve used it and liked it but have little else to compare to in the rust ecosystem.

                                1. 4

                                  Terra not Tera

                              2. 2

                                I share your frustrations. I absolutely adore Rust, but the web frameworks in particular are painful.

                                As far as your dislikes, compilation and Rust’s string types/APIs are things that are unfortunate and can’t really be helped, considering Rust’s design and use-case goals.

                                But, I tend to agree that Rust devs often times lean too heavily into traits and just having tons and tons of types where it’s not always worth the added cognitive burden. There has to be a decent way to write a low-overhead web framework in/for Rust that isn’t so damn painful to e.g., write a middleware handler for, etc.

                              3. 6

                                I was surprised that Leptos is not mentioned. I haven’t used it myself but there’s a fantastic Rustacean Station podcast interview w its creator Greg Johnston.

                                He spends half the interview summarizing the architectural history of the web and then uses that as a jumping off point to explain the design of Leptos. I found it very compelling and certainly grounded in real world experience.


                                1. 6

                                  With many of the “are we X yet” sites, they can be contributed to with any new projects. I help out with arewegameyet, and we mostly rely on the community to add their new content to it, though we curate some of it ourselves.

                                  In fact, looks like a PR is already up for it! https://github.com/rust-lang/arewewebyet/pull/380

                                  1. 1

                                    Thank you. This makes sense. I did not mean it as any sort of criticism, but I’ll keep that in mind for the future.

                                    1. 3

                                      I had the same reaction FWIW. I loved that episode. Just a random guy absolutely schooling me on web design patterns and he’s not even a full time dev.

                                      I’m on vacation now or would send a PR. Are you able to add leptos to that site, I think it would be an insta merge.

                                2. 6

                                  When will rust community stop begging for adoption?

                                  1. 19

                                    The dynamics is exactly the opposite: a lot of people do web, people want to try Rust => people want to do web in Rust => are we web yet is created as a canned answer for a stream of “how do I do $web_thing in Rust?” question.

                                  2. 3

                                    Wrong wording. Correct one would be “Blazing Fast”.

                                    1. 5

                                      Surely only if it’s some kind of Rust to .NET implementation?

                                    2. 2

                                      they claim that Rocket is production-ready. Is anyone using it in production?

                                      1. 3

                                        https://rust-lang.org for example.

                                        1. 7

                                          I’m not intentionally moving the goalpost here, but I just really don’t know what they mean by “production-ready”.

                                          Assuming this is the right repo: https://github.com/rust-lang/www.rust-lang.org

                                          rust-lang.org requires nightly and performs no database interactions; what data it has is stored in yaml files and loaded into memory. I would expect at the minimum to work with stable. If all they mean by “production-ready” is “well, we put it on the internet”, I don’t think that’s a meaningful signal.

                                          For context, I have a handful of Rocket services at my dayjob and have found it to be a bad experience.

                                          1. 4

                                            At $job we were using it for several fairly high volume/traffic services for quite a while.

                                            We did eventually move off it to warp due to the lack of maintenance/forward movement on the 0.5 release for the last 1.5 years~