DAML: A Haskell-Based Language for Blockchain

Digital Asset is a fintech company that helps companies design and run the next generation of business applications. One of their products is DAML, a functional smart contract language.

While we have already covered Digital Asset in our functional programming in fintech overview, I recently got a chance to talk with Anthony Lusardi, a developer advocate at DAML, and delve deeper into the product. In the interview, we talk about DAML, the benefits and downsides of functional programming languages, and their practical experience while building DAML.

Interview with Anthony Lusardi

Hi! Could you shortly explain what DAML is?

Sure! DAML is an open-source smart contract language with roots firmly planted in Haskell. It’s designed so multiple parties/business entities can perform workflows with high assurances and consistency between parties. So you have this transactional language that is atomic with every update, high level, portable across data persistence backends, and with strongly enforced permissions over who can update data when.

In more practical terms, imagine you’re managing an operationally complex workflow where multiple different stakeholders (ie. parties) need to see and interact with different parts of the workflow, definitely should not see other parts, and have a complex tree of dependencies. Today implementing such a thing is truly hard to manage with complex access control schemes implemented at a level outside of your program, and substantial difficulties maintaining data privacy. DAML treats these concerns as first-class elements of every class (what DAML calls templates) and thus makes it much easier to implement and manage these types of workflows.

Why should customers choose DAML over building their project on Ethereum, Tezos, or other public blockchains?

This really boils down to their needs. If you’re building something that truly needs permissionless, censorship-resistant, and entirely public transactions, then a public blockchain might be a good fit despite what would be substantial tradeoffs for most real-world applications in terms of low data storage, poor privacy, and high cost. DAML, on the other hand, won’t give you a permissionless architecture but will allow you to have high data storage, strong privacy, and significantly lower costs.

In practice, very few use cases actually need the properties of a permissionless public blockchain. The one that comes to mind for me where a public blockchain is a better fit would be Bitcoin for permissionless value storage/transfer.

While I think there are some interesting projects on Ethereum, I’m not personally convinced most use cases need Ethereum’s architecture as, with a few exceptions, most have components that in practice are replaceable and centrally administered by their development team. In such cases, these teams are trading off ease of operation for decentralized architectures and really getting neither. That is, of course, open for extensive theoretical debate that is well beyond the scope of this interview :)

What’s the main thing that separates DAML from other enterprise blockchain platforms like Corda and Hyperledger Fabric?

DAML applications can be written once and deployed on any supported platform without changing a single line of code. In this way, your code written in DAML is decoupled from the underlying backend allowing for much greater architectural flexibility.

In fact, DAML actually runs on these platforms (and many others) with a runtime that runs alongside them and uses them for data persistence and consensus. It’ll even run on PostgreSQL. It’s truly platform-agnostic.

What’s the benefit of basing DAML on functional programming languages like Haskell and Scala?

Simple. Functional programmers are the best programmers.

More seriously, though, the language is based on Haskell but has conventions and differences that make it uniquely its own language. The general benefits are a high degree of composability, as anyone who writes in functional languages knows, when your types match your functions and components can easily work together and extend each other. Functional languages are also beneficial for the more distributed applications that DAML is designed for because they reduce bugs and allow for better ensuring that operations will or won’t complete; both of which are big concerns whenever you’re writing a distributed application.

Are there any features of the language that really help smart contract language development?

Most definitely. DAML has two features that really help. The first is that all data concerns are laid out in templates and strongly typed. In a lot of ways, these templates are much like classes in imperative languages but they will always do what you expect them to.

The other feature (and this is really smart-contract specific) is that DAML treats permissions as first-class citizens, so we have observers, signatories, and choices which you can consider respectively akin to UNIX’s rwx permissions. Every template specifies ahead of time who has the authority to read, write, and execute functions on a given instance of that template (what we call a contract in DAML).

Have you seen any non-technical benefits? ( e.g. is it easier to hire good developers, etc.)

Reductions in codebase size and operational complexity are definitely benefits. It’s really designed from the ground up to allow developers to focus solely on business logic without having to worry about the backend. These factors, in turn, make DAML applications cheaper to maintain and easier to extend. Basically, all the benefits functional programmers have been touting for a long time.

One other great benefit is readability. While it takes a programmer to write DAML, many non-programmers can comprehend much of a DAML contract with just a little bit of familiarization. This really comes as a direct consequence of how explicit DAML is about data concerns and permissions. You can check out an example of this readability at https://beer.woah.xyz.

What about downsides? Are there any downsides to choosing a programming language for your project that is not that popular?

There certainly are, but if you’re reading this blog post, then you probably already use non-mainstream programming languages that are still wonderful and let you get your work done in effective ways that mainstream languages don’t support. Innovation happens at the edges so I think DAML’s benefits in the smart contract space and its enthusiastic and supportive engineers on our forum more than outweigh the tradeoffs.

Really the biggest concern people have is essentially “if I choose to invest time in learning this language, will it still be there next year?” and for that, the answer is yes. DAML is an open-source language maintained by Digital Asset, which is a company of 140+ people currently and growing. DAML will be here for years to come.

Do you feel happy about your choice to create an FP language for your project?

I don’t think you could build a non-functional language that accomplished what DAML does. It’s really a prerequisite for the rest of the stack. So in that sense, yes, and also the decision was made well before I joined Digital Asset.

If you had to give one tip to customers looking to come into the blockchain/DLT space, what would it be?

If the app needs you to first buy a token to use it, then run away.

I would like to thank Anthony for the interview and wish DAML the best of luck in conquering the private blockchain market!

If you wish to get more details on DAML, go straight to their homepage. You can also follow DAML on Twitter for updates and cool blog articles.

For more interviews with interesting projects in the functional programming space, be sure to check out the interview section of our blog.

Serokell is a blockchain development company with years of experience in the field. Contact us if you need a customized blockchain solution for your business.