Hacker News new | ask | show | jobs
by jcburnham 1840 days ago
So, I love Rust immensely, but it's a totally different style of programming than a functional language like Haskell. For example, Rust closures are absolutely not the same as pure functions, and if you try to use them that way you'll have a bad time. Another thing is that Rust's approach to garbage collection is "opt-in" (with Rc, etc), which is great for low-level control, but not so great when you're trying to write high-level or non-performance-critical things. And lastly, recursion is Rust is restricted by the stack, so if you try to recurse too much you'll panic. You can manually increase the stack, of course, but this is again a case of having to explicitly handle your resources.

In some sense, Yatima's trying to be to Rust what Haskell is to C. We reuse a lot of the primitives (like ints, uints, chars, etc), but in a separate runtime layer that lets you just use a lambda like a lambda, and not have to worry if you're recursing too much. Now, that comes with overhead, but in a lot of places (like on the web) that's acceptable.

Another thing to think about is determinism. One goal of Yatima is to have each content-id always run the same way given the same inputs. That means we have to forgo using things like hardware floats (or at least not without some complex wrapping) which can cause UB if you try to read their bits (even in WASM).

I think definitely we're going to want to explore both frontend (along the lines of something like https://seed-rs.org/) and backend use cases for Yatima. I'm looking with great interest at https://github.com/lunatic-solutions/lunatic to see if there's a way for us to integrate their lightweight processes. As far as I understand this is along the lines of what https://www.unisonweb.org/ is doing.

The other thing I'm thinking about is smart contracts. Since Yatima is almost `no_std`, we should be able to build it as a pallet for substrate.dev.

1 comments

> In some sense, Yatima's trying to be to Rust what Haskell is to C

Can someone explain to me how C and Haskell are related here ?

Sure, if you consider Haskell's runtime (I know that technically GHC /= Haskell, but in practice it's the only Haskell that matters, except maybe something like Asterius) all the primitives are backed by C libraries: https://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GH...

Likewise with conventions around pointers, arrays, etc. to the point where if you want to do anything really low-level or performance sensitive in Haskell, you're essentially punching a hole into C. As a random example, within the fast base64bytestring library, you find lots of use of `malloc`, `ForeignPtr` etc.: https://github.com/haskell/base64-bytestring/blob/master/Dat... And of course because this is C there aren't really many safety guarantees here.

The plan with Yatima with its primitives, and eventually when we write an FFI is to integrate with Rust in the same way that Haskell uses C. My hope is that with Yatima's affine types we might even be able to FFI to and from safe Rust (since the borrow checker uses affine types), but this is a little bit of a research project to see how much that works. Even to unsafe Rust though, we have better safety guarantees than C, since unsafe Rust's UB is still more restricted than C's is.

Haskell's GHC compiler (eventually) transforms haskell into a "fictional assembly" called C--. It has no relation to C at all except in the generic sense that it's a low-sugar low-semantics low-level language, intended to be a machine-friendly view of high level haskell. Maybe the author meant that relationship in the generic sense. (C--could be transformed to C to be read or compiled, but it could equally be transformed into LLVM IR or native.)

Some languages do compile to C (if only for the portability and compiler quality). C++'s first compiler used such a technique.

I wasn't talking about C--, more about how GHC essentially exposes C libs for its primitives. Also want to clarify that Yatima doesn't compile to Rust either.

The comparison to Haskell/C was an imperfect analogy, I was just trying to express that "functional programming language that integrates with Rust" seems like a mostly unfilled niche that Yatima could exist in