Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Getting Started with Axum – Rust's Most Popular Web Framework

shuttle.rs

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Getting Started with Axum – Rust's Most Popular Web Framework

#21

Post by Klonoar »

mdtusz wrote: post #15
boredumb wrote: post #10

I've been using Tide with great success lately. Also - for my own projects I haven't used docker lately and just dump the binary with it's configs to the debian box with a systemd configured and so far it's been painless, ymmv.

Tide is fantastic and has IMO the best ergonomics (and could be improved to be even better), except it's essentially abandonware at this point. I'd love to see it continue and thrive, but there's many PR's that have been ready to land for a long time gathering dust, and plenty of open issues that are at a standstill because there's simply no momentum or direction. Not blaming anyone - the maintainers don't owe us any…

I think there’s the bigger question of “what’s the deal with async-rs?”.

I know of more than a few projects that have looked into just dropping support for it entirely.

Re: Getting Started with Axum – Rust's Most Popular Web Framework

#22

Post by atoav »

jbandela1 wrote: post #2

> Deployment with Rust backend programs in general can be less than ideal due to having to use Dockerfiles, Actually, in my experience, Rust is one of the best languages for ease of deployment (for much the same reason as Go). Rust/Cargo produces self-contained statically linked binaries. Rust/Cargo also has a real nice cross-compiling story. Often my deployment will be to build the binary and then basically scp the…

As a seasoned python developer deployment of a pure Rust program is much simpler than Python. The only issue that I ever had was figuring out how to cross compile for a raspberry pi, but even that took me less time than the typical python dependency problem that may happen when you e.g. devlope on Ubuntu and deploy on Debian.

When Rust deployment gets hairy, it is typically the fault of non-Rust-dependencies.

Re: Getting Started with Axum – Rust's Most Popular Web Framework

#23

Post by goddtriffin »

Wonnk13 wrote: post #3

This isn't trolling, it's my genuine ignorance- I thought Actix was the goto web framework for Rust? I don't do a whole lot of Rust and when I do it isn't http router type work so I'm out of the loop here.

I used to use Actix for a web project, but the Websocket story was severely lacking. Actix is non-work-stealing multi-threaded (to achieve "performance", I presume) and thus it has to use a non-async Actor model for inter-Websocket interactions. This meant that I could not use an async DB pool or an async HTTP requests library within my Websocket code.

Alternatively, Axum is built by the same people that made tokio, is work-stealing multi-threaded, and the Websocket code is async be default. It is just overall a better library.

Re: Getting Started with Axum – Rust's Most Popular Web Framework

#24

Post by binary132 »

vilunov wrote: post #19
sshine wrote: post #17

Earlier quoted context omitted.

Tooting the Rust horn in predictable ways: Why would you want to restart a service frequently? - Flush incorrect state - Reset memory leaks - ...others reasons? Rust's borrow system makes it harder (but not impossible) to have memory leaks. Rust's immutable-by-default semantics makes it harder (but not impossible) to end up where your long-running process'es state is incorrect. You can still mark everything as `&mut`…

Close to memory leaks, but not exactly: memory fragmentation. Unlike runtimes with managed memory such as JVM, Rust apps cannot take a pause and defragment the memory heap, which depending on frequency and sizes of allocations sooner or later will lead to your app taking up a huge chunk of memory and not using it efficiently.

Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust? It’s the operating system’s job to manage fragmentation in the allocator, right? And it’s straightforward to switch to jemalloc, which often improves on the system allocator.

Re: Getting Started with Axum – Rust's Most Popular Web Framework

#25

Post by vilunov »

binary132 wrote: post #24
vilunov wrote: post #19

Earlier quoted context omitted.

Close to memory leaks, but not exactly: memory fragmentation. Unlike runtimes with managed memory such as JVM, Rust apps cannot take a pause and defragment the memory heap, which depending on frequency and sizes of allocations sooner or later will lead to your app taking up a huge chunk of memory and not using it efficiently.

Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust? It’s the operating system’s job to manage fragmentation in the allocator, right? And it’s straightforward to switch to jemalloc, which often improves on the system allocator.

> And it’s straightforward to switch to jemalloc, which often improves on the system allocator.

It is true that jemalloc is much better than the standard malloc, but it still suffers from memory fragmentation, although typically a program can run for much longer with it.

> It’s the operating system’s job to manage fragmentation in the allocator, right?

No, not really. The operating system does nothing with the memory space of the process, other than providing syscalls for giving the process more pages.

> Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust?

What some thicker runtimes such as JVM do is that 1) they track all pointers present in the data used by the program and do not allow programs to cast them to raw integers (or back); 2) they can defragment the heap by moving the memory chunks around to fill in the gaps and at the same time they rewrite all pointers that point to moved chunks so that they still point to the same data.

Re: Getting Started with Axum – Rust's Most Popular Web Framework

#26

Post by binary132 »

vilunov wrote: post #25
binary132 wrote: post #24

Earlier quoted context omitted.

Wouldn’t this be a criticism of any long-running program which uses dynamic allocation, not only Rust? It’s the operating system’s job to manage fragmentation in the allocator, right? And it’s straightforward to switch to jemalloc, which often improves on the system allocator.

> And it’s straightforward to switch to jemalloc, which often improves on the system allocator. It is true that jemalloc is much better than the standard malloc, but it still suffers from memory fragmentation, although typically a program can run for much longer with it. > It’s the operating system’s job to manage fragmentation in the allocator, right? No, not really. The operating system does nothing with the memory…

I know what JVM does, I was talking about other “native-allocator” stacks like C and C++, which are used in many very popular long-running services.
Post reply on HN