4 ms·

I do wonder where the recommendation to use http4s for beginners came from. http4s is a very capable library (and if you care much about composition it is excel

I do wonder where the recommendation to use http4s for beginners came from. http4s is a very capable library (and if you care much about composition it is excellent), but I wouldn't describe the documentation as beginner friendly. A slightly better starting point for scala 3 + type-safe server building is tapir e.g. https://github.com/softwaremill/tapir/blob/master/examples3/src/main/scala/sttp/tapir/examples3/ErrorUnionTypesHttp4sServer.scala https://github.com/softwaremill/tapir/blob/master/examples3/... . With that, you get a declarative definition of your endpoints (+ error types, auth, etc.) that you can use for both servers and clients, which comes very handy when writing integration tests of course. > absolutely ridiculous the fetishization of extremely complex FP and type-level hacking that goes on in the ecosystem An alternative way to look at it is that there is a lot of essential domain complexity that gets encoded via the type system to let the compiler do the hard work. That "extremely complex FP" does not arrive out of nowhere - I really recommend at least skimming through the slides from rossabaker, the http4s designer, that motivate where the core type signature comes from https://rossabaker.github.io/boston-http4s/#2 https://rossabaker.github.io/boston-http4s/#2 I suppose one of the "features" that I like about the (typelevel) community is that the approach of "worse is better" is not taken, and a lot of effort is expended to make things correct, modular and orthogonal. This has the drawback of increased upfront complexity, that anecdotally pays off the moment your compiler does not error and the program runs as intended.

klabb3 4y ago
> http4s is a very capable library (and if you care much about composition it is excellent), but I wouldn't describe the documentation as beginner friendly. A slightly better starting point for scala 3 + type-safe server building is tapir I am not a scala user but this sounds like a serious violation of composability (ironically), for something so ubiquitous as http. I don't really mind advanced features being available for power users, or later optimizations, but I really dislike being forced to make a mutually exclusive decision between simple and performant, early in the project lifecycle. I think Rust unfortunately often falls in this category as well with async and multiple http libraries, and even the inofficial doctrine of deferring ownership decisions for later. In Go there's basically one way to do things, and the few more advanced things you can do can be opted into later. I assume this is a quality inherited from C, and it's extremely pragmatic and creates a composable ecosystem.
- valenterry 4y ago
  If anything the documentation isn't great. Http4s is an advanced library and maybe expects some knowledge about PFP and related datatypes. They should make that clear to everyone imho. But other than that, running a simple hello-world service with http4s really isn't that hard. object Main extends StreamApp[IO] { val helloWorldService = HttpService[IO] { case GET -> Root / "hello" / name => Ok(s"Hello, $name.") } override def stream(args: List[String], requestShutdown: IO[Unit]) = BlazeBuilder[IO] .bindHttp(8080, "localhost") .mountService(helloWorldService, "/") .serve } Yeah, there are a couple of things that are more complex than with other simple webservers. For instance, what is the "IO" thing doing there? Well, http4s flexibly allows you to choose different libraries for handling concurrency without even knowing those libraries. Very few other programming languages are even powerful enough to support something like that, so it obviously confuses people. And then you need a StreamApp (there are other alternatives but that's the one from the documentation) and people might wonder why - they want a simple request/response webservice and nothing "streaming". Other than that, I don't think the code is overly complicated.

klabb3 4y ago

> http4s is a very capable library (and if you care much about composition it is excellent), but I wouldn't describe the documentation as beginner friendly. A slightly better starting point for scala 3 + type-safe server building is tapir I am not a scala user but this sounds like a serious violation of composability (ironically), for something so ubiquitous as http. I don't really mind advanced features being available for power users, or later optimizations, but I really dislike being forced to make a mutually exclusive decision between simple and performant, early in the project lifecycle. I think Rust unfortunately often falls in this category as well with async and multiple http libraries, and even the inofficial doctrine of deferring ownership decisions for later. In Go there's basically one way to do things, and the few more advanced things you can do can be opted into later. I assume this is a quality inherited from C, and it's extremely pragmatic and creates a composable ecosystem.

valenterry 4y ago
If anything the documentation isn't great. Http4s is an advanced library and maybe expects some knowledge about PFP and related datatypes. They should make that clear to everyone imho. But other than that, running a simple hello-world service with http4s really isn't that hard. object Main extends StreamApp[IO] { val helloWorldService = HttpService[IO] { case GET -> Root / "hello" / name => Ok(s"Hello, $name.") } override def stream(args: List[String], requestShutdown: IO[Unit]) = BlazeBuilder[IO] .bindHttp(8080, "localhost") .mountService(helloWorldService, "/") .serve } Yeah, there are a couple of things that are more complex than with other simple webservers. For instance, what is the "IO" thing doing there? Well, http4s flexibly allows you to choose different libraries for handling concurrency without even knowing those libraries. Very few other programming languages are even powerful enough to support something like that, so it obviously confuses people. And then you need a StreamApp (there are other alternatives but that's the one from the documentation) and people might wonder why - they want a simple request/response webservice and nothing "streaming". Other than that, I don't think the code is overly complicated.