
Actix Web 3.0 - lukastyrychtr
https://paper.dropbox.com/published/Announcing-Actix-Web-v3.0-QOXXb1lXgTubzXHzUq9ONY5
======
nik_s
Congrats on the release! Actix is super exciting, and it's great to see how
the community stepped up to maintain this amazing project.

Is there any effort to bring a Rails/Django like framework to Rust? AWWY [1]
seems to indicate that there isn't anything like it in the Rust ecosystem, but
I'd be curious to know if there's anyone working on something in that
direction. All of the frameworks I've seen seem pretty "bare-bones" by the
standards of Django/Rails (then again - it's hard to beat these frameworks in
terms of feature-completeness).

[1] [https://www.arewewebyet.org/](https://www.arewewebyet.org/)

~~~
trumpeta
Personally,I strongly prefer light libraries over comprehensive frameworks.
Yes, you have to build up your app, but at least you understand what you're
doing. And when something goes wrong you know how to fix it. You can follow
the code. This is super hard with a framework like Django.

~~~
nik_s
I totally understand the sentiment, and generally, when I do solo projects or
projects with small teams, I also prefer light frameworks.

In my experience, frameworks like Django and Rails shine when you have to
collaborate with large teams on solutions though - the fact that there's
comprehensive documentation, best practices, and clear standards make it so
much easier to work together on a project. I do think Rust brings a lot of
assets through its type systems when collaborating, but rolling your own
auth/admin dashboard/orm is a hefty investment for most mid-size companies.

~~~
pmontra
I agree. Admin can be complicated but the breadth of authentication is
surprising when you start enumerating the features. "I forgot my password" and
"remember me" are the easiest ones and yet they're not a hour's job.
Authentication is not where a company should invest its money. Use a well
proven library and keep solving problems that bring home money.

------
arusahni
Unfortunately, there are readability issues in dark mode (Firefox, MacOS) -
inline code blocks are unreadable. To fix the issue, run the following in the
browser console:

    
    
        $$("html")[0].classList.remove("paper-noir")

------
svnpenn
Anyone else getting this annoying jerking fixed menu at the top when
scrolling?

Why do people insist on doing fixed menu bars? Does anyone like them? I don't
think I have ever used a website where it improved the experience. Phones have
had reactive scrolling for years, so a quick flick and you're at the top. So I
don't even know what problem they're trying to solve.

~~~
dgb23
I feel you. Fixed position elements are really an anti-pattern in many cases.
This includes fixed "back to top" buttons and the like. They just clutter up
space and distract from content.

~~~
svnpenn
I mean, even a small “back to top” in the bottom right corner, would be better
than a fixed menu at the top. At least with that, its not taking up screen
height. _Phone screens are small_ , stop putting stuff in the way that’s not
needed.

------
ibraheemdev
Is it true that actix-web doesn't actually use the actix actor framework
anymore? I see it listed as a dependency in "actix_web_actors", but it doesn't
seem to be used internally...

~~~
nazka
Yes, the new core is now faster than ever. I think they said that actors are
awesome but that at this level, for this use case, it was better to start a
new design.

They kept the name actif-web with actix in it because it was already quite
established and they didn’t wanted to start from zero.

You can still use actix in your projet. It’s still actively maintained.

------
slezyr
Was it actix-web whose Git repo was removed during the brawl with the
developer?

How it was resolved?

~~~
atemerev
Bullying open-source developers is not exactly the best course of action if
one aims for the better adoption of a particular project. It is good that the
situation was somewhat resolved, but I still feel sorry for the original
developer, and I am not sure if I would want to use Actix after "the
community" (at least some awful parts of it) did such outrageous things to the
developer.

~~~
turbinerneiter
The "Community" that harassed the developer is probably not the same community
that now works on the code.

These mofos from Reddit who storm a GitLab ticket after it was posted there
usually do not actually contribute to Open Source projects. They are pseudos
who run their mouth but don't do the work. They are the ones who set up the
wiki, but never write a single line of code.

~~~
gnur
Honestly, the ones that set up a wiki but not the code are at least as
valuable as the ones writing the code.

~~~
throwaway744678
At _most_ as valuable. A Wiki without any code doesn't bring much value.

------
Zealotux
Web developer currently learning Rust and curious about Actix Web here: how
does it compare to let's say Node.Js in regard to performance and security?
Any feedback on real-world projects to give?

~~~
golergka
NodeJS is my primary stack, and I've built toy projects with Rust since 2014,
but never used it in production.

Rust offers perfomance improvements in CPU and memory usage of the core
application logic, and it's almost never the bottleneck for the typical web
apps. Almost always, they're limited by IO, and I don't see any reasons why it
would be better on Rust that on Node. Also, Rust offers security of safe
access to memory, but that's a problem that exists in C and C++, not in GC-
based languages. Finally, Rust offers a great type system, but Typescript has
a very good one as well, and offers a much easier transition for Javascript
Node developers, as well as a much more machure NPM ecosystem.

Overall, I just don't see how Rust would make much of an improvement over
existing state of affairs.

~~~
staticassertion
> Rust offers perfomance improvements in CPU and memory usage of the core
> application logic, and it's almost never the bottleneck for the typical web
> apps.

Has anyone actually managed to find that this is the case? Just because your
app is stalling on db queries doesn't mean it's "IO bound". Even the most
trivial service that's just routing messages between two other services is
likely to be radically faster when implemented in Rust vs JS.

~~~
golergka
> Just because your app is stalling on db queries doesn't mean it's "IO
> bound".

OK, "IO bound" may not be the best description in this case. Because you're
bound not by your ethernet card or operating system drivers, but literally by
the work that's happening on a separate, database server's CPU. I should work
on my terminology, thanks for the correction.

In my experience, it is usually waiting for DB. Regardless of whether your web
app is well or badly written, it would get, at my estimate, would get no more
than 5-10% request time improvement even if you made the app CPU infinitely
fast, as 90-95% of the time is taken waiting for that database query.

But if you spend the same developer time rewriting all your ORM-generated n +
1 select statements to a single SQL query, you would still spend the same
proportion of time waiting for the database, but your overall latency would
get 10 times less. I've had some situations where I could get 10-20 time
performance improvements by not touching application code at all, just
tweaking the database indexes.

So, rewriting it all in a new language where you can, at most, 10%
improvement, while you probably have areas where you can get 200-500%
improvements seems unwise.

~~~
eska
If your database queries are so bad that you can get such big improvements by
changing the queries and indexes, then obviously focus on that, not the client
programming language. But once you've done that your programming language is
responsible for a larger ratio of the total time, since it runs in series to
the database query, not in parallel. The benefit, in my experience, is much
larger than 10% then.

------
touilleMan
Congratulation this seems really cool ;-)

Actix was already a great project but the community-driven switch mentioned
here is a great step toward better support and broader adoption.

BTW is the fact the anouncement made on Dropbox paper has something to do with
Dropbox as a company ? (I heard they are investing heavily into Rust)

~~~
epage
Its just what the devs used to collabbrate and then they published it in place
rather than moving it, as reported in /r/rust.

------
mochijo2219
>> Extensive usage of the projects helped us resolve memory leaks.

Hu? I thought Rust was memory safe? At least that's how it's promoted.

What's the point of Rust when one of the flagship project (Actix) had memory
leaks for years?

~~~
lmkg
Under Rust's definition of memory safety, a memory leak is not unsafe. Data
will not be corrupted or accessed improperly.

Also Actix has had a strained relationship with the Rust community for a
number of years, because of Actix's cavalier attitude towards `unsafe`. The
result of which is that the project is under new leadership, and safety is
given a stronger emphasis. I also never really considered Actix a "flagship"
project of Rust. It was popular and promoted itself, but it sort of set itself
apart from the mainstream Rust community.

------
kevincox
I unreasonably avoid frameworks that have O(n) routing. For some reason I just
feel like the standard should be O(1) with the number of routes. There is a
crate [https://github.com/http-rs/route-recognizer](https://github.com/http-
rs/route-recognizer) which does this but most frameworks roll their own which
just loops over the registered routes and takes the first one.

It can be slightly less flexible, however in most cases if you are using this
sort of flexibility your URL structure is too confusing anyways. Since you can
group together an number of regular expressions and match them in O(n) with
the length of the URL you clearly have a lot of flexibility available.

Of course I should probably check the real benchmarks because the NFA based
approach almost certainly has more overhead.

~~~
mwkaufma
Is the route count unbounded? O(n) = O(1) for constant-bounded n.

~~~
kevincox
Yes, this is why my discomfort is "unreasonable".

However I feel bad knowing that every route I add is slowing down my app. And
I have the impulse to sort my routes by popularity to improve performance. I
wish I could just trust the framework to match "as fast as possible".

~~~
staticassertion
If it makes you feel better, it's honestly probably faster for a certain
number of routes or fewer.

------
renewiltord
I actually really like Actix. Switched to using Rocket because of some
controversy in the Actix stuff that I didn't care too much to keep tabs on.
Has anyone used Actix recently? Can you use it ergonomically on stable or do
you need nightly? Would love to hear opinions from users here.

~~~
capableweb
> Switched to using Rocket because of some controversy in the Actix stuff

That's the first time I've heard someone making a technical choice solely by
something that is not technical.

Did you change from Actix because you're afraid that the controversy would
eventually hit your own written software? Or just felt bad supporting
something that others didn't want people to support? Would love to hear the
reasoning behind the change.

~~~
renewiltord
Oh, I don't care if there's all the politics, but the code disappeared. Using
a dependency that disappears like that didn't make me happy. It was totally a
technical decision to try to avoid an evolutionary dead-end.

I wasn't even upset about the unsafe. I didn't care.

------
giancarlostoro
I want to love Rust but my biggest pain point was trying to produce a simple
enough REST web service, initially with Actix, though I think I was trying to
use it at a time where the docs were not in sync with what was released at the
time. Not sure if this has changed, but I'd be willing to give Actix another
try again if that's the case.

~~~
kamikaz1k
You should give rocket a try! The developer ergonomics are a lot better.
Assuming this is you learning about rust.

Because performance-wise rocket is slower. But they're working on adding async
support, after which they should be showing a lot better numbers.

~~~
giancarlostoro
Is it compiling under the stable compiler though? I tried switching compilers
to try out Rocket and it just didn't work out very well for me, compiler
errors everywhere that I couldn't seem to find a reasonable answer for. I'm
not a fan of switching to anything that isn't considered stable unless I
absolutely have to.

~~~
estebank
I believe async support is already on master as well as stable support, but
there hasn't been a release yet.

There were two unstable features that Rocket was waiting on (which have been
stabilized some releases back). Using nightly rustc is fine for the most part,
but I wouldn't want to _rely_ on it for production services.

------
newsbinator
> A powerful, pragmatic, and extremely fast web framework for Rust

In case anybody, like me, didn't know.

------
didip
Does it mean that Dropbox uses Rust?

~~~
staticassertion
This post is hosted on Dropbox's Paper product, which allows for publishing by
3rd parties (anyone with a free Paper account).

This post does not have to do with Dropbox engineering, which I do not believe
uses Actix. But Dropbox _does_ use Rust quite a lot - their storage layer and
sync engine, among other things, are implemented in Rust.

~~~
estebank
For one example of how Dropbox _does_ use Rust:
[https://dropbox.tech/infrastructure/-testing-our-new-sync-
en...](https://dropbox.tech/infrastructure/-testing-our-new-sync-engine)

