[carterschonwald]

Yeah. I’m pretty familiar with the history of their tech, and the problems with DAML and how they architected everything predate the surface syntax being Haskell.

Source: I was the evaluator of DAML for Jpmorgan.

The way daml is setup makes it more of a weird sibling of GRPC for stateful resource protocols. But where you have to write your own db and interpreter tooling to ingest the commands if you want all the usual nice things you’d expect from a database

[scrumper]

And a very patient and curious evaluator you were too (I was one of your counterparts at DA).

> The way daml is setup makes it more of a weird sibling of GRPC for stateful resource protocols.

Yes, well said. I think that's quite fair. It's wrong to look at it through the lens of Haskell (or any other FP language), it's really a declarative language for describing process flow and actor rights and obligations. Not something you could write a complete program in. A better way to think of it is as a big DSL for controlling state machines; you still need all the machinery around the outside to advance execution, handle IO, trigger events and transitions etc.

It's syntactically similar to Haskell because the people who created it were Haskell heads out of ETH Zürich. That's the only connection.

[carterschonwald]

The intial surface language for the dsl was actually not Haskell! But I think eventually shifted to using ghc as a frontend library?

I’m not sure if I was the most patient of evaluators ;). If I was despite that one of the more patient evaluators, wow!

I kinda view everything in this space from the lens of tools I want to build for myself. Namely a decent transactional db system where the modelling language for datatypes and workflows is a linear logical concurrent functional language with some soundness guarantees. I did build a preliminary version of the core of that at jpmorgan, though for various reasons it never saw the light of day

[scrumper]

> But I think eventually shifted to using ghc as a frontend library?

That's right. It happened fairly quickly, part of the efforts to formally verify the language. I think when you were poking at it was around the time it was changing underneath. But, that was years ago!

> Namely a decent transactional db system where the modelling language for datatypes and workflows is a linear logical concurrent functional language with some soundness guarantees.

I mean that's largely what Daml was trying to do. But of course it lacked the transactional DB system once we tossed out our in-house DLT. The approved answer back then was, deploy it over someone else's blockchain/DLT. Well, we all know about those. So before I moved on I spun up a successful skunkworks effort to integrated it into some relational databases; you'd be surprised what _that_ implementation ended up at the heart of.

Well, patient is maybe not the right word :) You weren't ever a dick though and that put you in a small club. You can draw your own conclusions about the space I'm talking about (Haskellers, JPMorgan, enterprise DLT...)

(I'll ping you separately as I have you at a disadvantage. For various reasons I won't put my name in this thread.)

[carterschonwald]

I assume you remember or heard of the crayons incident then ;)