Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programming language comparison by reimplementing the same transit data app

github.com

Post reply on HN
Print view View original

51–60 of 65 posts

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

#51

Post by Kabie »

losvedir wrote: post #22
pg_bot wrote: post #20

Earlier quoted context omitted.

The elixir implementation seems super slow. The first thing that jumps out to me is that we should be using streams instead of just reading the file. The second would be the `schedule_for_route` which should just be a GenServer lookup instead of reading from ets.

Yeah, I should benchmark streams. In my experience streams are rarely faster, though, and are instead something you should reach for if 1) you can't fit the file in memory or 2) you might stop the enumeration early. Regarding GenServer, I'm not so sure about that. I suppose I should benchmark it, but intuitively I expect ETS to be better here. There's more overhead in getting the data, but it allows you to concurrent…

Using stream can be faster here. Because you don't have to rebuild the same huge list again and again.

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

#52

Post by phibz »

losvedir wrote: post #4
joshlemer wrote: post #2

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…

> I have periodic crises of conscience where I wonder if I've been doing programming wrong all these years, or if it's an example of a community barking up the wrong tree.

When I first learned of FP about 20 years ago I thought it was a terrible idea. But I've convinced myself I have been proven wrong time and time again.

I still think sometime it's complexity for its own sake. Eg. why is it so hard to define a monad? But I enjoyed parts of Scala 2 and later Rust. There are good ideas in FP that lead to programs that are easier to reason about and manage complexity. Languages are borrowing these good ideas and I'm happier for it, algebraic data types, pattern matching and destructuring, result/either, immutability, etc

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

#53

Post by shirogane86x »

losvedir wrote: post #4
joshlemer wrote: post #2

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…

as someone who did (and still does) a lot of Haskell, and actually loves it, seeing http4s reminded me less of Yesod and more of Servant: really high flexibility, advanced type level magic, and a fairly steep learning curve - especially so if you're not accustomed to advanced typed functional programming.

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

#54

Post by zigzag312 »

losvedir wrote: 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…

Few tips to improve C# performance:

- enable source generation for JSON serialization

https://learn.microsoft.com/en-us/dotnet/standard/serializat...

- use `TryGetValue` to do single dictionary lookup instead of two.

  if (TripsIxByRoute.TryGetValue(route, out var tripIxs))
- specify List's capacity, if it's known when creating it, to avoid resizing operations while adding elements to the List

  var schedules = new List(stopTimeIxs.Count);

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

#55

Post by pasc1878 »

labrador wrote: post #32

> As for the language, C# is... all right, I guess. It kind of reminds me of Dart That's right because Google's Dart (2010's) was heavily influenced by Microsoft's C# (2000's) which was heavily influenced by Sun's Java (1990's) I've often wondered if would have been better if the companies had worked together to produce a standard VM language

You need to look at the history of Microsoft's version of Java to see why that did not happen.

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

#56

Post by dajonker »

craftoman wrote: post #49

I don't wanna be rude but comparing "languages" by using multithreaded examples VS single threaded ones is so dumb.

If you don't want to be rude just don't comment. I don't think the author intends this to be an objective comparison by any means. It's just their subjective experience trying to build some software in different languages. See also the opening paragraph of the project's readme:

> This repository implements the same simple backend API in a variety of languages. It's just a personal project of mine to get a feel for the languages, and shouldn't be taken too seriously.

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

#57

Post by kitd »

This is a great write-up. Personal impressions like this are as good as, if not better then, numbers and benchmarks for comparing languages, especially when covering things like how easy the docs or tooling are to use. That's the side of a language that most affects devs day-to-day.

Looking forward to the reports for plain Java and Nim.

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

#58

Post by awestroke »

andreygrehov wrote: post #15

According to the results, Go and Rust pretty much beat every other language. While Rust is the clear winner, it has a steep learning curve. When it comes to Rust vs Go, I always choose Go, because it still beats all the other languages and at the same time an extremely simple language to learn / read / write. This triplet has a greater weight in my books.

I always choose rust, because the tooling and language feel thought through and it's easy to write once you learn it.

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

#59

Post by Someone »

int_19h wrote: post #39
losvedir wrote: 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…

Regarding C#: > The "billion dollar mistake" is important to me, and while C# has non-nullability sugar in its typesystem (i.e. with ? after a number of types), the type system wasn't as rigorous as I was maybe hoping. I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't ex…

> I'm genuinely curious if you have any examples? Nullability checks may be bolted on, but once you enable them, they should consistently prevent you from dealing with any null values that you haven't explicitly allowed.

I’m not the one you asked, but there’s a difference between you no longer having to deal with null checks and your program no longer having to deal with null checks.

The CLR will still do the null checks and fail your program fast when needed. Other languages will require you to properly handle them (or at least, make it obvious where you chose to bluntly abort the program when they occur)

I also don’t think C# will prevent you from forgetting to do a if null check in cases where you expect values to sometimes be null.

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

#60

Post by belmont_sup »

KingOfCoders wrote: post #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.

I like that he made choices based on value per effort. I would’ve done the same thing too.

But that’s a fair take. Go’s web server ecosystem has diversified a lot too, and I’m sure his pick would’ve affected the outcome a reasonable amount if he had chosen fasthttp or gin for comparison.

Post reply on HN