sccache caches at the per-rustc invocation level, whereas we cache at the package level. In practice, this means we get more cache hits and our cache hits take less overhead to load. You can see the benchmarks in our CI!
Monads are a generalization of Promises. Each type in Monad defines their own `.then` in a different way. For promises, `.then` is defined as "run this function once you have this deferred value from the last promise". For optionals (`Maybe`), `.then` is defined as "run this function if the last optional had an actual value". For Either, `.then` is defined as "run this function if the last Either returned Right, otherwise early-return with the value from Left" (this is functional early-return, basically).
This is the first explanation of monads I've heard that makes intuitive sense to me and feels like it sufficiently captures the point. Unless I come back in a few hours to see a bunch of replies from uber-haskellers saying "no that's not what a monad is at all," then I'll consider my search for a good monad explanation to finally be over.
You need to be able to "wrap" values and then also "wrap" functions in the way you expect. That's literally it.
Btw, the list monad example is stupid imo and borderline misleading. The promise/nullable/Either examples are better. you "wrap" a function by putting it as the only value in a list, and "map" pretty much acts as your function wrapper, but technically this you need to jump through a couple hoops to make it monadic, and I'm just not sure the metaphor is helpful here
For some monads the "wrap" gets awfully metaphorical (for State it's a function that produces the value and updated state, for Const there is no value, etc) but I don't think that's actually a problem, just a thing to be aware of. There is certainly no expectation that you can actually get your hands on the thing.
A bigger issue is that you're missing a piece. If you can "wrap" values and "wrap" functions such that they operate on wrapped values, you (probably) have a functor. To be a monad you also need to have the ability to turn multiple layers of wrapping into one layer of wrapping. For lists, that's "flatten".
I said "probably" above because there are rules these pieces need to follow to behave well. They're pretty simple but I don't think we need to dig into them at this level of discussion.
Agree about the list monad. I have never used it in actual code. I always felt it was so arbitrary, and "implicit", in the sense that if you haven't learnt beforehand that it makes "joins", then it's certainly not obvious that it should work that way
λ> do { a <- [1,2]; pure a; }
[1,2]
-- oh so it returns the list unchanged
λ> do { a <- [1,2]; b <- [3,4]; pure a; }
[1,1,2,2]
-- no what is this spooky action at a distance
λ> do { a <- [1,2]; b <- [3,4]; pure [a]; }
[[1],[1],[2],[2]]
-- ...
λ> do { a <- [1,2]; b <- [3,4]; c <- []; pure [a]; }
[]
λ> do { a <- [1,2]; b <- [3,4]; c <- [5]; pure [a,b,c]; }
[[1,3,5],[1,4,5],[2,3,5],[2,4,5]]
This is misleading IMO because Promise is a particular kind of monad but in general monads don’t necessarily have anything to do with asynchrony. It is a useful example though because some people are more familiar with the API of promises.
I might have some inaccuracies in how I state this since I’m not from a functional programming background, but I think of monads as an abstraction of chaining functions over a value such that each returned value can specify what further transformations it supports, and particularly in such a way that generic transformations (like sequence reversal) can easily be applied, and errors or empty values can be accounted for within the control flow.
I think sometimes people call this a “fluent API”, but I would never call it “a generalization of callbacks” or of promises.
Anyway there’s a much more mathematically precise way of stating it but this is my intuitive caveman way of thinking about it.
Yup, this was similar to our experience as well. If publishing is still a source of toil for you, feel free to reach out at eliza@attunehq.com - we'd love to see if we can do any dev work or hosting pro bono for your open source projects.
I'm not familiar with mise and ubi, but these look like they're tools that the end user runs to install binaries. In contrast, we're building something that sets up a server so that end users can use their existing `apt-get install`.
Yeah, multi-distro and multi-arch is something on our roadmap! We're especially interested in automating the more annoying OS-specific parts of releasing, like MacOS notarization.
Thanks for trying, and sorry in advance for the rough edges :)
We're also working on a hosted service! If you'd like a sneak peek, send us a message at founders@attunehq.com (or email me directly at eliza@attunehq.com). I'm happy to talk about your specific needs and see if we can build something for them.
(And yes, it is Rust. I keep trying to find projects where I get to stretch my Haskell wings again, but unfortunately I keep working on things with silly requirements such as "easily understandable performance" and "a cross-compilation story" and "not making my collaborators sit through another monad tutorial".)
We don't plan to do that right now. The CLI isn't that complicated, and the choice for that was driven more by Go's excellent cross-compilation story than anything else.
It would be a fun thing to do if we had the resources to get equally good cross-compilation in Rust, but we're focused on building functionality right now.
