Learning Haskell before Rust?


I find it convenient to use the same language everywhere as much as possible in a project.

Of course there is the perfectly valid argument "use the right tool for the job".

Well, Rust is a good tool for small and or bare bones embedded systems where you want to get down to the low level details. Whilst at the same time I find it works very well on the server end for handling data collection, REST API's, database interaction as well. As a high level language almost as easy to write as doing the same in Javascript and node.js etc.

So I'm happy.

1 Like

I think I start to understand functional programming. I solved the "Single Number" task from leetcode in a single line

nums.iter().fold(0, |y, x| y ^ x )

I wasn't seeking to provide mainstream examples. 50 million Frenchmen can be wrong. I would cite Perl as Exhibit A. Both D and Nim are good work, in my opinion and do have some following. If you define 'mainstream' by the Tiobe ranking, then Rust isn't mainstream either, currently in 25th place, below things like Scratch and Delphi/Object Pascal. D trails Rust, in 34th place and Nim is somewhere in 50-100.

As for mention of garbage collection in Nim, you just haven't looked hard enough: https://nim-lang.org/docs/gc.html.

You also wondered in another post why rustfmt upset me so much. Try doing some Googling to find out how others feel about rustfmt. The defaults, in my opinion, make an utter unreadable tall skinny mess of the source code and trying to configure it fails utterly. And yes, I've tried the nightly version. There are options that are documented that aren't present in the nightly and those that are present don't allow me to correct the problems. I've used dfmt and even zig fmt and gotten good results (programming languages are a particular interest of mine and so I have a rather broad repertoire). astyle does a nice job with C code.

The intent of my post was not a 'scathing critique'. Rather it was to point out that, again in my opinion, there is a substantial cost -- in the slope of the learning curve -- to Rust's approach. I think that cost needs to be considered vs. the alternatives especially when considering a language for writing an application that has no real-time constraints.

I take rankings like the Tiobe with a pinch of salt. Interesting and one of many data points in choosing a language. You won't find me getting into language just because it at the top of the list. I use what gets the job done for me. Of course many languages can get a particular job done, so there is inevitably some subjective, non-technical, reasons for making a choice.

Personally I feel we should all use rust fmt, with default settings, and stop wasting time fretting over formatting. Then we will all produce an ocean of code that is formatted the same way, which will make life smoother for everyone.

As it happens rust fmt rarely does something I don't like. Looks like that's because I'm an 80 column max. kind of guy. Not rigorously mind. What you call "unreadable tall skinny mess" is how I like it. Long lines crammed full of as much as possible are hard on the eyes and much harder to read. There is a reason books are not short and fat and columns in newspapers and such are narrow. Short lines also make what happened in changes in git diffs and such harder to fathom.

I do agree. Rust has a lot to learn and requires some effort to get into. That is of course a cost to consider. But what language does not?

I considered that cost and concluded that 1) The cost will be recouped in the saving on bug hunting time. Every issue that the compiler annoys one about would an order of magnitude more expensive to deal with after the code is in production. 2) That cost is not likely to be much more than if I were to try and get into Perl or Haskell.

In my life all program have real-time constraints. Not always "hard real-time" as in the embedded world but everyone is concerned about performance now a days. From mobile phones to super computers with data centers along the way. Everyone is concerned about response times for users and energy consumption. Good performance is good for both.