zio-http VS dotty

For JNI, make sure you have `-H:+JNI` in your native image options. Be aware that Netty is a bit of a monster to include in a native image application (I just recently added it a Netty dependency and it completely broke my project and took a good day to figure out). Mine was through zio-http and I was able to piece together some working options from github issues: https://github.com/zio/zio-http/issues/20.

What's the hardware being used for your test? I get 55k RPS with a basic 200 responder with zio-http[0] (which uses Netty) on my i5-6600K, and over 20k RPS for an e2e POST endpoint that does write batching to postgres (committing the insert before responding with the db generated id). Postgres, client (vegeta[1]), and the app all on the same machine. I think that was with keep-alive, I think like 256 clients for the basic responder and 1024 for the one that writes to the db. There's a recently merged PR for zio-http that does 1M req/s on whatever machine they test on[2] so Netty can absolutely scale to high RPS.

[0] https://github.com/zio/zio-http

[1] https://github.com/tsenart/vegeta

[2] https://github.com/zio/zio-http/pull/1659

Yep! https://github.com/zio/zio-http

I was looking at HTTP frameworks for Scala. I found zio-http, https://zio.github.io/zio-http/. Has anyone tried this framework?

https://github.com/dream11/zio-http very simple and super performant, dead easy to abstract over routes to make a router

I'm starting a new project, essentially a standard web app (SPA + rest api). I'd like to stay as functional as possible. I'm debating between http4s + cats effect, http4s + zio, and zio-http (https://github.com/dream11/zio-http). I'm having a hard time figuring out which stack has the strongest (safest?) future especially with scala 3 out. Cats Effect 3 looks amazing, but so does the zio ecosystem. Thanks for any opinions/advice!

Dotty? Was it still the name later?

http://dotty.epfl.ch/

I think this might be related to this issue.

You can look (and EPFL collect feedback) about EPFL implementation of async/await: https://github.com/lampepfl/async. Also you can look at dotty ticket about this: https://github.com/lampepfl/dotty/pull/16739

The reason I’m not currently an opaque type user as they do not play well with the tagless final style we use, though I am patiently awaiting some attention on my bug report: https://github.com/lampepfl/dotty/issues/17281

Links: - https://dotty.epfl.ch/ - https://scala-native.org/en/stable/ - https://www.scala-js.org/ - https://typelevel.org/ - https://zio.dev/ - https://github.com/scala-native/scala-native/pull/3120 - https://github.com/lampepfl/dotty/pull/16517 - https://dotty.epfl.ch/docs/reference/experimental/index.html - https://scala-cli.virtuslab.org/ - https://scalameta.org/metals/ - https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html - https://www.scala-lang.org/blog/2023/04/18/faster-scalajs-development-with-frontend-tooling.html - https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html

Scala Native has much more control on how the Scala AST is compiled, and can easier workaround platform limitations, eg. lazy vals in Scala 3 required reflection config for Native Image (see this and that), while in Scala Native we could mitigate problems with unsupported usage inside in other ways within the compiler plugin.

By the way, you might be interested in this recent PR which overhauls the scala 3 macro docs: https://github.com/lampepfl/dotty/pull/17060.

For example, this issue (https://github.com/lampepfl/dotty/issues/12840) was blocking the migration, it was reported more than a year ago and the fix was finally released a month ago (https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2).

For the record, there is an implementation of :javap which is close to being done but might need a volunteer to get it over the finish line: https://github.com/lampepfl/dotty/pull/12210

im glad to tell you that in 3.3.0 a lot of these -Wunused lints will be supported: see https://github.com/lampepfl/dotty/pull/16157