DEV Community: Serokell

Rust vs. Haskell

Serokell — Tue, 14 Feb 2023 00:00:00 +0000

Rust and Haskell don’t shy away from powerful features. As a result, both languages have steep learning curves compared with other languages. Trying to learn Rust or Haskell can be frustrating, especially in the first couple of months.

But if you already know Rust, you have a head start with Haskell; and vice versa.

In this article, we want to show how knowledge of one of these languages can help you get up to speed with another.

We won’t cover all the similarities or differences and won’t talk about language domains. Our main goal is to show the bridge between the languages; you can decide whether you want to walk it.

We won’t cover syntax as well, but get ready to switch between indentation and braces, as well as read code in opposite directions. 😉

Basic concepts

Haskell and Rust have both been influenced by the ML programming language. ML has strong static typing with type inference, and so do Haskell and Rust.

There are other similarities:

algebraic data types;
pattern matching;
parametric polymorphism;
ad-hoc polymorphism.

We’ll cover all of these later in the article, but first, let’s talk about compilers. Both languages focus on safety – they are extremely good at compile-time checks.

Type system

If you’re coming from one of these languages, we don’t have to convince you that types are our friends: they help us avoid silly mistakes and reduce the number of bugs.

Rust and Haskell have similar type systems. Both support conventional basic types, such as integers, floats, booleans, strings, etc. Both make it easy to create new types, use newtypes, and type aliases.

🙂 When using strings, Rust beginners puzzle over String vs. &str, and Haskell beginners puzzle over String vs. Text vs. ByteString.

Rust can infer types when possible.

let bools = vec![true, false, true];
let not_head = bools[0].not(); // false, has type bool

But omitting function parameter types is not allowed.

fn get_double_head(ints) {
// ^ error: expected one of `:`, `@`, or `|`
// note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
// help: if this is a parameter name, give it a type
// help: if this is a type, explicitly ignore the parameter name
    ints[0] * 2
}

Omitting function return types is also not allowed.

fn get_double_head(ints: Vec<i32>) {
    ints[0] * 2
// ^^^^^^^^^^^ expected `()`, found `i32`
// help: try adding a return type: `-> i32`
}

In Rust, we always have to specify both:

fn get_double_head(ints: Vec<i32>) -> i32 {
    ints[0] * 2
}

Haskell can infer types when they’re not ambiguous.

let bools = [True, False, True]
let notHead = not (head bools) -- False, has type Bool

We don’t have to annotate function parameters and return types.

getDoubleHead ints =
  head ints * 2

But it usually results in a warning, and adding a type signature is a good practice.

getDoubleHead :: [Integer] -> Integer
getDoubleHead ints =
  head ints * 2

💡 Note: You can test the Haskell code snippets by pasting them in the REPL. Rust doesn’t have an interactive environment, so you have to reorganize the snippets and use the main function if you want to give them a try.

Variables and mutability

Rust variables are, by default, immutable – when you want a mutable variable, you have to be explicit.

let immutable_x: i32 = 3;
    immutable_x = 1;
// ^^^^^^^^^^^^^^^ error: cannot assign twice to immutable variable


let mut mutable_x = 3; // 3
mutable_x = 1; // 1
mutable_x += 4; // 5

There are no mutable variables in Haskell – the syntax has no such thing as a reassignment statement. However, the value to which the variable is bound may be a mutable cell, such as IORef, STRef, or MVar. The type system tracks mutability, and Haskell does not require a separate mut keyword.

💡 Note that Haskell allows name shadowing. But it’s discouraged and can be caught with a warning.

let immutable_x = 3
let immutable_x = 1
-- ^^^^^^^^^^^ warning
-- This binding for ‘immutable_x’ shadows the existing binding

In Rust, name shadowing is considered idiomatic. For example, the following code snippet reuses x and y:

// parse a string of the form "42,20"
let (x, y) = s.split_once(',').unwrap();
let x: i32 = x.parse().unwrap();
let y: i32 = y.parse().unwrap();

Haskell relies heavily on purely functional data structures, operations on which return new versions of data structures, while the original reference stays unmodified and valid.

For example, if we have a map and want to do some operation on a slightly modified map, we can have a value that keeps the old map but also works with the new map (without much performance cost).

import qualified Data.HashMap.Strict as HashMap

let old = HashMap.fromList [("Donut", 1.0), ("Cake", 1.2)]
let new = HashMap.insert "Cinnamon roll" 2.25 old

print old
-- Prints: fromList [("Cake", 1.2),("Donut", 1.0)]
print new
-- Prints: fromList [("Cake",1.2),("Cinnamon roll", 2.25),("Donut", 1.0)]

💡 Yes, that’s how Haskell prints a map. Yes, it’s weird.

The print function converts values to strings by using show and outputs it to the standard output. The result of show is a syntactically correct Haskell expression, which can be pasted right into the code.

In Rust, standard operations mutate the collection, so there’s no way to access its state before the modification.

use std::collections::HashMap;

let mut prices = HashMap::from([("Cake", 1.2), ("Donut", 1.0)]);
prices.insert("Cinnamon roll", 2.25);

println!("{:?}", prices); 
// Prints: {"Cake": 1.2, "Donut": 1.0, "Cinnamon roll": 2.25}

💡 What is {:?}?

We can use it to debug-format any type. It relies on the fmt::Debug trait, which should be implemented for all public types.

If we want to emulate Haskell when working with default collections, we have to clone the old one.

use std::collections::HashMap;

let old = HashMap::from([("Cake", 1.2), ("Donut", 1.0)]);
let mut new = HashMap::new();

new.clone_from(&old);
new.insert("Cinnamon roll", 2.25);

println!("{:?}", old); 
// Prints: {"Cake": 1.2, "Donut": 1.0}
println!("{:?}", new); 
// Prints: {"Cake": 1.2, "Donut": 1.0, "Cinnamon roll": 2.25}

💡 Note that persistent data structures in Haskell are usually designed for cheap cloning, so most operations have O(log n) complexity. In Rust, we don’t tend to clone that often, so access and mutation typically have O(1) and cloning – O(n).

💡 Haskell has mutable constructs (such as STArray and IORef), which you can use when you need mutability.

Algebraic data types (ADTs)

In simple terms, ADTs are a way to construct types. Haskell uses the single keyword data to declare product and sum types, while Rust uses struct and enum.

To learn more about algebraic data types, check out our article on ADTs in Haskell.

Product types (structs)

In Rust, product types are represented by structs, which come in two forms:

tuple structs;
structs with named fields.

// A tuple struct has no names:
struct SimpleItem(String, f64);

// A struct has named fields: 
#[derive(Debug)]
struct Item {
    name: String,
    price: f64,
}

Which is quite similar to Haskell’s datatypes and records.

-- A simple datatype with no names:
data SimpleItem = SimpleItem String Double

-- A record has named fields: 
data Item = Item
  { name :: String
  , price :: Double
  }
  deriving (Show)

Note that #[derive(Debug)] corresponds to deriving (Show).

In Haskell, we have to provide a type constructor (the name of our type) and a data constructor (used to construct new instances of the type), which are the same as in the previous snippet.

Creating instances of types

We can create instances of product types. In Rust:

// Creating a tuple struct:
let simple_donut = SimpleItem("Donut".to_string(), 1.0);

// Creating an ordinary struct:
let cake = Item {
    name: "Cake".to_string(),
    price: 1.2,
};

In Haskell:

-- Creating an ordinary datatype:
let simpleDonut = SimpleItem "Donut" 1.0

-- Creating a record:
let donut = Item "Donut" 1.0
let cake = Item{name = "Cake", price = 1.2}

We can use either the ordinary syntax or the record syntax to create records in Haskell.

Getting field values

In Rust, we can get the value of a field by using dot notation.

let cake_price = cake.price;
println!("It costs {}", cake_price); 
// Prints: "It costs 1.2"

In Haskell, we have been using field accessors (basically, getters), such as price:

let cakePrice = price cake
print $ "It costs " ++ show cakePrice 
-- Prints: "It costs 1.2"

But since GHC 9.2, we can use dot notation as well.

💡GHC is the Glasgow Haskell Compiler, the most commonly used Haskell compiler.

let cakePrice = cake.price
print $ "It costs " ++ show cakePrice 
-- Prints: "It costs 1.2"

🤑 What is $?

We use the dollar sign ($) to avoid parentheses.

Function application has higher precedence than most binary operators. The following usage results in a compilation error:

-- These are the same:
print "It costs " ++ show cakePrice

(print "It costs ") ++ (show cakePrice)

$ is also a function application operator (f $ x is the same as f x). But it has very low precedence. The following usage works:

-- These are the same:
print $ "It costs " ++ show cakePrice

print ("It costs " ++ show cakePrice)

Updating field values

In Rust, if the struct variable is mutable, we can change its values.

let mut cake = Item {
    name: "Cake".to_string(),
    price: 1.2,
};

cake.price = 1.4;

println!("{:?}", cake); 
// Prints: Item { name: "Cake", price: 1.4 }

In Haskell, a record update returns another record, and the original one stays unchanged (as we’ve covered in the mutability section).

let cake = Item{name = "Cake", price = 1.2}

let updatedCake = cake{price = 1.4}

print cake
-- Prints: Item {name = "Cake", price = 1.2}
print updatedCake
-- Prints: Item {name = "Cake", price = 1.4}

If we want to do something similar in Rust, we can use struct update syntax to copy and modify a struct.

let pricy_cake = Item { price: 1.6, ..cake };

println!("{:?}", pricy_cake);
// Prints: Item { name: "Cake", price: 1.6 }

Both languages have a simplified field initialization syntax if there are matching names in scope:

let name = "Cinnamon roll".to_string();
let price = 2.25;

let cinnamon_roll = Item { name, price }; // instead of “name: name”

To use it in Haskell, you have to enable GHC2021 or the NamedFieldPuns extension.

let name = "Cinnamon roll"
let price = 2.25

let cinnamonRoll = Item{name, price} -- instead of “name = name”

Sum types (enums)

Here is an example of a simple sum type:

#[derive(Debug)]
enum DonutType {
    Regular,
    Twist,
    ButtermilkBar,
}

let twist = DonutType::Twist;


data DonutType = Regular | Twist | ButtermilkBar
  deriving (Show)

let twist = Twist

The variants don’t have to be boring and can contain fields (which can be unnamed or named).

For example, we can have a Donut with DonutType:

#[derive(Debug)]
enum Pastry {
    Donut(DonutType),
    Croissant,
    CinnamonRoll,
}

let twist_donut = Pastry::Donut(DonutType::Twist);


data Pastry
  = Donut DonutType
  | Croissant
  | CinnamonRoll
  deriving (Show)

let twistDonut = Donut Twist

Partial field accessors

Haskell allows partial field accessors, while Rust does not.

For example, let’s take Croissant: the price field is present in both constructors, while filling is present only in WithFilling. In Rust, we get a compilation error when we try to access the filling of a plain croissant. In Haskell, we get a runtime error.

enum Croissant {
    Plain { price: f64 },
    WithFilling { filling: String, price: f64 },
}

let plain = Croissant::Plain { price: 1.75 };

println!("{}", plain.price)
// ^^^^^
// error[E0609]: no field `price` on type `Croissant`


data Croissant
  = Plain {price :: Double}
  | WithFilling {filling :: String, price :: Double}

let plain = Plain 1.75

-- This is ok and works as expected:
print $ price plain
-- Prints: 1.75

-- This is not
print $ filling plain
-- runtime error: No match in record selector filling

Pattern matching

We could have used pattern matching to deconstruct values in the previous snippets. To illustrate this, let’s create a function that returns a receipt for a croissant.

fn to_receipt(croissant: Croissant) -> String {
    match croissant {
        Croissant::Plain { price } => format!("Plain croissant: ${price}"),
        Croissant::WithFilling { filling: _, price } => {
            format!("Croissant with filling: ${}", price)
        }
    }
}

let croissant = Croissant::WithFilling {
    filling: "Ham & Cheese".to_string(),
    price: 3.35,
};
println!("{:?}", to_receipt(croissant));
// Prints: "Croissant with filling: $3.35"


toReceipt :: Croissant -> String
toReceipt croissant = case croissant of
  Plain price -> "Plain croissant: $" <> show price
  WithFilling _ price -> "Croissant with filling: $" <> show price

print $ toReceipt $ WithFilling "Ham & Cheese" 3.35
-- Prints: "Croissant with filling: $3.35"

Haskell also allows an alternative syntax:

toReceipt :: Croissant -> String
toReceipt (Plain price) = "Plain croissant: $" <> show price
toReceipt (WithFilling _ price) = "Croissant with filling: $" <> show price

Partial patterns

Rust is strict about pattern matches being complete.

fn to_receipt(croissant: Croissant) -> String {
    match croissant {
// ^^^^^^^^^
        Croissant::Plain { price } => format!("Plain croissant: ${}", price),
    }
}
// error[E0004]: non-exhaustive patterns:
// pattern `Croissant::WithFilling { .. }` not covered

While Haskell allows partial pattern matches:

toReceipt :: Croissant -> String
toReceipt croissant = case croissant of
  (PlainCroissant price) -> "Plain croissant: $" <> show price

print $ toReceipt $ WithFilling "Ham & Cheese" 3.35
-- runtime error: Non-exhaustive patterns in case

But it’s highly discouraged, and a warning can catch this at compile time.

Pattern match(es) are non-exhaustive
In a case alternative:
  Patterns of type ‘Croissant’ not matched: WithFilling _ _

Failure handling

Now, let’s look at two commonly used ADTs: Option / Maybe and Result / Either, as well as the standard ways of dealing with errors.

`Option` / `Maybe` and `Result` / `Either`

Option has two variants: None or Some; Maybe: Nothing or Just.

// Defined in the standard library
enum Option<T> {
    None,
    Some(T),
}

let head = ["Donut", "Cake", "Cinnamon roll"].get(0);
println!("{:?}", head);
// Prints: Some("Donut")

let no_head: Option<&i32> = [].get(0);
println!("{:?}", no_head);
// Prints: None


-- Defined in the standard library
data Maybe a = Just a | Nothing

safeHead :: [a] -> Maybe a
safeHead (x : _) = Just x
safeHead [] = Nothing

print $ safeHead ["Donut", "Cake", "Cinnamon roll"]
-- Prints: Just "Donut"

print $ safeHead []
-- Prints: Nothing

Result also has two variants: Ok or Err; Either: Right and Left (by convention, Right is success and Left is failure).

// Defined in the standard library
enum Result<T, E> {
    Ok(T),
    Err(E),
}

#[derive(Debug)]
struct DivideByZero;

fn safe_division(x: i32, y: i32) -> Result<i32, DivideByZero> {
    match y {
        0 => Err(DivideByZero),
        _ => Ok(x / y),
    }
}

println!("{:?}", safe_division(4, 2));
// Prints: Ok(2)

println!("{:?}", safe_division(4, 0))
// Prints: Err(DivideByZero)


-- Defined in the standard library
data Either a b = Left a | Right b
data DivideByZero = DivideByZero
  deriving (Show)

safeDivision :: Int -> Int -> Either DivideByZero Int
safeDivision x y = case y of
  0 -> Left DivideByZero
  _ -> Right $ x `div` y

print $ safeDivision 4 2
// Prints: Right 2

print $ safeDivision 4 0
// Prints: Left DivideByZero

When we work with either of the types, it’s common to pattern match to deal with different cases. Because it can be tiresome, both languages provide alternatives. Let’s check them out first.

In Rust, we can get a value from an Option or a Result by calling unwrap.

println!("{:?}", safe_division(4, 2).unwrap());
// Prints: 2

println!("{:?}", safe_division(4, 0).unwrap());
// thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: DivideByZero'

Calling it on a None or Error will panic the program, defeating the purpose of error handling.

💡 What happens when a panic occurs?

By default, panics will print a failure message, unwind, clean up the stack, and abort the process. You can also configure Rust to display the call stack.

We can use unwrap_or() to safely unwrap values.

let item = [].get(0).unwrap_or(&"Plain donut");

println!("I got: {}", item);
// Prints: I got: Plain donut

💡 There are a couple of ways to safely unwrap values:

unwrap_or(), which eagerly evaluates the default value;
unwrap_or_else(), which lazily evaluates the default value;
unwrap_or_default(), which relies on the type’s Default trait implementation.

It’s not very idiomatic to get things out of things in Haskell, but the standard library provides a similar function called fromMaybe.

import Data.Maybe (fromMaybe)

let item = fromMaybe "Plain donut" $ safeHead []

print $ "I got: " ++ item
-- Prints: I got: Plain donut

We prefer to chain things together in Haskell.

We can chain multiple enums and operations in Rust using the and_then() method. For example, we can sequence a few safe divisions:

let eighth = safe_division(128, 2)
    .and_then(|x| safe_division(x, 2))
    .and_then(|x| safe_division(x, 2));

println!("{:?}", eighth); 
// Prints: Ok(16)

let failure = safe_division(128, 0).and_then(|x| safe_division(x, 2));
println!("{:?}", failure);
// Prints: Err(DivideByZero)

💡 These are lambdas (we’ll cover them in detail later):

|x| x + 2


\x -> x + 2

In Haskell, we use the bind (>>=) operator.

let eighth = 
      safeDivision 128 2 >>= \x ->
          safeDivision x 2 >>= \x ->
            safeDivision x 2

print eighth -- Prints: Right 16

let failure = safeDivision 128 0 >>= \x -> safeDivision x 2
print failure
-- Prints: Left DivideByZero

And last but not least, Rust provides the question mark operator (?) to deal with Result and Option.

use std::collections::HashMap;

let prices = HashMap::from([("Cake", 1.2), ("Donut", 1.0), ("Cinnamon roll", 2.25)]);

fn order_sweets(prices: HashMap<&str, f64>) -> Option<f64> {
    let donut_price = prices.get("Donut")?; // early return if None
    let cake_price = prices.get("Cake")?; // early return if None
    Some(donut_price + cake_price)
}

let total_price = order_sweets(prices);
println!("{:?}", total_price); 
// Prints: Some(2.2)

The operation short-circuits in case of failure. For example, if we try to look up and use a non-existing item:

fn order_sweets(prices: HashMap<&str, f64>) -> Option<f64> {
    let donut_price = prices.get("Donut")?;
    let cake_price = prices.get("Cake")?;
    let missing_price = prices.get("Something random")?; // Fails here

    Some(donut_price + cake_price + missing_price)
}

let total_price = order_sweets(prices);
println!("{:?}", total_price); 
// Prints: None

And in Haskell, we favor do-notation (syntactic sugar to chain special expressions; we are big fans of these).

import Data.HashMap.Strict (HashMap)
import qualified Data.HashMap.Strict as HashMap

let prices = HashMap.fromList [("Donut", 1.0), ("Cake", 1.2), ("Cinnamon roll", 2.25)]

orderSweets :: HashMap String Double -> Maybe Double
orderSweets prices = do
  donutPrice <- HashMap.lookup "Donut" prices -- early return if Nothing
  cakePrice <- HashMap.lookup "Cake" prices -- early return if Nothing
  Just $ donutPrice + cakePrice

let totalPrice = orderSweets prices
print totalPrice
-- Prints: Just 2.2

And as expected, if one lookup fails, the whole function fails:

orderSweets :: HashMap String Double -> Maybe Double
orderSweets prices = do
  donutPrice <- HashMap.lookup "Donut" prices
  cakePrice <- HashMap.lookup "Cake" prices
  missingPrice <- HashMap.lookup "Something random" prices -- Fails here
  Just $ donutPrice + cakePrice + missingPrice

let totalPrice = orderSweets prices
print totalPrice
-- Prints: Nothing

General failure philosophy

We can split errors into two categories:

recoverable errors or regular errors (such as a “file not found” error);
unrecoverable errors or programmer mistakes (aka bugs, such as the “dividing by zero” error).

As we review in the previous section, the first category can be covered by enums. It’s the errors that we either want to handle, report to the user, or retry the operation that caused them.

Let’s look into unrecoverable errors. Rust has a panic! macro that stops program execution in case of an unrecoverable error.

// Hey users, don't forget to check for 0 yourselves!
fn optimistic_division(x: i32, y: i32) -> i32 {
    match y {
        0 => panic!("This should never happen"),
        _ => x / y,
    }
}

optimistic_division(2, 0);
// thread 'main' panicked at 'This should never happen' ...

Even though it’s possible, code like this is generally discouraged in Rust.

Haskell developers painstakingly try to use types to avoid the need for errors in the first place. If you get approvals from at least two other developers and CTO, you can use error (or impureThrow):

-- Hey users, don't forget to check for 0 yourselves!
optimisticDivision :: Int -> Int -> Int
optimisticDivision _ 0 = error "This should never happen"
optimisticDivision x y = x `div` y

optimisticDivision 2 0
-- error: This should never happen
-- CallStack (from HasCallStack): error, called at ...

But let’s be honest: we’re all prone to think that we’re smarter than the compiler, which leads to an occasional “this should never happen” error message in the logs. Both standard libraries expose functions that can panic/error (for instance, accessing elements of the standard vector/list by index).

💡 Haskell adds another dimension to failure handling by distinguishing pure functions from potentially impure ones. We’ll cover this later in the article.

Polymorphism

Most polymorphism falls into one of two broad categories: parametric polymorphism (same behavior for different types) and ad-hoc polymorphism (different behavior for different types).

Parametric polymorphism

Rust supports two types of generic code:

compile-time generics, similar to C++ templates;
run-time generics, similar to virtual functions in C++ and generics in Java.

Using compile-time generics (which we just call generics) is similar to using types with type variables in Haskell. For example, we can write a generic function that reverses any type of vector.

// [1] [1]
fn reverse<T>(vector: &mut Vec<T>) {
    let mut new_vector = Vec::new();

    while let Some(last) = vector.pop() {
        new_vector.push(last);
    }

    *vector = new_vector;
}

// [1]: `T` is a type parameter.
// The function is generic over the type `T`.
// That means that `T` can be of any type.

💡 We can use any identifier to signify a type parameter in Rust.

It’s common to name generic types starting from the T and continuing alphabetically. Sometimes the names can be more meaningful, for example, the types of keys and values: HashMap<K, V>.

The reverse function iterates over the elements of a vector using the while loop. We get the elements in the reverse order because pop removes the last element from a vector and returns it. We can use this function with any vector:

let mut price_vector: Vec<f64> = vec![1.0, 1.2, 2.25];
reverse(&mut price_vector);
println!("{:?}", price_vector);
// Prints: [2.25, 1.2, 1.0]

let mut items_vector: Vec<&str> = vec!["Donut", "Cake", "Cinnamon roll"];
reverse(&mut items_vector);
println!("{:?}", items_vector);
// Prints: ["Cinnamon roll", "Cake", "Donut"]

We can write a similar function for Haskell lists. Note that the Rust function reverses the vector in place, while the Haskell function returns a new list.

-- [1]
reverseList :: [a] -> [a]
reverseList = go []
 where
  go accumulator [] = accumulator
  go accumulator (current : rest) = go (current : accumulator) rest

-- [1]: `a` is a type variable.
-- That means that `a` can be of any type.

We use the intermediate go function to recursively go over the original list and accumulate its elements in reverse order.

💡 Type variable names in Haskell start with a lowercase letter.

Conventions:

Ordinary type variables with no particular meaning: a, b, c, etc.
Errors: e.
Famous typeclasses: f (functors, applicatives), m (monads), etc.

We can use this function with any list:

let priceList = [1.0, 1.2, 2.25]
print $ reverseList priceList
-- Prints: [2.25, 1.2, 1.0]

let itemsList = ["Donut", "Cake", "Cinnamon roll"]
print $ reverseList itemsList
-- Prints: ["Cinnamon roll", "Cake", "Donut"]

Ad-hoc polymorphism

Rust traits and Haskell typeclasses are siblings – their methods can have different implementations for different types.

We’ve already seen (and even derived) one standard trait and typeclass: Debug and Show, which allow us to convert types to strings for debugging. Let’s derive and use another one for comparing values.

#[derive(Debug, PartialEq)]
struct Item {
    name: String,
    price: f64,
}

let donut = Item {
    name: "Donut".to_string(),
    price: 1.0,
};

let cake = Item {
    name: "Cake".to_string(),
    price: 1.2,
};

println!("{}", donut == cake); 
// Prints: false

println!("{}", donut == donut); 
// Prints: true

💡PartialEq and Eq.

We can’t derive Eq for Item in Rust because Eq is not implemented for f64 (because NaN != NaN).

data Item = Item
  { name :: String
  , price :: Double
  }
  deriving (Show, Eq)

let donut = Item "Donut" 1.0
let cake = Item "Cake" 1.2

print $ donut == cake
-- Prints: False

print $ donut == donut
-- Prints: True

It shouldn’t be surprising that we can also define our own typeclasses and traits. For example, let’s create one to tax data.

trait Taxable {
    fn tax(&self) -> f64;
}

// It's 10% of the price
impl Taxable for Item {
    fn tax(&self) -> f64 {
        self.price * 0.1
    }
}

println!("{}", donut.tax());
// Prints: 0.1

In Rust, we implement the Taxable trait for the Item struct; in Haskell, we create an instance of the Taxable typeclass for the Item datatype.

💡 tax is an instance method – a trait method that requires an instance of the implementing type via the &self argument. The self is an instance of the implementing type that gives us access to its internals.

class Taxable a where
  tax :: a -> Double

-- It's 10% of the price
instance Taxable Item where
  tax (Item _ price) = price * 0.1

print $ tax donut
-- Prints: 0.1

We can implement functions that rely on typeclasses and traits. Such as a function that returns a sum of taxes for a collection of taxable elements.

fn tax_all<T: Taxable>(items: Vec<T>) -> f64 {
    items.iter().map(|x| x.tax()).sum()
}

println!("{}", tax_all(vec![donut, cake])); 
// Prints: 0.22

In Rust, we use trait bounds to restrict generics: <T: Taxable> declares a generic type parameter with a trait bound. In Haskell, we use (typeclass) constraints to restrict type variables; in the following snippet, it’s Taxable a.

taxAll :: Taxable a => [a] -> Double
taxAll items = sum $ map tax items

print $ taxAll [donut, cake]
-- Prints: 0.22

💡 We can use multiple constraints in both languages:

fn tax_everything<T: Taxable, U: Taxable + Eq>(items: Vec<T>, special: U) -> f64


taxEverything :: (Taxable a, Taxable b, Eq b) => [a] -> b -> Double

On the surface, these mechanisms are quite similar, but there are some differences. Rust doesn’t allow orphan instances – a trait implementation must appear in the same crate (package) as either the type or trait definition. This prevents different crates from independently defining conflicting implementations (instances).

In Haskell, we should define instances in the same module where the type is declared or in the module where the typeclass is. Otherwise, Haskell emits a warning.

Also, Rust refuses to accept code with overlapping (ambiguous duplicate) instances. At the same time, Haskell allows several instances that apply to the same type – compilation fails only when we try to use an ambiguous instance.

💡 Fun fact: Haskell also has a mechanism called Generics.

The Generic typeclass allows us to define polymorphic functions for a variety of data types based on their generic representations – we can ignore the actual datatypes and work with their “shapes” or “structure” (that consists, for example, of constructors and fields).

Advanced topics

We can’t go too deep on these topics because each deserves more attention, but we’ll provide basic comparisons and pointers for further learning.

Metaprogramming

The next abstraction level is compile-time metaprogramming, which helps generate boilerplate code and is represented by macros and Template Haskell.

Macros in Rust are built into the language. They come in two different flavors: declarative and procedural macros (which cover function-like macros, custom derives, and custom attributes). Declarative macros are the most widely used; they are referred to as “macros by example” or, more often, as plain “macros”.

Let’s use them to make pairs.

macro_rules! pair {
    ($x:expr) => {
        ($x, $x)
    };
}

The syntax for calling macros looks almost the same as for calling functions.

💡 We’ve been using the println! macro throughout the article.

let pair_ints: (i32, i32) = pair!(1);
println!("{:?}", pair_ints);
// Prints: (1, 1)

let pair_strs: (&str, &str) = pair!("two");
println!("{:?}", pair_strs);
// Prints: ("two", "two")

Template Haskell, also known as TH, is a language extension; the template-haskell package exposes a set of functions and datatypes for it.

Let’s use it to make pairs.

import Language.Haskell.TH

pair :: ExpQ
pair = [e|\x -> (x, x)|]

We have to define it in another module because top-level splices, quasi-quotes, and annotations must be imported, not defined locally. To use Template Haskell, we have to enable the TemplateHaskell extension.

{-# LANGUAGE TemplateHaskell #-}

let pairInts :: (Int, Int) = $pair 1
print pairInts
-- Prints: (1, 1)

let pairStrs :: (String, String) = $pair "two"
print pairStrs
-- Prints: ("two", "two")

Template Haskell doesn’t have a spotless reputation: it introduces extra syntax, increases complexity, and in the past, considerably affected compilation speed (it’s way better these days). Some people prefer to use alternative methods of reducing boilerplate, such as Generics (Generic typeclass).

💡 Later versions of GHC support typed Template Haskell, which type-checks the expressions at their definition site rather than at their usage (like regular TH).

Runtime and concurrency

Rust has no built-in runtime (scheduler). The standard library allows using OS threads directly through std::thread. For example, we can spawn a thread:

use std::thread;
use std::time::Duration;

thread::spawn(|| {
    thread::sleep(Duration::from_secs(1));
    println!("Hello from the spawned thread!");
});
println!(“Spawned a thread”);

thread::sleep(Duration::from_secs(2));
println!("Hello from the main thread!");

The Rust language defines async/await but no concrete execution strategy.

#[derive(Debug)]
struct Donut;

async fn order_donut() -> Donut {
    println!("Ordering a donut");
    Donut
}

async fn eat(donut: Donut) {
    println!("Eating a donut {:?}", donut)
}

async fn order_and_consume() {
    // Wait for the order before consuming it.
    // `await` doesn't block the thread
    let donut = order_donut().await;
    eat(donut).await;
}

// Blocks the current thread until the future is completed
use futures::executor::block_on;
block_on(order_and_consume());

We use the standard futures, which has its own executor but is not a full runtime. To get an asynchronous runtime in Rust, we have to use external libraries, such as Tokio and async-std.

Here is a snippet of code that uses Tokio to do some concurrent work using three different services and then either collect the successful result or return a timeout error (all the other errors are ignored for simplicity):

use tokio::time::timeout;

// Imagine `do_work` does some meaningful work
// async fn do_work(work: &Work, service: &Service) -> String

async fn concurrent_program(work: &Work) -> Result {
    timeout(Duration::from_secs(2), async {
        tokio::join!(
            do_work(work, &Service::ServiceA),
            do_work(work, &Service::ServiceB),
            do_work(work, &Service::ServiceC)
        )
    })
    .await
    .map(|(a, b, c)| Result::Success(vec![a, b, c]))
    .unwrap_or_else(|_| Result::Timeout)
}

// Still have to run this program
concurrent_program(&some_work).await;

Note that this will run all the work concurrently on the same task. If we want to do the job simultaneously or in parallel, we need to call tokio::spawn for each of the tasks to spawn and run it.

💡 Rust doesn’t oblige you to stick to one type of concurrency model (such as threads, async, etc.). You can use any if you find a suitable crate (library).

Haskell has green threads – the runtime system manages threads (instead of directly using native OS threads). The essential operation is forking a thread with forkIO:

import Control.Concurrent (threadDelay, forkIO)

forkIO $ do
  threadDelay $ 1000 * 1000
  print "Hello from the spawned thread!"

print "Spawned a thread"

threadDelay $ 2 * 1000 * 1000
print "Hello from the main thread!"

Various libraries in Haskell take advantage of green threads to provide powerful and composable APIs. For example, the async package (library). The following snippet uses async to do concurrent work with three services and then assembles the result.

import Control.Concurrent (threadDelay)
import Control.Concurrent.Async (mapConcurrently)
import System.Timeout (timeout)

-- Imagine `doWork` does some meaningful work
-- doWork :: Work -> Service -> IO PartialResult

concurrentProgram :: Work -> IO Result
concurrentProgram work = do
  results <-
    timeout twoSeconds $
      mapConcurrently (doWork work) [ServiceA, ServiceB, ServiceC]
  pure $ case results of
    Just success -> Success success
    Nothing -> Timeout
 where
  twoSeconds = 1000 * 1000

-- Run the program
concurrentProgram someWork

And we have to mention the Software Transactional Memory (STM) abstraction in Haskell, which allows us to group multiple state-changing operations and perform them as a single atomic operation.

Imagine the situation: I have $0 and want to buy a donut for $3; also, I earn $1 per second. I can keep trying to buy a donut until I have sufficient funds. We have a typical money transfer transaction, which needs to be retried and can be simulated using STM. We don’t need to worry about transaction rollbacks or retries – STM handles all of these for us.

runSimulation :: IO ()
runSimulation = do
  -- Start with 0
  wallet <- newTVarIO 0
  cashRegister <- newTVarIO 100

  -- Get paid at the same time
  _ <- forkIO $ getPaid wallet

  -- Try to make a donut-money transaction
  atomically $ do
    myCash <- readTVar wallet
    -- Check if I have enough money
    check $ myCash >= donutPrice
    -- Subtract the amount from my wallet
    writeTVar wallet (myCash - donutPrice)
    storeCash <- readTVar cashRegister
    -- Add the amount to the cash register
    writeTVar cashRegister (storeCash + donutPrice)

  myFinal <- readTVarIO wallet
  print $ "I have: $" ++ show myFinal

  storeFinal <- readTVarIO cashRegister
  print $ "Cash register: $" ++ show storeFinal
where
  donutPrice = 3

-- Put $1 in my wallet every second
getPaid :: TVar Int -> IO ()
getPaid wallet = forever $ do
  threadDelay $ 1000 * 1000
  atomically $ modifyTVar wallet (+ 1)
  print "I earned a dollar"

💡 TVar stands for transactional variable, which we can read or write to within STM, using operations such as readTVar and writeTVar. We can perform a computation in the STM using the atomically function.

When we run the program, we see that I must be paid at least three times before the transaction succeeds:

runSimulation
-- Prints: 
-- "I earned a dollar"
-- "I earned a dollar"
-- "I earned a dollar"
-- "I have: $0"
-- "Cash register: $103"

Functions and functional programming

Functions are widespread in both languages. Haskell and Rust support higher-order functions. Haskell is always functional, and functional Rust is frequently just proper, idiomatic Rust.

Lambdas and closures

A lambda is an anonymous function that can be treated like a value. We can use lambdas as arguments for higher-order functions.

In Rust:

let bump = |i: f64| i + 1.0;
println!("{}", bump(1.2));
// Prints: 2.2

let bump_inferred = |i| i + 1.0;
println!("{}", bump_inferred(1.2));
// Prints: 2.2

In Haskell:

let bump = \(i :: Double) -> i + 1.0
print $ bump 1.2
-- Prints: 2.2

let bumpInferred = \i -> i + 1.0
print $ bumpInferred 1.2
-- Prints: 2.2

💡 Note that annotating a type variable might require the ScopedTypeVariables extension, depending on your usage. But also, writing lambdas like that can be redundant in Haskell. We could have written a normal function:

let bump :: Double -> Double
    bump i = i + 1.0

We can use closures to capture values from the scope/environment in which they’re defined. For example, we can define a simple closure that captures the outside variable:

|x| x + outside


\x -> x + outside

In Rust, each value has a lifetime. Because closures capture environment values, we have to deal with their ownership and lifetimes. For example, let’s write a function that returns a greeting function:

fn create_greeting() -> impl Fn(&str) -> String {
    let greet = "Hello,";
    move |name: &str| format!("{greet} {name}!")
}

let greeting_function = create_greeting();

println!("{}", greeting_function("Rust"));
// Prints: Hello, Rust!

We use move to force the closure to take ownership of the greet variable.

💡 If we forget to use move, we get an error.

error[E0373]: closure may outlive the current function, but it borrows `greet`, which is owned by the current function
   |
   | |name: &str| format!("{greet} {name}!")
   | ^^^^^^^^^^^^ ----- `greet` is borrowed here
   | |
   | may outlive borrowed value `greet`
   |
note: closure is returned here
   |
   | |name: &str| format!("{greet} {name}!")
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to force the closure to take ownership of `greet` (and any other referenced variables), use the `move` keyword
   |
   | move |name: &str| format!("{greet} {name}!")
   | ++++

💡 What is Fn?

How a closure captures and handles values from the environment determines which traits (one, two, or all three) it implements and how the closure can be used. There are three traits:

FnOnce (can be called once);
FnMut (can be called more than once, may mutate state);
Fn (can be called more than once, no state mutation).

In Haskell, we don’t worry much about closures.

Currying and partial application

Currying is converting a function that takes multiple arguments into a function that takes them one at a time. Each time we call a function, we pass it one argument, and it returns another function that also takes one argument until all arguments are passed.

In Haskell, all functions are considered curried, which might not be obvious because it’s hidden in the syntax: Double -> Double -> Double is actually Double -> (Double -> Double) and add x y is actually (add x) y.

add :: Double -> Double -> Double
add x y = x + y

bump :: Double -> Double 
bump = add 1.0

full :: Double 
full = add 1.0 1.2

When we pass 1.0 to add, we get another function, bump, which takes a double, adds 1 to it, and returns that sum as a result.

add x y = x + y
bump = add 1.0

print $ bump 1.2
-- Prints: 2.2

bump is the result of partial application, which means we pass less than the total number of arguments to a function that takes multiple arguments.

We can do this in Rust, but it’s not idiomatic.

fn add(x: f64) -> impl Fn(f64) -> f64 {
    move |y| x + y
}

let bump = add(1.0);

println!("{}", bump(1.2)); 
// Prints: 2.2

There are crates that make it easier like partial_application:

use partial_application::partial;

fn add(x: f64, y: f64) -> f64 {
    x + y
}

let bump2 = partial!(add => 1.0, _);

println!("{}", bump(1.2)); 
// Prints: 2.2

Currying and partial application are convenient when we pass functions around as values and allows us to use neat features, such as composition.

Function composition

In Haskell, we can use function composition, which pipes the result of one function to the input of another, creating an entirely new function.

💡 We use the dot operator (.) to implement function composition in Haskell.

For example, we can compose three functions to get a maximum price from the list and negate it.

import qualified Data.HashMap.Strict as HashMap

-- HashMap.elems :: HashMap String Double -> [Double]
-- maximum :: [Double] -> Double
-- negate :: Double -> Double

negativeMaxPrice :: HashMap String Double -> Double
negativeMaxPrice = negate . maximum . HashMap.elems

let prices = HashMap.fromList [("Donut", 1.0), ("Cake", 1.2)]
print $ negativeMaxPrice prices 
-- Prints: -1.2

We can technically do it in Rust, but it’s not commonly used and not part of the standard library.

Iterators

In Rust, the iterator pattern allows us to traverse collections. Iterators are responsible for the logic of iterating over each item and determining when the sequence has finished.

For example, let’s use iterators to get the total price of all the products except for donuts:

use std::collections::HashMap;

let prices = 
  HashMap::from([("Donut", 1.0), ("Cake", 1.2), ("Cinnamon roll", 2.25)]);

let total: f64 = prices
    .into_iter()
    .filter(|&(name, _)| name != "Donut")
    .map(|(_, price)| price)
    .sum();

println!("{}", total); 
// Prints: 3.45

Iterators are lazy — they don’t do anything unless they are consumed. We can also use collect to transform an iterator into another collection. For example, we can return the prices instead:

use std::collections::HashMap;

let prices = 
  HashMap::from([("Donut", 1.0), ("Cake", 1.2), ("Cinnamon roll", 2.25)]);

let other_prices: Vec<f64> = prices
    .into_iter()
    .filter(|&(name, _)| name != "Donut")
    .map(|(_, price)| price)
    .collect();

println!("{:?}", other_prices);
// Prints: [1.2, 2.25]

In Haskell, we work with collections directly.

import qualified Data.HashMap.Strict as HashMap

let prices = 
      HashMap.fromList [("Donut", 1.0), ("Cake", 1.2), ("Cinnamon roll", 2.25)]

let total =
        sum
          $ HashMap.elems
          $ HashMap.filterWithKey (\name _ -> name /= "Donut")
          $ prices

print total 
-- Prints: 3.45


import qualified Data.HashMap.Strict as HashMap

let prices = 
      HashMap.fromList [("Donut", 1.0), ("Cake", 1.2), ("Cinnamon roll", 2.25)]

let otherPrices =
      HashMap.elems $
        HashMap.filterWithKey (\name _ -> name /= "Donut") prices

print otherPrices 
-- Prints: [1.2, 2.25]

Associated functions and methods

In Rust, we can connect functions to particular types — via associated functions or methods. Associated functions are called on the type, and methods are called on a particular instance of a type.

struct Item {
    name: String,
    price: f64,
}

impl Item {
    fn free(name: String) -> Item {
        Item { name, price: 0.0 }
    }

    fn print_receipt(&self) {
        println!("{}: ${}", self.name, self.price);
    }
}

// Calling an associated function:
let free_donut = Item::free("Regular donut".to_string());

// Calling a method:
free_donut.print_receipt(); 
// Prints: Regular donut: $0

In Haskell, we can’t and don’t.

Things we worry about in Rust

Speaking of the things we don’t do in Haskell. It shouldn’t be a surprise that the feature that sets Rust apart is its ownership model and the borrow checker.

Remember how we used move to force the closure to take ownership of the variable?

fn create_greeting() -> impl Fn(&str) -> String {
    let greet = "Hello,";
    move |name: &str| format!("{greet} {name}!")
}

Rust is a statically memory-managed language, which requires us to think about the lifetimes of values.

💡 If you want to learn more about this topic, check out the Understanding Ownership chapter of the Rust book.

And in Haskell? In Haskell, we have space leaks (but we usually don’t worry about those). 😉

Things we worry about in Haskell

Laziness

Haskell programs are executed using lazy evaluation, which doesn’t perform a computation until its result is required and avoids unnecessary computation.

Laziness encourages programming in a modular style without worrying about intermediate data and allows working with infinite structures. Let’s illustrate this by writing a function that returns the first prime number larger than 10 000. We can start with an infinite list of naturals, filter the prime numbers, and take the first prime after 10 000.

naturals :: [Int]
naturals = [1 ..]

-- Check there is no divisors for `n`
isPrime :: Int -> Bool
isPrime n = null [number | number <- [2 .. n - 1], n `mod` number == 0]

print $ take 1 $ filter (> 10000) $ filter isPrime naturals
-- Prints: [1000003]

Because of laziness, the work stops right after it finds the correct prime number – no need to calculate the rest of the list or the rest of the primes.

This computation takes ~40MB of memory (YMMV), primarily the runtime overhead. If we increase the number to 100 000, the memory usage stays the same.

All good so far. What if we try something else? Let’s take 1 000 000 naturals and return their sum along with the length of the list.

let nums = take 10000000 naturals
print $ (sum nums, length nums)
-- (500000500000,1000000)

This computation takes ~129MB of memory (YMMV). And if we take 10 000 000 – the memory usage goes up to ~1.376GB. Oops.

💡 Why does it happen?

Because the nums list is used for both sum and length computations, the compiler can’t discard list elements until it evaluates both.

Note that sum $ take 10000000 naturals runs in constant memory.

💡 If you want to learn more, check out our videos on laziness.

So, it’s favorable to be mindful of how expressions are evaluated when working with data in Haskell to avoid space leaks.

Purity

Haskell is pure – invoking a function with the same arguments always returns the same result.

As a consequence, in Haskell, there is no distinction between a zero-argument function and a constant.

f(x, y) // functino with two arguments
f(x) // function with one argument
f() // function with zero arguments
C // constant


f x y -- function with two arguments
f x -- function with one argument
F -- zero argument / constant 
c -– zero argument / constant

💡 Pure functions do not have side effects.

Purity, together with laziness, raises some challenges. Without digging too deep into the rabbit hole, let’s look at an example pseudo-Haskell code. The following impure example reads 2 integers from the standard input and returns them as a list (pay attention to the order):

-- `readNumber` is an impure function that reads a number from stdin

-- some impure computation
pseudoComputation =
  let first = readNumber
  let second = readNumber
  print [second, first]

As we’ve learned, because of laziness, Haskell doesn’t evaluate an expression until it is needed: evaluation of first and second is postponed until they are used, and when it starts forcing the list, it starts with reading the second number and then first. Which is the opposite of what we want and expect.

To deal with this mess, Haskell has IO – a special datatype that offers better control over its execution. IO is a description of a computation. When executed, it can perform arbitrary effects before returning a value of type a.

💡 Executing IO is not the same as evaluating it. Evaluating an IO expression is pure – it returns the same description. For example, io1 and io2 are guaranteed to be the same:

-- some IO function 
-- doSomeAction :: String -> IO ()

let variable = doSomeAction "parameter"
let io1 = (var, var)


let io2 = (doSomeAction "parameter", doSomeAction "parameter")

We’ve been using the print function to print things out; here is its type signature:

print :: Show a => a -> IO ()

We can’t print outside of IO. We get a compilation error if we try otherwise:

noGreet :: String -> String
noGreet name = print $ "Hello, " <> name
-- ^^^^^^^^^^^^^^^^^^^^^^^^^
-- Couldn't match type: IO ()
-- with: String

Okay, we have an IO function. How do we run it? We need to define the program’s main IO function – the program entry point – which the Haskell runtime will execute. Let’s look at the executable module example: it asks the user for the name, reads it, and prints the greeting.

module Main where 

greet :: String -> IO ()
greet name = print $ "Hello, " <> name

main :: IO ()
main = do
  print "What's your name?"
  name <- getLine
  greet name

💡 Remember the do-notation syntax that we used with Maybe and Either? We can use it with IO as well! It’s convenient to put actions together.

This differs from all the languages in which we can perform side effects anywhere and anytime.

For completeness, this is how a main module looks like in Rust:

fn main() {
    let two = one() + one();
    println!("Hello from main and {}", two);
}

fn one() -> i32 {
    println!("Hello from one");
    1
}

Note that we can execute arbitrary side effects.

Higher-order programming

In Haskell, we prefer general solutions for common patterns. For example, do-notation is syntactic sugar for the bind operator (>>=), which is overloaded for a bunch of types: Maybe, Either e, [], State, IO, etc.

do
  x <- action1
  y <- action2
  f x y


-- Desugared version:
action1 >>= \x ->
  action2 >>= \y ->
    f x y

As a result, we can use the notation to express many problems and deal with many use cases: optionality, non-determinism, error handling, state mutation, concurrency, etc.

-- Dealing with optionality: 
maybeSweets :: HashMap String Double -> Maybe Double
maybeSweets prices = do
  donutPrice <- HashMap.lookup "Donut" prices
  cakePrice <- HashMap.lookup "Cake" prices
  Just $ donutPrice + cakePrice

-- Dealing with IO:
ioSweets :: Statistics -> SweetsService -> IO Double
ioSweets statistics sweets = do
  print "Fetching sweets from external service"
  prices <- fetchPrices sweets
  updateCounters statistics prices
  pure prices

This is one of the design patterns for structuring code in Haskell. We implement them using typeclasses, and they are supported by laws (a whole different topic). When Haskell developers see that the library provides a datatype or an interface related to one of these typeclasses, they have some expectations and guarantees about its behavior.

💡 Top 7 useful typeclasses everyone should know about:

Semigroup, Monoid, Functor, Applicative, Monad, Foldable, and Traversable.

Higher-kinded types are the basis for these typeclasses. A higher-kinded type is a type that abstracts over some polymorphic type. Take, for instance, f in the following Functor definition:

class Functor f where
  fmap :: (a -> b) -> f a -> f b

f can be Option, [], IO, etc.; while f a can be Option Int, [String], IO Bool, etc.

You can check out Kinds and Higher-Kinded Types for a more detailed explanation.

Rust doesn’t support higher-kinded types (yet), and it’s more complex to implement concepts such as monads and their friends. Instead, Rust provides alternative approaches to solve the problems that these typeclasses solve in Haskell:

If you want to deal with optionality or error handling, you can use Option/Result with the ? operator.
If you want to deal with async code – async/.await.
etc.

Conclusion

Turns out Rust and Haskell have a lot in common: both languages have a lot of features and can be frustrating to learn. Luckily they share a lot of concepts, and knowledge of one language can be helpful while pursuing another.

And please remember that in both cases, the compiler has your back, so don’t forget that compilers are your friends. 😉

For more articles on Haskell and Rust, follow us on Twitter or subscribe to the newsletter via the form below.

Get Started with Rust: Generics

Serokell — Tue, 03 Jan 2023 00:00:00 +0000

Get Started with Rust: Generics

Generic programming allows programmers to write general algorithms that work with arbitrary types. It reduces code duplication and provides type safety, which enables us to write more concise and clean code. This approach is also known as parametric polymorphism or templates in other languages.

Rust supports two types of generic code:

Compile-time generics, similar to C++ templates.
Run-time generics, similar to virtual functions in C++ and generics in Java.

This article will cover compile-time generics (which we just call generics) and these questions:

Why do we use generics?
How to use generic types in Rust?
How to define custom types, functions, and methods with generics?
How to restrict generics with traits?

What are generics in Rust?

Let’s start with an example, creating and printing a vector of integers:

let mut int_vector = Vec::new();

int_vector.push(1);
int_vector.push(2);
int_vector.push(3);

for i in &int_vector {
    println!("{}", i);
}
// Prints:
// 1
// 2
// 3

We call the Vec::new function to create a new empty vector, add multiple elements with push, and print all the elements.

Rust is a statically typed language, meaning the compiler should know the types of all the variables at compile time. Once we push the first integer into the vector, the compiler recognizes int_vector as a vector of integers, and it can’t store any other type. If we try to push 4.0, the code doesn’t compile:

error[E0308]: mismatched types
   |
   | int_vector.push(4.0);
   | ---- ^^^ expected integer, found floating-point number
   | |
   | arguments to this function are incorrect

We can write a similar program using strings:

let mut str_vector = Vec::new();

str_vector.push("one");
str_vector.push("two");
str_vector.push("three");

for i in &str_vector {
    println!("{}", i);
}
// Prints:
// one
// two
// three

This time, if we try to push 4, the code doesn’t compile:

error[E0308]: mismatched types
   |
   | str_vector.push(4);
   | ---- ^^^ expected `&str`, found integer
   | |
   | arguments to this function are incorrect

Aside from the name and elements, both code snippets look pretty similar. With Vec::new, we created and used two vectors: one that holds integers and another that holds strings. This is possible because vectors are implemented using generics. When we use new, we construct a new empty Vec<T>, which can hold any type.

💡 The <T> syntax

We use the <T> syntax when declaring generic types. T is known as the type parameter, and it’s written between the angle brackets. T represents any data type, which means there is no way to know what T is at runtime – we can’t pattern match on it, can’t do any type-specific operations, and can’t have different code paths for different T’s.

You can use any letter to signify a type parameter, but it’s common to use T.

The compiler can often infer the type we want to use based on the value and how we use it. When we push a value of a specific type into a vector, the compiler figures out what kind of elements we want to store and infers the type of the vector. For example, when we populated int_vector with i32 values, Rust inferred that its type is Vec<i32>.

If we don’t insert any elements into the vector and don’t give any hints about the elements of the vector, the code doesn’t compile:

let mut int_vector = Vec::new();

for i in &int_vector {
    println!("{}", i);
}


error[E0282]: type annotations needed for `Vec<T>`
   |
   | let mut int_vector = Vec::new();
   | ^^^^^^^^^^^^^^
   |
help: consider giving `int_vector` an explicit type
    , where the type for type parameter `T` is specified
   |
   | let mut int_vector: Vec<T> = Vec::new();
   | ++++++++

Because we aren’t inserting any values into the vector anymore, Rust doesn’t know what kind of elements we intend to store. The error suggests that we can add an explicit type. With a type annotation, we can tell the compiler that the Vec<T> in int_vector will hold elements of the i32 type:

// We specify the type within angle brackets
let mut int_vector: Vec<i32> = Vec::new();

We can’t leave a vector without a specific type. We need to tell the compiler which concrete type we will use: explicitly (with type annotations) or implicitly (by using specific types).

Let’s look at another example, a HashMap collection, which has two generic types: key type and value type:

use std::collections::HashMap;

let mut score_map: HashMap<&str, i32> = HashMap::new();
score_map.insert("Jamie", 16);
score_map.insert("Ashley", 71);

let mut codes_map: HashMap<u32, &str> = HashMap::new();
codes_map.insert(282, "type annotation error");
codes_map.insert(308, "mismatched types error");

let mut flags_map: HashMap<&str, bool> = HashMap::new();
flags_map.insert("required", true);

We can create a hash map with any combination of keys and values. We don’t need to create a specific collection for all the possible types (e.g., StringIntMap, StringBoolMap, etc); we can use one collection and specify the types we want.

💡 We can define multiple generic parameters by separating them with commas:

fn take_three<T, U, V>(t: T, u: U, v: V) {}

It’s common to name generic types starting from the T and continuing alphabetically. Sometimes the names can be more meaningful, for example, the types of keys and values:

HashMap<K, V>

How do generics work?

In some sense, when we define a generic collection (e.g., Vec<T>), we define an infinite set of collections (such as Vec<i32>, Vec<i64>, and Vec<&str>).

💡 When Rust compiles generic code, it performs a process called monomorphization. We write generic code that works for some arbitrary type T, and Rust generates specific uses of the code by filling in the concrete types at compile time. For example, it will generate code for Vec<i32> and Vec<&str>, but the resulting code will be different due to how each type works underneath.

When we use generics, we can write code for multiple data types instead of rewriting the same code for each type, making the code more straightforward and less error-prone.

Rust can make use of generics in several places:

Function and method definitions.
Struct and enum definitions.
Impl blocks.
Trait definitions.
Type aliases.

Generic definitions

We will cover generics in various Rust definitions, starting with generic functions.

Generic functions

Let’s play around with some vectors. Imagine that we want to write a function that reverses elements of any vector, including int_vector and str_vector we’ve seen before. We can write specialized functions for different kinds of vectors, such as int_reverse, str_reverse, and so on:

fn int_reverse(vector: &mut Vec<int>) {...}

fn str_reverse(vector: &mut Vec<&str>) {...}

Because the actual type of the elements doesn’t matter when reversing a vector, these functions would have the same implementation and differ only in the types of their parameters. This is where generic functions come in – we can create one generic reverse function that is generic over the type of vector elements.

// [1][2] [3]
fn reverse<T>(vector: &mut Vec<T>) {
    let mut new_vector = Vec::new();

    while let Some(last) = vector.pop() {
        new_vector.push(last);
    }

    *vector = new_vector;
}

// [1]: The generic definition follows the function name.
// [2]: The function is generic over the type `T`.
// [3]: The function takes a reference to a generic vector as an argument.

The reverse function iterates over the elements of a vector using the while loop. We get the elements in the reverse order because pop removes the last element from a vector and returns it.

We can use this generic function with both of our vectors, as well as any other vector:

let mut int_vector: Vec<i32> = vec![1, 2, 3];
reverse(&mut int_vector);
println!("After: {:?}", int_vector);
// Prints:
// After: [3, 2, 1]

let mut str_vector: Vec<&str> = vec!["one", "two", "three"];
reverse(&mut str_vector);
println!("After: {:?}", str_vector);
// Prints:
// After: ["three", "two", "one"]

let mut bool_vector: Vec<bool> = vec![true, false, false, false];
reverse(&mut bool_vector);
println!("After: {:?}", bool_vector);
// Prints:
// After: [false, false, false, true]

This time, we use the vec! macro to create a vector with initial values and pretty-print it with {:?}. The reverse works, but don’t try this in production – better use the built-in function vector.reverse.

To sum up, with generics we write one function and delegate the task of writing repetitive code for all the different types to the compiler.

Generic enums

We can use generics in other definitions as well. For instance, Option<T> is a generic enum frequently encountered in Rust:

// [1][2]
pub enum Option<T> {
  None,
// [3]
  Some(T),
}

// [1]: The generic definition follows the enum name.
// [2]: The enum is generic over the type `T`.
// [3]: The `Some` takes an argument of type `T`.

Because it’s generic, we can use Option to wrap any type we like:

let o1: Option<i32> = Some(1);
let o2: Option<&str> = Some("two");
let o3: Option<bool> = Some(true);
let o4: Option<f64> = Some(4.0);
...

For example, we can use it to wrap integers (Option<i32>) and implement a safe division function:

fn safe_division(a: i32, b: i32) -> Option<i32> {
    match b {
        0 => None,
        _ => Some(a / b),
    }
}

println!("{:?}", safe_division(4, 2));
// Prints:
// Some(2)

Or we can use Option to safely access the elements of the str_vector:

let str_vector = vec!["one", "two", "three"];

let head = str_vector.get(0);
println!("{:?}", head);
// Prints:
// Some("one")

Note: The get method is a safe way to access an element of the vector at a given position: it either returns a reference to the element wrapped in Some or None if the position is out of bounds.

Generic structs

In the same way, we can create generic structs. Let’s imagine we need to create a struct that holds user scores. If our program supports multiple kinds of scores, we don’t want to repeat ourselves and write code for all the different score types; we can keep the score generic:

// [1][2]
struct Score<T> {
    user: String,
// [3]
    team_score: T,
// [4]
    scores: Vec<T>,
}

// [1]: The generic definition follows the struct name.
// [2]: The struct is generic over the type `T`.
// [3]: The `team_score` field is of type `T`.
// [4]: The `scores` field is of type `Vec<T>`.

At the point of usage, when we assign values to the struct’s parameters, we commit to the specific type for T. We can use any type for the score, for example, integer:

let int_score: Score<i32> = Score {
    user: "Lesley".to_string(),
    team_score: 1_641_213,
    scores: vec![5213, 1232, 1512],
};

println!(
    "Int score: user = {}, scores = {:?}",
    int_score.user, int_score.scores
);
// Prints:
// Int score: user = Lesley, scores = [5213, 1232, 1512]

Or float:

let flt_score = Score {
    user: "Simone".to_string(),
    team_score: 54.2526,
    scores: vec![4.2526],
};

println!(
    "Float score: user = {}, scores = {:?}",
    flt_score.user, flt_score.scores
);
// Prints:
// Float scores: user = Simone, scores = [4.2526]

Note that we didn’t specify the type of flt_score; the compiler can automatically infer the struct type from the used values.

The compiler ensures that the type of team_score is the same as the type of scores elements because they are defined as T. For example, using an integer for one and a float for another doesn’t work:

let broken_score = Score {
    user: "Simone".to_string(),
    team_score: 100,
    scores: vec![4.2526],
};


error[E0308]: mismatched types
    |
    | scores: vec![4.2526],
    | ^^^^^^ expected integer, found floating-point number

Generic methods

Furthermore, we can implement a generic method on generic structs. For example, we can implement a method to get the last score (assuming that scores preserves the order):

// [1] [2]
impl<T> Score<T> {
// [3]
    fn last_score(&mut self) -> Option<&T> {
        self.scores.last()
    }
}

// [1]: The generic definition follows the `impl` keyword.
// [2]: The struct is generic over the type `T`.
// [3]: The function's return value is generic over `T`
// (It returns an optional reference to a value of type `T`).

💡 Why are there multiple <T>?

First, we declare the type parameter (T) after the impl keyword (impl<T>), and then we use other Ts to refer to that first T: to specify the struct type we are implementing (Score<T>) or specify the return type (Option<&T>).

The distinction between these becomes more clear when we have more complex types; for example:

impl<T> Pair<T, T> { ... }


impl<T> MyStruct<Vec<T>> { ... }

We can use the last_score method with any type of score:

let int_score: Score<i32> = Score {
    user: "Lesley".to_string(),
    team_score: 1_641_213,
    scores: vec![5213, 1232, 1512],
};

let last_int_score = int_score.last_score();
println!("Last score: {:?}", last_int_score);
// Prints:
// Last score: Some(1512)

let flt_score = Score {
    user: "Simone".to_string(),
    team_score: 54.2526,
    scores: vec![4.2526],
};

let last_flt_score = flt_score.last_score();
println!("Last score: {:?}", last_flt_score);
// Prints:
// Last score: Some(4.2526)

How to constrain a generic type

We’ve covered a few generics that take any possible type: Vec<T>, Option<T>, etc. This flexibility doesn’t come for free. Not knowing anything about the type limits the kind of things we can do with the values of this type: we can’t print them, compare them, etc.

At least, in the previous examples, we knew something about the type of container, which allowed us to implement some functionality. What if we only have the type T? Imagine a simple generic function that accepts a value of one type and returns a value of the same type:

fn quick_adventure<T>(t: T) -> T

We don’t know anything about T. The only thing we can do is return the parameter’s value. Quite boring and limiting:

fn quick_adventure<T>(t: T) -> T {
    t
}

println!("{}", quick_adventure(17));
// Prints:
// 17

println!("{}", quick_adventure("out"));
// Prints:
// out

💡 When we write a polymorphic function that works for different types, we limit the possibilities in implementation. For example, we can easily add or multiply if we write a function that works for a pair of integers. But if we write a function that works both for a pair of integers and a pair of strings, we can’t because strings don’t support these operations. However, we can use shared operations, like comparing two elements that work for integer and string values.

Generics improve code readability. A “very” generic function can be, in great measure, described by the types themselves, which additionally serve as documentation.

Let’s look at a more practical example. We implemented a generic reverse function that reverses a vector in place. What if we change it and try to print the values instead of updating the vector?

fn reverse_print<T>(vector: &mut Vec<T>) {
    while let Some(last) = vector.pop() {
        println!("{}", last);
    }
}

It doesn’t compile!

error[E0277]: `T` doesn't implement `std::fmt::Display`
    |
    | println!("{}", last);
    | ^^^^ `T` cannot be formatted with the default formatter
    |
help: consider restricting type parameter `T`
    |
    | fn reverse_print<T: std::fmt::Display>(vector: &mut Vec<T>) {
    | +++++++++++++++++++

The compiler doesn’t know anything about the type. How is it supposed to print it? The error message suggests we should consider restricting the type parameter. Spoiler alert, we can do this with trait bounds.

Note: If traits are fresh on your mind or you’ve recently read our article Traits in Rust, you can skip the following recap.

Recap on traits

Traits allow us to define interfaces or shared behaviors on types. To implement a trait for a type, we must implement methods of that trait.

All types implementing a given trait must support the functionality defined by this trait. For example, if we want to compare values of some type, it has to implement PartialEq and PartialOrd:

#[derive(PartialEq, PartialOrd)]
struct LevelScore {
    main_score: i32,
    bonus_score: i32,
}

let my_score = LevelScore {
    main_score: 10,
    bonus_score: 5,
};

let your_score = LevelScore {
    main_score: 5,
    bonus_score: 2,
};

if my_score > your_score {
    println!("I have a bigger score!")
} else {
    println!("You have a bigger score!")
}
// Prints:
// I have a bigger score!

Otherwise, we would get an error:

// #[derive(PartialEq, PartialOrd)]
struct LevelScore {
    main_score: i32,
    bonus_score: i32,
}


error[E0369]: binary operation `>` cannot be applied to type `LevelScore`
    |
    | if my_score > your_score {
    | -------- ^ ---------- LevelScore
    | |
    | LevelScore
    |
note: an implementation of `PartialOrd<_>` might be missing for `LevelScore`
    |
    | struct LevelScore {
    | ^^^^^^^^^^^^^^^^^ must implement `PartialOrd<_>`
help: consider annotating `LevelScore` with `#[derive(PartialEq, PartialOrd)]`
    |
    | #[derive(PartialEq, PartialOrd)]
    |

A trait is an interface that defines behaviors with a contract that other code can rely on. We can implement functions that accept types implementing our trait. These functions don’t need to know anything else about these types.

Trait bounds on generic functions

Traits allow us to make certain promises about the type of behavior. We can use traits and generics to constrain a generic type, so it accepts only the types with a particular behavior and not just any type. As an example, we can restrict the generic type in reverse_print using a trait bound:

use std::fmt::Display;

// [1] [2]
fn reverse_print<T: Display>(vector: &mut Vec<T>) {
    while let Some(last) = vector.pop() {
// [3]
        println!("{}", last);
    }
}

// The function is
// [1]: generic over `T` that is
// [2]: bound by the `Display` trait, which guarantees
// [3]: that values of type `T` can be printed.

<T: Display> is the syntax to declare a generic type parameter with a trait bound. In this case, it means that T is any type that implements the Display trait, which also means that we can print it.

Because string slices and integers implement the Display trait, we can use reverse_print with both str_vector and int_vector:

let mut str_vector: Vec<&str> = vec!["one", "two", "three"];
reverse_print(&mut str_vector);
// Prints:
// three
// two
// one

let mut int_vector: Vec<i32> = vec![1, 2, 3];
reverse_print(&mut int_vector);
// Prints:
// 3
// 2
// 1

But it doesn’t work with types that don’t implement Display:

struct LevelScore(i32, i32);

let mut score_vector = vec![LevelScore(10, 5), LevelScore(5, 20)];

reverse_print(&mut score_vector);


error[E0277]: `LevelScore` doesn't implement `std::fmt::Display`
    |
    | reverse_print(&mut score_vector);
    | ------------- ^^^^^^^^^^^^^^^^^ `LevelScore` cannot be formatted with the default formatter
    | |
    | required by a bound introduced by this call
    |
    = help: the trait `std::fmt::Display` is not implemented for `LevelScore`
note: required by a bound in `reverse_print`

Trait bounds on type parameters let us tell the compiler that we want the generic type to have particular behavior.

Multiple trait bounds

We can specify more than one trait bound. Let’s write another generic function that works with vectors: print_max should find and print the maximum element, which we can find by using the corresponding iterator and its method max:

use std::fmt::Display;

// [1]
fn print_max<T: Ord + Display>(elements: &[T]) {
    match elements.iter().max() {
        Some(max_value) => println!("Max value: {}", max_value),
        None => println!("Vector is empty"),
    }
}

// [1]: We use `+` to specify multiple traits.

This time, because we need to compare and print elements, we tell the compiler that T can only be the types that implement both Ord and Display.

💡 Because we don’t change the number of items, it’s recommended to use a slice (&[T]) instead of a vector &Vec<T>. If you want to refresh your knowledge, check out The Slice Type in the Rust book.

There is an alternative syntax that helps make the function signature cleaner. Instead of writing the trait bound with the type parameter declaration, we can list traits after the function parameters:

use std::fmt::Display;

fn print_max<T>(elements: &[T]) // [1]
where // [2]
    T: Ord + Display, // [3]
{
    match elements.iter().max() {
        Some(max_value) => println!("Max value: {}", max_value),
        None => println!("Vector is empty"),
    }
}

// [1]: The function signature is followed by
// [2]: `where` clause, where we 
// [3]: specify the trait bounds.

With either syntax, the print_max function works with any vector of elements, as long as their type implements both Ord and Display:

let mut int_vector = vec![10, 200, 3];
print_max(&int_vector);
// Prints:
// Max value: 200

let mut str_vector = vec!["Go", "Scrabble", "Battleship", "Monopoly"];
print_max(&str_vector);
// Prints:
// Max value: Scrabble

Trait bounds on other generics

Trait bounds aren’t limited to generic functions. We can restrict any type parameter using traits.

For example, we can use trait bounds on generic structs:

// [1]
struct GameScore<T: Ord> {
    name: String,
    scores: Vec<T>,
}

impl<T: Ord> GameScore<T> {
    fn high_score(&self) -> Option<&T> {
// [2]
        self.scores.iter().max()
    }
}

// [1]: We bound `T` with the `Ord` trait.
// [2]: So we can use `max` to return the maximum score.


let taylor_score = GameScore {
    name: "taylor".to_string(),
    scores: vec![10, 200, 3],
};

println!("{:?}", taylor_score.high_score());
// Prints:
// Some(200)

We don’t have to restrict the whole struct. We can limit implementations; in other words, we can conditionally implement methods for types that implement specific traits. For example, we can create two GameScore methods: high_score that can be used when vector elements implement Ord and reverse_print_scores – when they implement Display.

use std::fmt::Display;

struct GameScore<T> {
    name: String,
    scores: Vec<T>,
}

impl<T: Ord> GameScore<T> {
    fn high_score(&self) -> Option<&T> {
        self.scores.iter().max()
    }
}

impl<T: Display> GameScore<T> {
    fn reverse_print_scores(&mut self) {
        while let Some(last) = self.scores.pop() {
            println!("{}", last);
        }
    }
}

In the case of integer vector, we can use both:

let mut taylor_score = GameScore {
    name: "taylor".to_string(),
    scores: vec![10, 200, 3],
};

println!("{:?}", taylor_score.high_score());
// Prints:
// Some(200)

taylor_score.reverse_print_scores();
// Prints:
// 3
// 200
// 10

But if we have a custom type that only implements Ord, we can only use one of the methods:

#[derive(PartialEq, PartialOrd, Eq, Ord, Debug)]
struct LevelScore(i32, i32);

let mut dale_score = GameScore {
    name: "Dale".to_string(),
    scores: vec![LevelScore(10, 5), LevelScore(5, 20)],
};

println!("{:?}", dale_score.high_score());
// Prints:
// Some(LevelScore(10, 5))

Calling the second method doesn’t compile because LevelScore doesn’t implement Display:

dale_score.reverse_print_scores();


error[E0599]: the method `reverse_print_scores` exists for struct `GameScore<LevelScore>`, but its trait bounds were not satisfied
    |
    | struct GameScore<T> {
    | ------------------- method `reverse_print_scores` not found for this
...
    | struct LevelScore(i32, i32);
    | ---------------------------- doesn't satisfy `LevelScore: std::fmt::Display`
...
    | dale_score.reverse_print_scores();
    | ^^^^^^^^^^^^^^^^^^^^ method cannot be called on `GameScore<LevelScore>` due to unsatisfied trait bounds
    |

Conclusion

Generics allows us to write both more flexible and more restrictive code. When we use generics, we can write generic code for multiple types and not worry about the implementation for concrete types.

We learned how to use generics to write less code, create generic functions, structs, enums, methods, or traits, and restrict generics with trait bounds.

This blog post covered how to achieve compile-time polymorphism (generic code) using generics. We can use trait objects to get a run-time polymorphism (similar to virtual functions in other languages). In the Rust Book, you can read about using trait objects to allow functions to perform dynamic dispatch and return different types at run-time.

Lifetimes are another kind of generics that give the compiler information about how references relate to each other. We can ensure that references are valid as long as we want them. A good starting point is the Validating References with Lifetimes chapter of the Rust Book.

If you would like to read more beginner-friendly articles about Rust, be sure to follow us on Twitter or subscribe to our newsletter via the form below.

Machine Learning Trends for 2023

Serokell — Mon, 02 Jan 2023 00:00:00 +0000

Machine learning and artificial intelligence is a field that drives major innovations across different industries. It is predicted that in 2023, the AI market will reach $500 billion, and in 2030, $1,597.1 billion in size. This means that machine learning technologies will continue to be in high demand in the near future.

However, the machine learning industry evolves very rapidly: new technologies and scientific research define how new products and services are built. At the end of 2022, everyone, from machine learning engineers to startup founders, is on the lookout for the most promising trends for the next year. If you want to learn about some of the hottest trends for the upcoming year, continue reading this article.

Machine learning technology trends

We can never predict with 100% certainty what kind of technologies will be in demand next year, since new innovations appear every day. But here are some of the most promising machine learning trends for 2023, based on what we have seen in 2022.

1. Foundation models

Large language models are an important innovation that has gained popularity recently and is most likely to stay with us in the nearest future. Foundation models are artificial intelligence tools that are trained on immense amounts of data, even compared to regular neural networks.

Engineers try to achieve a new level of understanding by teaching the machines to not just search for patterns but also accumulate knowledge. Foundation models are incredibly helpful in content generation and summarization, coding and translation, and customer support. Well-known examples of foundation models are GPT-3 and MidJourney.

An amazing thing about foundation models is that they can also scale fast and work with data they have never seen before, hence their wonderful generating capabilities. Leading providers of these solutions are NVIDIA and Open AI.

2. Multimodal machine learning

In such tasks as computer vision or natural language processing that involve interaction between the model and the real world, the model often has to rely only on one type of data, be it images or text. But in real life, we perceive the world around us through many senses: smell, hearing, feeling textures, and flavors.

Multimodal machine learning suggests using the fact that the world around us can be experienced in multiple ways (called modalities) to build better models. The term “multimodal” in AI describes how to build ML models that can perceive the event in multiple modalities at a time, just like humans do.

Building an MML can be achieved through combining different types of information and using them in training. For example, matching images with audio and text labels to make them easier to recognize. Multimodal machine learning is so far a young field that is yet to be developed and advanced in 2023, but many believe that it can be key to achieving general AI.

3. Transformers

Transformers are a type of artificial intelligence architecture that performs transduction (or transformation) on an input sequence of data using encoder and decoder and transforms it into another sequence. Many foundation models are also built on transformers. However, we wanted to point them out separately since they are used for many other applications. In fact, it is reported that transformers are taking the AI world by storm.

Also called Seq2Seq models, transformers are widely used in translation and other natural language processing tasks. Because transformers can analyze sequences of words rather than individual words, they generally show better results than ordinary artificial neural networks.

Rather than simply taking all words in a sentence and translating them word by word, a transformer model is able to assign weights that assess the importance to each word in the sequence. Then, the model transforms it into a sentence in a different language that takes in consideration the assigned weights. Some of the leading solutions that can help you build transformer pipelines are Hugging Face and Amazon Comprehend.

4. Embedded machine learning

Embedded machine learning (or TinyML) is a subfield of machine learning that enables machine learning technologies to run on different devices.

TinyML is used in household appliances, smartphones, and laptops, smart home systems, and more. As Lian Jye Su, AI & ML Principal Analyst at ABI Research explains:

The proliferation and democratization of AI has fueled the growth of Internet of Things (IoT) analytics. Data collected from IoT devices are used to train Machine Learning (ML) models, generating valuable new insights into the IoT overall. These applications require powerful and expensive solutions that rely on complex chipsets.

The rising popularity of embedded machine learning systems is one of the major drives of the chipset manufacturing industry. If ten years ago, the number of transistors on a chipset doubled every two years, according to Moore’s law, which allowed us to predict the increase in computational power as well, in the last few years, we have seen a 40-60% leap per year. We believe that this tendency will persist in the upcoming years as well.

With the wider proliferation of IoT technologies and robotics, embedded systems have gained even more importance. Tiny ML poses its own unique challenges that are yet to be resolved in 2023 as it requires maximum optimization and efficiency while saving resources.

5. Low-code and no-code solutions

Machine learning and AI have penetrated literally every field from agriculture to marketing to banking. Making ML solutions easy to use by non-techy employees is often considered by managers as a key to maintaining the efficiency of the whole organization.

However, instead of putting stuff through the long and costly process of learning programming, it’s much easier to simply choose apps that require zero or close to zero coding skills. But this is not the only issue no-code solutions are likely to solve.

Gartner has found that the demand for high-quality solutions on the market is bigger than the possibilities to deliver – “it grows at least 5x faster than IT capacity to deliver them”. No-code and low-code solutions can help bridge this gap and satisfy the demand. Similarly, low-code solutions enable tech teams alike to come up and test their hypothesis faster, reducing time-to-delivery and development costs. If 10 years ago, it would take a whole team of people to build an application or launch a website, today just one person can do the same and do it fast.

Moreover, 82% of organizations experience difficulties attracting and retaining the quality and quantity of software engineers and are willing to build and maintain their apps with the help of no-code and low-code techniques.

While many low-code and no-code solutions have appeared in recent years, the general trend is that they still are inferior in quality compared to regular development. Startups that will be able to improve the situation will win on the AI market.

Finally, it is worth mentioning that with the rapidly increasing computational power that is required to train an ML model (especially for real-time ML that runs in large organizations), cloud computing remains an important technology that lays behind the innovations. According to statistics, about 60% of the world’s corporate data is stored in the cloud, and this number is likely to grow. In 2023, we will see increased investment in cloud security and resilience to satisfy the growing needs of the ML industry.

Top technological segments for ML in 2023

Gartner has defined the technological segments that are expected to have obtained the most machine learning presence in the next 7-8 years. Among the leading areas that they have mentioned are:

Creative artificial intelligence. AI used for generative texts, code, and even images and video has gained wide popularity in 2022, especially with the release of state-of-the-art image generation network by MidJourney, DALLE-2, Stable Diffusion, and the new text-davinci-003 by Open AI. Products and services that use generational AI for fashion, creativity, and marketing will be in high demand in 2023.
Distributed enterprise management. With remote work becoming a norm, companies were bound to look for new ways to manage the workforce and maintain efficiency. According to Gartner, ML will help distributed companies to grow and increase their income.
Automation. Autonomous software systems that can take on increasingly complicated tasks and adapt to quickly changing conditions are in high demand in many industries from security to banking. New innovations that provide for smarter automation will appear in 2023.
Cybersecurity. The importance of cybersecurity is growing every year with increasing digitalization of various fields of life and the necessity to protect sensitive information. ML and AI are believed to be crucial in the role of protecting private data and securing organizations.

Conclusion

In 2023, machine learning will continue to be a promising and rapidly growing field that will present many interesting innovations. Large language models, multimodal machine learning, transformers, TinyML, and no-code and low-code solutions are the emerging technologies that will gain considerable importance in the near future.

Some of the technical segments that will increasingly use ML in 2023 are creative AI, autonomous systems, distributed enterprise management, and cyber security. Gartner predicts that in 2023, ML will penetrate even more business fields helping to increase efficiency and work security.

If you want to continue learning the latest news and gain inspiration from the leading professionals in the ML industry, stay tuned to our blog and follow us on Twitter.

Get Started with Rust: Traits

Serokell — Mon, 07 Nov 2022 00:00:00 +0000

Get Started with Rust: Traits

A trait is a basic language concept for defining shared behavior on types. Traits describe an interface that types can implement.

Rust traits are a sibling of Scala traits and Haskell type classes, as well as a cousin of C++ and Java interfaces.

This article will show you how to use traits in Rust. After reading it, you’ll be able to answer these questions:

What is a trait?
Why do we use traits in Rust?
How to implement and define traits in Rust?
What does it mean to derive a trait, and when can we do it?

We expect that you are somewhat familiar with structs and enums in Rust.

What is a trait?

Traits allow us to define interfaces or shared behaviors on types. To implement a trait for a type, we need to implement methods of that trait.

For example, let’s look at the simplified version of the PartialEq trait, which allows us to define equality for user-defined types:

trait PartialEq {
    fn eq(&self, other: &Self) -> bool;
}

For a type to implement PartialEq, it needs to implement its method: eq. Implementing it allows us to write x == y and x != y for this type.

Traits are everywhere

You don’t need to dig too deep to find traits in Rust. Let’s look at a couple of examples.

You might be familiar with for loops:

for i in [1, 2, 3] {
    println!("{i}");
}
// Prints: 
// 1
// 2
// 3

Rust’s for loop syntax is actually syntactic sugar for iterators, which are responsible for the logic of iterating over some items.

There’s a trait in the standard library for converting something into an iterator called IntoIterator. This is usually implemented for types that describe a collection. This includes Vectors, HashMaps, and Options.

Let’s look at another example.

Imagine that we’ve defined a simple Book struct and created an instance:

struct Book {
    title: String,
    author: String
}

let my_book = Book {
    title: String::from("Case of the Stuffed Goose"),
    author: String::from("Theo Witty"),
};

What can we do with it? Can we print a book?

println!("My book: {my_book}");

No. The code doesn’t compile:

error: `Book` doesn't implement `std::fmt::Display`
help: the trait `std::fmt::Display` is not implemented for `Book`

And the compiler gives us a hint. std::fmt::Display is a trait that we must implement for our Book struct if we want to print it out.

What else can we try? Can we compare two books?

let your_book = Book {
    title: String::from("Case of the Shrieking Bacon"),
    author: String::from("Casey Fennimore"),
};

if my_book == your_book {
    ...
}

Also no. We get a slightly different, but similar compilation error:

error: binary operation `==` cannot be applied to type `Book`
   |
   | my_book == your_book
   | ------- ^^ --------- Book
   | |
   | Book
   |
note: an implementation of `PartialEq<_>` might be missing for `Book`
help: consider annotating `Book` with `#[derive(PartialEq)]`
   |
   | #[derive(PartialEq)]
   |

We must implement PartialEq for our Book struct if we want to check for equality using the == operator.

We’ve got a hint that we should provide an implementation for these traits. Let’s do that next.

How to implement a trait?

How to implement a trait manually?

We should keep in mind that a trait defines an interface. In order for a type to implement a trait, it must provide definitions of all the required methods.

Let’s implement the PartialEq trait for Book. The only method we have to define is eq.

impl PartialEq for Book {
    fn eq(&self, other: &Self) -> bool {
        self.title == other.title && self.author == other.author
    }
}

These are a lot of new words at once, so let’s take a closer look. The first line defines the trait implementation:

//[1][2] [3] [4]
impl PartialEq for Book {

// [1]: `impl` keyword.
// [2]: The trait name (in this case, PartialEq).
// [3]: `for` keyword.
// [4]: The type name (in this case, Book).

Then we have to define the method:

// [1][2] [3]
    fn eq(&self, other: &Self) -> bool {
// [4]
        self.title == other.title && self.author == other.author
    }
}

// [1]: Trait instance method has
// [2]: the **&self** parameter as the first parameter;
// [3]: any extra parameters must come after.
// [4]: Implementation details.

Note: eq is an instance method – a trait method that requires an instance of the implementing type via the &self argument. Traits can also define static methods that don’t require an instance and do not have &self as their first parameter, but we aren’t going to cover them here.

The self is an instance of the implementing type that gives us access to its internals. For example, we can get our struct fields with self.title and self.author.

The actual implementation of eq is quite primitive. We compare each field between the structs and make sure that all of them are equal:

    self.title == other.title && self.author == other.author

💡 &self is syntactic sugar for self: &Self.

The Self keyword is only available within type definitions, trait definitions, and impl blocks. In trait definitions, Self stands for the implementing type. For more information, see The Rust Reference.

We can compare our books now:

if my_book == your_book {
    println!("We have the same book!");
} else {
    println!("We have different books.");
}
// Prints: 
// We have different books.

💡 Which common traits should my types implement?

There is no list of required traits. If you are writing an application, implement traits that you need as the need arises. If you are writing a library that will be used by others, it’s trickier. On the one hand, not adding a trait can limit your library users. On the other hand, removing a “wrong” trait is not backward-compatible. You can find more information on interoperability in the Rust API Guidelines.

Defining traits can be tedious and error-prone. That’s why it’s common to ask the compiler for help. The Rust compiler can provide an implementation for some of the traits via the derive mechanism.

Deriving a trait

Let’s drop the PartialEq implementation for the Book and rewind back to the compiler error:

error: binary operation `==` cannot be applied to type `Book`
   |
   | my_book == your_book
   | ------- ^^ --------- Book
   | |
   | Book
   |
note: an implementation of `PartialEq<_>` might be missing for `Book`
help: consider annotating `Book` with `#[derive(PartialEq)]`
   |
   | #[derive(PartialEq)]
   |

The compiler not only tells us what the issue is but also suggests a solution for it. Let’s follow the instructions and annotate the Book struct with #[derive(PartialEq)]:

#[derive(PartialEq)]
struct Book {
    title: String,
    author: String
}

We can compare the books again and it should behave the same:

if my_book == your_book {
    println!("We have the same book!");
} else {
    println!("We have different books.");
}
// Prints: 
// We have different books.

derive generates the implementation of a trait for us. We don’t have to do the work ourselves. It provides a generally useful behavior that we don’t have to worry about. For example, in the case of derived PartialEq on structs, two instances are equal if all the fields are equal, and not equal if any fields aren’t equal.

We can derive multiple traits at the same time – derive accepts a list of all the required traits inside the parentheses. Let’s try to derive Display so we can print our books:

#[derive(PartialEq, Display)]
struct Book {
    title: String,
    author: String
}

Unfortunately, it doesn’t compile:

error: cannot find derive macro `Display` in this scope

It says that it can’t find the way to derive it in this scope. But the compiler won’t be able to find it in any scope! Because Display can’t be derived. The Display trait is used for user-facing output, and Rust cannot decide for you how to pretty print your type. Should it print the name of the struct? Should it print all the fields? You have to answer these and other questions yourself.

Deriving is limited to a certain number of traits. In case you want to implement a trait that can’t be derived or you want to implement a specific behavior for a derivable trait, you can write the functionality yourself.

💡 Which standard library traits can be derived?

Rust book’s Appendix C: Derivable Traits provides a reference of all the derivable traits in the standard library.

💡 Can the non-standard-library traits be derived?

Yes. Developers can implement derive for their own traits through procedural macros.

💡 When should I implement and when should I derive traits?

When deriving is available, it provides a general implementation of the trait, which is what you want most of the time. If it’s not the case, you can manually define the desired behavior.

How to define a trait?

Until now, we have only been talking about other people’s traits. But we can also define our own traits.

Imagine that we want to estimate reading time. It shouldn’t matter what type of content we are reading (an article, a novel, or even a poem). We could use the following trait:

// [1]
trait Estimatable {
// [2] [3]
    fn estimate(&self) -> f64;
}

// [1]: The trait name (in this case, Estimatable).
// [2]: Trait methods (in this case, only one).
// [3]: The **&self** parameter, followed by other parameters (in this case, none)

Note: We are using a simple type for minutes for the sake of simplicity. Try not to do this at home! And try not to do this in production!

Any type implementing the Estimatable trait should define an estimate method that calculates how long it might take to read something in minutes.

Let’s try doing that.

Implementing a trait for an enum

In the previous section, we implemented a trait for a struct. Let’s try working with an enum this time. Imagine that we have a personal blog with different kinds of content:

enum Content {
    Infographic,
    PersonalEssay { text: String },
    TechArticle { text: String, topic: String },
}

We can define the Estimatable trait for it. It’s not that different from implementing a trait for a struct, but note that we have to define behavior for all the enum variants:

impl Estimatable for Content {
    fn estimate(&self) -> f64 {
        match self {
            Content::Infographic => 1.0,

            Content::PersonalEssay { text } => 
                word_count(text) / AVG_WORDS_PER_MINUTE,

            // You have to pay attention, especially when learning Rust
            Content::TechArticle { text, topic } => {
                if topic == "Rust" {
                    word_count(text) / (0.5 * AVG_WORDS_PER_MINUTE)
                } else {
                    word_count(text) / (0.7 * AVG_WORDS_PER_MINUTE)
                }
            }
        }
    }
}

Note: For this example, imagine that word_count is a function that returns the number of words in a string and AVG_WORDS_PER_MINUTE is a constant for 250.0.

Default implementations

Let’s revisit the PartialEq trait. We saw a simplified version before, here is the actual definition:

pub trait PartialEq<Rhs = Self>
where
    Rhs: ?Sized,
{
    const fn eq(&self, other: &Rhs) -> bool;

    const fn ne(&self, other: &Rhs) -> bool { ... }
}

When we defined the PartialEq implementation for the Book, we only had to implement one method, eq. But the definition clearly has two methods. How can this be?

Trait definitions can provide default method definitions. ne is a method with a default implementation.

As an example, we can extend the Estimatable trait with a display_estimate method:

trait Estimatable {
    fn estimate(&self) -> f64;

    fn display_estimate(&self) -> String {
        format!("{} minute(s)", self.estimate())
    }
}

We don’t have to update the implementation for the Content type. It works as expected based on estimate:

println!("Estimated read: {}", Content::Infographic.display_estimate())
// Prints:
// Estimated read: 1 minute(s)

Sometimes it’s useful to have default behaviors for the trait methods. When someone implements the trait for their type, they can decide whether to keep or override the default implementations.

Remember how we talked about iterators? The standard library provides a lot of useful methods for Iterator such as map, filter, and fold. As long as the collection implements either Iterator or IntoIterator, you get these for free.

(0..10) // A range of integers
  .filter(|x| x % 2 != 0) // Keep only odd numbers
  .map(|x| x * x) // Square each number
  .collect::<Vec<usize>>(); // Return a new Vector
// [1, 9, 25, 49, 81]

How to use traits in function parameters?

Now that we know how to define our own traits, we can explore how to make use of them.

A trait is an interface that defines behaviors with a contract that other code can rely on. We can implement functions that depend on this interface.

In other words, we can implement functions that accept any type implementing our trait. The functions don’t need to know anything else about these types.

Let’s see how we could implement a function similar to println! that can print any Estimatable type:

// [1] [2] [3]  
fn summarize<T: Estimatable>(obj: T) {
    println!("Estimated read: {}", obj.display_estimate());
}

// [1]: The function takes any type T
// [2]: that is Estimatable.
// [3]: `obj` has a type T.

<T: Estimatable> declares a generic type parameter with a trait bound. We can use trait bounds to restrict generics. In this case, it says that we accept any type T that implements the Estimatable trait. (If you would like to learn more about generic type parameters, see the Generic Data Types chapter of The Rust Book.)

In simple cases like this, we can use a more concise impl Trait syntax, which is syntactic sugar for trait bounds. We can rewrite it as follows:

// [1] [2] [3]
fn summarize(obj: impl Estimatable) {
    println!("Estimated read: {}", obj.display_estimate());
}

// [1]: The `obj` parameter should be a type
// [2]: that **impl** ements 
// [3]: the `Estimatable` trait.

The syntax impl Trait is convenient in simple cases, while the trait bound syntax can express more complex use cases.

Either way, we can now call summarize:

summarize(Content::Infographic)
// Prints:
// Estimated read: 1 minute(s)

If we try calling the summarize function with a type that doesn’t implement the Estimatable trait, the code won’t compile:

summarize(my_book)
// error: the trait bound `Book: Estimatable` is not satisfied

With traits, we can build functions that accept any type as long as it implements a certain behavior.

💡 We can also use traits as return types from functions.

For example, you can return an iterator from a function. Using traits in return types is less common than in parameters. If you are interested, make sure to explore it in The Rust Book.

How to extend traits?

Rust doesn’t have a concept of inheritance. However, you can define supertraits to specify that a trait is an extension of another trait. For example, we can add another trait that adds a paywall to long reads on the website. For this, we need the ability to estimate from Estimatable, so we’ll extend it.

// [1] [2][3]
trait PayWallable : Estimatable {
    fn use_pay_wall(&self) -> bool;
}

// To define 
// [1]: a subtrait,
// [2]: that extends 
// [3]: the supertrait.

If you want to implement a subtrait (PayWallable), you must implement all the required methods of the trait itself (PayWallable) as well as all the required methods of the supertrait (Estimatable). When you implement a method on a subtrait, you can use the functionality of the supertrait:

impl PayWallable for Book {
    fn use_pay_wall(&self) -> bool {
        self.estimate() > 10.0
    }
}

But if you don’t implement the supertrait, you will get a compiler error:

error[]: the trait bound `Book: Estimatable` is not satisfied
    |
    | impl PayWallable for Book {
    | ^^^^^^^^^^^ the trait `Estimatable` is not implemented for `Book`
    |

We can fix the error by implementing the supertrait as well:

impl Estimatable for Book {
    fn estimate(&self) -> f64 {
        let book_content = get_book_content_todo();
        word_count(&book_content) / AVG_WORDS_PER_MINUTE
    }
}

Traits have many uses

In this blog post, we’ve covered one major use case for traits. Traits can be used as interfaces. Traits can serve as a contract that defines an interaction between components that use the interface. All types implementing a given trait must support the functionality defined by this trait, but it can be implemented differently for each type.

For example, a sort algorithm can be applied to a collection of items of any type, as long as they support comparison (implement the Ord trait).

But traits are more flexible than that. Look at what different things we can do with traits:

Traits can be used to extend the functionality of types. We can use traits to add methods to types that are defined in other libraries. For example, the itertools library adds a lot of convenience methods to all iterators (outside of their definition).
Traits can be used for dynamic dispatch (deciding which method to call at runtime). When used like this, they are very similar to Java interfaces.

There are many other uses: traits as abstract classes, as mix-ins, as behavioral markers, and for operator overloading.

Conclusion

Understanding traits and how the standard library traits work is an important part of learning Rust.

We have learned that traits in Rust are a way to add functionality to structs or enums and define shared behavior between different types. We’ve also explored how to use traits as interfaces and peeked at the various uses of traits.

If you would like to learn more about traits and the problems they solve, check out the Rust book chapters on traits and advanced traits, and the Rust Blog post about traits.

And if you would like to read more beginner-friendly articles about Rust, be sure to follow us on Twitter or subscribe to our newsletter via the form below.

Get Started with Rust: Enums

Serokell — Tue, 25 Oct 2022 00:00:00 +0000

Get Started with Rust: Enums

There are two ways to create custom data types in Rust: structs and enums.

In contrast to structs, enums construct a type that has multiple variants and not multiple fields.

While structs are a part of pretty much any programming language, enums are not so mainstream and are mostly seen in statically typed functional languages like Haskell or OCaml. But, as we’ll see, they are quite nice for domain modeling with types.

This article will show you how to use enums in Rust. By the end of the article, you’ll know the answers to these questions:

How to define and instantiate an enum?
When to use enums instead of structs?
What is pattern matching, and why is it so useful?
What are the Option and Result enums, and how to use them?

What is an enum in Rust?

Enums (short for enumerations) are a way to create compound data types in Rust. They let us enumerate multiple possible variants of a type.

For example, we can use enums to recreate a Bool data type with two variants: True and False.

// [1]  
enum Bool {
// [2]
    True,
    False,
}

// [1]: The name of the data type.
// [2]: The variants of the data type.

We can get a value of this type by constructing it with one of the two variants.

let is_true = Bool::True;
let is_false = Bool::False;

Enum variants are like structs: they can contain fields, which can be unnamed or named. In the example below, the Alive variant contains an unnamed signed 8-bit integer.

enum HealthBar {
    Alive(i8),
    Dead,
}

let is_alive = HealthBar::Alive(100);
let is_dead = HealthBar::Dead;

If we would like to signify that the field represents life points, we can use a named “life” field instead:

enum HealthBar {
    Alive{life: i8},
    Dead,
}

let is_alive = HealthBar::Alive{life: 100};
let is_dead = HealthBar::Dead;

Rust enums might be familiar to you from other languages in the guise of sum types (Haskell and other FP languages) or discriminated unions. Together with structs, they create a simple yet highly usable mechanism for encoding a lot of information in your types.

Enums vs. structs

A struct has multiple fields. In contrast, an enum has multiple variants.

But, while the concrete value of a struct type has multiple fields, a concrete value of an enum type is exactly one variant.

Enums enable you to build clearer types and decrease the number of illegal states that your data can take.

Let’s look at an example. We want to model a character in a game.

It can have three states:

Alive. In this case, it has life points.
Knocked out. In this case, it has life points and a counter of turns it needs to wait to regain consciousness.
Dead. In this case, it doesn’t need any additional fields.

Modeling it with only a struct is quite awkward. But we can try the following:

struct Player {
    state: String,
    life: i8,
    turns_to_wait: i8,
}

Here, we store the name of the state in a string. If the character is “dead”, their life should be 0. And if they are “knocked out”, they should have some turns to wait until they can act.

let dead_player = Player {
    state: "dead".to_string(),
    life: 0,
    turns_to_wait: 0,
};

let knocked_out_player = Player {
    state: "knocked out".to_string(),
    life: 50,
    turns_to_wait: 3,
};

This works, but it’s very wonky and obscures the states in type. You need to read the code or docs to know the available states, which diminishes the value of types as documentation. You can also use any kind of string in your code, such as “daed” or “knacked out”, without a compiler error.

Using an enum, we can list all the possible states in a readable manner.

enum Player {
    Alive{life: i8},
    KnockedOut{life: i8, turns_to_wait: i8},
    Dead,
}

let dead_player = Player::Dead;
let knocked_out_player = Player::KnockedOut { 
    life: 50, 
    turns_to_wait: 3, 
};

Pattern Matching

Enum types can have one of multiple variants. So if a function takes an enum, we need a way to adapt the function’s behavior depending on the variant of data it will encounter.

This is done with pattern matching. If variants construct values of a type, pattern matching deconstructs them.

Recall our Bool data type:

enum Bool {
    True,
    False,
}

Suppose we want to create a function called neg that returns the opposite of the boolean that we provide.

This is how we can do it in Rust using pattern matching.

fn neg(value: Bool) -> Bool {
// [1]
    match value {
// [2] [3]
        Bool::True => Bool::False,
        Bool::False => Bool::True,
    }
}

// [1]: The value we’re pattern matching on.
// [2]: Pattern we want to match. 
// [3]: Result.

The result of a match statement can be either an expression or a statement.

fn print_value(value: Bool) {
    match value {
        Bool::True => println!("Clearly true!"),
        Bool::False => println!("Unfortunately false!"),
    }
}

If you want the result to be more than a single statement or expression, you can use curly braces.

fn print_and_return_value(value: Bool) -> Bool {
    match value {
        Bool::True => {
            println!("Clearly true!");
            Bool::True
        }
        Bool::False => {
            println!("Unfortunately false!");
            Bool::False
        }
    }
}

While this basic case highly resembles a case/switch statement, pattern matching can do much more. We can use pattern matching to assign values while choosing the code path to execute. This enables us to easily work with nested values.

fn take_five(player: Player) -> Player {
    match player {
        Player::Alive { life: life } => Player::Alive { life: life - 5 },
        Player::KnockedOut {
            life: life,
            turns_to_wait: turns_to_wait,
        } => Player::KnockedOut {
            life: life - 5,
            turns_to_wait: turns_to_wait,
        },
        Player::Dead => Player::Dead,
    }
}

To make the code example above even simpler, we can use the field init shorthand. It lets us substitute life:life with life in pattern matching and construction of structs.

fn take_five(player: Player) -> Player {
    match player {
        Player::Alive { life } => Player::Alive { life: (life - 5) },
        Player::KnockedOut {
            life,
            turns_to_wait,
        } => Player::KnockedOut {
            life: (life - 5),
            turns_to_wait,
        },
        Player::Dead => Player::Dead,
    }
}

The code above has one problem: it doesn’t take into account the fact that a player will die if their health reduces to 0. We can fix that with the help of match guards. and wildcards.

Match guards enable you to add if conditions to the pattern. So we can make the pattern match if the life of Player::Alive is larger than 5, for example.
If you put a wildcard (marked by underscore) in a pattern, it will match anything. It can be used at the end of a match statement to handle all the remaining cases.

fn take_five_advanced(player: Player) -> Player {
    match player {
        Player::Alive { life } if life > 5 => Player::Alive { life: (life - 5) },
        Player::KnockedOut {
            life,
            turns_to_wait,
        } if life > 5 => Player::KnockedOut {
            life: (life - 5),
            turns_to_wait,
        },
        _ => Player::Dead,
    }
}

The match statement must be exhaustive – it needs to cover all the possible values. If you fail to cover some of the options, the program won’t compile.

For example, if we didn’t use the underscore at the end of the statement, we would have two states that are not covered: Alive and KnockedOut with less than 5 life points. The compiler can detect this and reject the code.

//error[E0004]: non-exhaustive patterns: `Alive { .. }` and `KnockedOut { .. }` not covered

fn take_five_advanced(player: Player) -> Player {
    match player {
        Player::Alive { life } if life > 5 => Player::Alive { life: (life - 5) },
        Player::KnockedOut {
            life,
            turns_to_wait,
        } if life > 5 => Player::KnockedOut {
            life: (life - 5),
            turns_to_wait,
        },
        Player::Dead => Player::Dead,
    }
}

Enum methods and traits

Like structs, enums allow for the creation of associated methods and the implementation of traits. They are a powerful tool for clearing up your code and reducing boilerplate.

Defining methods for enums

Take a look at the negation function that we implemented earlier.

fn neg(value: Bool) -> Bool {
  match value {
    Bool::True => Bool::False,
    Bool::False => Bool::True,
  }
}

It would be better to have it be a method so that we can access it via dot-notation.

let is_true = Bool::True;
let not_true = is_true.neg();

To do that, we need to create an implementation block for Bool. In it, we use the self keyword to refer to the Bool value at hand. Self stands for the type we’re writing the implementation for.

impl Bool {
  fn neg(self) -> Self {
    match self {
      Self::True => Self::False,
      Self::False => Self::True,
    }
  }
}

Defining traits for enums

Like structs, enums can also have traits – Rust’s version of interfaces that enable common functionality among types.

You can derive common traits such as Debug, Clone, and Eq using the derive attribute.

#[derive(Debug, Eq, PartialEq)]
enum Bool {
  True,
  False,
}

For example, after deriving Debug and PartialEq, we can now print and compare values of Bool.

let is_true = Bool::True;
let is_false = Bool::False;
println!("{:?}", is_true); // Prints “True”. 
let are_same = is_true == is_false; // false

It’s also possible to create your own custom traits and implementations. For more info on this, you can read the trait section of the Rust book.

`Option` and `Result` enums

Two enums you will frequently encounter in Rust are Option, Rust’s safe alternative to null, and Result, Rust’s safe alternative to exceptions.

Where can they be used? Well, sometimes a function is not able to return a result for a given input. As a simple example, you cannot divide a number by 0.

let impossible = 4 / 0;

In fact, Rust doesn’t let you compile a line of code that divides by zero. But you can still do it in multiple other ways.

fn main() {
  println!("Choose what to divide 4 with!");
  let mut input = String::new();
  std::io::stdin().read_line(&mut input).unwrap();
  let divisor: i32 = input.trim().parse().unwrap();

  let result = 4 / divisor;
}

But what if we don’t want the program to crash whenever we encounter a division by zero? We can instead make the function return the Option type and handle the problem further down the code.

Option has two variants: None or Some. The first represents a lack of output – something you would commonly use null or nil for. Some can wrap any type and signifies that the function has successfully returned a value.

pub enum Option<T> {
    None,
    Some(T),
}

For example, we can wrap division in Option so it doesn’t panic when we divide by 0.

fn safe_division(a: i32, b: i32) -> (Option<i32>) {
    match b {
        0 => None,
        _ => Some(a / b),
    }
}

let possible = safe_division(4, 0); // None

Result is similar, but it returns the error encountered instead of returning None.

enum Result<T, E> {
   Ok(T),
   Err(E),
}

Here’s how safe_division looks with Result:

#[derive (Debug, Clone)]
struct DivideByZero; // custom error type

fn safe_division_result(a: i32, b: i32) -> (Result<i32, DivideByZero>) {
    match b {
        0 => Err(DivideByZero),
        _ => Ok(a / b),
    }
}

let also_possible = safe_division_result(4, 0); // Err(DivideByZero)

As you can see, we created a custom error type for the error. It’s possible to use strings to denote errors, but it’s not recommended.

`Option` and `Result` methods

Both of these enums are useful, but they tend to complicate the code.

Here are some commonly used methods that will make working with them easier. They work on both Option and Result types.

`unwrap`

The straightforward way to get the value inside an Option or a Result is to call unwrap on it.

This method has a big downside, though. Calling it on a None or Error will panic the program, defeating the purpose of error handling.

let some = safe_division(6, 3); // Some(2) let none = safe_division(4, 0); // None

let two = some.unwrap(); // 2 let oops = none.unwrap(); // thread ‘main’ panicked at ‘called Option::unwrap() on a None value’

Therefore, its use is generally discouraged. It can come in handy when you’re writing prototypes, using Rust for simple scripts, or trying out libraries.

`unwrap_or_else`

A safe way to unwrap values is to use the unwrap_or_else method.

It takes a closure (anonymous function) as an argument. If it runs into None or Err, it uses this closure to compute a value to use instead of panicking.

For example:

let two = Some(2).unwrap_or_else(|| {0}); // 2
let safe = None.unwrap_or_else(|| {0}); // 0

There are two more unwrap variants that you can use:

unwrap_or, which lets you provide a value directly. The difference between it and unwrap_or_else is that it calculates the default value anytime you run the function, while unwrap_or_else calculates it only when necessary.
unwrap_or_default, which provides a default value instead of panicking if the type has a Default trait implemented.

`?`

The question mark (try) operator is a way to get values out of Option and Result without handling the None case.

You can write it at the end of any function call that returns Option or Result that is inside a function block that returns Option or Result.

If it encounters a success state, it will extract the value and proceed with the function. If it encounters a fail state (None or Err of some sort), it will short-circuit the function and return the result.

For Option, it is approximately equivalent to:

match expr {
    Some(x) => x,
    None => return None,
}

Let’s look at an example: a function that performs safe division twice.

fn safe_division_twice(a: i32, b: i32, c: i32) -> Option<i32> {
    let result = safe_division(a, b)?;
    safe_division(result, c)
}

let one = safe_division_twice(4, 2, 2); // Some(1)
let oops = safe_division_twice(4, 0, 2); // None

It can be very useful when chaining multiple functions that use one of these enums. The alternative of safe_division_twice with match is quite wordy.

fn safe_division_twice(a: i32, b: i32, c: i32) -> Option<i32> {
    match safe_division(a, b) {
        Some(x) => safe_division(x, c),
        None => None,
    }
}

But it would become even worse when we need to chain more than two of these functions: each operation requires its own nested match statement.

How a `safe_division_thrice` function looks with `match` vs. `?`

With pattern matching

fn safe_division_thrice(a: i32, b: i32, c: i32, d: i32) -> Option<i32> {
    match safe_division(a, b) {
        Some(x) => match safe_division(x, c) {
            Some(y) => safe_division(y, d),
            None => None,
        },
        None => None,
    }
}

With the question mark operator

fn safe_division_thrice(a: i32, b: i32, c: i32, d: i32) -> Option<i32> {
    let first = safe_division(a, b)?;
    let second = safe_division(first, c)?;
    safe_division(second, d)
}

`and_then`

Another way to chain these enums without writing deep pattern matching statements is the and_then combinator.

let one = safe_division(4, 2)
    .and_then(|x| safe_division(x, 2));

let oops = safe_division(4, 0)
    .and_then(|x| safe_division(x, 2));

It extracts the wrapped value and then applies the function provided as its argument to it. In case the value is None or Error, it will short circuit the function and return that value.

In our case, it will extract the result of the first function. Then, it will take that result and pass it to the anonymous function we provided, which is the same as safe_division, but with the second argument already provided.

Conclusion

In this article, we covered the basics of enums in Rust. We looked at what they are and how they can be useful. We also looked at pattern matching, a powerful tool that can be used with enums. We also briefly touched two common enums – Option and Result – and the methods that you can use to handle them.

If you would like to read more beginner-friendly articles about Rust, be sure to follow us on Twitter or subscribe to our newsletter via the form below.

Get Started with Rust: Structs

Serokell — Tue, 16 Aug 2022 00:00:00 +0000

Get Started With Rust: Structs

In almost any programming language, you can create data structures – like classes or records – that pack a group of things together. Rust is no exception to this with structs.

This article will show you how to use structs in Rust.

By the end of this article, you’ll know:

how to define and instantiate a struct;
how to derive a trait for a struct;
what are struct methods, and how to use them.

All the code from this post is available here.

What is a struct in Rust?

In Rust, a struct is a custom data type that holds multiple related values.

Let’s jump straight into our first example and define Point – a wrapper for two coordinates.

// [1] [2]
struct Point {
// [3] [4]
    x: i32,
    y: i32,
}

// We
// [1]: tell Rust that we want to define a new struct
// [2]: named "Point"
// [3]: that contains two fields with names "x" and "y",
// [4]: both of type "i32".

Tuple structs

You can use a tuple struct to group multiple values together without naming them.

Tuple structs are defined like this:

// [1] [2] [3]
struct Point(i32, i32);

// [1]: Struct name.
// [2]: First component / field of type i32.
// [3]: Second component of type i32.

How to create an instance of a struct?

Here are the structs that we defined previously.

// Ordinary struct
struct Point {
    x: i32,
    y: i32,
}

// Tuple struct
struct PointTuple(i32, i32);

We can now create instances of these structs – objects of type Point and PointTuple.

// [1]
let p_named = Point {
// [2] [3]
    x: 13,
    y: 37,
};

// [1]: Struct name.
// [2]: Field name.
// [3]: Field value.

// [1] [2] [3]
let p_unnamed = PointTuple(13, 37);

// [1]: Struct name.
// [2], [3]: Field values.

As you can see, the initialization syntax is pretty straightforward. It’s like defining a JSON object where keys are replaced by field names.

Two things to keep in mind:

All fields must have values. There are no default parameters in Rust.
The order of field-value pairs doesn’t matter. You can write let p_strange_order = Point { y: 37, x: 13 }; if you wish to.

How to access struct fields?

Getting a value

You can get the value of a field by querying it via dot notation.

let x = p_named.x;
let y = p_named.y;

One may wonder: what’s the syntax to get the value of a specific field of a tuple struct? Fortunately, Rust has chosen the simplest way possible, by indexing tuple components starting from zero.

let x = p_unnamed.0;
let y = p_unnamed.1;

Setting a value

It’s possible to change the value of a field using dot notation, but the struct variable must be defined as mutable.

let mut p = PointTuple(1, 2);
// ^^^
p.0 = 1000;
assert_eq!(p.0, 1000);

Unlike some other languages, Rust doesn’t allow to mark a specific field of a struct as mutable or immutable.

struct Struct {
    mutable: mut i32,
// ^^^
// Expected type, found keyword `mut`.
    immutable: bool,
}

If you have an immutable binding to a struct, you cannot change any of its fields. If you have a mutable binding, you can set whichever field you want.

Reducing boilerplate

Two features reduce boilerplate code while initializing struct fields:

struct update syntax
field init shorthand

To illustrate them, we first need to define a new struct and create an instance of it using the usual syntax.

struct Bicycle {
    brand: String,
    kind: String,
    size: u16,
    suspension: bool,
}

let b1 = Bicycle {
    brand: String::from("Brand A"),
    kind: String::from("Mtb"),
    size: 56,
    suspension: true,
};

Struct update syntax

It often happens that you want to copy an instance of a struct and modify some (but not all) of its values. Imagine that a different bicycle brand manufactures a model with identical parameters, and we need to create an instance of that model.

We can move all values manually:

let b2 = Bicycle {
    brand: String::from("Other brand"),
    kind: b1.kind,
    size: b1.size,
    suspension: b1.suspension,
};

But this method involves too much code. Struct update syntax can help:

let b2 = Bicycle {
    brand: String::from("Other brand"),
    ..b1
// ^^ struct update syntax
};

..b1 tells Rust that we want to move the remaining b2’s fields from b1.

Field init shorthand

You can omit the field name in field: value initialization syntax if the value is a variable (or function argument) with a name that matches the field.

fn new_bicycle(brand: String, kind: String) -> Bicycle {
    Bicycle {
        brand,
// ^^^ instead of "brand: brand"
        kind,
// ^^^ instead of "kind: kind"
        size: 54,
        suspension: false,
    }
}

Traits

Okay, let’s try to do something with our struct. For example, print it.

let p = Point { x: 0, y: 1 };
println!("{}", p);
// ^^^
// Compile error

Suddenly, the compiler says "Point" doesn't implement "std::fmt::Display" and suggests that we use {:?} instead of {}.

Ok, why not?

let p = Point { x: 0, y: 1 };
println!("{:?}", p);
// ^^^
// Compile error

Unfortunately, that doesn’t help. We still get the error message: "Point" doesn't implement "Debug".

But we also get a helpful note:

note: add `#[derive(Debug)]` to `Point` or manually `impl Debug for Point`

The reason for this error is that both Debug and std::fmt::Display are traits. And we need to implement them for Point to print out the struct.

What is a trait?

A trait is similar to an interface in Java or a typeclass in Haskell. It defines certain functionality that we might expect from a given type.

Usually, traits declare a list of methods that can be called on the types that implement this trait.

Here’s a list of commonly-used traits from the standard library:

Debug. Used to format (and print) a value using {:?}.
Clone. Used to get a duplicate of a value.
Eq. Used to compare values for equality.

In our example, Point needs an implementation of the Debug trait because it’s required by the println!() macro.

There are two ways to implement a trait.

Derive the implementation. The compiler is capable of providing basic implementations for a fixed list of traits via the #[derive] macro.
Manually write the implementation.

Let’s start with the first option. We need to add #[derive] before the definition of Point and list the traits we want to derive.

#[derive(Debug, PartialEq, Eq)]
struct Point {
    x: i32,
    y: i32,
}

let p = Point { x: 0, y: 1 };
println!("{:?}", p);

Now the compiler doesn’t complain, so let’s run our program.

> cargo run
Point { x: 0, y: 1 }

We didn’t write anything related to formatting Point ourselves, but we already have a decent-looking output. Neat!

`Eq` and `PartialEq`

You may have noticed that we also derived the Eq and PartialEq traits.

Because of that, we can compare two Points for equality:

let a = Point { x: 25, y: 50 };
let b = Point { x: 100, y: 100 };
let c = Point { x: 25, y: 50 };

assert!(a == c);
assert!(a != b);
assert!(b != c);

Manually implementing traits

Trait deriving has its disadvantages.

Only a small number of traits are derivable. Though, procedural macros allow for creation of custom derive attributes.
Sometimes the derived implementation doesn’t match your needs.

That’s why it’s possible to implement a trait by yourself.

Implementing `Display`

When we tried to print a Point instance using "{}", the compiler said that Point doesn’t implement std::fmt::Display. This trait is similar to std::fmt::Debug but it has a few differences:

It must be implemented manually.
It should format values in a prettier way, without containing any unnecessary information.

You can think of the Debug and the Display as the formatters for programmers and users, respectively.

Let’s add a manual implementation of Display. In the brackets, we have to define every function that is declared in the trait. In our case, there is only one — fmt.

impl std::fmt::Display for Point {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        write!(f, "({}, {})", self.x, self.y)
    }
}

Now we can print our Point struct both for developers and users.

let p = Point::new(0, 1);

assert_eq!(format!("{:?}", p), "Point { x: 0, y: 0 }");
assert_eq!(format!("{}", p), "(0, 0)");

Struct methods

Just like in Java or C++, you can define methods that are associated with a particular type. This is done in an impl block.

impl Point {
    // Method that can't modify the struct instance
    fn has_same_x(&self, other: &Self) -> bool {
        self.x == other.x
    }

    // Method that can modify the struct instance
    fn shift_right(&mut self, dx: i32) {
        self.x += dx;
    }
}

You can call these methods via dot notation.

// Mutable binding
let mut point = Point { x: 25, y: 25 };
assert!(!point.has_same_x(&Point { x: 30, y: 25 }));

// Calling a method that changes the object state
point.shift_right(3);
assert_eq!(point.x, 28);

Methods can mutate the struct instance they are associated with, but this requires &mut self as the first argument. This way, they can be called only via mutable binding.

Self

You may have noticed that methods have self as their first argument. It represents the instance of the struct the method is being called on, similar to how it’s done in Python. Some syntax sugar is involved here. Let’s desugar it in two steps.


1	`fn has_same_x(&self, other: &Self)`	`fn shift_right(&mut self, dx: i32)`
2	`fn has_same_x(self: &Self, other: &Self)`	`fn shift_right(self: &mut Self, dx: i32)`
3	`fn has_same_x(self: &Point, other: &Point)`	`fn shift_right(self: &mut Point, dx: i32)`

Don’t confuse self with Self. The latter is an alias for the type of the impl block. In our case, it’s Point.

Associated functions

You can also use the impl block to define functions that don’t take an instance of Self, like static functions in Java. They are commonly used for constructing new instances of the type.

impl Point {
    // Associated function that is not a method
    fn new(x: i32, y: i32) -> Point {
        Point { x, y }
    }
}

You can call these functions by using a double semicolon (::):

let point = Point::new(1, 2);

Why use methods instead of regular functions?

Methods are quite useful for making your code better. Let’s look at some examples.

Nice-looking dot notation

To call methods of a type, we use dot notation.

Besides beautiful syntax, dot notation provides an additional property — autoreferencing — which means you can write point.shift_right(3); instead of (&mut point).shift_right(3);.

Functions don’t have this advantage, you always have to reference:

shift_right(&mut point, 3);

Code organization

All methods are placed inside one or multiple impl blocks. This implies two things.

First, you don’t have to import methods.

use my_module::MyStruct;

...
let s = MyStruct::new();
s.do_stuff();
s.do_other_stuff();

Without methods, it would look like this:

use my_module::{MyStruct, do_stuff, do_other_stuff}; // ugly

...
let s = MyStruct::new();
do_stuff(&s);
do_other_stuff(&s);

Second, methods are namespaced: you don’t have name collisions across types.

my_rectangle.area()
my_circle.area()

Without methods, you would need to write something like this:

rectangle_area(my_rectangle)
circle_area(my_circle)

Methods vs. traits

Methods and traits are somewhat similar, so beginners can mix them up.

The general rule for when to use which is simple for beginners:

If you are implementing a common functionality for which a trait exists (converting to string, comparison, etc.), try to implement that trait.
If you are doing something specific to your application, probably use methods in regular impl blocks.

A method can be invoked only on the type it is defined for. Traits, on the other hand, overcome this limitation, as they are usually meant to be implemented by multiple different types.

So traits allow certain functions to be generalized. These functions don’t take just one type, but a set of types that is constrained by a trait.

We have already seen such examples:

println!("{:?}", ...) doesn’t care what kind of an object we want to print as long as it implements the Debug trait.
assert_eq!(...) allows to compare objects of any type as long as they implement PartialEq.

Conclusion

In this article, we covered the basics of structs in Rust. We explored the ways of defining, initializing, and adding implementation blocks to both structs and tuple structs. We also looked at traits and how to derive or implement them.

Structs are not the only way to create custom types. Rust also has enums. While we did not cover them in this blog post, concepts as methods, traits, and deriving can be applied to them in a similar way.

If you would like to read more beginner-friendly articles about Rust, be sure to follow us on Twitter or subscribe to our newsletter via the form below.

Kinds and Higher-Kinded Types in Haskell

Serokell — Tue, 02 Aug 2022 00:00:00 +0000

One of the more frequent comments that Haskell developers make about other programming languages is that they lack something called higher-kinded types.

Which leads to a communication problem. Since those programming languages don’t have a way to express either kinds or HKTs, it is hard for non-Haskell developers to understand what they are missing out on.

In the end, the words of the Haskell developer are dismissed as mad ravings, and everybody moves on.

But once you start working with Haskell, it makes it very intuitive for you to understand both kinds and higher-kinded types.

In this article, I will introduce you to the concept of kinds. Then, we’ll use our newfound knowledge to understand what are higher-kinded types and what makes them useful.

What’s the type of a type?

In one sentence, kinds are to types what types are to values.

We can imagine a universe of values, populated by values like "hello", True, [1, 2, 3]. And we can imagine a universe of types governing those values, with types such as String, Bool, and [Int].

But in Haskell, we have the third universe governing types, which is populated by kinds.

*
* -> *
* -> * -> *

For now, the most important thing about them is that they show the arity of a type (if we think of that type as a function).

You can read * as Type. In fact, a commonly used GHC extension called NoStarIsType disables the use of * in favor of Type. But since GHC still uses * by default, I’ll use that in the article.

To see the kind signature of a type, you can use the :k command in GHCi.

Let’s look at some examples.

All concrete types, such as String, Bool, and [Int] have the kind of *.

> :k String
String :: *
> :k Bool
Bool :: *
> :k [Int]
[Int] :: *

To have a more complex kind, you need a polymorphic type – a type with type variables in its definition. In other languages, type variables are also called generics.

For example, look at how Maybe (Haskell’s optional type) is defined in Haskell.

data Maybe a = Nothing | Just a

Maybe takes a type variable – a – and returns a type – Maybe a – that might contain an item of a.

Hence, it has the kind of * -> *.

> :k Maybe
Maybe :: * -> *

Maybe by itself is a type-level function, a type constructor. As such, there are no actual values of type Maybe – there are only values of types like Maybe Int, Maybe String, etc. We can say that Maybe is uninhabited.

Once you provide a type to Maybe, it will return a concrete type that contains values.

> :k Maybe Bool
Maybe Bool :: *
> :k Maybe String
Maybe String :: *

To have a kind of * -> * -> *, you need to have two type variables.

A classic example of this is Either (Haskell’s result type).

data Either a b = Left a | Right b

It takes two types – a and b – and returns a concrete type.

It can be applied with zero, one, or two arguments. Its kind signature varies accordingly.

> :k Either
Either :: * -> * -> *
> :k Either String
Either String :: * -> *
> :k Either String Int
Either String Int :: *

Most programming languages support these kinds of types – the most common examples of these are list and array types.

But if concrete types are like values and polymorphic types are like functions, can we have something akin to higher-order functions on types?

In other words, can we have a kind like (* -> *) -> * -> *?

Turns out, yes. In Haskell, it’s kinda easy.

What are higher-kinded types in Haskell?

One of the things that separates Haskell from most programming languages is the existence of higher-kinded types.

Higher-kinded types are types with kind signatures that have parenthesis somewhere on the left side, like this: (* -> *) -> * -> *.

This means that they are types that take a type like Maybe as an argument. In other words, they abstract over polymorphic types.

A common example is a type for any collection.

data Collection f a = Collection (f a) deriving (Show)


> :k Collection
Collection :: (* -> *) -> * -> *

This type takes a wrapper f (such as []) and a concrete type a such as Int and returns a collection of f a (such as Collection [] Int).

a :: Collection [] Int
a = Collection [1,2,3]

b :: Collection [] String
b = Collection ["call", "me", "ishmael"]

c :: Collection Maybe String
c = Collection (Just "whale")

Types like this one cannot be created in most programming languages like Java, TypeScript, or Rust without resorting to dark magic.

Example of a (failed) HKT attempt in C#.

interface ISingleton<out T>
{
T<A> One<A>(A x);
}

class ListSingleton : ISingleton<List>
{
public List<A> One<A>(A x) => new List<A>(new A[]{x});
}

The following code returns three compilation errors, out of which the first – The type parameter 'T' cannot be used with type arguments – is the compiler explicitly forbidding HKTs.

You can also see a TypeScript example of an unimplementable Collection in our article about functional TypeScript.

Of course, we cannot really write a lot of functions for this data type because it is too generic. To make it more useful, we can add some constraints, such as the outer type (f) being a functor.

But what is a functor?

HKTs and functors

In Haskell, HKTs is the realm of typeclasses like Functor and Monad. In this article, we’ll cover only Functor since it’s simpler. But most things written here apply to Monad as well.

Let’s look at what GHCi can tell us about Functor.

> :info Functor
type Functor :: (* -> *) -> Constraint
class Functor f where
  fmap :: (a -> b) -> f a -> f b
  (<$) :: a -> f b -> f a

If you’re not familiar with Haskell, this might look a little confusing. Let’s try to untangle it.

Functor in Haskell is a typeclass, which is something that bears resemblance to Rust traits, or if you squint hard, Java interfaces. Typeclasses define a set of common methods that can be shared across types.

The kind signature of Functor is (* -> *) -> Constraint, which means that it takes a type constructor like Maybe and returns something of a Constraint kind.

Constraint kind

While * is the most common kind that you will find in basic Haskell without extensions, it’s not the only one.

While data types are of kinds like * or * -> *, typeclasses are of a kind like * -> Constraint or (* -> *) -> Constraint.

Constraint is the kind of class constraints – it covers anything that can appear on the left side of the arrow when defining a type.

For example, if we want to define a polymorphic plus function in Haskell, we need to add a constraint of Num.

-- {1}
plus :: Num a => a -> a -> a
plus a b = a + b
-- {1}: Num constraint on the type of a in the signature.

It comes from the Num typeclass, whose kind is * -> Constraint.

In general, kinds with names are something you will run into much more when starting to work with extensions like DataKinds.

The main method of Functor is fmap, which is a map that works for multiple types of wrappers. Below are some examples of its usage.

fmap with []:

> fmap (+3) [1, 2, 3]
[4,5,6]

fmap with Maybe:

> fmap (+3) (Just 1)
Just 4

fmap with Either:

> fmap (+3) (Right 5)
Right 8
> fmap (+3) (Left "fatal Err0r")
Left "fatal Err0r"

If you want more information about the typeclass, you can read our article on functors.

In general, since types with the kind of * -> * don’t have any values, you can’t really work with them in most programming languages.

But in Haskell, we can take a type with such a kind and create a Functor instance for it. For example, our own data type Optional.

data Optional a = Some a | None deriving (Show)

instance Functor Optional where
  fmap f (Some a) = Some (f a)
  fmap f None = None

Once we have the instance, we can use the Functor methods for this data type.

> fmap (+3) (Some 4)
Some 7

Functor instance restrictions

Note that you can only define a Functor instance for a type of a kind * -> *. So it has to be Optional, not Optional Int or Optional String.

Types with the kind of * -> * -> * like Eitheror (,)(the tuple type) cannot have Functor instances without being applied up to the correct kind. For example, you can have a functor instance for Either a, but not Either or Either a b.

instance Functor (Either a) where
    fmap _ (Left x) = Left x
    fmap f (Right y) = Right (f y)

And because partial application happens from the left, fmap maps only the Right element of Either.

Now that we are somewhat familiar with Functor, we can use it as a constraint for the Collection data type. We’ll define a cfmap function on collections whose wrappers are functors.

It takes a function and a Collection that has a functor wrapper, and returns a Collection with the same functor wrapper but with the function applied to the value inside of it.

cfmap :: Functor f => (a -> b) -> Collection f a -> Collection f b
cfmap fun (Collection a) = Collection (fmap fun a)

Here’s how this method works:

> cfmap (<> "!") (Collection ["call", "me", "ishmael"])
Collection ["call!","me!","ishmael!"]

> cfmap (+3) (Collection [1, 2, 3])
Collection [4,5,6]

Of course, the definition is awfully similar to the fmap itself. So we could just make Collection a Functor instead.

instance Functor f => Functor (Collection f) where
  fmap fun (Collection a) = Collection (fmap fun a)

This enables us to use fmapfor collections that have a Functor wrapper.

> fmap (<> "!") (Collection ["call", "me", "ishmael"])
Collection ["call!","me!","ishmael!"]

Quite cool.

And this concludes our journey into higher-kinded types in Haskell. 🏞️

To sum up, here’s a table with the differences between concrete types, simple polymorphic types, and higher-kinded types.

(Real-life examples from base include alternative and applicative wrappers from Data.Monoid.)

Benefits of higher-kinded types

So why would a language need to support higher-kinded types?

If you ask a Haskeller, it is, of course, to be able to easily define something similar to the Functor and Monad typeclasses.

These typeclasses are very beneficial for those that know how to use them. Abstracting over a bunch of similar behaviors can lead to very elegant code.

And, additionally, if HKTs are available naturally, there’s a smaller chance that someone will create an FP library that’s unreadable for 99% of the language users. 🙃

At the same time, plenty of programming languages choose to skip HKTs. Rust, for example, is somewhat inspired by FP languages like Haskell, but it lacks higher-kinded types at the moment. People love it nonetheless.

So, it’s a complex tradeoff at the very least. Thankfully, it is one mostly resolved by language designers and not us mere mortals.

All in all, if you write code in a language that enables you to write HKTs (like Haskell), you should, of course, make use of the power. They are not that complex but help quite a lot.

But if you want to use them in a language where they are not natural to use (for example, via an FP library like fp-ts), be sure that everyone involved is OK with that beforehand.

What's That Typeclass: Functor

Serokell — Tue, 26 Jul 2022 00:00:00 +0000

You might already know the map function:

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs


> map (\x -> x + 1) [1, 2, 3]
[2, 3, 4]

It takes a function of type a -> b and applies it to each element of a list. The elements change, but the data type storing them ([]) remains the same. In this article, we’ll call such a data type with another type inside it a context.

Transforming values inside fixed contexts is common in programming.

For example, the optional data type (Maybe) provides a context of a possibly failed computation. It can also be “mapped” by trying to apply a function to the wrapped value without changing the context.

map' :: (a -> b) -> Maybe a -> Maybe b

map' f (Just x) = Just (f x)
map' f Nothing = Nothing


> map' (\x -> x + 1) (Just 1)
Just 2
> map' (\x -> x + 1) Nothing
Nothing

This article will introduce you to Functor – a typeclass that unifies these kinds of transformations and provides common functionality for them.

After reading this article, you will know:

what Functor is in Haskell;
how to define and use your own Functor instances;
why and where Functors are useful.

We’ll also provide a set of exercises to consolidate your knowledge.

How to generalize `map`

Look at the type signature of map:

map :: (a -> b) -> [a] -> [b]

It takes a function a -> b. Then, it uses that function to change the contents of a list.

Now, look at the type of map'. It uses the same type of function – a -> b – to change the contents of Maybe.

map' :: (a -> b) -> Maybe a -> Maybe b

The type signatures are kind of similar!

Could we have a more general function that works for many different contexts? Absolutely. It’s Haskell, after all.

fmap :: Functor f => (a -> b) -> f a -> f b

Here’s how it works. fmap takes an a -> b function and an f a data type (a wrapped in any context f). The function is applied to what’s inside the context, and a value of type b wrapped in f is returned. The value can change, but the context remains the same.

Let’s look at a few examples:

-- Apply `reverse :: String -> String`
-- to a list of `String`s
-- to get a list of `String`s.
> fmap reverse ["abc", "def", "ghi"]
["cba","fed","ihg"]
> fmap reverse []
[]

-- Apply `show :: Int -> String`
-- to a list of `Int`s
-- to get a list of `String`s.
> fmap show [1..3]
["1","2","3"]
> fmap show []
[]

-- Apply `(+1) :: Int -> Int` 
-- to `Maybe Int`
-- to get `Maybe Int`.
> fmap (+1) $ Just 1
Just 2
> fmap (+1) Nothing
Nothing

-- Apply `(> 0) :: Int -> Bool` 
-- to `Maybe Int`
-- to get `Maybe Bool`.
> fmap (> 0) $ Just (-1)
Just False
> fmap (> 0) $ Just 1
Just True
> fmap (> 0) Nothing
Nothing

-- Apply `chr :: Int -> Char`
-- to a pair `(a, Int)`
-- to get a pair `(a, Char)`.
-- Note that only the second value is mapped.
> fmap chr (65,65)
(65,'A')
> fmap chr ('a',97)
('a','a')

As you may have guessed, map is just a synonym of fmap for lists. But it can do much more. With fmap, we can do actions inside data types like [], Maybe, Either a, ((,) a), and others.

Of course, we cannot provide an implementation of fmap that works for all contexts. Instead, to use it on a data type, that type needs to have an instance of the Functor typeclass. As we’ll see, Functor is the thing that provides the implementation.

The Functor typeclass

What’s the Functor typeclass? Let’s ask GHCi.

> :info Functor
type Functor :: (* -> *) -> Constraint
class Functor f where
  fmap :: (a -> b) -> f a -> f b
  (<$) :: a -> f b -> f a
  {-# MINIMAL fmap #-}

Functor in Haskell is a typeclass that provides two methods – fmap and (<$) – for structure-preserving transformations.

To implement a Functor instance for a data type, you need to provide a type-specific implementation of fmap – the function we already covered.

For most common data types, instances of Functor are already implemented. For your own data types, you’ll need to define them yourself.

data Option a = Some a | None

instance Functor Option where
  fmap f (Some a) = Some (f a)
  fmap f None = None

We’ll cover how to do this in more detail later.

What can be a functor?

There’s two things that limit what you can implement a Functor instance for: the kind signature of Functor and its laws.

Kind signature of Functor

The kind of Functor is (* -> *) -> Constraint, which means that we can implement Functor for types whose kind is * -> *. In other words, we can implement Functor for types that have one unapplied type variable.

For example, Maybe and [] take one type variable. Hence their kind is * -> *, and there’s a straightforward Functor implementation for them.

> :kind Maybe
Maybe :: * -> *

Int has no type variables, and its kind is *, so you cannot create a Functor instance for it.

> :kind Int
Int :: *

Either takes two type variables, so it’s kind is * -> * -> *. But if we apply it once, we can make the kind be * -> *.

> :kind Either
Either :: * -> * -> *
> :kind Either String
Either String :: * -> *

Therefore, there is a valid Functor instance for an applied Either – instance Functor Either a, where a signifies any variable that could be applied.

Functor laws

Some of Haskell typeclasses have laws – conditions that instances have to meet. Usually, these laws come from the math concept of the same name.

A functor is a mapping in category theory. Hence, we need fmap to adhere to the following laws.

Identity
Composition

You may wonder why you should follow these laws. The answer is simple – if the instance doesn’t meet these conditions, the typeclass’ methods won’t work as expected. You might run into unpredictable behaviour and confuse people that work with your code as well.

Laws aren’t enforced by the compiler, hence you need to ensure their correctness yourself. It may be a bit difficult at the beginning, but after a couple of instances, it will start to feel natural.

There is a tool that can verify whether an instance follows laws – QuickCheck. It checks properties by random testing. You can provide it a property the code needs to satisfy (a typeclass law, in our case), which is then checked on a large number of randomly generated values. You may look at the “Checking the laws” section of this article as an illustration.

The `(<$)` operator

fmap is all you need to define a Functor instance. However, the (<$) operator is worth looking at too.

Here’s the type signature of (<$):

(<$) :: a -> f b -> f a

The operator takes a value of type a, a value of type b packed in a functor f – f b – and produces a functor f a. Basically, the operator packs the first argument’s value in the context of the second argument, throwing away the second value.

Now, a little exercise. Let’s try to guess the definition of (<$) by using the provided description and the following examples.

-- replace an `Int` value
-- inside `Maybe Int`
-- with a `String`
> "abc" <$ Just 123
Just "abc"
> "abc" <$ Nothing
Nothing

-- replace each element
-- of the list `[Int]`
-- with an `Int`
> 1 <$ []
[]
> 1 <$ [0]
[1]
> 1 <$ [1..5]
[1,1,1,1,1]

Pay close attention to the list examples. y <$ [x1, x2, x3] results in [y, y, y] not [y] since the list has many values inside and not one. Each element of the list is transformed instead of the value being wrapped in [].

So, what do you think is the default definition of (<$)?

The definition of `(<$)`.

Exactly! (<$) just runs fmap with const function.

x <$ f = fmap (const x) f

Now that we’ve seen the basic components of Functor, it’s time to create our own instance of this typeclass!

How to implement a Functor instance

Let’s see how you can implement your own instance of Functor. We’ll use the NonEmpty data type as an example.

NonEmpty' represents a list with at least one element. It has two components: a must-have head a and a tail [a], which might be empty.

data NonEmpty' a = NonEmpty'
  { neHead :: a
  , neTail :: [a]
  }

To define the Functor instance, we need to implement fmap.

We define it by pattern matching on the head and the tail of the non-empty list. Applying f to the head x takes care of it, but what about the tail?

Note: to be able to write the type signature of fmap in an instance definition, you need to use the InstanceSigs extension.

instance Functor NonEmpty' where
  fmap :: (a -> b) -> NonEmpty' a -> NonEmpty' b
  fmap f (NonEmpty' x xs) = NonEmpty' (f x) ??

The tail is a regular list. And fmap for lists is already defined, so we can just use that:

instance Functor NonEmpty' where
  fmap :: (a -> b) -> NonEmpty' a -> NonEmpty' b
  fmap f (NonEmpty' x xs) = NonEmpty' (f x) (fmap f xs)

However, let’s explore the implementation to understand the mechanics of fmap better.

instance Functor [] where
  fmap :: (a -> b) -> [a] -> [b]
  fmap f x:xs = f x : fmap f xs
  fmap _ [] = []

In fact, it follows the same principle – splitting a list on head and tail and calling the function recursively. On each iteration, we apply f to the head and call fmap with the tail of the list. In the end, we need to cover the empty-list case – “fmapping” an empty list gives an empty list.

And it’s done! You’ve just seen how to define an instance of Functor. If you wish to practice more, the exercise section has an additional implementation exercise for you to try.

Functor is not always a container

There is one noteworthy fact about Functor – it’s not always a container. The laws of Functor permit some rather wild implementations. For example, functions are functors too!

But is there any data type that corresponds to functions? The answer is yes. It’s (->).

> :info (->)
type (->) :: * -> * -> *
data (->) a b

(->) is parametrized with two types – (->) a b. In other words, it is a -> b – a function with one argument.

We know that Functor can only be implemented for types with the * -> * kind. Unfortunately, the kind of (->) is * -> * -> *. It doesn’t satisfy the Functor instance in this form because a Functor can only have one type argument.

Hence, it’s required to apply it once, as we do with Either a or ((,) a). In the (->) case, it means providing the function argument’s type – (->) a or a -> (the latter is not valid syntax in Haskell, though).

For example, functions with the following type signatures have Functor instances:

Int -> a
String -> a
(Char, Int) -> a
[Int] -> a

So we’ve found out what functions can be functors and what data they match. The next question is – what does it mean to fmap a function? Intuitively, it’s about changing the function, i.e., the action it performs. But what is the fixed context here?

Let’s construct the type definition of fmap for a one-argument function. For an arbitrary Functor f, fmap is:

fmap :: Functor f => (a -> b) -> f a -> f b

The type of our data is (->) c. Therefore, we need to replace f t by (->) c t or c -> t. Consequently, the type signature is:

fmap :: (a -> b) -> (c -> a) -> (c -> b)

Now we can see that the fixed context corresponds to the type of function’s argument c. And the value being modified is the function’s return type – we go from a to b with the help of the a -> b function.

All in all, fmap for functions transforms what the function returns while keeping the input unchanged! Does that look familiar to you?

Which Haskell function or operator can produce a `c -> b` function from `a -> b` and `c -> a`?

Function composition:

> :t (.)
(.) :: (a -> b) -> (c -> a) -> c -> b

Note that

(a -> b) -> (c -> a) -> c -> b

is exactly the same as

(a -> b) -> (c -> a) -> (c -> b)

since -> in Haskell is right-associative.

Cool! fmap for Functor is just the composition of functions.

Here’s the ((->) a) instance implementation:

instance Functor ((->) a) where
  fmap = (.)

In conclusion, let’s make sure fmap is (.) for one-argument function a -> b with the example below:

-- fmap :: (Int -> Int) -> (Int -> Int) -> Int -> Int
> fmap (+1) (*2) 2
5
> (+1) . (*2) $ 2
5

It’s uncommon to consider a function a Functor in Haskell. In fact, it’s more of a fancy case. However, you’ll not be puzzled when you come across this magical and strange usage of fmap in the future!

Why is Functor useful?

In general, Functor is not an extraordinary typeclass. Its methods are easy to grasp and to implement.

Nevertheless, a Haskell project can hardly do without a couple of Functor instances. It enables one to do transformations on the wrapped type without knowing anything about the wrapper, and that’s very beneficial.

Moreover, Functor is a solid basis and the predecessor of the Applicative typeclass, which further leads to Monad. The latter is a famous and widely used typeclass in Haskell. Understanding it will give you a considerably greater command of the language.

Conclusion

In this article, we have covered the Functor typeclass: what it is, where it can be used, and how to implement your own instances of Functor. It’s a part of the What’s That Typeclass series, where we introduce readers to commonly used Haskell typeclasses.

If you want to read more articles from Serokell, be sure to follow us on Twitter or subscribe to the newsletter via the form below.

And finally, if you see anything that’s wrong with the article or if there’s something you don’t understand, you’re welcome to submit an issue in our GitHub repo – we’d appreciate that greatly!

Exercises

Implement Functor for binary search trees.
Implement (<$) for Maybe a.
Implement a function that converts strings to upper case (toUpperString :: String -> String) without using toUpper.
Prove that the instance Functor ((->) a) we discussed previously follows the identity and composition laws.

Universal and Existential Quantification in Haskell

Serokell — Tue, 19 Jul 2022 00:00:00 +0000

In logic, there are two common quantifiers: the universal quantifier and the existential quantifier. You might recognize them as ∀ (for all) and ∃ (there exists).

They are relevant to Haskellers as well, since both universal and existential quantification are possible in Haskell.

In this article, we’ll cover both types of quantification.

You’ll learn how to:

Make universal quantification explicit with ExplicitForAll.
Create a heterogeneous list with existential data types.
Use existentially quantified type variables to make instantiation happen at the definition site.

Universal quantification

In Haskell, all type variables are universally quantified by default. It just happens implicitly.

As an example, look at the id function.

id :: a -> a

We can think of it as “for all types aaa, this function takes a value of that type and returns a value of the same type”.

With the ExplicitForAll extension, we can write that down explicitly.

{-# LANGUAGE ExplicitForAll #-}

id :: forall a. a -> a

The syntax is simple – at the beginning of a function or instance declaration, before any constraints or arguments are used, we use the forall quantifier to introduce all type variables that we’ll use later.

Here, we introduce four variables: a, b, c, and m:

func :: forall a b c m. a -> b -> m c -- OK, it compiles

All type variables that you introduce in your type signature should belong to exactly one forall. No more, no less.

func :: forall a b c. a -> b -> m c -- Error, type variable `m` is not introduced

Of course, we can also add constraints. For example, we might want to specify that the m variable needs an instance of the Monad typeclass.

func :: forall a b c m. Monad m => a -> b -> m c

So far, it might not seem very useful. Nothing changes when we add the quantifier because it’s already there (although implicit). On its own, ExplicitForAll doesn’t do a lot.

However, making the quantification explicit allows us to do some new things. You frequently need it to work with other extensions. Some of them will work better, and some of them just won’t work at all without the forall quantifier. :)

Practical use cases of universal quantification

Reordering type variables

With ExplicitForAll, you can change the order that type variables appear in the forall quantifier.

Why is that useful? Let’s imagine you want to define a function with 10 type variables.

veryLongFunction :: a -> b -> c -> d -> e -> f -> g -> h -> i -> j
veryLongFunction = ...

(Yes, there are real-life examples of such functions.)

And when you use it, you want to instantiate the last type variable explicitly.

Instantiation

Before we proceed, a quick note on the instantiation of type variables – the process of plugging in a type to replace a type variable.

You can either let GHC do instantiation implicitly:

fst :: forall a b. (a, b) -> a
fst (x, _) = x

pair :: (Int, String)
pair = (1, "a")

-- The argument of `fst` is of type `(Int, String)`,
-- so GHC infers how to instantiate its type variables:
-- a=Int, b=String.
x = fst pair

Or you can do it explicitly with the TypeApplications extension:

{-# LANGUAGE TypeApplications #-}

-- Explicitly instantiate fst's first type variable to Int
-- and the second type variable to String.
x = fst @Int @String pair

TypeApplications assigns types to type variables in the order they appear in the (implicit or explicit) forall.

Explicit instantiation with TypeApplications is often used to give GHC a hand when it’s having trouble inferring a type or simply to make code more readable.

Now, without an explicit forall, you would write something like this:

veryLongFunction :: a -> b -> c -> d -> e -> f -> g -> h -> i -> j
veryLongFunction = ...

func = veryLongFunction @_ @_ @_ @_ @_ @_ @_ @_ @_ @Integer ...

Quite long, right? However, this can be simplified with an explicit forall:

veryLongFunction :: forall j a b c d e f g h i. a -> b -> c -> d -> e -> f -> g -> h -> i -> j
veryLongFunction = ...

func = veryLongFunction @Integer ...

Since j is the first type variable in the declaration of veryLongFunction, you can explicitly instantiate only j and omit the others.

Supporting `ScopedTypeVariables`

A common extension that needs ExplicitForAll is ScopedTypeVariables.

The code below may seem reasonable, but it will not compile.

example :: a -> [a] -> [a]
example x rest = pair ++ rest
  where
    pair :: [a]
    pair = [x, x]

It seems reasonable because it looks like both functions are referring to the same type variable a. However, GHC is actually inserting an implicit forall in both functions. In other words, each function has its own type variable a.

example :: forall a. a -> [a] -> [a]
example x rest = pair ++ rest
  where
    pair :: forall a. [a]
    pair = [x, x]

We can rename one of those type variables to make the issue even more obvious:

example :: forall a. a -> [a] -> [a]
example x rest = pair ++ rest
  where
    pair :: forall b. [b]
    pair = [x, x]

Now it’s clear that pair is a polymorphic function that promises to return a list of any type b, but its implementation actually returns a list of type a.

What we meant to say was that pair should be a monomorphic function that return a list of the type a declared in example.

To fix this, we can enable the ScopedTypeVariables extension. With this, the type variables declared in an explicit forall will be scoped over any accompanying definitions, like pair.

{-# LANGUAGE ScopedTypeVariables #-}

example :: forall a. a -> [a] -> [a]
example x rest = pair ++ rest
  where
    pair :: [a]
    pair = [x, x]

The above are just two of many examples where ExplicitForAll is useful. Other extensions that benefit from the usage of ExplicitForAll are LiberalTypeSynonyms, RankNTypes, and many more.

Existential quantification

As said earlier, besides universal quantification, Haskell also supports existential quantification. This too can be done with the forall keyword.

You can do it this way because these two constructions – (exists x. p x) -> q and forall x. (p x -> q) – are equivalent in terms of first-order predicate logic. For a theoretical proof of this statement, you can check this thread.

In this section, we’ll look at existential quantification in data types and function signatures.

Existential quantification in data types

First, to declare existentially quantified data types, you need to enable either the ExistentialQuantification or the GADTs extension.

A classic motivating example are heterogeneous lists. Haskell’s [] type represents a homogeneous list: a list whose elements are all of the same type. You can’t have a list where the first element is an Int and the second is a String.

However, you can emulate a heterogeneous list by wrapping all the elements in an existential type.

You can define an existential type by using forall on the left side of the constructor name.

data Elem = forall a. MkElem a

This effectively “hides” the element’s type a inside the MkElem constructor.

multitypedList :: [Elem]
multitypedList = [MkElem "a", MkElem 1, MkElem (Just 5)]

This is not very useful, though. When we pattern match on MkElem, the type of the inner value is not known at compile time.

useElem :: Elem -> Int
useElem (MkElem (x :: Int)) = x + 1
                 ^^^^^^^^
-- • Couldn't match expected type ‘a’ with actual type ‘Int’

There’s nothing we can do with it, not even print it to stdout.

printElem :: Elem -> IO ()
printElem (MkElem x) =
  print x
  ^^^^^^^
-- • No instance for (Show a) arising from a use of ‘print’
-- Possible fix:
-- add (Show a) to the context of the data constructor ‘MkElem’

GHC kindly suggests adding a Show constraint to the MkElem constructor. Now, when we match on MkElem, the Show instance is brought into scope, and we can print our values.

data Elem = forall a. (Show a) => MkElem a

multitypedList :: [Elem]
multitypedList = [MkElem "a", MkElem 1, MkElem (Just 5)]

printElem :: Elem -> IO ()
printElem (MkElem x) =
  -- We can use `print` here because we have a `Show a` instance in scope.
  print x

main :: IO ()
main = forM_ multitypedList printElem

λ> "a"
λ> 1
λ> Just 5

Note that, since the type variable a is “hidden” inside the MkElem constructor, you can only use the constraints declared in the constructor. You can’t constrain it any further.

allEqual :: Eq ??? => [Elem] -> Bool -- There is no type variable that you can add a constraint to.
allEqual = ...

Another useful example of hiding type variables is the SomeException wrapper.

data SomeException = forall e. Exception e => SomeException e

All exceptions, upon being thrown, are wrapped in SomeException. If you want to catch all thrown exceptions, you can use catchAll to catch a SomeException.

When you pattern match on the SomeException constructor, its Exception instance is brought into scope.Exception implies Typeable and Show, so those instances are also brought into scope.

exceptionHandler :: SomeException -> IO ()
exceptionHandler (SomeException (ex :: e)) =
  -- The following instances are in scope here:
  -- `Exception e`, `Typeable e`, `Show e`
  ...

These three instances are all the information we have about ex at compile time. Luckily, the Typeable instance we have in scope lets us perform aruntime cast, and that’s exactly what functions like catch and fromException do under the hood.

Existential quantification in function signatures

Type variables of a function can also be existentially quantified.

Before proceeding further, let’s first have a look at higher-rank types.

Higher-rank types

By default, Haskell98 supports rank-0 and rank-1 types.

Rank-0 types are just monomorphic types (also called monotypes), i.e. they don’t have any type variables:

f :: Int -> Int

Rank-1 types have a forall that does not appear to the left of any arrow. The type variables bound by that forall are universally quantified.

f :: forall a. a -> a

-- Keep in mind that the `->` operator has precedence over `.`
-- so this is equivalent to:
f :: forall a. (a -> a)

By enabling the RankNTypes extension, we unlock higher-rank types. Just like higher-order functions take other functions as arguments, higher-rank types take lower-rank types as arguments.

Rank-2 types take a type of rank 1 (but no higher) as an argument. In other words, they may have a forall that appears to the left of one arrow. The type variables bound by that forall are existentially quantified.

f :: (forall a. (a -> a)) -> Int

Similarly, rank-3 types take a type of rank 2 (but no higher) as an argument. The forall appears to the left of two arrows.

Here, a is universally quantified.

f :: ((forall a. (a -> a)) -> Int) -> Int

In general:

A rank-n type is a function whose highest rank argument is n-1.
A type variable is universally quantified if it’s bound by a forall appearing to the left of an even number of arrows.
A type variable is existentially quantified if it’s bound by a forall appearing to the left of an odd number of arrows.

Here’s another example for good measure:

f :: forall a. a -> (forall b. Show b => b -> IO ()) -> IO ()

Here, f is a rank-2 type with two type variables: a universal type variable a and an existential type variable b.

But what does it mean for a type variable to be existentially quantified?

In short: whereas universally quantified type variables are instantiated at the “use site” (i.e. the user of the function has to choose which type they want that type variable to be), existentially quantified type variables are instantiated at the “definition site” (where the function is defined). In other words, the function’s definition is free to choose how to instantiate the type variable; but the user of the function is not.

Let’s look at a real-life example. Imagine a function that prints logs while calculating some result. You may want to write logs to the console or to some file. In order to abstract over where the logs are written to, you pass a logging function as an argument.

func :: _ -> IO ()
func log = do
  username <- getUsername
  log username

  userCount <- getUserCount
  log userCount

getUsername :: IO String
getUsername = undefined

getUserCount :: IO Int
getUserCount = undefined

main :: IO ()
main = do
  -- log to the console
  func print

  -- log to a logfile
  func (appendFile "logfile.log" . show)

What type should the log function have? Since it logs both String and Int, one might think that adding a function with signature a -> IO and a constraint Show a would be enough to implement it.

log :: Show a => a -> IO ()

However, if we try this:

func :: Show a => (a -> IO ()) -> IO ()
func log = ...

We will see this compiler error:

  log username
      ^^^^^^^^
Couldn't match expected type `a` with actual type `String`...

We get this error because:

func’s type variable a is universally quantified, therefore it can only be instantiated at the use site.
We’re trying to instantiate it at func’s definition site (log username is trying to instantiate the type variable a with String and log userCount is trying to instantiate the type variable b with Int).

Because we want a to be instantiated at func’s definition site (rather than its use site), we need a to be existentially quantified instead.

{-# LANGUAGE RankNTypes #-}

func :: (forall a. Show a => a -> IO ()) -> IO ()

Now the compiler knows that no matter which function we pass to func, it must work for any type a, and func’s definition will be responsible for instantiating it.

func :: (forall a. Show a => a -> IO ()) -> IO ()
func log = do
  username <- getUsername
  log @String username

  userCount <- getUserCount
  log @Int userCount

Note that type applications aren’t strictly necessary here, the compiler is smart enough to infer the right types, but they do help with readability.

Connection between existential types and existentially quantified variables

Lastly, we should point out that existential types are isomorphic to functions with existentially quantified variables (i.e. they’re equivalent), hence their name.

For example, the Elem type we saw earlier is equivalent to the following CPS function:

data Elem = forall a. Show a => MkElem a

type Elem' = forall r. (forall a. Show a => a -> r) -> r

And we can prove this isomorphism:

elemToElem' :: Elem -> Elem'
elemToElem' (MkElem a) f = f a

elem'ToElem :: Elem' -> Elem
elem'ToElem f = f (\a -> MkElem a)

Summary

We have taken a look at universal and existential quantification in Haskell. With a few extensions and the forall keyword, quantification allows you to further expand the rich type system of the language and to express ideas that were previously impossible.

For more Haskell tutorials, you can check out our Haskell section or follow us on Twitter.

If you see any issues with the text of the blog or need some help understanding it, you’re welcome to submit an issue in blog’s GitHub repo.

Functional Futures: Carp with Erik Svedäng

Serokell — Thu, 14 Jul 2022 00:00:00 +0000

In this month’s episode of Functional Futures, our guest is Erik Svedäng, a game designer who has created many board and video games. Among them is Else Heart.Break(), a puzzle video game with its own programming language. He is also the creator of Carp, a statically-typed lisp for real-time applications.

In the episode, we talk about game design, game development, and how Carp enables developers to build performant games while keeping true to functional programming idioms.

As always, you can check out the episode on our YouTube channel or listen to the audio version on our podcast page.

Highlights from the episode

Game design

Jonn: We invite a lot of programming language designers to our podcast. And we usually jump straight into the goals of their programming language and some specifics of the runtime, etc. But with you, we’ll obviously start with games, because this is, as far as I can tell, your passion. And I think that in the case of Carp, your language, it’s kind of impossible not to start by talking about games. I hear a lot of stuff like “oh, games are so silly” or “why do adult humans play games”. Why are games so important to you?

Erik: Oh, big question. Well, I think most humans actually do play games. Even people who say they never play games actually prefer or like to play some games on their phone, and they like to play games with their friends, and so on. So it seems to me like only very boring, busy people never play games. And it’s just a part of life, I think, to enjoy games, especially with others.

So yeah, for me, it’s just one aspect of a full life. Like, you have to have food, you have to enjoy music, and you have to play some games sometimes.

Jonn: That’s a good description. And when you were talking about it, I thought that maybe even some day-to-day activities that people don’t recognize as games have features of games, where people think about those as games without realizing that those are games.

Erik: Sure, yeah, I think that happens a lot. Like, crossword puzzles or game shows on TV, and so on – that’s a very old-fashioned way of streaming.

Jonn: A very, I think, important thing to consider when we’re kind of thinking and talking about games is – what are the buckets into which we distribute games. And you know, in my humble opinion, I think the way that a particular game designer spreads the games into these buckets informs the games that this designer makes. How do you divide different games, such as, for example, Sims, Dungeons & Dragons, Magic: The Gathering, and others?

Erik: Well, that seems like a long-winded way to get me to define what a game is, which, as an academic of games – that’s a whole complete podcast.

When I create games, I don’t think too much about these pockets. My games have usually fallen into two piles. One is very hardcore versus games, kind of like new versions of chess and Go, but maybe for iPad and for the digital medium. So those are very much like hardcore game mechanics games.

And then, on the other hand, I’ve also worked a fair bit with storytelling in games. And I think those games usually can’t use game mechanics in the same way. It’s hard to force too many game mechanics on that kind of game, where the story is actually what you want to focus on.

So, for example, in Else Heart.Break(), which is one of these story games, despite the puzzles in the programming – if you fail to solve the game or the puzzles, you actually still get to experience a story, it’s just a story about this programmer who is not very good, and it still becomes a fun story. I think, for storytelling, failure is usually a big part of it, stories are about people who have problems. Maybe they succeed in the end, but still, tragedy is a big part of good storytelling.

I think that’s maybe one of the big divides between games: should the game be about winning or about losing. So yeah, I think that’s one way to divide up games.

But on the other hand, there is so much technology and systems thinking, and so on that overlaps between these two things, so you could just as well put them into the same bucket and say that it’s just games or whatever.

Jonn: Does it mean that, for example, when you’re making a, let’s say, computer “versus” game or a board “versus” game, do you think about them in the same way?

Erik: I think I used to think about them completely differently or more differently, but I also feel like the more I’ve played board games and thought about this, I feel like board game and social play, and word play, and all kinds of play can really or could really inform video games in a lot of ways.

I mean, let’s take something like Among Us, which is kind of a social party game converted to a video game, and it got a really big effect out of that. That’s maybe a good example of the kind of thing you can’t really get to – like, it’s obviously inspired by board games, and so on.

The more I learn and think about game design, I’ve realized it’s all the same, actually, in the end. It’s systems that we interact with, and what’s really important is what happens in our head when we play and what we experience, actually.

Jonn: I wonder how many of our viewers and listeners currently think “well, what is game design, even?” Because, on one hand, it’s a very, very old profession, right? We already mentioned chess and Go in passing, but it’s not like people who were inventing chess were professional game designers, right, it was very much an incremental process that spanned perhaps like hundreds or thousands of years. I mean, we have a documented history of chess rules evolving even over the past three centuries or something.

But recently, game design, at least as far as I know it’s fairly recently, has started to be recognized as a proper profession and with research elements to it. So you can go to university to study game design, but I think that there’s still this kind of veil of mystery around it. So if you could lift it a little bit and then talk a little bit about what it means to be a game designer, it would be really nice.

Erik: Sure. I’ve mainly worked as a game designer on my own or with a very small group of friends, so I don’t know much about how it is to be a game designer at a triple-A game studio, actually. It’s probably fun, but it’s very few people who get to command thousands of people to make these huge titles.

But, I mean, usually the game designer is the person who has an idea for what would be a fun game, so they are kind of the person with a vision, a bit like a director for a game, and they try to get this vision through the process of drawing art and programming the game if it’s a video game. And yeah, they’re usually also very much in charge, of course, of testing the game, especially in the early stages, like playtesting with people and seeing what is fun, and they, of course, play the game themselves a lot and change the rules of the game. So yeah, the person who comes up with the rules and the theme, and so on for the game.

Jonn: You mentioned that game designers work a lot on playtesting. So what are the actual further stages in game design before you can, you know, present your black and white prototype or beautiful prototype to your friends and start to test it?

Erik: Well, I mean, the most common place for game ideas to die is when you just try to make it work the first time, I would say. Someone has a great idea in their head and they think about the game, and then, when they sit down and start to try to put it to paper or to code or whatever, it just falls apart and it doesn’t feel as much fun as it felt when you thought about it. Because when you thought about it in your head, it was all alive, in a way, but then you have to make it so concrete when you make it on your own, or actually make it.

So yeah, that’s the first playtest, and it’s not even a playtest, it’s just the first obstacle to get over. But if you can get over that and if you can get through – usually, I try to just simulate the game versus myself to spare anyone the pain of having to play through the game, but if it feels like I actually have to make interesting decisions on my own (let’s say this is a board game), then I’ll bring it to my girlfriend or a friend or something and start playing it, and usually it changes a lot from there.

And then you just keep doing that and making, hopefully, smaller and smaller changes, until it’s something that actually works. And by that point, maybe you have started adding art and so on, and then you’re actually kind of recreating that magic that you had in your head from the beginning. But there is a long stretch there where it’s just not that cool.

But if there was something to your initial idea, I mean, that’s kind of the trick – to have this kind of seed or core vision that you can have to remember that feeling that you wanted to create in people at the beginning. If you can use that to get to the end point where that actually happens, that’s very cool and satisfying, and then you probably have something good by that point.

Game development

Jonn: Approaching the language that you made that is game oriented, can you tell us a little bit about how you approach programming games? Does it mimic the design stages? Do you have a method? Like, you have an idea for a game, you kind of have outlined its rules, let’s say, and what do you do then? Are there certain steps, like, I don’t know, I’ll take Unity, I’ll encode my gameplay loop, etc.?

Erik: Yeah, I mean, I’ve been jumping around a lot when it comes to technology. I guess, Unity is the thing I’ve used the most. A lot of game developers have the same story, it’s like the go-to tool. Creating my own language is, of course, a way to get away from that. My latest project, I used C for that one as a way to not have to use Unity.

But no matter what you do, when you make video games, what you usually want to do is to get something up on the screen. And if there is a game about moving around something, which it often is, you want to be able to move that thing with your controls. And the interesting thing about that is as soon as you have that on the screen, since you made this happen, you usually get stuck for hours.

Anyone who has programmed a game knows this. Like, it could just be a square that you move around with your gamepad, and it’s so much fun to move it around. So yeah, I guess, the professional part of me is like “yeah, yeah, so then don’t do that for five hours” but maybe I do. But yeah, you just want to get to a point where you can start feeling if there is some kind of magic to your idea.

Usually, with video games, there is a lot more extra stuff and reusing of tried and true game mechanics. For example, maybe you are creating a platforming game where you jump, and even if you have a lot of interesting ideas around the jumping part, it’s gonna work, if it doesn’t work, it’s because you did something wrong, it’s not like this is a broken way to control a character.

While if you create your own kind of game system from scratch for a board game, it could very well be that it’s not working at all. So it’s a bit different in that sense. But yeah, you just want to get to the unknowns quickly to see if you can get those working, and if your programming skills are good enough to make it happen, whatever it is that you want to happen.

Carp

Jonn: Basically, as far as I understand, you’re kind of going through the boring parts, and then you get to this open-ended thing where you actually code your game, and then, you know, you hope that you don’t crumble under like technical debt, third-party dependencies, and stuff like this. Where does Carp come into this? From what I understand from our interview so far, you kind of created it out of frustration with state of the art, one could say. Is it fair?

Erik: Sure. I’ve spent a lot of time, basically the last 10 years or so, trying to come up with a way to write games using functional languages. I did a lot of research on programming languages when I was making the language for Else Heart.Break(), and that got me, of course, into a lot of theory and books, and information about all these functional languages, and they really spoke to me, especially Lisp and Haskell.

And at the time Clojure was kind of newish, and I learned a lot of Clojure, and that was my favorite language for a while. And I really wanted to make games with it. It felt like the perfect system for creating games, with the live reload and all of that, but I realized that it had a lot of problems for making a sizable game.

I mean, Else Heart.Break() is not super optimized, but to create something of that size in Clojure, it would kill the computer, it would die, probably. It’s just really hard to handle the kind of data throughput and garbage collector nonsense that you have to deal with in that kind of language. But at the same time, I, like many people, had seen the light, I had seen how nice these kinds of languages could be and it just felt really boring to go back to writing games in C# and just be fine with that.

So that’s when I started thinking about if I could make a kind of a Lisp that I could actually use for my future games. That was the vision and goal, which I’m still working towards. I have not yet made an actual finished game with Carp, so it’s still just a distant goal but one that I’m still working towards.

Jonn: Do you have some demos of squares moving around out there already?

Erik: Sure, I mean, I’ve made Game Jam games and so on with it, but I realized that to create a big game with it, it would have to be even more stable and even faster as a compiler. Like, I can’t spend years working on something and then get stuck because my language is not good enough. Even though I think the runtime characteristics of the language would be fine for most things I want to do. But there is also just the whole tooling and especially compilation speed, which becomes a big factor when you make an actual big game or big project.

So that’s where I’m right now with the project. I’m taking a very good look at how to create a new version of Carp that has much better compilation speed.

Jonn: And the main features of Carp, aside from it being a Lisp, are that it’s borrow-checked and well-typed, right?

Erik: Yeah, exactly. The type system is kind of an ML, very basic, standard, sum types, product types, that kind of stuff. And yeah, it’s using borrow checking, very Rust-inspired but still has a kind of different feel from Rust, it’s not trying to be as detailed as Rust, it’s trying to be a bit slower but more ergonomic.

Rust is obviously a very huge influence for a lot of programming language designers nowadays, and especially people who want to make languages for games and so on. And yeah, I think it’s just kind of interesting – Rust has made their decisions, but there are many little choices you can make different from them. And I think it’s cool to see different languages trying out variations on the core idea of a fine type system.

So yeah, it feels like Rust really started a kind of revolution there with lots of languages experimenting with those ideas.

Jonn: Do I understand correctly that the biggest problem, for example, with using Clojure for programming games would be that you have a lot of stuff going on all the time and since it has a garbage collector, you kind of want to make sure that you don’t hiccup between the frames, or something like that? But how does Unity solve it? Do they have some sort of a custom runtime or is NET just so much better?

Erik: I mean there are many factors there. Unity is written in C++, I think, like the core, so it’s actually not C# all the way. That’s just in the user space. So that’s one answer. The other big answer, of course, is mutability. Like, it’s really relying on mutability, so if you just have a thousand objects in the scene and you move them slightly, you actually create no garbage at all, while if you do that in Clojure, for each frame you would create garbage for basically the whole world each frame, which is a big difference. And yeah, I guess those are the main differences, then also C# and .NET is very good for some kinds of memory usages, but so is JVM, of course.

But yeah, I think with all those things together, you get a pretty nice system. But people still run into problems with the garbage collector in Unity, so it just becomes a problem later in production. Like, you can get away with it for a long time, but if you don’t think about it, eventually you’ll have to start thinking about it, and at that point it’s not very fun.

Carp tries to be more upfront about that whole thing. Like, you would have to think about memory in the beginning of your project, but not that much in the end, while C# is the other way around.

Jonn: That’s very interesting. I assume you actually have a way to store mutable state of the world in Carp?

Erik: Yeah, it’s actually completely free in that sense, exactly like Rust, you can mutate anywhere. It’s not like Haskell where you have to mark things at all. If some algorithm or function would benefit from some kind of mutability, you can just do that wherever you are.

But the main tools people should reach for when they write a program in Carp are supposed to be functional in nature, so there are maps and filters, and so on, and those are supposed to be how you do the bulk of the work, but you can always go in and mutate if you want to. At least in the current design.

Jonn: Let’s say I want to make a very big tic-tac-toe or a Game of Life, something that can be unbounded, that can grow. How would you do that in Carp?

Erik: The way I prefer to do it is to write it very much like you would write in Clojure with immutability (like, it looks immutable). So you would maybe have some kind of reduction over the state over time. So you’re actually not storing the state like in a mutable variable or something, you’re just passing it around and around in a recursive function, basically, from the outside. And all your functions look immutable – they take the state and return the state, but since they have the borrow checker rules ingrained in them, they can do internal mutation if that’s faster. And they know that no one else is sharing that state, so it’s completely safe to do so.

Usually, that’s the kind of code I’ve been trying to make work. You basically take something that would run in Clojure and you run it in Carp instead, and instead of getting killed by GC, it never allocates after the first frame, basically.

Jonn: By the way, when I asked you how do you develop a game and you said “well, you want to get something on the screen as soon as possible” – with Carp, I can attest that it’s like really, really quick. It’s almost like I remembered in school when we had the Pascal language and you had like a graph module, you could write like use graph and draw straight away.

Erik: Yeah. I guess most languages could be like that. I just ship the compiler with some graphics bindings to STL. It’s not important that it’s STL, it’s just like it feels good for this kind of project and this kind of language to have something out of the box. It’s not the only thing you can use, but it’s something that everyone will have access to, so if you want to do something quickly or you want to do a tool or something, you know it’s built-in and it’s there. I think that makes a big difference compared to most other languages where you have to go to the package manager and find those bindings.

I mean, maybe in the future we’ll have to remove it, but I think that has been very good for people to just try out the examples and try out the language. Because it’s supposed to be used for that kind of stuff, it’s good to have it built in. I’m happy you had this experience, that was exactly what I wanted: like, just download the compiler and paste in some simple example code, and actually get graphics on the screen, and not just text.

Jonn: What does Carp compile to?

Erik: Right now, it compiles to C. The compiler is written in Haskell and compiles or emits C code, and then you use some C compiler on your system to compile it. In my new secret version of the compiler, which is going to be much faster, it’s using LLVM straight up instead of C.

And if I get that to work out, it’s gonna be much much faster. Since it’s a Lisp, it does a lot of cool stuff with the dynamic runtime to get the language to work, but that is also hard to get fast enough in Haskell. At least for me, it’s hard to write a very efficient interpreter. So the idea there is to use LLVM editing to get a much faster dynamic runtime so that compilation is faster.

Jonn: How do you see Carp used in the ideal world? Let’s say you have infinite resources. Like, you can hire the best engineers from Facebook to work on Carp. How would you develop it, and to what goal – how would engineers use the ideal Carp?

Erik: Well, I just want to have a decently fast compiler that handles what the language is right now. If you download the compiler right now, it’s a bit buggy but it works. And so I think that system would suit me very well, just no bugs and decently fast compile times is all I’m really asking for.

My idea was to make it pretty small and easy to learn language, so it’s not supposed to have that much more. The cool thing when you have macros and so on is that you can create so much yourself if something is missing, and that’s been really fun – to see people. For example, one of the coolest things that the community did with the language was to create a derive functionality, which the language did not have, where you could derive different interfaces for types, and that was just all built with macros.

Yeah, it doesn’t need to be much more than what it is right now, it just has to be done in a more efficient way. And I think now we have learned a lot from creating this current version of the compiler, so I think a rewrite of sorts will be pretty beneficial, in that sense. Since we know so much more about how to create this kind of language.

But yeah, I don’t need all Facebook engineers to make this happen, it shouldn’t be like the biggest project ever, I think. And I mean, when it comes to reaching out, I think, there is this very particular kind of person who likes both Lisp and game development. There is definitely a crew of people who enjoy both of these things, but it’s never going to be the mainstream. It’s like a niche thing.

But I think it would be fun if people in that niche got to try it out, and that it worked very well, and they could use it for their projects. So yeah, just trying to fill the needs of the gamedev Lisp programmer, that’s my only goal.

Thanks to Erik for being a guest on our podcast! 🙏

If you would like to learn more about Erik and his work, you can visit his website. To learn about Carp, you can visit its GitHub page.

If you want to hear more from us, be sure to subscribe to Functional Futures either on YouTube or your favorite podcasting platform.

Haskell in Production: Channable

Serokell — Tue, 28 Jun 2022 00:00:00 +0000

In our Haskell in Production series, we interview developers from companies that use Haskell for real-world tasks. We cover benefits, downsides, common pitfalls, and tips for new Haskellers.

Our today’s guest is Fabian Thorand, who is a team lead at Channable. Read further to learn where Channable uses Haskell, why they chose it, and what they like and don’t like about it.

Interview with Fabian Thorand

Could you tell us a little bit about Channable and your role there?

Channable offers a channel management platform through which webshops can publish their products (or other offers like job postings or vacation deals) to a wide variety of marketplaces, ad platforms, or price comparison sites. The product information can be tweaked through user-defined rules following a simple “IF … THEN … (ELSE …)” structure (e.g. reducing prices during a sales period or removing products with missing information before sending them to a third-party platform).

I joined Channable about 4,5 years ago as a backend developer in the infrastructure team, where we work on the core applications powering the Channable tool. About a year ago, the team was split into two subteams due to our continuous growth, and I became the team lead of one of them.

Where in your stack do you use Haskell?

We use Haskell for a variety of backend services. The biggest one by far is our data processing system, which powers the import from our customers, manages the data storage, and applies the user-defined rules to the data before streaming it to other components in our backend which handle the actual connections to the third-party platforms.

Another big project is our job-scheduling system for running a set of jobs with dependencies between them in the right order on a cluster of worker machines (think of “downloading data from the client system” or “exporting products to a third-party system”).

The third major part of our infrastructure using Haskell is an API gateway that handles routing (to our various backend services) and provides a common implementation for authentication, authorization, rate-limiting, etc. so that the backend services don’t have to concern themselves with that.

Last but not least, there are a few smaller utilities that we have open-sourced, such as vaultenv (fetching secrets from Hashicorp Vault and providing them via environment variables to a program) and icepeak (a JSON document store with support for push notifications via websockets).

Why did you decide to choose Haskell?

Haskell was first introduced as an experiment rewriting a component that was hitting the limits of what was possible in Python and the existing architecture (the full story is on our tech blog).

We needed a language that would complement Python well. A language that would compile to fast code while providing safety rails through its strong type system and still being high productivity. Given that we also already had several people enthusiastic about functional programming, Haskell was the natural choice.

Since that project turned out to be very successful (and is still in use today – being continually developed since then), Haskell was also chosen for another greenfield project that was started shortly after, our API gateway.

When I joined Channable, Haskell was thus already in use for these two projects. At the time, we were also running into scaling and operational troubles with our existing feed processing application (written in Scala using Apache Spark), and so Haskell was chosen once more for its replacement. More details about that rewrite can be found here.

Are there any specific qualities of Haskell that made you decide in its favor?

The main selling point is Haskell’s strong type system. It eliminates many types of runtime errors that we regularly see crop up in our Python code base (though it has gotten better since we use types in Python as well – via mypy). Additionally, it makes refactoring existing code a breeze: one can be sure that almost all required changes are caught by the compiler.

Another advantage is the focus on immutable (and persistent) data structures, allowing for cleaner designs and better testability and concurrency.

An underappreciated advantage of Haskell is also its great runtime system. It makes it very easy to add both concurrency and parallelism to your programs using lightweight threads. Something that is usually a lot harder to do in other programming languages if you didn’t design for it from the start.

Are there any libraries that you found very useful in the development process and would like to feature?

First of all, there is conduit which we use for stream processing. In our experience it has been both fast and easy to use. The only downside is that code using it is quite prone to space leaks. Well-typed has a very informative blog post on that topic.

Besides that, we use the excellent warp server for both internal and external HTTP-based interfaces. In some projects, we used it directly, in others through an additional layer like scotty or servant.

And last but not least, there is ghc-compact, which has helped us tremendously to get good performance even when working with large datasets. Though it might not really qualify as a library since it’s shipped with GHC and just wraps a feature of the GHC runtime system.

What kind of effect system do you use: RIO, mtl, fused-effects, Polysemy, or something else?

Some of the older projects use mtl-style MonadXYZ classes and corresponding deep monad transformer stacks. Those turned out to be quite unwieldy to work with for various reasons.

Firstly, for M monad (transformer) types in your stack and N classes, you need about N * M instance declarations, which adds a lot of noise to the codebase. Additionally, deep monad stacks hurt performance quite a bit, so whenever we have performance critical code, we just use plain IO.

A secondary issue is that some monad transformer combinations look tempting at first glance, but turn out to be a bad idea in practice, like the (in)famous “ExceptT over IO”: not only is it incurring a performance penalty due to the repeated packing and unpacking of the inner Either, but it also makes the code more complex instead of simpler, as there are now two failure paths to consider (with different handling functions), since IO can always potentially throw an exception.

For those reasons, our newer projects usually use some form of ReaderT IO (or just IO-functions with explicit function arguments for dependencies). Occasionally, we also use free monads in places where there is a well-defined “language” of operations that we might want to mock in tests.

Did you run into any downsides of Haskell while developing the project? If so, could you describe those?

One big downside of Haskell that is noticeable in the daily development workflow is the lack of tooling. Fortunately, at least the “IDE” side of it improved quite a bit with the haskell-language-server project, which was a game-changer in terms of development convenience.

The remaining areas that are still lacking compared to other languages are debugging (Debug.Trace-debugging is often the only viable approach) and profiling. The latter probably deserves some explanation as GHC does come with built-in profiling capabilities. Unfortunately, those are very intrusive and sometimes drastically change the performance and allocation behavior of the generated code. External profilers that don’t require special builds (except for debugging info) like perf don’t work with Haskell code. On the upside, we did have good experiences with the eventlog-based profiling, which has a lower overhead than a full-blown profiling build.

In terms of the language itself, by far our biggest issue was its GC which is performing really badly when having large heaps (upwards of several gigabytes) without taking precautions like using compact regions (see our blog for more details). With heaps growing even to the 100+GB region, we also encountered some quadratic runtime algorithms in the memory allocator of the RTS – and even compact regions didn’t help then. We documented that particular bug and have since provided a fix for it as well.

While there are a few tuning parameters, there is nothing that would alleviate these particular problems without requiring invasive code changes.

How easy is it to hire Haskell engineers for the team? Do you do any in-house training programs to get non-Haskell engineers up to speed with Haskell?

So far we didn’t have trouble finding Haskell engineers to fill our vacancies. That can probably partially be attributed to the fact that our headquarter is located in Utrecht – since Utrecht University has a strong Haskell-focused track in the Computing Science Master’s programme.

We have no explicit in-house training program, but we have hired and successfully onboarded people of varying Haskell skill levels – and an important part of the culture at Channable is to grow and learn.

As an aside, you also use Nix, which seems like a popular choice for Haskell projects nowadays. How did you decide to use it, and how was your experience using these two technologies together?

Some colleagues were using Nix for their side projects or running NixOS on their personal machines. At the time, we also had some trouble with our existing build and deployment infrastructure and were searching for solutions, and it turned out that Nix fit the bill perfectly.

We started by using Nix just as a convenient manner to bring various development tools into scope (such as stack), but not yet using it for building our code (so stack – while installed via nix – was not run in Nix-mode yet at that time). That way, we already prevented some of the issues, like having incompatible stack versions installed across developer machines.

The next step was then to port some of our build pipelines, starting with the Haskell projects. The main advantages were the pre-built Nix cache for Haskell packages (no more rebuilding the entire stackage snapshot with every minor upgrade) and the reproducibility of the builds.

The full story can be found on our tech blog

Your tech blog posts mention languages like the aforementioned Nix and Idris, working with which is definitely on some people’s bucket lists. Is experimenting with technologies common in Channable? If so, what benefits do you see in this?

We have a regular Hackathon day in the development department where people can just try out ideas they have, or investigate new technologies that look interesting. The tool written in Idris is dbcritic and was the product of one of those days.

Having this room for experimentation is definitely an important part of the engineering culture at Channable. There are a few things that people came up with during those Hackathons that are now regularly used – either in our production software, as a productivity tool, or as part of the CI pipeline.

We probably wouldn’t use Idris for any larger project, but since this particular program solves a concrete problem we had and was easy enough to package as it was, we decided to adopt it in our CI workflow.

What tips would you give for a new Haskell team starting a project in an area similar to yours?

My first recommendation would be to keep things simple. Haskell provides a lot of language-level complexity at your fingertips (just enable a few language extensions), but one needs to carefully consider if that complexity is worth the cost. Both in terms of syntactic overhead, but also in terms of increasing the burden for onboarding future colleagues

The other is more specific, but if you plan to work with large amounts of data (that isn’t just plain bytes), be sure to take into account Haskell’s GC from the start. When working with a large heap, there will be GC troubles. The only mitigation (while still being able to work with regular Haskell data structures) are compact regions. As using those has an impact on the overall architectural and algorithmic design, rewriting an existing program to use them might not be straightforward.

Where can people learn more about Channable?

About what we do on the technical side: https://www.channable.com/tech/
About the company in general: https://www.channable.com/
About our open-source projects: https://github.com/channable/

Hope you enjoyed our interview with Fabian!

To read more interviews with companies that use Haskell to solve real-world problems, head to our interview section. Also, be sure to follow us on Twitter or subscribe to our mailing list (via form below) to get updates whenever we release new articles.

Functional Futures: Grain with Oscar Spencer

Serokell — Tue, 21 Jun 2022 00:00:00 +0000

In this month’s episode of Functional Futures, our guest is Oscar Spencer – a co-author of a functional programming language called Grain that compiles to WebAssembly.

Listen to the episode to learn more about Grain, WebAssembly, and how to sell functional programming to developers.

You can check out the full episode on our YouTube channel or listen to the audio version on our podcast page.

Below, you can find some of the highlights of the episode, edited for clarity.

Highlights from our conversation with Oscar Spencer

Learning WASM

Jonn: Hello, Oscar, was my introduction fair?

Oscar: Hello! Yeah, I think your introduction was pretty fair, that’s pretty much me in a nutshell – just sort of sitting around doing WebAssembly all day – all day, every day.

Jonn: Right, and you’ve been doing it for a while, right? You started Grain a long time ago, back then like it was 2017, right?

Oscar: Yep, 2017.

Jonn: So were you a WASM guru already then and decided that you should make a language, or how did that go?

Oscar: No, I wasn’t really a WASM guru, I don’t think too many people were back then other than, you know, the folks at Mozilla. I think it was right when WebAssembly had just got turned on by default in all the major browsers, and I was a huge front-end person back then. And so I got really excited by the idea of: “Hey, wait, can we run languages that aren’t JavaScript in the browser? I absolutely want to give this a shot.”

At the time, I’d actually just completed a compilers course, and I thought it’d be really interesting if I put something together with a buddy of mine that targeted WebAssembly. And then, you know, we did that – I’ll never forget the shock on our faces when we managed to bind a DOM event from inside of WebAssembly, that was absolutely amazing. I think we both jumped out of our chairs with excitement of: “Hey, we clicked the button, and WebAssembly happened!”

So that was really exciting, and it’s crazy to think that that was back in 2017. In a way, I feel like I grew up with WebAssembly, so I’ve just been here for the ride all along, learning as I go, and I mean, it’s been great.

Jonn: A lot of people these days are basically more or less in the position like you were five years ago while working on Grain. How did you learn the concepts of the WASM virtual machine and how it’s executed? Did you just read the specification like 20 times and then it clicked? Or how was the process of learning for you?

Oscar: Funny enough, we had a lot of help. The Grain compiler initially targeted x86. I don’t want to call it boring, but for these days it was maybe a little bit boring in that sense. And so we had the official WebAssembly spec online that everyone could read. However, there was an actual reference implementation of WebAssembly written in OCaml.

That felt like a little bit of a cheat code for us because it didn’t take too much for us to figure it out. All we did was we just downloaded this WASM library from OPAM and then we just changed that as our target. We were like: “Hey, we’re gonna swap out most of these instructions with WebAssembly ones.” Doing stuff like register allocation was super easy because in WebAssembly we have unlimited registers, so it’s actually not too bad to get started, especially if you’re an OCaml nerd like we were and still are. We had a pretty easy time of it. So, yeah, definitely a little bit of a cheat code in the beginning.

But after that it’s supposed to just be, you know, reading specs, chatting with folks. There’s so many lovely people who are happy to help you understand anything that’s going on in the community. You just gotta reach out and say hi, and folks are more than happy to help you out.

Jonn: What is kind of the place to go for a beginner to to ask questions about WASM and its peculiarities?

Oscar: There is an official WebAssembly Discord that folks can join, and people chat about everything WebAssembly in there, things that you might not even imagine people are doing with WebAssembly – folks are chatting about it in there.

I think it’s good to join these circles, but also the specific circles for the actual languages and frameworks you want to use. In those circles you can get a lot more specific. Folks are going to have a little bit better answers for “how do I do this exact thing in Rust?” or “how do I do this exact thing in Grain?”.

And folks are gonna be able to get you really good answers because, like you said, WebAssembly is still pretty new. It’s not easy to figure out exactly, for example, once you’ve managed to produce a WebAssembly module, how do you actually go deploy that and run it in production, right? There are tools out there that can make it easier for you, there are folks who are running WebAssembly in Kubernetes and getting really crazy with it, but the way that you’re gonna find out about these things right now is through that personal chatting with folks, mostly on different discords.

We are gonna get to the point where we’ve got all the tooling in place and it’s super easy and everything’s well documented, but we’re still not quite there yet as a community. But we’re rapidly getting there.

Grain

Jonn: Can you tell us a little bit about your vision for Grain? If I had to do an elevator speech for Grain, I would say it happens to be the Golang of WASM. Is that a fair analogy?

Oscar: Yeah, sort of, in a way. I think my long-term vision for Grain is to be that easy entry point for people into WebAssembly with the very sly plan in the background of letting functional programming take over the future.

The whole point is to have this language that’s extremely approachable. And, I think, this is a concept that I have really picked up while looking at the React framework, looking at ReasonML, languages like this. You can take some pretty “advanced functional concepts”, but if you present them in a way that folks say, “Hey, actually, yeah, this makes a lot of sense, I’m not getting bugs in my code,” when you’re able to tell those stories about how Messenger.com went from 10 bug reports a day to 10 bug reports a year after switching to ReasonML, when you’re able to tell these stories – that gets people really excited. And so we’re trying to do a lot of that with Grain. We can give you all of this type safety, we can give you all these functional features where you’re going to be able to write really good production code, but it’s not scary, it’s approachable.

We’re breaking a couple rules in Grain. Like, we have let mut, we have mutable bindings by default, that probably scares some people, but we want to have these places where folks can come in and really feel like they’re at home, feel like they’re writing a language that they’re super comfortable in, and that they just really feel good about. I mean, along the way it’s going to be teaching them functional concepts and […] just exposing people to these things and getting them excited about it.

So that’s a lot of where we want to go with Grain – just providing a rock-solid developer experience, just having folks feel really good writing whatever programs they want. Basically being that 90 percent. So 90 percent of the programs you want to write, you can write them in Grain, and the other 10 percent of WebAssembly you need to write, you can write it in Rust. That’s sort of where we’re aiming as far as how high of a level of a language we want to be.

Jonn: To clarify one point here: I’ve seen a lot of comparisons between Grain and Elm as well. My personal experience with Elm is that it’s roughly 80-20, but stuff that’s 20 is really borderline impossible. Like, you have to go through such hoops to get that 20 percent of use cases that 80 percent don’t cover, that it almost makes me personally question if I should even go for it in the first place. How do you go about creating escape hatches for people who know what they’re doing and that really need this escape hatch?

Oscar: That’s something that we’ve been toying with. We want to make sure folks are able to do things in Grain that we don’t necessarily endorse, and so we have a couple features to do this. One of those, for example, is an attribute you can put on functions called unsafe, and it’s an attribute that allows you to say: “Hey, I’m just going to drop down and write low-level WebAssembly right here, right now.” This is not something that I want 99 percent of users to do, however, we’re going to make sure that it’s possible. For one, it made things a little bit easier for us. The entire runtime for Grain is written in Grain, and we probably wouldn’t have been able to do that without being able to write some bare WebAssembly stuff. But it’s providing escape hatches like this in the language where folks can do things, especially when it comes to, for example, binding to a WebAssembly host. Right now, doing that – it’s some low level code, and that’s not something that I expect every user do, and we’re working on projects like [inaudible] that allow you to automatically generate Grain code to bind to these interfaces, so you don’t have to do that sort of stuff.

But yeah, we want to make sure that we have these things in Grain so folks can go wherever they want. And I’ll even add on to that. One of the big exciting things about WebAssembly is the WebAssembly Component Model where we want to be able to mix languages, we want to be able to pull in components from all over the place.

So sure, maybe you don’t want to write that cryptography library in Grain, but that’s okay, you can pull in Rust’s amazing performant cryptography library, be really happy with it, and integrate it into your Grain code. Are we there right this second? No, but we can actually get there.

And I and I’m telling you, if someone came into the Grain discord and said, “Hey, I’m trying to statically link to this Rust binary,” I’d say “Okay, let’s make it happen,” because that’s something that we can actually make happen if folks are asking for it now. But this is definitely where WebAssembly is going in the future, and we’ll have these different ways for you to get that last 10 percent that you might not have wanted to write in Grain.

Jonn: That’s really cool and very very pleasant to hear! You mentioned bindings to host platforms. As far as I understand these are the kind of capabilities that are provided by the host, for example, the file system would be one such binding or like localStorage in a browser.

Oscar: Yeah, exactly. WebAssembly code runs in a sandbox, so it’s completely sealed off walls, with absolutely zero way to speak to the outside world at all. And this is how WebAssembly gets to be secure by default.

The way that we start adding on new capabilities (because maybe you do want to talk to a file or you do want to talk to the network, or something) is we add on these capabilities back via host functions. There is a set of host functions for common system calls – WASI, the WebAssembly System Interface – which provides a standard way to interact with all of these different system calls on a system. So we have that, but, additionally, you can have your host provide whatever host functions you want to do all sorts of things.

For example, there are a couple of game engines where they give you some host functions that say “here is the controller input” or “here is a buffer that you can write to for the graphics”. And that’s super cool, and there’s gonna be all sorts of different hosts providing all kinds of different host functions.

Even at Suborbital, we want folks to be able to do things like talk to a database very easily, and, of course, we could let you go make a network connection and do all that fun stuff, or we can just give you a function that says “hey, I want to query this thing” and go from there. So that’s what host functions are about. Of course, folks need to be able to bind to those host functions, but they’re very low-level things. If you’ve ever written C bindings into a language, it’s sort of exactly that – you’re writing those sort of bindings to what these host functions look like. Like I said before, we are working a lot on automating a lot of this, so folks don’t have to do it themselves.

I think my long-term vision for Grain is to be that easy entry point for people into WebAssembly with the very sly plan in the background of letting functional programming take over the future.

Grain compiler

Jonn: I briefly looked at the Grain repository and I saw that the compiler was written in the aforementioned ReasonML. You know, I don’t regularly see code written in ReasonML, and especially not one originating from 2017. Can you please talk a little bit about the language of choice first, and second, how do you get ReasonML to actually emit WASM because, as far as I understand, it’s kind of like dual-targeting language, it targets JavaScript and I think it targets x86.

Oscar: Funny enough, back in 2017, the Grain compiler was just written in pure OCaml. The reason for OCaml is – you know, that ML part stands for “meta language” – it is the perfect language for writing a language. I will take that to my grave, no one can tell me otherwise. Developing the compiler in OCaml has been an absolute dream. If you want to tell me that OCaml is bad for all these other use cases, whatever, but for building a compiler, OCaml is fantastic.

I’m not exactly sure when it happened, I think it was maybe 2019 or 2020 when we made the cut over to ReasonML and the hilarious reason for that is that there aren’t a lot of OCaml developers out there. They definitely exist, we’re here, we’re a community, but there’s not that many of them. And at this point, ReasonML had gotten more popular, probably quite a bit more popular than OCaml. It was a pretty easy switch – we could just run a tool to convert all the OCaml into ReasonML, and all of a sudden, we had a full community of people who might be interested in coming and contributing to the compiler, you know, open source is hard and we need as much help as we can get. And that’s sort of the origins of why we are in ReasonML. It’s just to have the still glorious OCaml programming to write our language.

To your other point of how do we get ReasonML to emit WebAssembly – it’s not actually the ReasonML compiler doing that. The Grain compiler just ends up being this regular binary, but the actual WebAssembly emitting happens via a project called Binaryen. Binaryen is a project that essentially gives you an IR to target just with WebAssembly instructions, and then it can serialize and deserialize modules for you. It’s very convenient and, of course, on top of that, it has loads and loads of optimizations.

We could have used full LLVM for our back end, you know, Binaryen is the project that is behind LLVM as well, but we didn’t need that. We really knew that “Hey, we’re targeting WebAssembly, let’s just sort of skip all of the LLVM bits and let’s just go straight to Binaryen,” because we still get all the same WebAssembly optimizations that we’d get if we were going through LLVM. Not the LLVM IR ones – that can be pretty powerful, but we can handle that, that’s something that we can take care of ourselves.

But yeah, we wrote some OCaml bindings to Binaryen, and that’s what we use to generate WebAssembly.

Jonn: How do you make sure that these optimizations kind of make sense for your runtime, and did you need to make any adjustments in the process of using Binaryen?

Oscar: Just to clarify, we do have a full suite of optimizations as a part of the Grain compiler that we do run. You can sort of think of these optimizations as enabling Binaryen to do more optimizing. So it’s mostly saying: “Okay, we might have a bit of code that at the WebAssembly level Binaryen wouldn’t necessarily understand how to optimize, but it’s something that we totally understand how to optimize, and we can take care of that.”

So we have a bunch of our own passes that we run, and then after that, we additionally can have those Binaryen optimizations. It’s a lot of sort of adapting our code to make sure we’re putting out WebAssembly modules that are easily optimizable.

Jonn: From what I know about WASM so far is that WASM itself does not define a runtime. It’s up to the users of WASM spec to figure out how they actually want to run this bytecode. So, and this is where for me it gets kind of intellectually tricky to figure out, what do you mean when you say runtime?

Oscar: Yeah, it is a tricky one. When I say runtime in Grain, I’m specifically referring to two things. The first thing is memory allocation and garbage collection – how do we actually manage all of this memory and everything we’re doing with all these objects that we’re allocating. That’s the first big piece. And that’s incredibly important.

There is a whole WebAssembly proposal for garbage collection that’s in the works, which we are incredibly excited for. And I think it is going to be a major piece in getting modules across languages to link together. That’s the number one concern you have right now: you can have two website modules that do something, but to make them talk to each other, they’re just gonna be writing over each other’s memory.

The second bit for the Grain runtime is all of the support infrastructure for things: like the print function for things, like the toString function, stuff like that. Sort of like the language support stuff that you expect to exist in the language, but that code has to actually exist somewhere, it’s not just given to us for free.

Jonn: In terms of Grain, I understand that you’ve made runtime yourself. Can you talk a little bit about its properties: is it strict, is it lazy, what’s your garbage collection collection strategy, etc.?

Oscar: So, one thing about WebAssembly is – some people feel that it’s kind of annoying, other people feel that it’s fine – the way you write WebAssembly is as though it’s running on a stack machine. So you push values onto the stack, you pop values off the stack, you have a good time. That’s all fine and dandy. But one of the things that WebAssembly does not allow you to do is inspect your stack. So there isn’t really a way to just see what values are in the stack, what values are live, so can I actually you know walk my stack and do some garbage collection, that’s not something you can do with WebAssembly today.

The way folks have gotten around this is they’ve implemented their own stack and they just have the actual website code manipulate the stack that’s in memory. That’s one way to do it. For us, we chose to use the WebAssembly stack as intended, and so that gets rid of a whole class of garbage collection that we could potentially do. So instead we do reference counting garbage collection. We just keep track of how many references you have to this thing, and if it goes dead, then we reclaim that memory.

That’s really all that happens there, it’s fairly simple. But it’s still a garbage collector, which means it is a pain to maintain, and so we’re always looking up to the WebAssembly spec gods and asking “please deliver sgc”. We will be so grateful when we no longer have to maintain this. Nothing hurts my soul more than a GC bug and just the hours and hours lost to debugging.

In terms of language properties, we’re fairly strict, we evaluate things when you write it, it’s evaluated there, you don’t have to worry about if it is going to be lazy, is this happening later. Which, I think, might come as a disappointment to some people that might want to see lazy evaluation everywhere, but yeah, no, we’re pretty strict.

The reason for OCaml is – you know, that ML part stands for “meta language” – it is the perfect language for writing a language. I will take that to my grave, no one can tell me otherwise. Developing the compiler in OCaml has been an absolute dream. If you want to tell me that OCaml is bad for all these other use cases, whatever, but for building a compiler, OCaml is fantastic.

Keeping up with WASM spec

Jonn: This actually brings me to the following question. Throughout this interview, you say a lot of phrases like “as of today, WASM has this property”. How do you cope with changes in the spec, because I assume that you want to be on the forefront at all times?

Oscar: I think that’s one of our biggest challenges right now. There are some runtimes that we support and that we want to support that are maybe a little bit behind the times in keeping their WebAssembly internal engine up to date to actually be able to run some of this stuff.

And that’s a problem because we want to continue moving fast, we want to be using all the latest features and whatnot. So we have a handful of compiler flags to deal with this that turn off specific classes of instructions. For example, we have a flag that’s “no bulk memory”. It’s like hey, just don’t use bulk memory instructions. and go get some polyfills of these things. Which is kind of a little sad. We do want to be on the forefront of things.

I will say, a lot of folks are pretty good at updating their runtimes. We probably will end up having just more flags to turn features on and off, but come the end of the year, I think we might get a little more strict, I might start just dropping old WebAssembly features. Because, yeah, WebAssembly is rapidly evolving, we’re seeing proposals land, things are happening.

I think a really big one is tail calls, for example. We waited a long time for WebAssembly to have support for tail calls, and now we do. And if anyone ever opens an issue on Grain saying: “Hey, I wrote a tail-recursive function but it blew the stack,” I will not be happy to say the least, because this is a feature that exists in WebAssembly but not all runtimes support it, and so, by default we don’t have that flag turned on. And you do have to know to turn on that flag in certain runtimes.

So yeah, I think it is kind of just going to come to the point where we’re just not going to support old features, we’re going to be expecting folks – you know, proposals that were marked finished a year ago, I think we can safely say “Hey, yeah, you need to go upgrade your engines if you want to continue using the language.”

But, honestly, I think some of the old versions of Grain are pretty good too, it’s like they might be stuck on one version for a little while, but I think that’s okay.

Jonn: In terms of you personally like or your team, rather: you mentioned that there are features that are getting implemented for WASM, but are there breaking changes, do you need to do a lot of refactoring to accommodate those new features or breaking changes?

Oscar: I have to say, the WebAssembly team did an amazing job at making WebAssembly be in a position where it didn’t have to have a set of breaking changes. The binary format – the major version has not changed since launch, we’re still on version one of WebAssembly, so there’s no sort of random bytes that are going to just straight up crash the runtime other than new instructions that have been introduced.

And so some runtimes, when they’re trying to load a module, might just say “oh, I don’t recognize that opcode, and I’m gonna die.” And you know, that’s okay, it happens. But in terms of all the tooling to prepare the WebAssembly, you know, all that stuff continues to work.

So we haven’t had too much trouble in terms of breaking changes that’s like “Ugh, here they go again, breaking stuff,” it’s actually been quite pleasant. I think there’s a proposal right now for WebAssembly feature detection, if I’m not mistaken, to just make sure that “Hey, I know that this runtime is going to support these things,” and you can compile different versions of your modules depending on what features are available. That’ll be pretty nice when we can do stuff like that. As long as we’re able to support a couple flags that turn features on and off, then you know we’ll be okay.

I have to say, the WebAssembly team did an amazing job at making WebAssembly be in a position where it didn’t have to have a set of breaking changes. The binary format – the major version has not changed since launch, we’re still on version one of WebAssembly, so there’s no sort of random bytes that are going to just straight up crash the runtime other than new instructions that have been introduced.

Refactoring Grain

Jonn: In terms of your early work, if we go a little bit back in history, did you hit the nail on the head from the first attempt?

Oscar: Oh, absolutely not. [laughs]

Jonn: So, then, what was your experience with refactoring the compiler code or bits of runtime that you write, etc.?

Oscar: That experience there was sort of the journey of going from a toy language to like a real, actual, serious language. Because, yeah, in the beginning the code base was kind of just the result of a school project, and I don’t know about you, but I’m not really trying to ship code from a school project to production, right? So it was a lot of refactoring, rebuilding a lot of pieces from the ground up to make them production class.

Ever since then, I’ve grown a ton as an engineer, other folks on the team have grown a ton as engineers in general, but also compiler engineers, which is understanding more concepts and things that we should be doing right as we’re developing.

I think a lot of it was refactoring code that way, refactoring a lot of ideas we had in the language of just how we want to reason about things, really hitting, “Okay, where exactly do we want the language to go?” Because in the beginning, we didn’t necessarily know, we were just kind of having fun, and we saw an opportunity – if we put in a little bit of effort, a little bit of elbow grease, we can actually build something that people are gonna love to use and people will actually want to use.

Because, fundamentally, a lot of the languages we have for WebAssembly right now are just super low-level, and that’s fine for some folks writing WebAssembly, they can deal with that. But the vast majority of people probably want to write a bunch of high-level code. And so it was a lot of how can we mold Grain to fit that bill more, how can we get Grain to a place where it’s super approachable for people to write code and run it, and where it runs reasonably fast. Is it gonna be as fast as a very serious Rust module? Maybe no, but most people probably don’t need that, given how fast WebAssembly is.

So it’s a lot of just reworking a lot of the ideas of the language, and, of course, there’s a lot of code with that too. But yeah, the road to 1.0 is paved with many, many features and things we want to get done. A huge one that folks have been asking for is macros. We want to have macros in the language. That’s a big, hairy feature that hopefully we’ll get a chance to start working on soon.

OCaml / ReasonML

Jonn: Does OCaml or ReasonML, now, help you formulate your ideas better, or do you do whiteboard brainstorming and then kind of shove your idea into the type system? How does it go?

Oscar: It’s definitely a lot of both. But I have to say, my thinking has been so shaped by OCaml, it’s kind of ridiculous. I think the major thing that OCaml has done for me is it really makes me think about data first. Which is very different to a lot of other languages, where other times you’re maybe thinking about a model, you might be thinking about an object and things you can do to that object, but the thing that I love about OCaml (and this has definitely started making its way into Grain) is thinking about the data first.

That means you’re thinking about the types first. The very first thing you’re thinking about is, okay, how am I gonna model this data, that’s like the very first step, and then we start thinking about transforming that data and moving that data around, and doing things to it.

I think that’s a lot of how the Grain experience works out as well. There’s this particular goal that we want to achieve, it’s not “Hey, let’s just start writing code and hopefully we make it there.” No, it’s, like, “This is what we’re gonna achieve,” and it sort of builds itself out from there.

I remember way back in school we had this thing called the design recipe, which essentially was thinking about your data, thinking about your transforms, and even thinking about your tests up front. […] And that’s a lot of what we do today, it’s really thinking about that end case first of what is the real problem that we’re trying to solve, modeling it from there, and then the very last step is “Okay, now we’ll implement it.”

I definitely have been influenced a lot by this sort of idea.

Jonn: That’s really cool, and it’s great that these sorts of approaches also make their way into frontend as well with types these days.

Oscar: Absolutely.

Jonn: For refactoring, I think type systems have obvious benefits. To name one, as you change a thing in one place, and then the compiler tells you what you missed.

Oscar: Oh yeah, that’s the entire development process in the Grain compiler. It’s really funny, especially when I explain the Grain compiler code base to folks, I’m always telling them that it’s actually really simple, we’re literally just moving from IR to IR. So, essentially, you just go to the compilation step at the very end, and you make a code change and say, okay, I want this data to output this WebAssembly code. And then the compiler graciously guides you all the way back through every phase of the compiler, making sure you’re implementing, how to lex this, how to parse this, how to go to abstract normal form, how do we do all these different things.

It’s really cool and that is the development experience I want everyone to have: make one small change, and then don’t try and guess, let’s not have engineers walking around being like: “Oh, should I change this thing in that file?” No, let’s have a tool that can tell me how to do it. That’s huge.

And it’s funny because we have some of these features in Grain that people think are revolutionary. Like, with pattern matching, you forget a case and the compiler tells you “hey, you missed an edge case, and, by the way, here’s an example of the code that you missed.” People, who’ve never seen this before – it blows their mind – they’re like “whoa, that’s insane” and like “this is really how you avoid bugs”, and you’re like “yeah, it’s crazy, this has existed forever and it’s just not in the mainstream languages, but yeah, it’s here and you can avoid all sorts of classes of bugs.”

That’s one of my favorite things about languages like OCaml – the fact that you write some code, and if it compiles, it’s correct. It may not do what you wanted it to do, but it’s definitely correct and is what you wrote. And that’s amazing to me and I think that’s kind of lovely, right, as you’re following all these compiler errors, usually, by the time you actually get the program to actually compile, it usually works “on the first try”. It’s not really your first try because you ran the compiler command like 12 times to get to this point, but by the time you get to that point, you’re usually done, and you can breathe a sigh of relief and say “ah I implemented this feature”, and submit your PR.

And because you had to use these beautiful types and think about things, the PR comments are so lovely. It’s more just ideas of, like “oh, we could express this type this way” or “we can think about this this other way”, it’s none of the low-level – how I hated those discussions in JavaScript, just like: “Oh well, actually, with this function you got this edge case where when it’s null instead of zero… “. I hate those sorts of things, and so removing that entire class of discussions is just fantastic.

Jonn: Do you have any problem convincing people that that’s good? The argument I hear particularly a lot is that untyped languages or uni-typed languages are like languages for rapid prototyping, and you can’t move as fast with the ML-like languages or Rust, or something like that. Do you have this sort of pushback, and if yes, then how do you kind of respond to it?

Oscar: I think a lot and I preach this you know to the team all the time: the biggest thing with Grain is really how we tell our story. It’s all about how we talk about the language. Which is why you don’t see me going around talking about how you do this really complex functional thing in Grain, you never hear me say those sorts of things. It’s all about “here’s how I can develop faster”, “here’s how I can build better programs”. And I think when you come with that mindset, a lot of people are a lot more open to it.

Because when you tell folks that they have to write your programs a certain way, they’re immediately going to get really defensive and say “oh, but I don’t want to do it like that”. Versus, for example, on the types issue – I think this is an amazing one – in Grain, all types are inferred. So I can tell someone – especially people like JavaScript or TypeScript developers, who are like “oh, I really love TypeScript, but I got to write all these types” – well, actually, imagine that the compiler just knew exactly what you were thinking when you wrote the code.

Like, when you wrote that plus sign on that variable, the compiler knew that that thing is a number, which means this argument is a number, which means, in all these functions where you use this, this thing is a number, and the compiler is gonna make sure you’re being consistent about it.

And then someone might hit you with: “Oh, but the types aren’t in the code, I can’t see the types, so how do I know what types these things are?” But these days, having amazing editor support is huge. And with that, not only do we have like in VSCode, you’ve got your code lenses where every single statement is telling you: “hey, this is the type of this thing”, you can hover over literally any value, and it’s going to tell you what it is.

You alleviate a lot of these concerns and you tell people, hey, you can write this exact same code, you don’t even have to think about the types, you can just write the code like you might in Python. You just write the code, you don’t think about it, you run it, and you’re done. The difference is the compiler will let you know, in our case, that, hey, you did something a little bit wrong, and just make sure you clarify this or fix this thing, so that way it’s obvious not only to other people reading the code, but also to you and the compiler.

And then it’s actually pretty easy to get people on board with this. When you tell them that it’s just super magical and it’s gonna make sure you never make a mistake, they’re really excited by that. When you tell them that you can eliminate null pointer exceptions from your code entirely, it’s something you never need to worry about, they get excited by that.

So I think it’s all about how we talk about these things and how we get people thinking about them. Because, yeah, then you’re gonna get less pushback. And I think a lot of people, as they’ve come to Grain, they’ve sort of seen that, like, “Oh, yeah, this is fine”, like, “I can write this code, I feel really comfortable, I can use this library, it’s not a huge deal”. And then, of course, the language slowly, sneakily starts adding more functional concepts on you, but that’s okay, you’re with open arms, you’re accepting how good it feels to write your programs and how confident you feel about your programs, and that they’re doing the right thing.

It’s really cool and that is the development experience I want everyone to have: make one small change, and then don’t try and guess, let’s not have engineers walking around being like: “Oh, should I change this thing in that file?” No, let’s have a tool that can tell me how to do it. That’s huge.

Questions from the audience

Jonn: All right, we have a spicy one. What do you think is the best entry point right now for functional programmers to start working with WASM? Should I just learn Rust?

Oscar: What a spicy one. Okay, so there’s a couple of different ways you can look at this. Rust has enough functional features, I think, for your average functional person to be pretty happy. You got the strong borrow checker, it’s going to be telling you how to live your life, you’ve got pattern matching, all sorts of things, so you totally can learn Rust if you are just trying to do some functional programming.

I think it really depends on the level at which you want to write the code. If you want to write super-duper low-level code, yeah, go ahead and pick up Rust, but if you’re looking for something a bit easier, a bit friendlier, yeah, I think it’s going to be pick up Grain.

In terms of functional programming languages, right now those are going to be your really good options. However, there is a Haskell WebAssembly compiler called Asterius, and so if you specifically are a Haskell person and you want Haskell, you can check out that project as well, and you’ll probably be pretty happy because it’s exactly Haskell.

But yeah, I’m not going to tell people to not write Rust. Rust is an amazing language, it’s a fantastic freaking language, and even at work, when I get to write it, I’m pretty excited. But at the end of the day, it is pretty low level. Grain is like that just higher-level Rust friend. I thought someone on Twitter described Grain as being a child of JavaScript and Rust. I kind of agree with that, and I think that’s how a lot of people can think about it too in terms of, you know, getting into something functional, having enough of the features that you want.

Some people just get a result type and they’re happy, that’s all they care about, but, like, there’s different levels to it.

Jonn: I think we have one last question. “Oscar said that WebAssembly is used like 80 percent serverside. It’s kind of surprising. Could we get a brief elevator pitch for server side WebAssembly?”

Oscar: [laughs] Oh, you shouldn’t have asked me that. Yeah, so there’s so much you can do with WebAssembly on the server. So I think that thing we were talking about earlier, about WebAssembly being that write-once-run-anywhere language. Not to completely upset the JVM, but that’s sort of, in a way, what it’s doing right now.

There is a WebAssembly runtime called WAMR – the WebAssembly Micro Runtime – that thing runs on literally anything. If you want to run WebAssembly on a Nintendo DS, you totally can, it’s like that level. And so you can actually get your WebAssembly code into all these places.

So, with WebAssembly’s sandboxing capabilities and other things like that, all of a sudden a use case that we couldn’t really have before suddenly became known. You can run arbitrary code from people you don’t know safely, and that is kind of insane. That opens up a ton of opportunities.

So what we do at Suborbital is we extend your SaaS applications, whatever kind of application you have, with this ability for your users to write functions that do things in your app. And previously that’s something that maybe you had to run some custom Docker container solution for, which was still probably a little bit unsafe, but now we can actually completely lock down that sandbox and say: “No, you are allowed to do this thing and this thing only, that’s it.”

Being able to do that is actually kind of huge. There’s a lot of use cases like this, and then even going into replacing Docker containers of: “Hey, actually we don’t need these big hefty containers to do something. If I can have a WebAssembly module that does this one task, I can then go and link all these modules together and do all this work. I’m all set.”

And that’s how we end up having a lot of WebAssembly happen on the server. And even going to edge computing as well. It’s like hey, how do I actually push compute out to my users? Shipping massive binaries and containers and deploying them all around the world is really cumbersome, but when I have a WebAssembly module that’s 100k, it’s actually very easy for me to be like “Okay, actually have this one module on a server in India and run it.” That’s actually like something that’s much easier to consider. It’s actually very serious. And I think that’s what makes us really excited about the capabilities of WebAssembly.

Like, yeah, WebAssembly will be popular in the browser, don’t get me wrong, we are going to get there. I think the thing a lot of folks forget right now is that, fundamentally, JavaScript is kind of a good language. Even if it’s not what people want it to be, it has done extraordinary things and people have done extraordinary things with JavaScript. JavaScript’s really fast. Some people will write their program in Rust, be like: “I’m gonna write this thing in Rust and deploy in the browser.” And they find out that it’s not that much faster than the JavaScript version.

And it’s because JavaScript engines are crazy, they can JIT code faster than you can believe. It’s really, really impressive. So yeah, just outside the browser, running in tiny places, running on servers at the edge – there are loads and loads of applications that we’re seeing for WebAssembly. I still dream of the day that some Grain code is running on a light bulb somewhere. I imagine that, you know, we will definitely get there.

Big thanks to Oscar for being a guest on Functional Futures! 🙏

To hear more from him, you can follow him or the Grain language on Twitter. Additionally, you can check out Grain on GitHub or join their discord.

If you want to hear more from us, be sure to subscribe to the Functional Futures podcast on your favorite podcast platform. 😉

DEV Community: Serokell

Rust vs. Haskell

Basic concepts

Type system

Variables and mutability

Algebraic data types (ADTs)

Product types (structs)

Creating instances of types

Getting field values

Updating field values

Sum types (enums)

Partial field accessors

Pattern matching

Partial patterns

Failure handling

Option / Maybe and Result / Either

General failure philosophy

Polymorphism

Parametric polymorphism

Ad-hoc polymorphism

Advanced topics

Metaprogramming

Runtime and concurrency

Functions and functional programming

Lambdas and closures

Currying and partial application

Function composition

Iterators

Associated functions and methods

Things we worry about in Rust

Things we worry about in Haskell

Laziness

Purity

Higher-order programming

Conclusion

Get Started with Rust: Generics

Get Started with Rust: Generics

What are generics in Rust?

How do generics work?

Generic definitions

Generic functions

Generic enums

Generic structs

Generic methods

How to constrain a generic type

Recap on traits

Trait bounds on generic functions

Multiple trait bounds

Trait bounds on other generics

Conclusion

Machine Learning Trends for 2023

Machine learning technology trends

1. Foundation models

2. Multimodal machine learning

3. Transformers

4. Embedded machine learning

5. Low-code and no-code solutions

Top technological segments for ML in 2023

Conclusion

Get Started with Rust: Traits

Get Started with Rust: Traits

What is a trait?

Traits are everywhere

How to implement a trait?

How to implement a trait manually?

Deriving a trait

How to define a trait?

Implementing a trait for an enum

Default implementations

How to use traits in function parameters?

How to extend traits?

Traits have many uses

Conclusion

Get Started with Rust: Enums

Get Started with Rust: Enums

What is an enum in Rust?

Enums vs. structs

Pattern Matching

Enum methods and traits

Defining methods for enums

`Option` / `Maybe` and `Result` / `Either`

`Option` and `Result` enums

`Option` and `Result` methods

`unwrap`

`unwrap_or_else`

`?`

How a `safe_division_thrice` function looks with `match` vs. `?`

`and_then`

`Eq` and `PartialEq`

Implementing `Display`

How to generalize `map`

The `(<$)` operator

The definition of `(<$)`.

Which Haskell function or operator can produce a `c -> b` function from `a -> b` and `c -> a`?

Supporting `ScopedTypeVariables`