Is this a new service built from scratch in Actix, or did you migrate the service from something else?

Do you have any performance numbers, or a prior version of this service to compare it to? I'm curious how async in Rust compares to synchronous code in real-world applications, especially given its yet-incomplete state.

Have you tried to create a more complex web page and have the web frameworks render that as well? Sometimes being the fastest at the most trivial request isn't enough, if it can't handle complex request fast as well.

Also, do you have a list of speeds for the frameworks you've tested?

To explain this to people who don't know the background - this is about 'impl NameOfTrait' in the return position.

It allows functions to return an object that provides a certain interface without specifying the actual type of that object. This was only previously true by wrapping it in a 'box', which meant a heap allocation and dynamic dispatch. The 'impl trait' provides static dispatch and no other overhead, so produces equivalent code to returning the type directly, but with all the abstraction flexibility that you want.

we use actix. but that is all i can share :)

What motivated you to move away from Rocket (just curious, I've only used Iron)?

I feel like Let It Crash and Fail Fast make a lot of sense in a dynamically typed language where, if you were to go ahead and code defensively and try to make assumptions about where your program could possible fail, you'll end up with a bunch of redundant error code and will probably have written error handling for places where the program might not have ever crashed. Rust's Result type makes sections where an error can occur pretty explicit, so I'm not sure it makes sense to follow the same methodology. I'm interested to hear what other people think.

first, you need to define what is crash in rust means. panic or error. in general case you can not recover from panic. in case of error, type system prevents unhanded errors in actors. you can restart actor, but that is controlled by developer action.

Ought to be good, site was designed by the creator of Flask :)

5MB is nothing compared to what you'd use for a similar project in node or Python or Ruby. Sure, it's not the tiniest it could be, but using tools like strip, not including debug symbols etc it gets pretty damn small. Honestly though, at that point I think size becomes entirely pointless to even mention unless you need to run it in a super constrained environment, which you're probably not when you're using the standard library :)

> I have just started playing with Actix-web. Rust-Noob as well. The yellow world example compiled to a binary that was ~ 5 MB.

I've only played around with Rust a bit, but IMO, as a general rule: don't judge back-end frameworks by the size of the deliveries, unless we're talking about something ridiculous (5GB). It's extremely superficial and has a very low correlation with the quality of the actual tool.

> The yellow [sic] world example compiled to a binary that was ~ 5 MB.

See: "Why are Rust executables so huge"

https://stackoverflow.com/questions/29008127/why-are-rust-ex...

Wanted to do the same exact thing! Is it public?

Actors are generally a very powerful abstraction.

To give a specific example: they can be used to mediate access to a resource without requiring complex synchronisation: instead of sharing a piece of mutable state (like a cache) and protecting it with a lock, you can ensure a single actor accesses the cache, and other code communicates with that actor.

This is particularly useful with asynchronous code, because it's not possible to have a fair, asynchronous "passive" mutex without suffering from the thundering-herd problem. If you try to implement such a mutex, you will find yourself needing to queue up lock requests and responses, and you will end up reinventing the concept of an actor.

I started using Scala for Play and Akka and I'm currently using Akka[1] in production in many projects.

[1]: http://akka.io/ Akka is the implementation of the Actor Model on the JVM.

Funny, I'm learning Scala for work after teaching myself Rust. It's definitely made the whole process a lot more straightforward thanks to the commonalities between them.

That's a good question, and something that's not always obvious without having been in a situation to get advantage from such an improvement.

First, even if waiting for a response from the database is the largest single contributor to your response time, and if you're running an extremely low-traffic service, there's still benefit in reducing your total latency

Second, if you're not running a low-traffic service, and have enough requests that you're approaching the memory or cpu capacity of your web server (or have an existing application that's already deployed across multiple servers), making significant reduction in your CPU or memory use can let you handle quite a bit more traffic with less hardware.

Third, not all web services involve little more than making a request to a single external slow database. The data for your service could be: * Static * Ephemeral, kept in-process * In a database on the same server * In a fast database (memcache) * Require nontrivial processing * Processed by a separate service you're just acting as a proxy for

That's only true for certain workloads and applications.

Many modern databases are very fast and many modern web servers are very slow. I've run into many applications where database performance was not the bottleneck.

Even with an opinionated type system, it's possible to slack off a bit. There are different degrees of strictness/specificity when composing types.

Most projects use buzzwords like that though.

- Safe! - Blazing fast! - Powerful! - Elegant! - Shiny! - Modern!

You know, marketing stuff that tells you absolutely nothing about the software itself but is required to fill space on a website.

The thing is, a boring "Benchmarks" heading in the README doesn't get you as many GitHub stars as a "Blazingly fast!" heading+icon. And you know how addictive Internet Points can be.

A few devs are over enthusiast and missed the 80/90's wave of safe systems languages.

Hi urschrei, I naively tried to port turf to Rust, but from my past experience [0] and flaky time commitment in the past; I thought it'd be too much to do alone.

I've seen georust, and it's on my backlog. There's a few functions that I saw missing (that I actively use). With mentorship, I'd love to contribute them. I'll open some issues and introduce myself in the coming days.

[0] https://github.com/nevi-me/turf-kotlin

Hey by the way the link in the readme to the documentation is broken. It points here https://docs.rs/geo/0.9.1/geo/

I would like to join so that I would be mentored . So, where do I start ?

I run a public transport website that includes a few mobile apps. I've broken it down into quite a few microservices, but the bulk of it runs on Node and JVM.

I have a 64GB RAM, 12 core server, and the JVM services take up about 25% of resident RAM (ignoring Kafka and other Java stuff).

I've wanted to learn Rust for a while, so I recently bit the bullet. I use gRPC everywhere (Dart/Flutter, Node, JVM, Python), so I decided to start by rewriting some small services in Rust using gRPC for comms.

For now, I've taken a Java service that used 500MB at peak, to under 10MB RAM. I'm planning on eating into the big stuff over the coming months.

It's not making money, so it's a "hobby" yes. Consulting's paying the bills so I don't mind at this point.

EDIT:

E.g. here's an url shortener gRPC server that runs on NodeJS, and a Rust client that can shorten urls and get results back.

https://github.com/MovingGauteng/shorty

https://github.com/MovingGauteng/rust-grpc-shorty

To supplement the other sibling question that I answered:

It's a learning experience. Right now, I can't port everything to Rust, because each platform has its advantages. Rust is still missing a lot of libs that exist in NPM and Maven, so it makes it difficult.

I've been exploring exposing some functions that exist in Java/Kotlin through gRPC (as everything runs on the same network anyways) until it's available on Rust.

I hope to blog about my experiences in the coming days/weeks.

Any chance you could elaborate on this, because I dont really understand how it answers my original question.

I have not checked recently, but last I saw, the database libraries for rust did not use async IO. Looking at (what I presume is) the code for the benchmark [1], it seems it imports the postgres and diesel crates. Last I heard diesel did not support async [2] and looking at the postgres crate [3] it does not mention async, which I assume it would in case it was supported.

My whole point was that, sure, I can see how async IO is important for handling many concurrent http requests, but each of those requests would still have to pass through the synchronous database driver which uses threadpooling, right? Or what am I missing here? I can see how it has great performance on the plaintext and json benchamrks, but I dont understand what gives it such a large boost in fortunes or multiple queries.

For example, Iron is doing 300k at plaintext/json benchmarks, but drops to 18k on fortunes, and the way I remember the benchmark code it is written in a fairly straight forward way. If the database layer supported 160k requests per second I dont see why we would see such a huge drop? (Edit: 160k is the performance of Actix on fortunes.)

I also recall seeing numbers on the 10k order of magnitude from doing naive benchmarks with the various database libraries available, without any http part to the application. But I'm not sure, maybe I'm missing something or remember incorrectly?

[1]: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

[2]: https://github.com/diesel-rs/diesel/issues/399

[3]: https://crates.io/crates/postgres

I tried out actix-web and to be fair I'm not very fluent in Rust yet, so I had a similar experience of not being able to figure out some things readily enough.

So as a result I've opted to using D instead for my current project, I've been able to get more figured out with Vibe.d in shorter time so I'll likely stick to D for this project due to time being a factor against me.

I've done a simple hobby project in Rocket and ported to Actix.

I'm not experienced with web services and my project was very limited for learning purposes, here my take away:

I like both and for me Rocket was way more ergonomic for creating routes dealing as if they're simple functions where input and output are dealt automatically with (from request and to response).

Actix advantage is actors and is easy to be fully async, I had some issues dealing with it but most of my troubles were extracting request data and building responses.

When actix-web will support magic as Rocket (once proc-macros becomes stable) then actix-web will have the edge if Rocket don't become async-ready and stable before.

For both it is only question of missing stable rust features and actix-web is already running on stable.

actix-web: - easy - async - stable

Rocket: - stupidly easy - sync - nightly

I also recently just finished porting a side project of my own from Rocket to Actix. I'm absolutely loving Actix so far!

Other than Rocket being nightly, the other reason I switched to Actix was because Rocket doesn't have the ability to respond to requests directly within the middleware layer, you can only modify the response but not return early. This is pretty important with regards to CORS and trying to catch all OPTIONS requests. There are a few solutions of course, but all of them felt hacky or verbose.

I have no complaints with Actix yet.

i think from ergonomics standpoint, actix is very close to rocket. of course rocket has some advantage, but actix compiles on stable and has zero codegen code. as soon as proc macro stabilizes both will be on par.

from performance perspective, actix is faster than rocket on any type of load.

We've got some stuff in the pipeline that should relax that requirement. It plus async/await (which has a PR open in the compiler) should make all of this way easier.

Rocket should be usable on stable this year, but is nightly only for now.

"unwrap" doesn't mean "panic". It means "to take out of some kind of container". So, the question is, what to do if the thing isn't in the container?

    unwrap: panic
    unwrap_or: produce this value instead
    unwrap_or_else: produce a value by running this closure instead
    unwrap_or_default: produce a default value instead

or and or_else are just like unwrap_or and unwrap_or_else, but they don't do the unwrapping; you keep the container.

In this case, the "container" is option, but similar types have the same methods, like Result.

> Why couldn't it just be .or() or perhaps .default()?

or returns Option<T>, unwrap_or returns T. .default returns the default value for a T already.

TL;DR: you have a lot of options (pun intended, sorry!) with what to do, but the names all follow a quite regular scheme.

The "unwrap" is referring to getting a plain T out of a Foo<T> container: all of those "unwrap" functions return a plain T.

One way to look at them is "unwrap", "or" and "or_else" are building blocks that have a common meaning across the different examples:

- unwrap: returns a plain T

- or: the left-hand side, unless it is a "failure", then use the argument value

- or_else: the left-hand side, unless it is a "failure", then use the argument function to create the value

For prefixes, unwrap mean Option<T> -> T while or means Option<T> -> Option<T>[0].

For suffixes, "else" means executable code (a closure).

> > It's as if the .unwrap() that is festooned throughout such example Rust code has become so ubiquitous that someone felt it had to be used and so tacked on "_or". Why couldn't it just be .or() or perhaps .default()?

Because Rust doesn't have function overloading and thus you'd be missing most of the cases?

[0] or more generally Wrapper<T> -> T and Wrapper<T> -> Wrapper<T>

Learn about the Option type: https://en.wikipedia.org/wiki/Option_type