#programming-language #compiler #dusk #interpreter #systems #forms #back-end

libdusk

This crate implements most of the compiler for the Dusk programming language, in library form

6 releases

0.1.6 Aug 7, 2022
0.1.5 Aug 7, 2022
0.1.4 Jul 22, 2022

#425 in Programming languages


Used in dusklang

MIT license

645KB
13K SLoC

Dusk

Dusk is a work-in-progress systems programming language.

Status

Pre-pre-alpha. Barely usable for anything. There is a working interpreter and a VSCode plugin, and some early work has been done on a few backends and linkers, as shown in the tables below. But fundamental aspects of the language are still missing.

Backends

Platform x86-64 arm64 Dalvik bytecode WASM JavaScript
Windows 🚧 🚧
macOS 🚧
Android 🚧
Linux
Web

Linkers

Format Status
PE32+ 🚧
Mach-O 🚧
DEX 🚧
ELF

Legend

Symbol Meaning
Planned
🚧 More than zero work has been done
Usable in practice

Goals

  • General-purpose and scalable: should be well-suited to a wide variety of domains, including kernels, game engines, and high-level GUI applications
  • Fast: both in runtime performance and compile times
  • Extensible: the core language should be as simple as possible, while enabling advanced tools and abstractions typically thought of as features of the compiler, debugger or editor to be implemented in libraries instead
  • Safe: should prevent common mistakes, potentially using refinement types and typestate
  • Delightful interop with other languages and runtimes: in the fullness of time, it should be possible to easily use any library from Dusk—or integrate Dusk into any codebase—regardless of language. In the short to medium term, platform-provided APIs on Apple platforms, Windows, Android and Linux should feel pleasant to use from Dusk, while imposing zero overhead compared to the best-performing alternative. Higher-level convenience interfaces that impose a small amount of overhead might be permitted in some cases, as long as it’s possible to drop down to the lower-level version.
  • Single source, multiple contexts: it should be possible (and encouraged) to mix code intended to be run in completely different contexts. For example, suppose you are writing an Android app. A single file in your project should be allowed (though not necessarily encouraged) to contain all of the following:
    • A build function that operates as a script for the build system
    • Metadata to be included in a manifest file
    • Rust/Swift-inspired procedural macros to reduce boilerplate in other parts of the file or project
    • A main activity, compiled to Dalvik bytecode
    • A Vulkan renderer, compiled to native ARM machine code with automatically-generated JNI glue
    • Shaders that will run on the GPU, compiled to SPIR-V bytecode and consumed by the renderer

Dependencies

~4–14MB
~151K SLoC