Slang + EDR

Our long-term plan to unleash Ethereum’s developer experience potential.

Editor’s Note (Sept 2023): Our Rust runtime project, previously named Rethnet, has been renamed to EDR (Ethereum Development Runtime). For clarity, we’ve updated this piece.

A development platform is only as successful as its tools, and the higher the complexity in the platform-language combination, the more its success depends on the success of its tools.

Rust is the gold standard of developer experience. They achieved this level of quality by embedding developer experience as a core value for the project and prioritizing it as a functional requirement across all aspects of the product, including the lowest layer of the platform: the compiler.

Most modern successful languages like Go, Rust, Swift, Kotlin, or TypeScript have concrete tactics to make developers happy. They manage the different components that make up the programming experience in a carefully coordinated dance to produce a smooth and stable experience.

Some examples:

• TypeScript includes a new version of the language server with each new release of the language.
• Rust releases a new version of basically everything alongside each release. Linter, package manager, libraries, etc.
• Kotlin includes changes to IDE and Gradle integrations as part of the language releases.
• Go, Rust, Swift, and Kotlin all ship with a package manager and code formatter as part of the core.

It’s clear that achieving a world-class developer experience requires going beyond building a compiler. It requires building tools as part of the core language effort, coordinating releases, and importantly, building infrastructure for a tooling ecosystem to flourish.

• TypeScript offers tsserver, a service that wraps the compiler to enable a stateful interface for tools to communicate with it. This is what TypeScript editing assistance is built on top of.
• Rust has rust-analyzer, which is a separate Rust compiler frontend built specifically to achieve great editing assistance.

These kinds of efforts are what’s required to build a great developer experience in traditional development platforms. What is required for blockchain development platforms?

Ethereum-specific Challenges

In addition to all the challenges that any new programming language must address, Solidity (or any other EVM language ) faces at least two unique challenges specific to running on Ethereum.

Immutability

Once immutable code is deployed and usage picks up, there’s no upgrading of the language version that was used to write the contract without significant cost to the developer. This leads to versions of Solidity being used for a long time. Tools — including the compiler — need to support every version of the bytecode for a long time, since there’s no possibility of recompiling with a newer compiler and redistributing. This is a technical requirement of significant difficulty, particularly for the compiler.

Scarce Computation (Gas Costs)

The fact that computation on Ethereum is paid for makes compilers generate very minimal bytecode. Traditional compilers usually add into the compilation output debugging utilities for developers, like the generation of stack traces, but doing this on the EVM would be too wasteful.

In traditional platforms, these things are the responsibility of the compiled software, but in Ethereum they need to be done externally through runtime observation in order to reduce costs for end-users.

Runtime Observation: The Key to Ethereum Tooling

Runtime observation, as the name states, happens during the execution of compiled bytecode. This means that during the development process, the only place where it makes sense for it to happen is the local development runtime that developers use to test their code locally. This makes the development runtime the core pillar of tooling for all EVM languages.

This is what is innovative about Hardhat Network: we built it fundamentally as an EVM-level runtime observation engine, enabling it to produce Solidity stack traces, console.log statements, and to identify and explain failure cases through descriptive error messages.

This same tactic is what will eventually enable reliable and advanced step debuggers, code coverage analysis, and code profiling.

The process requires essentially reversing the compilation process of turning source code into bytecode. It starts by analyzing bytecode execution to point out insights on the original source code.

An essential aspect of this approach being successful in the long term is the compiler design being influenced by the need for transparency on how the compilation process works. Direct compiler support enables tools to reliably observe bytecode execution at runtime, collect information, and present it to developers for debugging.

The Magic Recipe: DX Core Value + Tooling Infra + Runtime Observation 💥

Developer experience is a critical aspect of Ethereum’s future as the backbone of an alternative financial system. Without good developer experience, new developers leave in frustration as the learning curve is steeper and more time-consuming. Coding is less fun.

Every improvement to the developer experience creates an immediate injection of productivity across every single team in the ecosystem, makes developer learning faster, and improves retention rates. The impact is an increase in the pace of innovation and growth, building a powerful compounding effect over the long term.

The path to a world-class developer experience for Ethereum requires prioritizing developer experience as a fundamental value in the building of core platform components. This value has to be present at the lowest level of the toolchain (the compiler) so that it can trickle up — at the developer infrastructure level so that there’s leverage for the ecosystem to build on, and at the end-user tooling level for the last-mile magic touches that make the interaction with any kind of product a delightful experience.

We’re executing a plan that follows this path by building new core building block components that will enable advanced runtime observation tooling to be the norm, bringing about many new tools offering the goodies developers love about Hardhat.

An Ethereum Tooling Platform: EDR (formerly Rethnet)

Runtime observation is a significant engineering challenge that requires working at the bytecode level. Given the platform’s nascent status, its maintenance is not a set-it-and-forget-it effort, but rather a very involved undertaking. Currently, this makes it a non-starter for teams that are resource-constrained.

To service the needs of their respective users, tools like Hardhat, Truffle, Remix, Ganache, and DappTools have all built their own form of runtime observation. Because there are no existing building blocks to do this, these projects built different ad-hoc implementations, each with a different combination of tradeoffs and limitations. This led to varying developer experiences in which the often-incomplete (even in Hardhat) mix of essential features that a developer has access to — e.g. console.log, error messages, stack traces, step-debugger — depends on the tool being used.

We’re building EDR to achieve a fast and consistent development experience, across all Ethereum tools.

EDR will be a reusable debugging runtime to build developer tools. A native, flexible, extensible, fast, and language-agnostic EVM local development runtime, as a Rust library that is designed to be the back-end for tools that provide debugging information to developers.

It will be a completely open-source public good infrastructure layer that will handle the complexities of runtime observation, but designed as a platform for others to build on top, regardless of the development environment of choice. We’re choosing Rust so that it can either be imported as a native library into any other language (JavaScript, Python, Go, etc) or compiled into WebAssembly to run in the browser.

Different tools will be able to build their own differentiated features on top of this library, and EDR will simply sit in the back-end, providing a baseline of functionality. It will directly provide console.log, stack traces, code coverage, and gas profiling, in addition to a step debugger, not just for Solidity but also for any other EVM language that wants to build an adapter.

The cost and difficulty of building an Ethereum developer tool will decrease, leading to new ones being built and to the developer experience becoming better and more consistent. We’re betting this will be the future of Ethereum tooling.

As mentioned before, doing this reliably requires coordination with a compiler that supports runtime observation as a top priority.

A New Solidity Tooling Compiler: slang

The current Solidity compiler, solc, does a good job at creating mainnet-ready bytecode that is safe — a critical aspect. Great developer experience that leads to software that can't be trusted won’t be effective in contributing to the success of Ethereum. This is why the objective for slang is to complement solc through a different set of priorities.

To facilitate the developer experience at the top of the stack, it needs to be baked in at the bottom, without compromising on other key aspects.

Designed from first principles as a platform for Solidity developer tools, the top priority will be servicing tools through domain-specific APIs and metadata to enable, among other things, runtime observation. To manage the risk of discrepancies caused by using two compilers, EDR will run slang side by side with solc to ensure that the state transitions generated by slang match those of solc.

Because the main objective of slang is tooling and not mainnet deployment, it won't have to deal with the Ethereum challenge of immutability. This means that it won't be obstructed by an impediment to change the bytecode that is produced for a given Solidity version, making it easier to provide continuous support for historical versions of Solidity. Developers will regularly benefit from updates regardless of which language version they're using.

To make sure tools can reliably work with Solidity code, it will expose its internal parser and type resolution engine. To enable top-notch editing assistance, it will provide a language server like rust-analyzer and tsserver do.

In tight coordination, slang and EDR will provide rich and stable platforms for the ecosystem to continue building new tools that offer consistency and high quality, regardless of the EVM language or application language that developers may choose.

The long-term possibilities are truly remarkable: we’re aiming to empower the ecosystem to create entirely new EVM programming languages. Just like Kotlin is implemented on top of the JVM and VB.net is implemented on top of dotnet thanks to their deep universes of infrastructure.

We’re making slang extensible, which means that implementing a parser and tweaking a type system could be all you need to get a sophisticated and comprehensive package of tooling functionality for a new EVM language, from day one. For free.

Both projects are at a very early stage, and we are looking for world-class engineering leaders to drive them.

• Follow @HardhatHQ on Twitter and Nomic Labs on Medium.
• Join the Hardhat Discord server to get help and participate in the community.