Slightly disappointed in Nemerle

I've been coding with Nemerle a bit during the last couple of months. I've discovered that I had set my expectations too high. It doesn't quite live up to them. Might be as much my fault as Nemerle's, but that doesn't really change anything.

I was hoping for a experience closer to OCaml (only with better cross platform library support) than I got. With OCaml, once your code compiles, you know you are doing pretty good. With Nemerle, not so much. First of all, it feels like you get to fight a bit more with the type inferer than in OCaml. This is probably partially due to the maturity of the implementation, partially due to the fact that with OCaml, I didn't use as serious class hierarchies as I do with Nemerle, thanks to the .NET standard library and heavier Gtk+ usage.

The second problem I've encountered is that when you interface a lot with C# code, you don't really get much mileage out of the functional stuff in Nemerle. When you have a List generated in C#, you don't get to fold over it. While Nemerle does have the ICollection interface extending System.Collections.Generic.ICollection with all the functional iteration tools, there are no wrapper classes and no standalone functions. If you want a foldable List, you'll have to copy stuff. Not nice.

And third, while the variables are by default non-mutable, which is nice, and when you define your types in Nemerle you can do matching and get the safety that brings, you end up interacting so much with .NET code that you have to do the normal null checks all over the place anyway.

In short, the benefits of Nemerle over the current features of C# are feel pretty limited. Maybe it would be better if you were working with pure Nemerle projects, but at least interacting with C# eliminates most of them.

© Juri Pakaste 2023