nix-store --query --tree can be very helpful to figure out the transitive dependencies of a derivation, but the output can be overwhelming for many complicated derivations.
Here’s an example of what the output of nix-store --query --tree looks like:
Coming from Haskell, I felt that it was pretty easy to get started with Rust.
From what I’ve seen so far, people new to Rust have trouble with the following things:
Traits (typeclasses in Haskell)
Lifetimes
Ownership, moving, borrowing, references, etc
Traits are pretty much a subset of the functionality of Haskell’s typeclasses, so they shouldn’t give you much of a problem.
Lifetimes aren’t a thing in Haskell, so they might give you a little more trouble. However, I didn’t have much trouble with them after reading the section in the Rust book about them. I think it is because the rules governing lifetimes somewhat resemble parametric polymorphism in Haskell. (Although I should say that I havent done a huge amount of Rust, so it is possible there are some really tricky things I haven’t stumbled on yet.)
The thing I had the most trouble with was ownership, moving, references, and borrowing.
I feel like I had to write maybe 1500 lines of Rust to have a clear idea how this worked, and then another 1500 to actually start to feel comfortable.
However, I still don’t feel like I have a perfect understanding of how to write the most polymorphic code in terms of ownership. That is to say, how to write functions that can be called from the most places.
The nicest thing I found about Rust is the community. Having an enthusiastic community, and backing by a company make a world of difference. I really can’t overstate how nice this is.
Here are the biggest things I dislike about rust coming from Haskell:
No polymorphism over higher-kinded-types. This isn’t a huge deal if you’re just writing applications, but it sucks if you’re writing a library, or trying to creat some types of abstraction. Not having functor/applicative/monad/foldable/traversable is really terrible.
In my opinion, this is the number one reason I’d continue to write any “serious” projects in Haskell.
(I was going to add a second thing here, but nothing is coming to mind. I’ll update this list if I think of anything)
I have missed higher-kinded types on several occasions, but I think there is also a large benefit. If you have to use another Rust library, they are usually pretty easy to understand, because the Rust ecosystem does not suffer from abstractionitis as much as the Haskell ecosystem. This was the primary reason I stopped using Haskell after two years or so – there were a lot of abstractions to learn, every library used a different set of abstractions (I was using Haskell at a time that there were several competing ‘lens’ implementations), and abstractions were changing every few months.
If there is one thing I would take from Haskell, it would be more pedestrian: a good REPL. Unfortunately, Rust does not really have the lightweight syntax necessary to make it amendable for REPLs. There is a Jupyter kernel though.
language extensions were also a big source of complexity for me when I was trying to learn. I would look at some of the more “advanced” codebases which would have 12+ language extensions turned on, and it’s a completely different language.
Thanks, I hadn’t seen that, but it is spot-on. Haskell is both a great research vehicle and a great production language, but the mixing of both purposes sometimes make things hard on the production side. I look forward to see what comes from his efforts!
I think this is a good point. Haskell gives you almost unlimited freedom for abstraction, but that freedom definitely comes with a cost. It’s annoying when you want to reach for that type of abstraction and it doesn’t exist, but it definitely makes the language/ecosystem harder to learn.
