Jooby VS lumen

One of the good things about it is that using asynchrony is optional. If you don't have to call out anywhere to build the response, processing can all stay in the handler's calling thread. If you do, you can return a future and have the library handle the async for you.

One downside is that it is based on Jetty which isn't considered the most performant backend. A lib with a similar API but based on Netty is Jooby [1] which scores well in the Techempower benchmarks.

[1] - https://jooby.io/

Jooby and Helidon SE are among the best.

The code snippet gave me a vibe like it was jooby Looks cool, I suggest maybe start incorporating Project Loom virtual threads in the future.

Speaking of backend development, recently I gave Jooby[1] a try after discovering it was one of the world's top performer in Tech Empower's web framework benchmark[2].

Surprisingly enough, it's terribly easy to put together a REST API with Jooby. I wonder why it's adoption rate is so low.

[1] https://jooby.io/

[2] https://www.techempower.com/benchmarks/

Do you need to use Spring btw? If you want to broaden the tool selection I've had great success with i.e Jooby (https://jooby.io/) together with Kotlin coroutines. Another alternative is the KTOR framework.

Jooby I think is the best bet. https://jooby.io/ watch out for jooby dot org I think someone sniped the domain.

Personally I find it extremely difficult to read and use code that uses ASM directly vs ByteBuddy or some wrapper library. For example take a peak at this: https://github.com/jooby-project/jooby/blob/2.x/modules/jooby-apt/src/main/java/io/jooby/internal/apt/HandlerCompiler.java

[4] https://jooby.io/

See the about section: https://github.com/GetFirefly/firefly#about-firefly

> The primary motivator for Firefly's development was the ability to compile Elixir applications that could target WebAssembly, enabling use of Elixir as a language for frontend development. It is also possible to use Firefly to target other platforms as well, by producing self-contained executables on platforms such as x86.

There are details on this also: https://github.com/GetFirefly/firefly#runtime

Generally it should be assumed that actors and their concurrency model is fully supported as that is a part of the core semantics for BEAM languages.

Probably not a practical solution for what you are building now, but it's worth pointing out Lumen, an Erlang VM implementation that compiles to WebAssembly, and could one day enable Elixir on the frontend.

Another vector could be some tooling that makes it easy to run Go programs compiled to Wasm run inside of Wasmtime environment hosted in Rust. If we run the go tooling in the same system, one could point this tool at a Go repo and be running that Go in a matter of milliseconds. A fun feature would be running channels across separate Wasm envs. Or maybe use Lumen.

Wish the Elixir WASM project -- Lumen -- were active. It seems like nothing much is happening on it.

The BEAM (runtime?) is written in C. There is also an effort to rewrite it in Rust (https://github.com/lumen/lumen). Some functions are built into the VM but most of the supporting 'standard library' (OTP / Open Telecom Platform) is written in Erlang. The (main) compiler is written in C. So it's all C or Erlang afaik.

It is ported to every major flavour of OS.

I don't know what 'back end' means in this context.

There are attempts to implement an Erlang/BEAM-inspired reactor/runtime/executor/ecosystem for Rust's Async, in particular Bastion. (There are also Lumen, Lunatic and Async-Backplane/Async-Supervisor.)

If I recall correctly, Saša Jurić mentioned in an interview that he envisions the BEAM being used as an OS in the future, where you can run your database, web server and other services under one VM.

While I don't personally have much use for it (at the moment), I'm curious about how this would look like with Lumen [0] where you can run your whole web stack with a single binary and being internally supervised by the BEAM.

Lumen's development has been slow but I remember seeing a tweet from a team member stating that development is slowly ramping back up (not a criticism in any way, just providing some context).

[0] https://github.com/lumen/lumen