Rouille, Rust web server middleware VS gleam

Your CRUD web application server almost certainly doesn't need async Rust. Using a blocking HTTP server is not "might be a good idea", it simply is a good idea.

I recommend Rouille for this: https://github.com/tomaka/rouille. In case you are worried about performance, check the benchmark. Blocking Rouille is faster than builtin async server in Node.js.

As you say, the majority of the web ecosystem in Rust has moved to async - but if you’re happy to stray a bit from the beaten path then rouille might do the trick.

In strongly typed languages like Rust, composing smaller libraries is usually quite painless, so you don't need a large framework.

Personally for backend Rust I use rouille[0] for the server (it's very simple and async-free), askama[1] for compile-time HTML templates and (if a SPA is unavoidable, as that is of course always to be avoided if at all possible) yew[2] for client-side WASM.

Now this stack is what I like personally, but there are many options that you can combine, some more full-featured than others. Check out https://www.arewewebyet.org/ for a partial overview.

[0]: https://github.com/tomaka/rouille

[1]: https://github.com/djc/askama

[2]: https://yew.rs/

rouille

I'd like to put in a word for a simple, sync framework such as rouille. The compile times are much, much better, the number of dependencies is much smaller, the stuff it's built on (the standard library) is extensively tested and extremely reliable. Kernel context switches are slower than userspace thread scheduling, but not much slower, and as long as your services aren't just shoving bytes from one place to another (i.e. actually doing some computation) the time taken for a context switch vanishes into noise. A lot of benchmarks test how quickly a web service can move bytes, which (if your business logic is non-trivial) actually isn't the most critical factor.

I don't have any Rust-relevant experience here, but if I wanted to build a web server in Rust and was okay with "reasonable" performance, I'd probably give rouille a try first.

Rouille is fairly solid in my experience. Save the pain of async and spend it building software that works. Honestly with Rust's lack of GC you get predictable response times already.

How would you differentiate it from let's say Rouille ?

Want a friendly language for building safe systems at scale? Gleam is here for you. It features modern and familiar syntax, that's reliable and scalable. Gleam runs on an Erlang virtual machine, and can run plenty of concurrent tasks. It comes with a compiler, build tool, formatter, editor integrations, and package manager all built in so you can get started right away. Congrats to the team on shipping your first major version 🙌.

While I love Clojure, I have to agree about tooling. I recently started using Gleam* and was impressed at how easy it was to get up and running with the CLI tool. I think this is an important part of getting people to adopt a language.

* https://gleam.run/

If you use languages that compile to WASM (such as Gleam https://gleam.run), and can also run Postgres via WASM, then it opens very interesting offline scenarios with codebases which are similar on both the client and the server, for instance.

Recently, Gleam has gained more popularity, and a lot of developers (including me) are learning it. At the time of this writing, it has exceeded 14k stars on GitHub; it grew really fast for the last month.

Oh, strange that github had a date of 2016 on this one: https://github.com/gleam-lang/gleam/issues/2

I was just going by that, though I do remember checking out gleam 5 years ago or so.

Re: macros, I really do think they’re a big deal and all the other newer languages I’ve used, such as Rust have some kind of macros or powerful meta programming features.

For older languages, a few, like Ruby have enough meta programmability to make nice DSLs, but many others don’t. Given the choice, I’d much rather have Elixir/Clojure style macros than other meta-programming facilities I’ve seen so far.

I had been only following this language with some interest, I guess this was born in gitlab not sure if the creator(s) still work there. This is what I'd have wanted golang to be (albeit with GC when you do not have clear lifetimes).

But how would you differentiate yourself from https://gleam.run which can leverage the OTP, I'd be more interested if we can adapt Gleam to graalvm isolates so we can leverage the JVM ecosystem.

I don't think the implementation itself is at fault, but yes, I do think that the design of dialyzer makes it an (at times) faulty type checker. The unfortunate reality of a type checker that fails sometimes is that it makes it mostly useless because you can never trust that it'll do the job.

To be clear, I've had it fail in a function where I've literally specced that very function to return a `binary` but I'm returning an `integer` in one of the cases. This is a very shallow context but it can still fail. Now add more functions, maybe one more `case`.

I think an entire rethink of type checking on the BEAM had to be done and that's why eqWalizer[0] was created and why Elixir is looking to add an actual sound, well-developed type checker. Gleam[1] I would assume is just a Hindley-Milner system so that's completely solid. `purerl`[2] is just PureScript for the BEAM so that's also Hindley-Milner, meaning it's solid. `purerl` has some performance issues caused by it compiling down to closures everywhere but if you can pay that cost it's actually pretty fantastic. With that said my bet for the best statically typed experience right now on the BEAM would be `gleam`.

0 - https://github.com/WhatsApp/eqwalizer

1 - https://gleam.run

2 - https://github.com/purerl/purerl