For me, I have a use case that needs to support a few thousand users, probably a few hundred concurrently.

The combination of SQLite (libsql, a concurrent implementation of sqlite) and Rust means I can do so from a $2/m VPS and a single server instance.

Backups are done via a cron job that uploads to S3.

Does it pass the "Netflix scale" test? No

But it doesn't need to. I'm not profiting from the service and SQLite offers a path to scale if/when ready because... well it's just SQL and I can literally just swap `libsql::Connection` with `psql::Connection` in my repositories.

Plus upgrading from a $2/m VPS to a $10/month VPS quadripples the number of concurrent users I can support.

IMO, you can vertically scale extraordinary far with SQlite and an efficient server implementation.

I'd wager that 90% of forum websites, wordpress sites and online shops would be fine with SQLite.

> The combination of SQLite (libsql, a concurrent implementation of sqlite) and Rust means I can do so from a $2/m VPS and a single server instance.

You can probably do it with regular SQLite, too. Being limited to a single writer isn't as devastating as it sounds when they get processed very quickly. Probably don't need Rust either but it'll be more efficient than the usual choices.

(Also, it looks like libsql is the same as SQLite? Only Turso has concurrent writes)

Makes sense. I honestly haven't thought about it too much. I liked that I could move to Turso if I needed cloud storage given the free tier and that the API works with tokio nicely

Why do you need libsql? Single writer tends to scale better than concurent writes.

I wouldn't underestimate people in the React ecosystem not to adopt insanity en mass.

I wrote Go professionally for years. I don't know how many hours I've spent debugging and reviewing nil pointer bugs and race conditions. Generics were sorely needed but the initial implementation was lacking.

I moved to Rust professionally 4 years ago and haven't looked back. Mutex<T> Option<T> Result<T, Err> are all phenomenal.

I've written everything from web backends, frontends (hurry up wasm, seriously), to Node.js and Python extensions.

Web backends use under 1mb of memory and can support hundreds of thousands of concurrent users on a $2/m VPS. Frontends can be beautifully multithreaded. Native extensions can dance between OS threads and multi-threaded runtimes.

When I review code I focus only on the logic, not sidetracked by reasoning about race conditions or anything. Great when you review the work of less experienced contributors.

The ultra strict compiler is extremely helpful with LLMs. You bounce back and forth until it compiles and, if it compiles, it's usually correct.

It's at the point where I can't really see a use case for another language - and yet, no one uses it! It's madness!

I have nothing to add to your comment, but it matches so eerily my exact experience, that I just wonder if your alias is a second account of mine :-)

By frontend, do you mean wasm in the browser? I'd have expected multithreading there, especially in wasm, to be extremely unergonomic.

Maybe you mean to refer to concurrency?

I wrote Go professionally for years. Moved to Rust and couldn't be happier. There are some annoying syntax quirks but they are minor.

After writing web services, GUI apps and terminal apps professionally in Rust, I honestly struggle to see a use case for other languages.

Shameless plug. I've been developing a web server library for Rust based on the ergonomics of the Golang standard library.

It has a router, middleware, and uses AsyncRead, AsyncWrite for the request/responses.

I use this for my production applications and have found it much easier to work with than Hyper or Axium.

https://github.com/alshdavid-public/uhttp/blob/main/examples...

The API is largely complete but under the hood I have a few things that need doing. Open to contributions so please feel free to help out

You gotta know how to write Rust (and general software arch) first. LLMs + Rust have been great for me.

"Write an SQL Repository with this interface"

Sweet - no need for SQLc or an ORM

I use Rust for web services all the time. It's a dream compared to Go (which I wrote professionally for years).

At this point, I can't imagine a scenario not to use Rust for writing a web API.

Dunno... I really like FastEndpoints in C# a lot as well as Hono in JS/TS environments. That said, I do like Axum in Rust. All for varying reasons though.

100% this

How nice would it be if there were ReadAsync and WriteAsync traits in the standard library.

Right now, every executor (and the futures crate) implements their own and there are compat crates to bridge the gaps.

Having written a JavaScript runtime in Rust in the past - Rust is an excellent choice. Not just due to the development experience, but also for embedders who want to consume the project as a a library (rather than a binary, e.g. node).

Not sure about vibe-coding it. While they aren't using v8, LLMs made it easier to understand v8 quirks and update v8 as they make weird changes every now and then. It couldn't write the runtime without help though.

For those curious: https://github.com/alshdavid/ion

They describe themselves as an "established startup" lol. It's just an industry-tailored CRM so it's a form-heavy application, nothing about it is ground breaking.

IMO if you're profitable and have been around longer than a decade, you're no longer shipping features for survival and should have bandwidth allocated to improve the product reliability and performance.

No observability/monitoring, no automated testing, no CI/CD, a 30 second - 5 minute login time, and a 20mb JavaScript bundle is a pretty poor customer and developer experience.

I spoke to the head of sales / product to understand customer retention and the factors on failed sales - it looks like our customer retention is unaffected by a slow or unreliable the product.

Luckily I am about as frugal as they come (humble beginnings) - but also I'm in Australia and big tech here pays about as much as an average Sr salary in a non big-tech company in the states.

At my last job, I was on 220k/y USD TC as a Sr.

This role is 140k/y USD, which is close to the top end of non big tech salaries here.