Posts

A Deep Dive Into the Rust Type System

Introduction This post is going to be a deep dive into Rust's type system and how compares to the Scala 3 type system. I use the Scala type system as comparison as I know it well and it's one of the most powerful type systems available in a "production grade" language. It can express most everything found in the Rust type system (except everything related to borrowing checking of course), but the opposite is not true since Scala has many advanced type features which Rust lacks (for example union/intersection types, subtyping, HKT's etc. etc.). Type Relationships The relationships between types in Scala are specified using subtyping ( C extends A with B ), union types ( type C = A | B ) and intersection types ( type C = A & B ). In Rust there are  no  relationships between types (except type aliases, type B = A ) . There is however a way to specify subtype-like relationships for traits, which we will get into in the next section. Traits Rust traits is a desc

Rust for the Seasoned Scala Developer

Updated: removed lack of extension methods as they can be implemented using traits, added language editions Intro Scala has been my language of choice (both for work and personal projects) for at least 10 years now. No other language has even made me consider switching: Kotlin is basically a lesser clone of Scala with a weaker type system Java and C# have both improved greatly, but are still lacking important features (like type classes/implicit parameters) Go is a no-go because of the badly designed type system Swift has a pretty nice type system, but it's not better than Scala in any way really, has worse memory management (basically implicit reference counting) and the portability is bad TypeScript also has a pretty nice type system, but again doesn't provide any benefits for general application development, and if I want to target the browser I'll rather use Scala.js That pretty much just leaves Rust , which as an old C++ developer, always has intrigued me as it provide

Data Modelling in Rust Continued

Intro So, just after my previous blog posting about data modelling in Rust I started looking at GhostCell  (and corresponding crate ) and how to use that for my game example. It's an extremely simple data type that works similarly to RefCell , but all borrow checks are performed at compile time and thus avoids all runtime overhead. It achieves this by separating the cells from the actual borrowing permission. When borrowing a reference to the interior of a cell you need a reference to a token connected to the cell. The cell and token are connected using a common lifetime parameter. Truly ingenious stuff! Solution 4: Reference Counted GhostCell's For my example it's probably most convenient to use GhostCell in combination with Rc . The reference types now looks like this: struct Ref<'brand, T>(Rc<GhostCell<'brand, T>>); type WRef<'brand, T> = Weak<GhostCell<'brand, T>>; type PlayerRef<'brand> = Ref<'brand

Data Modelling in Rust

Intro Recently I've been experimenting on how to efficiently and ergonomically model data types containing mutual and cyclic references in Rust. In a language with built in garbage collector like Java, C# etc., this is relatively straightforward as the GC handles cycles and object deallocation automatically for you. In Rust there's no included general purpose GC, instead there are many helper types for facilitating memory handling included in the standard library. There are many ways of solving the problem, each with different trade offs and characteristics. In this post I'll present some of the alternatives available using the Rust standard library. First I should point out that I'm not an expert Rust developer, so this experimentation has been part of my Rust learning process, but I hope it can provide some ideas and insights for new Rust developers coming from a GC language. Please point any stupid errors I might have made, or just things I've totally missed. Exa

An exploration of the DAW landscape

Intro Recently I've really been getting into computer music and synthesizers again. It's been a long time interest of mine, especially the early nineties when I was studying in the university and had (took) a lot of time to delve into it. Back then I bought some classic hardware synths like the Roland D-50 and Alpha Juno-1 (both of which I still own), and created the Soundblaster AWE32 homepage (for its time a very powerful PC soundcard) together with a friend. In those days the DAW (Digital Audio Workstation) and VST (Virtual Studio Technology, first SDK version released in 1996) concepts hadn't really developed, mainly because the limited power of the PC's at the time, and the PC software available was basically MIDI editors like Cakewalk and Cubase . After university I got busy with work life and other stuff, so my music creation was basically halted to a stand still. Lately I've had much more free time and have decided to get into creating music again.