Here comes part II of the Hamler blog post series …
For this year’s Advent-of-Code I wanted to take a look at Hamler.
I just finished implementing all of the part-1 solutions in Hamler.
I had to skip Day 20 (the seamonster), because Hamler only supports a very small/limited number of packages, which means I would have needed to write a lot of code before I would have been able to tackle the actual problem.
Hamler is under active development and I started to build it from the main branch to make sure I can use some features/capabilities that I needed/wanted (e.g. read) to make my life easier.
My development environment (emacs) had the source code in a frame on the left and an iwatch -c 'hamler test' src/Day00.hm on the right (that way the tests where running every time I saved the file). I also had a window/frame open with a hamler repl in it and was cutting/pasting code from/to it. This was a very limited IDE, but it worked.
On Day 23 I build Hamler again and afterwards was not able to make the repl work again. And without the repl development became very cumbersome.
So I decided that it is time to bite the bullet and port all of the code to Haskell.
That went well, because my Hamler code was very haskell-ish. Means it was not using any of the Erlang capabilities (e.g. GenServers), which made porting it easy (mainly changing Integer to Int, changing list pattern matching from [x|_] to (x:_) and changing some of the functions (e.g. splitOn)). You can take a look at some of the commits to get a feel for the changes I had to make.
One big difference was obviously that (suddenly :)) I had a fully functional IDE again (code completion, LSP language server, …) and that was huge!!!
After I was done porting Day 1 to 22 to Haskell, I developed the solutions for Day 23 to 25 in Haskell and ported that code back to Hamler. That worked too.
At the end I did a little bit of benchmarking between Hamler and Haskell. In general Hamler is roughly 5-20 times slower than Haskell. There was/is something wrong with Day 21. For that day Hamler is 6000 times slower than Haskell (running the same code).
So far the main take-aways for me are …
- Hamler works much better than I expected
- But there is a lot of tooling missing to support a good development experience
- And there are (a lot of) packages missing
- And Hamler is slower that Haskell
… and this assessment is not really fair, because it suggests to look at Hamler as Haskell on the BEAM.
I am not sure this is a good/the right way to look at this. For me a better/the right way to look at this is to compare Hamler with Erlang and ask: What is Hamler giving me that Erlang is not giving me?
I think the core strength of Hamler is not that it is a better Haskell, but more that it allows you to get to the capabilities of the BEAM writing Haskell-like code.
The next step will be/needs to be to investigate some of these strength more (using GenServers, (re)using/linking with existing Erlang/Elixir artifacts, …). Stay tuned …