Building on Cardano Without Haskell: Modern Paths for Developers

Cardano, a prominent third-generation blockchain, has distinguished itself with a rigorous, research-driven approach to security and scalability. Unlike many other ecosystems, which often center on a single dominant language (such as Ethereum's Solidity), Cardano supports a diverse array of on-chain programming languages for smart contract development.

This article aims to guide newcomers through this unique landscape, shedding light on the various on-chain languages available and how they may interact with off-chain development. For both developers crafting the next generation of decentralized applications (DApps) and entrepreneurs considering building on this robust platform, understanding these distinct options is paramount to making informed strategic decisions.

The two sides of smart contract development

Building DApps on Cardano requires a clear understanding of both on-chain and off-chain programming. These two components work in tandem to create a complete and functional experience.

On-chain programming

At its core, on-chain programming involves writing the smart contract logic that executes directly on the Cardano blockchain. This code uses the Cardano Ledger and the underlying Plutus Core execution environment to ensure secure, verifiable transactions. Within the Cardano ecosystem, developers have several options, with at least seven primary on-chain languages available for crafting these critical smart contracts.

Off-chain programming

In contrast, off-chain programming handles all blockchain interactions without directly executing on it. This includes building user interfaces, managing transactions, and preparing data for on-chain consumption. Think of it as the bridge between your users and the decentralized world. Every day, off-chain tasks include developing user-friendly wallets, designing DApp frontends, and creating services that monitor blockchain activity. To achieve this, developers use a range of robust off-chain tools and libraries, including Lucid Evolution, Cardano Client Lib, pycardano, Plu-ts, and Atlas.

Interactions between on-chain and off-chain languages

The power of Cardano smart contracts emerges when applications can invoke them and interact with them from the off-chain environment. This interface allows DApps to extend functionality beyond the blockchain. All on-chain languages produce artifacts that off-chain libraries such as Lucid Evolution can invoke, and these languages do not create distinct off-chain interaction pathways unless they support an isomorphic model.

For example, Scalus provides shared syntax that simplifies the developer experience, while a contract written in Plutarch can still integrate with a Java application through standard libraries. This interaction layer is essential for building complete decentralized applications, even when the underlying on-chain languages share similar invocation patterns.

An emerging ideal in this space is isomorphic development, where shared syntax aims to reduce cognitive load when working across environments. In practice, only a small portion of logic, often between 5-10%, can be shared effectively between on-chain and off-chain code because the complexity of the two environments limits deeper reuse. Languages such as Plu-ts explore this direction by offering a familiar TypeScript syntax for both domains, although the benefits remain primarily syntactic rather than semantic.

Not all on-chain languages include a direct or mature off-chain counterpart, and this rarely defines their value. Developers generally prioritize commercial stability, predictable maintenance, and strong performance rather than syntactic convenience. CPU and memory usage, and the resulting execution cost, affect the viability of a contract because users incur these costs directly, and excessive resource consumption can prevent a transaction from succeeding.

Aiken provides an example of a language that continues to gain favor because it delivers efficient execution, clear semantics, and strong compiler assurances. A language that combines these strengths with effective syntactic alignment holds an advantage, but languages without these core attributes often lose ground even when they offer syntactic ease.

Exploring programming language levels

Programming languages are categorized by their level, which describes the degree to which they abstract away the complexities of computer hardware. This isn't a judgment of good or bad, but rather an assessment of their design trade-offs. Higher-level languages offer greater abstraction and ease of use, while lower-level languages provide more direct control and optimization potential.

General programming language levels (on-chain and off-chain)

Importantly, levels represent just one method of categorization. The best language often depends on the specific project, developer preference, cost constraints, and the required level of completeness for certain smart contract functionalities.

Low-level

These languages are tightly integrated with hardware, offering maximum control and optimization potential, but they require a deep understanding of computer architecture. As such, they are generally not beginner-friendly.

Example: Assembly uses mnemonics that directly map to CPU instructions, dictating operations with the processor's fundamental primitives. An assembler (like Jasmin, a Java assembler interpreter) translates assembly code into machine code for execution.

Medium-level

These languages strike a balance, offering more direct control than high-level languages while still providing significant abstraction.

Example: C, which allows for memory manipulation and closer hardware interaction, making it suitable for system programming.

High-level

These languages prioritize developer productivity and readability by abstracting away intricate hardware details, simplifying the development process. They often rely on virtual machines or interpreters to translate code into machine-executable instructions.

Examples: SQL, CSS (declarative languages that focus on what to achieve), Ruby, Python, Kotlin, C#, Haskell. These languages hide much of the underlying processor's workings, including the low-level virtual machine (LLVM) or runtime environments.

A framework for assessing Cardano's on-chain languages

The following section will delve deeper into specific smart contract languages within the Cardano ecosystem. We will assess each language based on key metrics: the performance of compiled code, the difficulty for developers outside the Cardano ecosystem, their closeness to mainstream programming, ease of debugging, overall friendliness for developers, and the availability of comprehensive documentation. We will also briefly touch on their off-chain friendliness or isomorphism.

Plinth

• Language developer(s): Plinth maintainers within the Cardano community
• Performance: Plinth contracts tend to consume more resources, increasing on-chain execution costs and reducing efficiency.
• Developer difficulty: High. The learning curve remains steep due to Plinth’s Haskell-based syntax.
• Closeness to mainstream: Low. Plinth functions as a specialized subset of Haskell.
• Debuggability: Low. Practical debugging is challenging. The compiler operates as a GHC plugin with limited tooling support, and developers often rely on VM internal tracing.
• Environment friendliness: Medium. Straightforward for Haskell developers but harder for teams without Haskell experience.
• Off-chain friendliness: High. Supports an isomorphic model allowing shared functions.
• Documentation: Available.
• Notes: Strong control and isomorphism, but higher resource consumption and complexity limit accessibility.

Aiken

• Language developer(s): Led by Matthias Benkort with contributions from the Aiken open-source community
• Performance: Excellent performance with very low memory consumption and CPU usage, enabling highly efficient on-chain execution.
• Developer difficulty: Low. Aiken introduces a minimal, focused set of functional programming concepts, creating an accessible learning path despite its functional nature.
• Closeness to mainstream: High. The language maintains a functional design while offering syntax and ergonomics familiar to developers with mainstream programming backgrounds.
• Debuggability: Good. Although Visual Studio Code does not include a native debugger, Aiken provides an emulator for running and testing contract code, and Gastronomy can generate source maps that enable step-by-step debugging of generated UPLC.
• Environment friendliness: Very high. Aiken offers a strong developer experience through a simple single-binary setup, robust Visual Studio Code integration, an embedded Language Server Protocol, formatting, import management, go-to-definition, hover documentation, type information, quick fixes, an integrated playground, and a documentation generator with Markdown and MathJax support.
• Off-chain friendliness: Medium. Aiken provides built-in support for CIP-0057, transaction simulation, and flexible configuration patterns, but it does not support an isomorphic model, so some code duplication may be required.
• Documentation: Strong documentation with clear structure and detailed guides.
• Notes: Aiken emphasizes performance, clarity, and developer experience, and its balance of accessibility and execution efficiency has made it a leading choice within the Cardano ecosystem.

Scalus

• Language developer(s): Scalus maintainers and contributors within the Cardano developer community.
• Performance: Moderate. CPU and memory usage sit above Aiken but below Pebble, with ongoing work aiming to reach performance parity with Aiken.
• Developer difficulty: Medium. Scala is less ubiquitous than languages such as Java or Python, yet its C-like syntax and expressive features make it approachable for many developers.
• Closeness to mainstream: High. Despite its functional orientation, Scala aligns well with mainstream development practices and offers a simple yet expressive set of constructs.
• Debuggability: Very high. Full IDE support, including IntelliJ IDEA tooling, improves debugging and developer productivity.
• Environment friendliness: Medium. Setup remains manageable, though installing the Java Development Kit may require additional steps for teams unfamiliar with the broader Java ecosystem.
• Off-chain friendliness: High. Supports an isomorphic model that allows functions to be shared between on-chain and off-chain components where appropriate.
• Documentation: Documentation is available.
• Notes: Offers a balanced combination of expressiveness and isomorphism.

Plutarch

• Language developer(s): Plutarch maintainers within the Cardano community.
• Performance: Strong performance characteristics, although the language can feel less intuitive compared to more accessible options.
• Developer difficulty: High. Plutarch introduces significant complexity for developers without prior Haskell experience due to its typed embedded DSL structure.
• Closeness to mainstream: Very low. Plutarch is a typed eDSL built in Haskell, which limits its alignment with mainstream programming languages.
• Debuggability: Relies on standard Haskell tooling, though information about ease of use or specialized debugging workflows remains limited.
• Environment friendliness: Very low. Development requires a Haskell-based environment, which increases setup complexity for teams outside the Haskell ecosystem.
• Off-chain friendliness: Low. Off-chain integration introduces a higher learning curve, particularly for developers who do not work with Haskell in their broader application stack.
• Documentation: Documentation coverage varies.
• Notes: This assessment reflects Plutarch (1). Plutarch (2) remains under active development and may change several characteristics in future iterations.

Pebble

• Language developer(s): Harmonic Labs
• Performance: Strong performance relative to earlier TypeScript-based DSLs. Generates efficient Plutus Core code, though performance depends on careful authoring because of the low-level exposure.
• Developer difficulty: Moderate. Familiar TypeScript syntax lowers the barrier to entry, yet developers must understand the Extended UTXO model and certain low-level Plutus semantics.
• Closeness to mainstream: High. Uses TypeScript, providing broad accessibility and aligning with skills already held by many development teams.
• Debuggability: Improved over earlier versions, with clearer error messages and better tooling, but still constrained by the inherent complexity of translating TypeScript expressions into Plutus Core.
• Environment friendliness: Moderate. Requires a TypeScript development environment and node-based tooling, though integration remains straightforward for teams already working in web or full-stack ecosystems.
• Off-chain friendliness: High. Strong alignment with TypeScript enables unified patterns across off-chain code, supporting smoother integration in isomorphic or near-isomorphic workflows.
• Documentation: Growing and more structured than earlier versions, though still maturing as the language evolves.

Helios

• Language developer(s): Independent open-source developer; maintained under the HeliosLang GitHub organization.
• Performance: Strong performance across most use cases, though current implementations do not yet match the execution efficiency of Aiken or Plutarch.
• Developer difficulty: Low. JavaScript compatibility provides an accessible entry point and enables a broad developer base to adopt the language quickly.
• Closeness to mainstream: Very high. Direct alignment with JavaScript creates strong compatibility with mainstream development practices and familiar programming patterns.
• Debuggability: Limited formal debugging support at present. A proposal for a VS Code debugger plugin has been submitted to Project Catalyst, indicating potential improvement.
• Environment friendliness: High. Strong integration with Visual Studio Code and a browser-based playground creates a supportive and accessible development environment.
• Off-chain friendliness: High. Supports an isomorphic model, enabling shared patterns and code between on-chain and off-chain components where appropriate.
• Documentation: Good documentation that supports onboarding and contributes to broader adoption.
• Notes: Early-stage ecosystem relative to other languages, yet notable for accessibility, mainstream alignment, and developer-friendly tooling.

OpShin

• Language developer(s): OpShin project maintainers; open-source contributors within the Cardano community.
• Performance: No publicly available benchmarks currently exist, so performance characteristics remain undetermined relative to other Cardano smart contract languages.
• Developer difficulty: Low. Python compatibility provides an accessible entry point for a broad developer audience and reduces the learning effort required to begin building on Cardano.
• Closeness to mainstream: Very high. Alignment with Python offers strong familiarity for mainstream developers and supports broad potential adoption.
• Debuggability: No formal debugging tools have been published to date, and information on OpShin-specific debugging capabilities remains limited.
• Environment friendliness: High. Benefits from the established Python ecosystem, including syntax highlighting, linting, static analysis tools, and mature testing frameworks.
• Off-chain friendliness: Moderate. Does not support an isomorphic model, so on-chain and off-chain code cannot be shared directly. However, integration remains straightforward through off-chain Python libraries such as PyCardano.
• Documentation: Good documentation that assists adoption and supports developers as they explore the language.
• Notes: Stands out for accessibility and alignment with mainstream Python frameworks.

As we've explored, the landscape of smart contract languages within the Cardano ecosystem is rich and rapidly evolving. It's essential to note that while all are mainnet-ready, some of these languages and their associated tooling are still under active development, and gaining full access to operational metrics for all users can be challenging. Our assessment here is a best-effort exercise based on currently available information. Ultimately, the optimal language choice for your project will hinge on its specific needs, your team's existing expertise, and your core priorities.

Virtual machine interactions

The virtual machine sits at the core of smart contract execution, yet a language’s abstraction level does not always determine the difficulty of building reliable applications on Cardano. The most significant challenge often does not arise from syntax or semantics, but from the need to reason within the Extended UTXO (EUTXO) model. Developers must map real-world business logic onto EUTXO’s deterministic structure, which imposes constraints unfamiliar to those coming from account-based systems. This “impedance mismatch” explains why tools such as Starstream aim to abstract parts of the EUTXO model rather than remove functional or syntactic complexity. Even in higher-level languages, effective development depends on understanding how application logic aligns with transaction inputs, outputs, and validation behavior.

Because of this, the distinction between high-level and low-level languages does not always translate into predictable differences in performance, control, or optimization effort. Some languages, such as Aiken, demonstrate that accessibility and strong optimization can coexist, challenging the assumption that these attributes lie at opposite ends of a spectrum. Rather than focusing solely on the abstraction level, teams should consider how well a language supports reasoning about EUTXO, how it integrates with off-chain infrastructure, and how its tooling helps developers navigate validation and resource usage. These factors often shape the overall experience more than the language's surface-level syntax.

A tale of two smart contract blockchains

The virtual machine (VM) is at the heart of smart contract execution. Ethereum's dominant VM is the Ethereum Virtual Machine (EVM). While there are some niche or experimental approaches, for all practical purposes and in mainstream development, Ethereum runs on this single, unified VM. Its widespread adoption has created a rich ecosystem, mainly because its primary language, Solidity, is easy for JavaScript developers to learn. Ethereum smart contracts remain continuously available and can receive transactions at any time, with external services often creating the appearance of active, event-driven behavior even though the contracts themselves remain passive.

Conversely, Cardano smart contracts function as entirely passive validators that never initiate actions and require off-chain infrastructure to construct and submit every interaction. While this might seem more complex, it reflects a deliberate design choice that enables faster computation off-chain while settling only critical information on-chain. The model prioritizes fast off-chain execution over slow on-chain processing, benefiting zero-knowledge applications by allowing developers to generate proofs off-chain and then validate them deterministically on-chain.

Cardano takes a different approach with its Plutus Core VM. Instead of a single, monolithic VM, individual versions of Plutus Core (e.g., Plutus Core VM V1, Plutus Core VM V3) operate as distinct VMs. This design emphasizes security and formal verification. A key aspect of Cardano's flexibility is that while it uses different VMs, they must all be compatible with its Extended Unspent Transaction Output (EUTXO) model, which underpins its deterministic and parallel transaction processing.

The future: zero-knowledge optimization and specialized virtual machines

Cardano's inherent optimization for zero-knowledge is a significant advantage. Interestingly, even Ethereum's co-founder, Vitalik Buterin, wants to shift Ethereum toward a blockchain better suited to zero-knowledge proofs, potentially replacing the EVM with a ZK-VM. However, it's crucial to understand that a ZK-EVM is not directly compatible with the Ethereum mainnet and must be implemented as a Layer 2 solution.

Moreover, Cardano has historically favored functional programming languages for its smart contracts. While powerful for security, functional programming can have a steeper learning curve. However, new languages like Aiken, Scalus, and Plu-ts 2.0 are bridging this gap, making Cardano smart contract development more accessible. These languages aim to simplify complexity, making it accessible to a broader range of developers.

Both Ethereum and Cardano are advancing the development of smart contracts. However, Ethereum has benefited from early adoption and developer familiarity. At the same time, Cardano focuses on security, formal methods, deterministic transactions, and a forward-looking approach to scalability and privacy through its architecture. This approach is particularly well-suited to zero-knowledge technologies and evolving developer tools.

Key considerations for new ventures

For businesses, the choice of programming language extends far beyond technical specifications. It influences developer availability, hiring cost, and ultimately delivery timelines. Languages with broad, established talent pools, such as TypeScript, can reduce recruitment costs and support faster onboarding. For many teams, the primary adjustment when entering the Cardano ecosystem involves understanding the EUTXO model rather than learning an unfamiliar language. This distinction matters because it allows organizations to retain their existing developer skill sets while leveraging Cardano’s unique capabilities.

Enterprises should also carefully evaluate the perceived complexity of different blockchain platforms. Projects arriving from account-based ecosystems may initially find Cardano’s EUTXO model unfamiliar. However, this model offers meaningful advantages that do not immediately surface during early exploration. A language that appears academically rigorous may, in practice, deliver significant security, operational clarity, and ease of use once developers understand how EUTXO structures state and validation. The model introduces a learning curve while increasing system resilience and reducing ambiguity in contract behavior, making it valuable for mission-critical applications.

To support new ventures effectively, clear communication and accessible resources remain essential. The ecosystem must articulate how familiarity with programming languages, robust tooling, and predictable execution semantics creates a stable foundation for development on Cardano. Guidance that helps teams understand EUTXO in practical terms reduces perceived risk and highlights the long-term advantages of Cardano. This strategic clarity empowers organizations to transition confidently and unlock the platform’s potential for innovative decentralized solutions.

Choosing the right path in the Cardano ecosystem

This overview of Cardano programming languages highlighted the distinction between on-chain validation and off-chain application logic, as well as the range of languages that emerged during the ecosystem’s early growth. Despite this variety, teams do not need to learn multiple languages to build effectively. Cardano remains highly accessible because familiar languages remain viable, and the primary adjustment is to understand the EUTXO model rather than adopt an unfamiliar programming paradigm.

Although Cardano offers options, development does not require proficiency in Haskell. The ecosystem continues to converge toward clearer tooling and more ergonomic workflows, reducing fragmentation and enabling faster onboarding. At the same time, Cardano introduces a user experience profile shaped by EUTXO. Deterministic behavior and resilience form key advantages, yet applications must handle coin selection and other off-chain responsibilities that influence usability. These trade-offs allow users to avoid paying for failed contract execution and provide predictable validation behavior that supports long-term security.

For developers and businesses, the decision to build on Cardano should focus on project requirements, existing team expertise, and the level of predictability and assurance the application demands. The ecosystem continues to mature, with ongoing improvements in tooling and developer resources. As this progress accelerates, opportunities for robust and innovative DApps will expand across the platform.