Live data from Hacker News

Programming language comparison by reimplementing the same transit data app

github.com

41–50 of 65 posts

Re: Programming language comparison by reimplementing the same transit data app

#42
post #3

Oh, hey, didn't expect to see this here. Thanks for submitting! I tried a few days ago but didn't really get any traction.[0] Since I submitted it, though, I posted it to /r/rust and got a lot of feedback. At the time, rust and dotnet were comparable and at the top of the list, with ~10k req/sec. Now rust is far and away the most performant at ~20k req/sec! I also was able to improve Go's performance 30% or so. Still…

For anyone interested about the “posted it to /r/rust and got a lot of feedback”: https://old.reddit.com/r/rust/comments/ya4xfw/why_is_cdotnet...

Re: Programming language comparison by reimplementing the same transit data app

#43

The experience report on Scala I find pretty cathartic. It really is absolutely ridiculous the fetishization of extremely complex FP and type-level hacking that goes on in the ecosystem, to the point where, in the case of the author's hello world web server snippet, it's just so complex and laden with concepts you need to know that are unrelated to the problem you're trying to solve it could be mistaken for a parody…

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/... . With that, you get a declarative def…

> 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.

Re: Programming language comparison by reimplementing the same transit data app

#44
What again and again I find interesting, that Rust is (slightly) faster than Go (with all the discussions about generics etc.)

Still I would try a framework with Go, it seems odd to not use one when a framework is used with the other languages.

Re: Programming language comparison by reimplementing the same transit data app

#45
post #4

The experience report on Scala I find pretty cathartic. It really is absolutely ridiculous the fetishization of extremely complex FP and type-level hacking that goes on in the ecosystem, to the point where, in the case of the author's hello world web server snippet, it's just so complex and laden with concepts you need to know that are unrelated to the problem you're trying to solve it could be mistaken for a parody…

It's a shame, too, because until that point (when I was still just following the "getting started" docs and doing the first half of the app, which loads a CSV and parses it and stuff), I was actually really enjoying it! The type-magic style of development is so different from what I'm used to, I have periodic crises of conscience where I wonder if I've been doing programming wrong all these years, or if it's an examp…

And from founding a startup on Scala (Lift + Play), grow over some years and sell, I most dread compiler errors with the type magic. If something doesn't compile because of types, the error messages (at least some years back) were so confusing, it took quite some time to fix problems.

Re: Programming language comparison by reimplementing the same transit data app

#46
post #43

Earlier quoted context omitted.

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/... . With that, you get a declarative def…

> 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 availa…

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.

Re: Programming language comparison by reimplementing the same transit data app

#47
post #4

The experience report on Scala I find pretty cathartic. It really is absolutely ridiculous the fetishization of extremely complex FP and type-level hacking that goes on in the ecosystem, to the point where, in the case of the author's hello world web server snippet, it's just so complex and laden with concepts you need to know that are unrelated to the problem you're trying to solve it could be mistaken for a parody…

It's a shame, too, because until that point (when I was still just following the "getting started" docs and doing the first half of the app, which loads a CSV and parses it and stuff), I was actually really enjoying it! The type-magic style of development is so different from what I'm used to, I have periodic crises of conscience where I wonder if I've been doing programming wrong all these years, or if it's an examp…

The http4s library was a bad choice in your case and it's at least partly their fault. They should really make it clear from the very beginning that you MUST understand certain PFP concepts and datatypes to effectively use the library.

It is a NOT a library that you should start out with when you learn Scala, unless you have a mentor.

I think for you, cask was the right choice and it's good that you found it.

Re: Programming language comparison by reimplementing the same transit data app

#48
post #3

Oh, hey, didn't expect to see this here. Thanks for submitting! I tried a few days ago but didn't really get any traction.[0] Since I submitted it, though, I posted it to /r/rust and got a lot of feedback. At the time, rust and dotnet were comparable and at the top of the list, with ~10k req/sec. Now rust is far and away the most performant at ~20k req/sec! I also was able to improve Go's performance 30% or so. Still…

Did you post on the elixir forum? Those results seem very low, I feel like there has to be something amiss.

I posted to the Elixir Forum

https://elixirforum.com/t/an-informal-comparison-of-several-...

----

It's not surprising that Elixir is not good at large json handling and complicated data structure manipulation. This reminds me of https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...

At the same time I see that Elixir gave the most consistent response time. Max response time is less than 6x of median compared to ~x10 (Deno / C#) or x23 (Go / Rust) / x58 (Scala), probably thanks to preemtive scheduling of per-request process in Erlang VM

Post reply on HN