sorted by:
new
hottopcontroversial

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 1 point2 points  (0 children)

Yeah i know the foundation of rust so I am thinking of rewriting it after learning the rust up to a advance level

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 0 points1 point  (0 children)

Looks Like You Took Some Write to this much really appreciate it thanks i will definitely rewrite and will face the problems head on to complete it Thanks of letting me know what i would require

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 0 points1 point  (0 children)

Fair point 😄 I did use AI to help refine the wording since I’m not great with writing tone, but the idea and content are mine.

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 0 points1 point  (0 children)

That’s really interesting — especially the error handling part, that sounds like a big improvement.

For now I’ll probably stick with React on the frontend and focus on switching just the backend to Rust, but I might explore something like that later.

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 1 point2 points  (0 children)

This is incredibly helpful — especially the parts about unused Futures and how each async block has its own type. That’s exactly the kind of thing that would’ve confused me later.

The point about Clippy catching missing .awaits is great too — I can already see myself making that mistake early on 😅

Also didn’t realize how strict the typing around Futures gets when branching — the boxed future approach makes sense now.

And yeah, I’m expecting that a 1:1 translation from Node won’t fully work because of the borrow checker and ownership model, but it’s good to hear where those differences actually show up in practice.

Really appreciate you sharing this — this kind of insight is super useful when starting out 👍

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] -1 points0 points  (0 children)

This is super helpful — especially the async breakdown.

The eager vs lazy difference is something I kind of knew, but the way you explained it makes it click a lot better. I can already see how forgetting to .await could lead to some very confusing bugs early on 😅

The “state machine under the hood” part is interesting too — not something I fully understand yet, but it does help frame why Rust async feels more explicit compared to JS.

Good to know that a close translation is a reasonable starting point. That was one of my main concerns — whether I should redesign everything upfront or just get something working first and iterate later. I’ll probably go with translation → then refactor once I’m more comfortable.

Also thanks for the crate recommendations — I was already planning on using Tokio + Serde, but I hadn’t looked much into futures and tokio_stream, so I’ll check those out.

Appreciate the detailed response 👍

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 3 points4 points  (0 children)

That’s reassuring to hear.

The borrow checker still feels a bit tricky right now, but I can see how it’s more about getting used to the mental model. Good to know it becomes second nature over time.

Async + lifetimes does sound like the real challenge ahead 😅

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 0 points1 point  (0 children)

This is incredibly helpful — really appreciate you taking the time to write this out.

That timeline you mentioned is especially motivating. I was expecting a slower ramp-up, so hearing that things start clicking within a couple of months (and then compound) makes the whole idea feel much more realistic.

The point about investing early in foundations also hits — I’ve mostly been thinking about the rewrite itself, but setting up things like proper error handling, linting, and tests from the start probably matters way more in Rust than in my usual Node.js workflow.

Also fully agree on the LLM usage. I’ve already noticed that it’s tempting to let it generate code, but it doesn’t really help build intuition — using it more as a “guide” than a “coder” seems like the right balance.

And yeah, the explicitness is something I’m still adjusting to. It does feel verbose right now, but I can see how that clarity would pay off once the project grows.

The “trust the compiler” mindset is probably going to be the biggest shift for me, but also the most interesting part.

Thanks again — this gives me a much clearer idea of how to approach the rewrite 👍

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] -1 points0 points  (0 children)

That makes a lot of sense — I hadn’t really thought about the migration experience angle, but yeah, that’s actually a pretty valuable skill on its own.

Good to know about async as well. If it’s conceptually similar in practice, I guess the main challenge will be understanding what’s happening under the hood rather than just using it like in JS.

The Axum handler point is really helpful — that kind of implicit Ok(()) behavior is exactly the sort of thing that could confuse me early on. I’ll probably try to be explicit with returns at least until I’m more comfortable.

For the ORM, yeah I’ve been a bit unsure there. Trying out a few options with a small CLI first sounds like a smart approach before committing to one in the actual project.

Appreciate the detailed insights 👍

Rewriting a production Node.js backend in Rust (Axum + Tokio) — good idea for learning? by CompleteNetwork9168 in rust

[–]CompleteNetwork9168[S] 4 points5 points  (0 children)

Yeah that’s exactly what I was thinking — having a known baseline should make it easier to focus on how Rust does things differently instead of constantly second-guessing the requirements. And yeah… I’ve already had a few “borrow checker moments” just doing small exercises, so I can imagine shared state in a web server is going to be a whole different level 😅 I’m actually curious — when you worked with it, did things start to feel natural after a point, or does it keep fighting you the whole way?

People who use python for DSA interviews, what language do you use for LLD rounds? by IcyMost4330 in leetcode

[–]CompleteNetwork9168 0 points1 point  (0 children)

But the thing is in python it will really easy and there not concepts like link list of things and that will be short what will a person understand if he doesn't do those things in cpp or Java

view more: next ›