Chris Krycho - Rust

Appearance: Corecursive #34

Mon, 15 Jul 2019 16:45:00 -0400

I was delighted to spend a bit over an hour chatting with Adam Gordon Bell on the Corecursive podcast. I was there officially to talk about TypeScript, and I did a lot of that… but we also dug into Rust a bit, of course, as well as talking about my schedule and “productivity”.

I’ve been podcasting for a few years now, but this was only the second time I’ve ever been on someone else’s podcast—and it was a blast. Thanks so much to Adam for having me on!

JavaScript is C

Thu, 20 Dec 2018 18:45:00 -0500

Assumed Audience: software developers, especially those interested in modern, typed programming languages.

Earlier this week, I was working on a problem in the Ember app where I spend most of my day job, and realized: JavaScript is the same as C.

That probably doesn’t make any sense, so let’s back up. The scenario I was dealing with was one where there was a bit of invariant around a piece of data that I had to maintain for the application not to blow up in horrible ways, but had no good way to enforce with the language’s tools. This action on that piece of data was only valid if this condition held true… but even with the fully-type-checked TypeScript application we now have, the action (because of the entire application’s architecture and indeed the entire way that Ember apps are wired together!) could not be statically verified to be safe.

As I considered the best way to handle this—I ended up having the function involved in the action just throw an error if the invariant wasn’t properly maintained—I was reminded of the years I spent writing C. In C, it’s quite possible to write safe code around memory management. I managed it fine in the applications I worked on, by carefully documenting the invariants a given function required to be safe. This piece of data is allocated by that function and then released to the caller to manage. Even with every bit of static analysis I threw at those kinds of things, it was possible to get it wrong.

The exact same kinds of problems I had in C, I have in JavaScript or even TypeScript today. Experientially, JavaScript¹ is C, as far as having to deal with these kinds of invariants goes.²

Enter Rust: the kinds of management of memory that I was always having to keep track of in my head (or, better, with detailed documentation comments along the way—but with the same problem that it was easy to get wrong), I could now have statically guaranteed by a compiler. Given that I spent the first six years of my career managing and carefully tracking all of that by hand, it’s no wonder I fell in love with Rust. I could have the compiler guarantee the invariants I needed around memory management.

And it turns out, this same dynamic exists in the world of front-end web development. People sometimes wonder why (and colleagues are often bemused that) I get so excited by Elm. But the step from JavaScript (or even TypeScript) to Elm is just like the step from C to Rust. It’s a real and profound shift in what kinds of things you can know for certain about your program.

In a C application, try as hard as I may, at the end of the day I am always on my own, making sure the invariants I need for memory safety hold. In Rust, I can be 100% confident that I will not have memory-unsafe code. Not 98%-and-I’d-better-check-those-last-2%-really-closely. One hundred percent. That’s a game-changer.

In a JavaScript or TypeScript application, try as hard as I may, at the end of the day I am always on my own, making sure the invariants I need for state management hold. In Elm, I can be 100% confident that I will not have code which needs a given invariant about a piece of state to hold break the way it could in this TypeScript application. Because I can’t even apply the relevant transformations in question if it isn’t! That’s a game-changer.

Neither of those is a guarantee I won’t have bugs. (A compiler that could guarantee that would have to be sentient and far smarter than any human!) Neither of them means I can’t intentionally do stupid things that violate invariants in ways that get the program into broken states from the user’s point of view. But both of them give me the tools and the confidence that I can absolutely guarantee that certain, very important kinds of invariants hold. We’re not looking for an absence of all bugs or a system which can prevent us from making any kind of mistake. We’re looking to be able to spend our times on the things that matter, not on minutiae the computer can check for us.

So: I’m not going back to C, and I’m ready to move past JavaScript and TypeScript.

This goes for plenty of languages that aren’t JavaScript, too. It’s equally true of c^♯ or Python.↩
Obviously there are some kinds of things you don’t have to worry about in JS that you do in C: memory management, for one. The point is that the manual-verification-of-every-invariant-you-care-about is the same.↩

Review: The Rust Programming Language

Wed, 07 Nov 2018 07:00:00 -0500

I intended to publish this review months ago, but the single hardest month of my career punched me in the face repeatedly and I just found myself entirely unable to write for all of September and most of October. Here it is at last, with apologies to No Starch for the delay!

No Starch Press kindly provided me with a review copy of The Rust Programming Language, by Steve Klabnik and Carol Nichols, with contributions from the Rust community. A real-world, physical review copy. And it’s magnificent.

The Rust Programming Language

I’ve read the vast majority of this book (as well as the previous edition) online over the last couple years as Steve and Carol have worked on it; it has been an invaluable resource for many a New Rustacean episode. (Bonus: you can hear me talk with Carol about working on The Rust Programming Language in my interview with her back in 2016! And yes: writing the book took that long.) This is in some sense the authoritative book on Rust.

You might wonder why you’d pick up a physical copy of this book given that it is available online for free. There are a few reasons that come to mind:

The quality of the online book is in many ways a direct result of No Starch Press’ deep investment in the text. They’re not making any money from the online copy. They do recoup some of their costs when we buy ebook or physical copies. So that’s one good reason: a way of saying “thank you!” and investing in the continued existence of No Starch and projects like this.
I used the word magnificent above to describe this, and I mean it. This printing is a fabulous example of really excellent book design. I take typography and presentation seriously, and not a whit less for programming books than for copies of The Lord of the Rings. Everything in this printing is top-notch. Little details like the way that code listings are displayed—right down to the way some text is faded away to emphasize what’s new in a listing—make this one of the most readable programming texts I’ve ever seen.
As delightful and powerful as hypertext is, the physicality of a book is equally delightful and powerful, just in different ways. There is nothing quite like the tactile experience of flipping through a book. Nothing in digital text lets you forge connections to learning the way that scribbling notes in a margin does. And the sheer physicality of a volume this large gives you mental hooks to hang what you’re learning on: you can remember that it felt like this to have the book open to where you learned it.

(That last point is an argument in favor of printed books in general. You can expect me to come back to that theme time and again in this space, even while I continue to value digital spaces like this one for what they uniquely do.)

No Starch sent me this copy to review with no expectation of a positive review—but even if they’d been paying me, they couldn’t make me say that this book is great. But great it is. If you have any interest in Rust, you should grab a copy!

Scales of Feedback Time in Software Development

Mon, 22 Oct 2018 21:15:00 -0400

Assumed Audience: fans of compiled languages with expressive type systems. I’m not trying to persuade fans of dynamic languages they should use a compiler here; I’m trying to surface something that often goes unstated in discussions among fans of compiled languages with expressive type systems, but hopefully it’s interesting beyond that. If you don’t like compiled languages, just skip the build step bits; the rest all still applies.

There are basically six stages of the development of any given software component where you can receive feedback on what you build:¹

compilers, static analysis tools, and/or pair programming
automated test suites
manual local testing
continuous integration (CI) test results
deploying to staging (or a similar test environment) for manual testing
deploying to live, i.e. when production traffic is meaningfully different from what you can test on staging

What’s interesting to note is that there are also, in my experience, roughly order-of-magnitude differences between each of those layers in terms of the cycle time between when you make a change and whether you know it is broken. That is, there seem to be rough factor-of-ten differences between the feedback you get from—

compilers, static analysis tools, and/or pair programming—all of which can show you feedback in near-real-time as you’re typing and saving your code, especially with a good language server or a fast compiler or a speedy linter
automated test suites, assuming they’re running on every build change and are reasonably speedy themselves, or scoped to the things impacted by the changes made
manual local testing, which you can repeat after every build, but which usually requires you to switch contexts to execute the program in some way
CI, presumably doing the automated equivalent of what you do in both layers 2 and 3, but requiring a push to some central location and a remote build and execution of the test suite, and often a much larger integration test suite than you’d run locally
deploying to staging, and repeating the same kinds of manual testing you might do locally in layer 2 in a more production-like environment
deploying to live, and repeating the same kinds of manual testing you might do locally in layers 2 or 5, as well as getting feedback from observability or monitoring systems using your real traffic

(Those last two might be comparable in the cycle time sense. However, the way most teams I’ve heard of work, any deploy to live is usually preceded by a deploy to staging. What’s more, with most changes that you can’t test until it’s live, it’s often the case that you’re not going to know if something is wrong until it has been live for at least a little while. Finally, some kinds of things you can really only test with production load and monitoring or observability systems, and those kinds of things are at least sometimes not to be visible immediately after deployment, but only in the system’s aggregate behavior or weird outliers that show up given enough scale.)

What all of this gets at is that stepping to a higher layer nearly always entails a dramatic increase in the cycle time for software development: that is, the amount of time between when I make a change and when I know whether it’s broken or not. If I can know that I have a problem because my compiler surfaces errors in my editor, that probably saves me a minute or two each day over only being able to see the same error in a test suite. By the same token, being able to surface an error in a test suite running on every build will likely save me anything from minutes to hours of cycle time compared to something I can only test in production.

At first blush, this looks like an argument for pushing everything to the lowest-numbered layer possible, and I think that’s kind of right. I (and probably many other people who end up in, say, Rust or Haskell or Elm or other languages with similarly rich type systems) tend to prefer putting as much as possible into layer 1 here precisely because we have so often been bitten by things that are at layer 2 in other languages or frameworks and take a lot of time to figure out why they broke at layer 2. This happened to me in a C^♯ server application just a couple weeks ago, and chasing it down was not fun.

However, my enthusiasm for rich type systems notwithstanding, I don’t think this observation about these layers of cycle time means we should put everything in the compiler all the time. Indeed, there are some things it is too expensive or difficult to test anywhere but production (all the way up at layer 6). What’s more–although this is often overlooked in these discussions–putting too much of this rich information in layer 1 can absolutely kill your compile times in many languages. In my experience, this is particularly true of many of the languages with rich enough type systems to make layer 1 handling genuinely viable in the first place!²

I do think, though, that being aware of the cost in cycle time is useful, as is being explicit about why we think it’s worth slotting a particular set of feedback into layer 2 vs. layer 1 (or layers 3, 4, 5, or 6). That goes for library development, of course.³ It goes equally for application development, though! It can be really helpful to make explicit both which of these layers you’re landing in and (just as important) why you’ve landed there for any given bit of feedback you want or need to get–making the tradeoffs explicit along the way.

Thanks to my friend Ben Makuh for looking over an earlier draft of this piece and providing really helpful feedback on it! Thanks as well to Greg Vaughn for noting shortly after I published it that pair programming also sits at the “immediate feedback” layer.

There’s some ongoing work in the Rust web working group to build an exemplar web framework, Tide. The most recent post tackled routing, and prompted an interesting discussion on the Rust internals forum. This post is a cleaned-up, better-articulated, more general version of a post I offered in that thread.↩
Right now I and a few others are trying to figure out why one particular type definition in the TypeScript definitions for Ember.js causes a build to take about 20× as long as the build without that type definition. It’s the difference between a 6.5-second build and a 2.5-minute build.↩
as in the example of a web server’s API for route handling which originally prompted this post↩

Rust is Incredibly Productive for CLIs

Sun, 20 May 2018 08:35:00 -0400

There are reasons I’m a Rust fanboy. One of them is the kind of thing I proved out to myself today—again, because I’ve had this experience before, albeit not with anything quite this “complicated.”

I built a little tool in Rust to convert Evernote exports (in their custom .enex XML format) to Markdown files with YAML metadata headers—mostly just to see how quickly and effectively I could do it, because I’ve never actually had an excuse to use Serde and I thought this might be a nice spot to try it.

There’s a lot this little library doesn’t do. (Like include the creation and modification timestamps in the header, for example.) But all of those things would be very straightforward to do. I built this functioning little “script” in about two hours. For context: I’ve taken multiple passes at this in Python—which in the way people normally think about these things should be way easier—and I’ve failed both times.

Rust’s compiler just helps you out so much along the way, not only with the type-checking but with the really amazing metaprogramming capabilities you get with it. Being able to slap #[derive(Deserialize)] on a struct and a couple attributes on struct fields and having it Just Work™ to deserialize XML into local types is mind-blowing. (The only thing I know of that’s playing the same game is F^♯ type-providers. I’d love to hear about similar capabilities in other languages!)

I’m basically at the point where if I need a small command-line tool, I write it in Rust, not in a conventional scripting language like Python, because the benefits I get more than outweigh whatever small extra amount of mental overhead there is. And there’s not much of that mental overhead anyway for this kind of thing! As you can see in the actual code, I make free and liberal use of expect for this kind of tool.

It’s also hard to oversell the ecosystem—even as relatively nascent as it is compared to some much older languages, the tools which exist are just really good. This project uses Serde for deserializing from XML and serializing to YAML; Regex; Clap for command line parsing; a nice little wrapper around pandoc; and, superpower even among superpowers, Rayon: free parallelization.

Rust is, in short, very productive for things in this space. Far more than you might expect from the billing. Yes, it’s a “systems programming language” and you can write operating systems with it. But it’s also just a really great tool for all sorts of domains, including little CLI tools like this one.

Aesthetics and Programming Languages

Sun, 13 May 2018 11:00:00 -0400

My distaste for the aesthetics of C^♯ are fairly well known to people I talk to about programming languages—perhaps equally as well known as my love of Rust. So much so that both are running jokes among some of my colleagues and friends. My hypersensitivity to aesthetics both in general and also specifically in programming languages and work environment is also so well-known as to be a gag.

But I was writing a bunch of Rust this weekend, and looking at it and thinking about it and wondering why it is that C^♯ drives me so up the wall aesthetically and experientially, while Rust doesn’t. On the surface, they don’t actually look all that different.

Here’s roughly equivalent code in each:

public class Person {
    public string Name { get; set; } = "Chris";

    public void greet() {
        Console.WriteLine($"Hello, {Name}");
    }
}

struct Person {
    name: String,
}

impl Person {
    pub fn new() -> Person {
        Person { name: String::from("Chris") }
    }

    pub fn greet(&self) {
        println!("Hello, {}", self.name);
    }
}

When you start tossing in generics and lifetimes, Rust can actually end up looking a lot messier than C^♯.

impl<'a, 'b, T, U> SomeTrait<'a, U> for SomeType<'b, U>
where
    T: SomeOtherTrait + YetAnotherTrait,
    U: OhWowSoManyTraits
{
    fn some_trait_method(&self) {
        // ...
    }
}

Nothing about that is what I would call aesthetically beautiful in a general sense! There’s a lot of syntax.

What I’ve concluded so far, though, is that my difference in feelings comes down to the way that syntax maps back to the underlying semantics, and my feelings about those underlying semantics. The basic language design approach C^♯ takes—i.e. everything is a class; mutation is both encouraged and implicit; don’t bother with value types—drives me batty. I don’t love the syntax, not least because it ends up being so verbose and noisy (you can express the same things in F^♯ much more briefly)—but also because I actively dislike the programming models it encourages (I don’t like the C^♯ programming model when I see in in F^♯ either!).

Rust, by contrast, matches the way I do and want to think about the world. Mutability is allowed but neither actively encouraged nor actively discouraged; more to the point it’s explicit. Insofar as “shared mutable state is the root of all evil,” Rust has two legs up on C^♯: it (a) doesn’t allow shared mutable state and (b) makes explicit where mutation is happening. It also separates data from behavior. It also has real value types. It also has sum types and pattern matching. In both cases, a lot of the syntactical noise is inessential, a holdover from the legacy of C; but in Rust’s case the way it maps onto a programming model that is more like OCaml than like C decreases the pain I feel from that noise.

This could be taken to validate the idea that syntax doesn’t matter, that the underlying semantics are everything, but that’s not the case. It’s not that I love Rust’s syntax. It’s that, although I dislike it at times, it doesn’t rise to the level of frustration I feel in C^♯ because it’s not coupled to a programming model that I loathe. The syntax matters; it’s just not the only thing that matters.

An interesting thing to consider: what Rust would look like in a world where it embraced its OCaml roots. (I don’t think Rust should have done this; spending its complexity budget on ideas instead of syntax was the right choice. But it’s still interesting.) The simplest level of translation might look something (very) roughly like this:

impl 'a 'b T U SomeTrait 'a T for SomeType 'b U
  where T : SomeOtherTrait + YetAnotherTrait

  some_trait_method :: &self -> void
  some_trait_method self =
    -- ...

This is obviously still a lot of syntax, but it’s all basically necessary given the things Rust is trying to express with lifetimes, ownership, etc.—and I did this off the top of my head with literally no consideration other than “what’s the most direct translation into roughly Haskell-ish syntax I can write?” It makes me genuinely curious where a language that aimed for Rust’s same kinds of guarantees but actively embracing the ML/Haskell family’s syntax might end up. I have a guess that I’d like it even better than I do Rust.

Exploring 4 Languages: Integrity and Consistency

Sat, 24 Mar 2018 22:00:00 -0400

In chapter 6, Wlaschin turns to one of the most important aspects of “domain modeling”: keeping it consistent. It’s all well and good to set up a domain model, but if you don’t have a way to make sure that model is reliable everywhere you use it, well… you’ve done a lot of extra work and you’re not going to see a lot of results for all that effort! But as Wlaschin points out, we can actually use the type systems, and the types we wrote up in the previous chapter, to help us enforce the business rules for our domain (as well as the business shapes in the domain).

An important note: you can see the latest version of this code (along with history indicating some of my travails in getting there!) in this public repository on GitHub.

A simple example: `WidgetCode`

We’ll start with one of the simpler examples: validating that a WidgetCode is legitimate. A WidgetCode, in this domain, is valid if, and only if, it has a W followed by four digits.

The basic tack we’ll take, in all four languages, is to leverage the way the types work to make it so we have to use a function to create a valid instance of a WidgetCode. That’s a bit of extra work (though especially in the functional-first languages, it ends up not being a lot of extra work) but it lets us use Result types to handle invalid data up front.

The downside is that we can’t just get directly at the value inside our wrapper types using basic pattern matching. Instead, we need to be provide a function for “unwrapping” it. Tradeoffs!

We’ll go at this using the most appropriate tool from each language, but in every case we’ll end up with a create function that takes a string and returns a Result with the successful option being a WidgetCode and the error option being a string describing the error; and a value function to unwrap a valid code. Throughout, I also assume an essentially-identical implementation of a related GizmoCode type; I pull both in to show how they end up being used side by side.

Rust

We are using a tuple struct to wrap the string value here. Since there is no pub modifier in the wrapped String, it’s opaque from the perspective of the caller—and this is exactly what we want. We’ll pull in the Regex crate and validate the code passed to us on creation.

use regex::Regex;

pub struct WidgetCode(String);

impl WidgetCode {
    pub fn create(code: &str) -> Result<WidgetCode, String> {
        let re = Regex::new(r"W\d{4}").expect(r"W\d{4} is a valid regex");
        if re.is_match(code) {
            Ok(WidgetCode(String::from(code)))
        } else {
            Err(String::from(
                "`WidgetCode` must begin with a 'W' and be followed by 4 digits",
            ))
        }
    }

    pub fn value(&self) -> &str {
        &self.0
    }
}

This is fairly idiomatic Rust: we’re borrowing a reference to the code as a “string slice”, and creating a new, wrapped String instance to wrap up the code or return a new String as an error. When we get the value out, we return a reference to the string,¹ with &self.0: & to indicate a reference, .0 to indicate the first item of a tuple. Note as well that the final if block here is an expression. There’s no semicolon terminating it, and this whole if block ends up being the resulting value of the function.

One other point of interest here is that the creation of the regex itself is checked by the compiler for us! If we pass an invalid regular expression, this simply won’t compile.

This could also live in its own module, ordering/widget_code.rs, and in fact that’s how I would normally do this (and have in the repository where I’m working): every one of these small types would get its own module file within the containing Ordering module. It’s not necessary, but as the domain model grows, it becomes increasingly convenient in that you always know where to find things.²

Then we can import it and use it like this in ordering/mod.rs:

mod widget_code;
mod gizmo_code;

use widget_code::WidgetCode;
use gizmo_code::GizmoCode;

pub enum ProductCode {
    Widget(WidgetCode),
    Gizmo(GizmoCode),
}

fn demo_it() {
    let valid = WidgetCode::create("W1234");
    let invalid = WidgetCode::create("wat");

    let unwrapped = match valid {
        Ok(ref code) => code.value(),
        Err(_) => "",
    };
}

Notice that in Rust, the mod.rs file declares all child modules. If you had a widget_code.rs on the file system but no mod widget_code;, Rust would just ignore the declaration entirely. Then Rust also requires us to use widget_code; to access its contents. The distinction between declaring and using a given module makes some sense: by the time all is said and done with this exercise, we won’t be doing much of anything in this Ordering module; it’ll exist primarily as a grouping construct for all the other modules.

In this case, we go ahead and import the WidgetCode type from the module. We only have the one type there, with no standalone functions: everything is attached to the type via the impl block; so we can just call everything directly off of the type. This ends up feeling kind of like the way we’d do things in a traditional OOP language, but also really not, because we still have a separation between the data type and the implementation of functionality attached to it. It’s not obvious here, but we could write impl WidgetCode in some other module in the crate, and as long as there’s no conflict between the implementations, it’s fine! And then we could call whatever function we defined in that block “on” WidgetCode. This is on the one hand totally unlike what we’ll see in the other languages, and on the other hand weirdly analogous to them.

I’m going to pass over why we need ref code here, as it gets into details of Rust’s model of ownership and reference borrowing and it’s going to be unneeded because of improvements to Rust’s compiler fairly soon. The one thing to note here is that we get nice memory/allocation behavior, i.e. we’re not doing a bunch of separate heap string allocations here. This is one of the big upsides to Rust in general! It’s not quite as pretty as what we’ll see below, but the performance wins are awesome.

Elm

Elm introduces us to a pattern we’ll see in each of the more traditional “functional” languages: the use of modules for this kind of structure. First the code, then some comments on it:

-- src/ordering/WidgetCode.elm
module Ordering.WidgetCode exposing (WidgetCode, create, value)

import Regex exposing (contains, regex)


type WidgetCode
    = WidgetCode String


create : String -> Result String WidgetCode
create code =
    if contains (regex "W\\d{4}") code then
        Ok (WidgetCode code)
    else
        Err "`WidgetCode` must begin with a 'W' and be followed by 4 digits"


value : WidgetCode -> String
value (WidgetCode code) =
    code

Elm’s module system lets you choose exactly what to expose. In this case, we’re only exporting the type itself along the create and value functions—but, importantly, not the normal type constructors for the type.

You can import the things exposed both as a module and as individual items. Assume we implemented GizmoCode the same way. We’d import and use them in Ordering.elm like this:

-- Ordering.elm
import Ordering.WidgetCode as WidgetCode exposing (WidgetCode)
import Ordering.GizmoCode as GizmoCode exposing (GizmoCode)

type ProductCode
    = Widget WidgetCode
    | Gizmo GizmoCode
    
valid =
    WidgetCode.create "W1234"


invalid =
    WidgetCode.create "wat"


unwrapped =
    case valid of
        Result.Ok code ->
            WidgetCode.value (code)

        Result.Err _ ->
            ""

As with Rust, we can’t construct the type without using the provided function. As I’ve written the imports, you’d create a WidgetCode by writing WidgetCode.create "W1234". You could also import it directly, but that would have its own problems once you had the create function imported for GizmoCode as well.

Finally, notice the way we aliased the module name here with as on the import: we don’t have to write out the fully qualified path this way. And there’s no conflict between the aliased module name and the type name – they live in their own namespaces (as it should be!). Importing the type name distinctly is handy because it means we don’t have to write the body of the union type out as Widget WidgetCode.WidgetCode.

F^♯

The F^♯ code looks a lot like the Elm code. The main differences here have to do with their module systems.

namespace Ordering

type WidgetCode = private WidgetCode of string
module WidgetCode =
    let create code =
        if Regex.IsMatch(code, @"W\d{4}") then
            Ok (WidgetCode code)
        else
            Error "`WidgetCode` must begin with a 'W' and be followed by 4 digits"

    let value (WidgetCode code) = code

Here we declare that we’re in the namespace Ordering. Everything here will be publicly visible to everything else in the namespace Ordering. We could also make this a module, and in that case we’d need to explicitly open it in other modules. Because it’s part of the base namespace we’re using for Ordering, though, we get it for “free”. There’s a downside to this, though. More on that below.

Also notice that this means that we have yet one more “namespace” for names to live in: namespace names are different from module are different from type names! So here we declare a top-level module Ordering here so that we can actually write code that does something in the file – namespaces can only contain type definitions (including module definitions).

namespace Ordering

type ProductCode =
    | Widget of WidgetCode
    | Gizmo of GizmoCode

module DemoIt =
    let valid = WidgetCode.create "W1234"
    let invalid = WidgetCode.create "wat"
    
    let unwrapped =
        match valid with
        | Ok(code) -> WidgetCode.value code
        | Error(_) -> ""

The things to notice here as particularly different from the others:

We don’t have to explicitly import the module names, because we used the same namespace (Ordering) to group them. We could also have done namespace Ordering.WidgetCode and open Ordering.WidgetCode; that might actually make more or less sense in the context. I think this is probably more idiomatic, however, which is why I picked it.
Since we’re keeping the rest of the containing module in the same namespace, we do have to declare module DemoIt for functionality – not just types – to live in. This is true for both Ordering.fs and WidgetCode.fs and so on.

This way of structuring things works really well, but it has one major downside compared to Elm and Rust: where any given name comes from is not obvious from any given text file. Using modules instead of namespaces and using more fully qualified names could help here, but the reality is simply that F^♯ (like C^♯) basically leaves you out to dry here. My take is that this is basically what happens when you design a language assuming IDE-like tooling. But especially when looking at e.g. GitHub diff views, or just browsing source code in general, I strongly prefer the way Elm and Rust generally lead you to do explicit imports or fully qualified paths. (Both have an escape hatch: Rust’s use path::to::module::*; and Elm’s import Path.To.Module exposing (..), but both are actively discouraged as bad practice in most situations.)

Reason

Interestingly, Reason looks most like Rust but behaves most like F^♯. The biggest difference is that I need a separate interface file for Reason to get the privacy benefits that I’m getting in all the other languages.

We put the definition file at ordering/Ordering_WidgetCode.rei. (I’ll comment on the long name in a moment.)

type gizmoCode = pri | GizmoCode(string);

let create: string => Js.Result.t(widgetCode, string);

let value: widgetCode => string;

With that module definition in place, we can separately supply the implementation, in ordering/Ordering_WidgetCode.re.

type widgetCode =
  | WidgetCode(string);

let create = code => {
  let isMatch =
    Js.Re.fromString("W\\d{4}") |> Js.Re.exec(code) |> Js.Option.isSome;
  if (isMatch) {
    Js.Result.Ok(WidgetCode(code));
  } else {
    Js.Result.Error(
      "`WidgetCode` must begin with a 'W' and be followed by 4 digits"
    );
  };
};

let value = (WidgetCode(code)) => code;

Note that you could do the same thing with an interface file for F^♯. We’re also doing something that’s similar in principle to the use of private types in in F^♯, but unlike in F^♯ we have to use the module interface to make it work as far as I can tell. The interface can declare the type private, but in the actual implementation, the type has to be non-private to be constructable. (If I’m wrong, please send me a note to let me know! But that’s what I gathered from reading OCaml docs, as well as from command line error messages as I played around.) Also, the fact that Reason has landed on the keyword pri instead of OCaml and F^♯’s much saner private is super weird.

The interface file just defines the types, and has the .rei extension. type widgetCode here is an abstract type, which provides no information about what it contains. Note the function types are provided as well. Here I’m using specifically the Js.Result type; there is also a Result type in at least one of the OCaml standard libraries. This is one of the more complicated things about Reason compared to the others: there are… several standard libraries to choose from, which will or won’t work differently depending on what compile target you’re picking.

In any case, once we have both the module and the implementation defined, we can use it like this in ordering.re:

module WidgetCode = Ordering_WidgetCode;

module GizmoCode = Ordering_GizmoCode;

open WidgetCode;

open GizmoCode;

type productCode =
  | Widget(widgetCode)
  | Gizmo(gizmoCode);

let valid = WidgetCode.create("W1234");

let invalid = WidgetCode.create("wat");

let unwrapped =
  switch valid {
  | Js.Result.Ok(code) => WidgetCode.value(code)
  | Js.Result.Error(_) => ""
  };

We do this mapping from Ordering_WidgetCode to WidgetCode here because OCaml and therefore Reason has only a single global namespace for its module names as defined by the file system. You can nest modules, but only within files. The workaround is, well… Ordering_ and remapping the name as we have here. This lets you access the nested modules as Ordering.WidgetCode and so on elsewhere.

Then we open WidgetCode etc. so that we can write widgetCode instead of WidgetCode.widgetCode in the productCode definition. This is basically the same effect we get from just being in the same namespace in F^♯ (which, again, we could rewrite exactly this way), or from the kinds of imports we discussed above for Rust and Elm.

Numeric validation: `UnitQuantity`

So far, the showing tilts heavily in F^♯’s and Elm’s favor in terms of expressiveness and elegance. However, there’s a lot of variation depending on exactly what you’re doing. If, for example, you want to validate a range, well… then Rust actually has a pretty good approach! Once again, you’ll note that these all have a lot in common; the difference mostly comes down to the degree of syntactical noise required to express the same basic thing.

In this section, I’m not really going to spend a lot of time discussing the details and differences; I’m just leaving it here to show an interesting example where the languages’ design decisions end up have slightly different ergonomic tradeoffs.

Rust

// ordering/unit_quantity.rs
pub struct UnitQuantity(u32);

impl UnitQuantity {
    pub fn create(qty: u32) -> Result<UnitQuantity, String> {
        match qty {
            0 => Err(String::from("`UnitQuantity` cannot be less than 1")),
            1...1000 => Ok(UnitQuantity(qty)),
            _ => Err(String::from("`UnitQuantity` cannot be greater than 1000")),
        }
    }

    pub fn value(&self) -> u32 {
        self.0
    }

    pub fn minimum() -> UnitQuantity {
        UnitQuantity(1)
    }
}

Elm

-- ordering/UnitQuantity.elm
module Ordering.UnitQuantity exposing (UnitQuantity, create, value)


type UnitQuantity
    = UnitQuantity Int


create : Int -> Result String UnitQuantity
create qty =
    if qty < 1 then
        Err "`UnitQuantity` cannot be less than 1"
    else if qty > 1000 then
        Err "`UnitQuantity` cannot be greater than 1000"
    else
        Ok (UnitQuantity qty)


value : UnitQuantity -> Int
value (UnitQuantity qty) =
    qty

    
minimum : UnitQuantity
minimum = UnitQuantity 1

F^♯

// ordering/UnitQuantity.fs
namespace Ordering

type UnitQuantity = private UnitQuantity of uint32
module UnitQuantity =
    let create qty =
        if qty < 1u then
            Error "`UnitQuantity` cannot be less than 1"
        else if qty > 1000u then
            Error "`UnitQuantity` cannot be greater than 1000"
        else
            Ok (UnitQuantity qty)

    let value (UnitQuantity qty) = qty
    
    let minimum = UnitQuantity 1

Reason

/* ordering/Ordering_UnitQuantity.rei */
type unitQuantity = pri | UnitQuantity(int);

let create: int => Js.Result.t(unitQuantity, string);

let value: unitQuantity => int;

let minimum: unitQuantity;

/* ordering/Ordering_UnitQuantity.re */

type unitQuantity =
  | UnitQuantity(int);

let create = qty =>
  if (qty < 1) {
    Js.Result.Error("`UnitQuantity` cannot be less than 1");
  } else if (qty > 1000) {
    Js.Result.Error("`UnitQuantity` cannot be greater than 1000");
  } else {
    Js.Result.Ok(UnitQuantity(qty));
  };

let value = (UnitQuantity(qty)) => qty;

let minimum = UnitQuantity(1);

Aside: On Documentation

One thing that became extremely clear in the course of working all of this out is that the documentation stories for these languages are in vastly, vastly different places.

Figuring out how to write this private create/value approach was very straightforward in Rust, because it’s literally just right there in how impl blocks and the pub keyword work: things default to private, including the contents of a struct, and you always define the related functionality with pub fn declarations in the related impl block.

Elm and F^♯ were both slightly harder, in that I had to poke around a bit to figure out the right way to do it. But not that much harder. Both use module-level isolation to accomplish this; the main difference there was that F^♯ just lets you do it inline and Elm explicitly ties modules to files.

Reason… was very, very difficult to get sorted out. This is just a function of the state of the ecosystem. Reason is distinct syntax for OCaml, but it also leans on BuckleScript. That means that if you want to figure out how to do anything, you probably need to search in the docs for all of those, and if your answer turns out to come from OCaml then you have to figure out how to translate it back into Reason and BuckleScript! Ultimately, I was able to figure it out and get the project layout to how you see it in the repository, but… it took a lot more digging than with any of the other projects!

Summary

As with our previous foray, we can see a ton of similarities across these languages. All lean heavily on pattern-matching for dealing with different scenarios; all let us make use of a Result type for handling success or failure; all make heavy use of expression-bodied-ness; and all supply some way to make types constructable only in safe/controlled ways.

For Rust, that’s a matter of leaving the internals of a struct private and making pub fn helpers to do the construction and value retrieval. For Elm, F^♯, and Reason, that’s a matter of having the normal type constructors be private while exposing the types themselves normally. They do that in different ways (F^♯’s private type, Elm’s exposing, and Reason’s pri annotation on the type variant in a module interface file), but the effect is essentially identical, and functionally equivalent to what we see in Rust.

The main differences we see across Elm, F^♯, and Reason have to do with the nature of the various module systems. In a lot of ways, Reason’s is the least capable for this specific purpose, because it’s directly tied to OCaml’s module system, which substantially predates any of the others. (I say “in a lot of ways” because OCaml’s modules are surprisingly capable; they end up being their own kind of types and you can do some crazy things with them, all of which I’d like to actually come to understand… eventually.) Rust’s module system, meanwhile, has a lot of similarities to Elm’s in particular, but because we actually carry functions along with the types they impl (though they get defined separately, with all the power that entails), we have a bit less boilerplate we need to write just to get at the specific functions in play.

Next time (probably only a couple of weeks away because we’re working through the book at work in a book club!), I’ll be looking at Chapter 7: Modeling Workflows as Pipelines. I suspect this will be a place where the true functional orientation of Elm, F^♯, and Reason will much more sharply differentiate them from the sometimes-functionalish-but-not-actually-functional way we write things in Rust.

This reference will live and be valid as long as the underlying WidgetCode is. We could also return a String if we wanted that value to live independently of the WidgetCode instance backing it.↩
Putting it in its own module, whether in a separate does have implications for privacy, though we don’t much care about them in this case. Rust lets us set the privacy on a whole spectrum, from “visible everywhere” to “only visible in this specific module.”↩

Exploring 4 Languages: Starting to Model the Domain

Sun, 14 Jan 2018 09:00:00 -0500

In the first three chapters of Domain Modeling Made Functional, Wlaschin walks through the creation of a “domain model” for an order-taking system. (It’s well worth reading the book just for a bunch of the lessons in that section—I found them quite helpful!) Then, after spending a chapter introducing F^♯’s type system, he introduces the ways you can use those type mechanics to express the domain. In today’s post, I’ll show the idiomatic implementations of these types in each of Rust, Elm, F^♯, and ReasonML.

Simple values

Simple wrapper types let you take simple types like strings, numbers, etc. and use types to represent part of the business domain you’re dealing with—the basic idea being that a Customer ID may be a number, but it’s not interchangeable with other numbers such as Order IDs.

Here’s the most ergonomic and effective (and automatically-formatted in line with the language standards, where applicable!) way to do that in each of the languages:

Rust:

struct CustomerId(i32);

Elm:

type CustomerId
    = CustomerId Int

F^♯:

type CustomerId = CustomerId of int

ReasonML:

type customerId =
  | CustomerId(int);

Note how similar these all are! The Rust implementation is the most distinctive, though you can do it with the same kind of union type as the others. Here’s how that would look:

enum CustomerId {
  CustomerId(i32),
}

For performance reasons, you might also choose to implement the F^♯ type as a struct:

<Struct>
type CustomerId = CustomerId of int

Complex data

Wlaschin then moves on to showing how to model more complex data structures: types that “and” or “or” together other data. We “and” data together using record or struct types, and “or” data together using “union” or “enum” types. (Assume we’ve defined CustomerInfo, ShippingAddress, etc. types for all of these.)

Rust:

// "and"
struct Order {
    customer_info: CustomerInfo,
    shipping_address: ShippingAddress,
    billing_address: BillingAddress,
    order_lines: Vec<OrderLine>,
    billing_amount: BillingAmount,
}

// "or"
enum ProductCode {
    Widget(WidgetCode),
    Gizmo(GizmoCode),
}

Elm:

-- "and"
type alias Order =
    { customerInfo : CustomerInfo
    , shippingAddress : ShippingAddress
    , billingAddress : BillingAddress
    , orderLines : List OrderLine
    , billingAmount : BillingAmount
    }

-- "or"
type ProductCode
    = Widget WidgetCode
    | Gizmo GizmoCode

F^♯:

// "and"
type Order = {
    CustomerInfo : CustomerInfo
    ShippingAddress : ShippingAddress
    BillingAddress : BillingAddress
    OrderLines : OrderLine list
    AmountToBill: BillingAmount
}

// "or"
type ProductCode =
    | Widget of WidgetCode
    | Gizmo of GizmoCode

ReasonML—note that since we’re assuming we’ve already defined the other types here, you can write this without duplicating the name and type declaration, just like you can with JavaScript object properties.

/* "and" */
type order = {
  customerInfo,
  shippingAddress,
  billingAddress,
  orderLine,
  billingAmount
};

/* "or" */
type productCode =
  | Widget(widgetCode)
  | Gizmo(gizmoCode);

An interesting aside: unless you planned to reuse these types, you wouldn’t usually write these as standalone types with this many wrapper types in it in Rust in particular (even if the compiler would often recognize that it could squash them down for you).¹ Instead, you’d normally write only the base enum type to start, and refactor out the struct wrapper later only if you found you needed it elsewhere:

enum ProductCode {
-    Widget(WidgetCode),
+    Widget(String),
-    Gizmo(GizmoCode),
+    Gizmo(String),
}

That said: given how the book is tackling things, and the fact that you might want to validate these types… having them as these low-cost wrappers is probably worth it. (In fact, having read a bit further than I’ve managed to write out yet, I can guarantee it.)

We work through the rest of the basic types this way. But what about the types where we don’t yet have a good idea how we want to handle them?

Each of these languages gives us an out (or more than one) for how to say “I don’t know what to put here yet.”

Rust (which does not have a built-in Never type… yet; see below):

// Make an empty enum (which you by definition cannot construct)
enum Never {}

// Use it throughout where we don't know the type yet. It will fail to compile
// anywhere we try to *use* this, because you can't construct it.
type OrderId = Never;

Elm (which has a built-in Never type):

-- It will fail to compile anywhere we try to *use* this, because you cannot
-- construct `Never`.
type alias OrderId =
    Never

F^♯ (which sort of does):

// Make a convenience type for the `exn`/`System.Exception` type
type Undefined = exn

type OrderId = Undefined

Reason (which also sort of does—identically with F^♯):

/* Make a convenience type for the `exn`/`System.Exception` type */
type undefined = exn;

/*
  Use it throughout where we don't know the type yet. It will compile, but fail
  to run anywhere we try to *use* this.
 */
type orderId = undefined;

For both F^♯ and Reason, that’s following Wlaschin’s example. The main reason to do that is to make explicit that we’re not actually wanting an exception type in our domain model, but just something we haven’t yet defined. Anywhere we attempted to use it, we’d have to handle it like, well… an exception, instead of an actual type.

type OrderId = !;

Workflows and functions

Once we have the basic types themselves in place, we need to write down the ways we transform between them. In a functional style, we’re not going to implement instance methods—though as we’ll see in the next post, what we do in Rust will have some similarities to class methods—we’re going to implement standalone functions which take types and return other types.

Again, you’ll note that despite the common lineage, there is a fair amount of variation here. (Note that we’d also have defined the UnvalidatedOrder, ValidationError, and ValidatedOrder types for all of this; I’m mostly interested in showing new differences here.)

Rust (using the Futures library to represent eventual computation):

type ValidationResponse<T> = Future<Item = T, Error = ValidationError>;

fn validate_order(unvalidated: UnvalidatedOrder) -> Box<ValidationResponse<ValidatedOrder>> {
    unimplemented!()
}

Elm (using the built-in Task type for eventual computation; Tasks encapsulate both eventuality and the possibility of failure):

type ValidationResponse a
    = Task (List ValidationError) a

type alias ValidateOrder =
    UnvalidatedOrder -> ValidationResponse ValidatedOrder

F^♯ (using the built-in Async type for eventual computation):

type ValidationResponse<'a> = Async<Result<'a,ValidationError list>>

type ValidateOrder =
    UnvalidatedOrder -> ValidationResponse<ValidatedOrder>

Reason (using the built-in JavaScript-specific Js.Promise type—which is exactly what it sounds like—for eventual computation):

type validationResponse('a) = Js.Promise.t(Js.Result.t('a, list(validationError)));

type validateOrder = unvalidatedOrder => validationResponse(validatedOrder);

Once again Rust is much more different here from the others than they are from each other. The biggest difference between Elm, F^♯, and Reason is how they handle generics and type parameters.

You’ll note that in Elm, they just follow the name of the wrapping type. This is a kind of syntactic symmetry: the way you name a generic type like this is the same basic way you construct it. It’s quite elegant. And as it turns out, the same is true of Reason; it’s just that its authors have chosen to follow OCaml and use parentheses for them instead of following Haskell with spaces—a reasonable choice, given Reason is surface syntax for OCaml and not Haskell.

F^♯ uses angle brackets, I strongly suspect, because that’s what C^# uses for generics, and keeping them syntactically aligned in things like this is very helpful. Rust similarly uses angle brackets for similarity with other languages which have similar surface syntax—especially C++ (with its templates).

The way you name generic parameters differs between the languages as well. Elm, following Haskell, uses lowercase letters to name its generics (usually called type parameters in Elm). F^# and Reason both (unsurprisingly) follow OCaml in using lowercase letters preceded by an apostrophe to name generics—in F^#, TypeGenericOver<'a>; in Reason, typeGenericOver('a). Rust follows the convention from languages like C++, Java, and C^# and uses capital letters, TypeGenericOver<T>. The use of specific letters is conventional, not mandated by the language (unlike the casing). The ML family usually starts with a and moves through the alphabet; Rust and the languages it follows usually start with T (for type) and moves forward through the alphabet. (Sometimes you’ll also see different letters where it’s obviously a better fit for what’s contained.)

These languages also vary in the syntax for constructing a list of things. In F^# has convenience syntax for a few built-ins (the most common being the List and Option types), allowing you to write them either as e.g. List<ConcreteType> or ConcreteType list (as here in the example). Elm, Reason, and Rust all just use the standard syntax for generic types—List a, list('a), and Vec<T> respectively.

Finally, you’ll also note that we haven’t written out a type declaration here for Rust; we’ve actually written out a stub of a function, with the unimplemented!() macro. If you invoke this function, you’ll get a clear crash with an explanation of which function isn’t implemented.

Now, Rust also does let us write out the type of these functions as type aliases if we want:

type ValidateOrder =
    Fn(UnvalidatedOrder) -> Box<ValidationResponse<ValidatedOrder>>;

You just don’t use these very often in idiomatic Rust; it’s much more conventional to simply write out what I did above. However, the one time you might use a type alias like this is when you’re defining the type of a closure and you don’t want to write it inline. This is a pretty sharp difference between Rust and the other languages on display here, and it goes to the difference in their approaches.

Rust is not a functional-first language in the way that each of the others are, though it certainly draws heavily on ideas from functional programming throughout and makes quite a few affordances for a functional style. Instead, it’s a programming language first and foremost interested in combining the most screaming performance possible with true safety, and leaning on ideas from the ML family (among others!) as part of achieving that.

Among other things, this is why you don’t have currying or partial application in Rust: those essentially require you to have invisible heap-allocation to be ergonomic. We don’t have that in Rust, as we do in Elm, Reason, and F^♯. If we want to pass around a function, we have to explicitly wrap it in a pointer to hand it around if we construct it in another function. (I won’t go into more of the details of this here; I’ve covered it some on New Rustacean and some in my Rust and Swift comparison a couple years ago.)

That same underlying focus on performance and explicitness is the reason we have Box<ValidationResponse<ValidatedOrder>> in the Rust case: we’re explicitly returning a pointer to the type here. In Elm, F^♯, and Reason, that’s always the case. But in Rust, you can and often do return stack-allocated data and rely on “move” semantics to copy or alias it properly under the hood.

Summary

So: lots of similarities here at first blush. The biggest differences that show up at this point are purely syntactical, other than some mildly sharper differences with Rust because of its focus on performance. The fact that these languages share a common lineage means it’s not hard to read any of them if you’re familiar with the others, and it’s actually quite easy to switch between them at the levels of both syntax and semantics.

As usual, when dealing with languages in a relatively similar family, it’s most difficult to learn the library differences. The most obvious example of that here is Reason’s Js.Promise, Elm’s Task, F^♯’s Async, and Rust’s Future types: each of those has their own quirks, their own associated helper functions or methods, and their own ways of handling the same basic patterns.

Still, if you have played with any one of these, you could pretty easily pick up one of the others. It’s sort of like switching between Python and Ruby: there are some real differences there, but the similarities are greater than the differences. Indeed, if anything, these languages are more similar than those.

Next time I’ll dig into Wlaschin’s chapter on validating the domain model, and here some of the not-just-syntax-level differences in the languages will start to become more apparent.

I can’t speak to what’s idiomatic this way in any of the non-Rust languages, because I just haven’t used them enough yet.↩

Exploring 4 Languages: Project Setup

Mon, 01 Jan 2018 13:00:00 -0500

In this post, I’m just going to briefly talk through the steps I needed to do to set up each of the languages and my editor setup for them. Gladly, it was pretty simple. At the end, I’ll offer a note on my thoughts on the setup processes. (Note that this isn’t “How to do this for anyone ever”—it’s “how I did it, with some notes where it might be relevant to you.”)

For context, I’m running macOS and using VS Code as my editor. Whenever I say “Install the VS Code extension,” you can do it either by opening the extension side panel and searching for <Extension Name>, or by typing ext install <extension label>—I’ll write it like <Extension Name>/<extension label>.

The source code as of what I’m describing in this post is at the project-setup tag in the repo.

Rust

Language installation: Install rustup: curl https://sh.rustup.rs -sSf | sh¹.
Editor setup: Installed the VS Code extension: Rust (rls)/rust.
Project setup: In the root of my repo, I ran cargo new rust.

Elm

Language installation: There are installers, but I just did npm i -g elm.
Editor setup: Installed the VS Code Elm extension: Elm/elm.²
Project setup:
- Install the create-elm-app tool: npm i -g create-elm-app
- In the root of the project, I ran create-elm-app elm.

F^♯

Language installation: Install mono: brew install mono (note installation instructions here).
Editor setup: Install the VS Code Ionide extension: Ionide-fsharp/ionide-fsharp. It’ll automatically install the associated Paket and FAKE extensions from the Ionide project as well, and those will install Paket and FAKE during installation.
Project setup:
- In the root of the repo, I created the fsharp directory.
- Then I opened a VS Code instance to to that directory, opened the command palette, and ran F#: New Project.
  - I chose console
  - I left the directory blank
  - I named the project dmmf (for Domain Modeling Made Functional).
  - Since F^♯ (like C^♯) prefers PascalCase names, I renamed the generated module DMMF.

ReasonML

Language installation: Following the setup instructions here, I ran npm install -g bs-platform.
Editor setup: following the official instructions—
- I ran npm install -g https://github.com/reasonml/reason-cli/archive/3.0.4-bin-darwin.tar.gz to install the dependencies for the editor configuration.
- I installed the VS Code extension: Reason/reasonml.
Project setup: In the root of the repo, I ran bsb -init reason -theme basic-reason.

Comments on the setup processes

Most of the languages have fairly straightforward processes to get up and running with a good-to-excellent tooling experience.

The best of them is Rust, which is extremely easy to get up and running with.³ Elm is roughly in the middle—it’s less straightforward than Rust in that create-elm-app is not an officially supported approach, unlike rustup and cargo, so you’re going to have a much less awesome experience if you don’t know about it.

Reason and F^♯ both have slightly larger negatives.

Reason requires you to npm install a large, gzipped file with multiple dependencies all bundled, instead of having a dedicated installer a la rustup. It also has the possibility for a not-so-great first-run experience in the editor, which I discovered all too quickly.

F^♯ essentially requires you to use an editor extension to get the language setup with Paket, which is a much better choice of package manager than the default .NET package manager NuGet. Command line tools exist and are improving rapidly, and you can get them working… but it’s harder than it needs to be. And that project setup wizard is fine, but it’s a lot noisier than just doing create-elm-app or especially cargo new.

In any case, though, I have them all up and running now! More soon!

If you’re uncomfortable with running that script, there are other options as well.↩
Note that the VS Code extension is not the best experience out there for Elm: the Atom extensions (language-elm and elmjutsu) are. I stuck with VS Code because it’s good enough and, more importantly, the Code extensions are arguably best in class for the other languages… and it’s what I use every day.↩
I’m not just saying that because I’m a Rust fanboy, either! If Rust were hard to use, I’d be complaining louder because of my enthusiasm for the language.↩

Exploring 4 Languages

Sun, 31 Dec 2017 20:20:00 -0500

Today, as I hit the first of the implementation chapters in Domain Modeling Made Functional, I started thinking about how I wanted to implement it. As I’ve noted elsewhere in the past, very little of the book is truly specific to F^♯, though that’s the language Wlaschin uses in the book—and Wlaschin himself agrees:

Thanks! Yes, it’s true that you could easily use #ElmLang, #RustLang, #Scala, or especially #OCaml to work through the book. I use hardly any F# specific features.

So… I decided to try something a little bit bonkers. I’m going to implement these exercises in four different languages:

These languages are all related: they’re descended from Standard ML. ReasonML and F^♯ are like siblings: Reason is merely a custom syntax for OCaml; F^♯ is (originally) an implementation of OCaml on .NET (though the two languages have diverged since F^♯ came into existence). Elm and Rust are cousins of each other and of Reason and F^♯, though they’re both drawing on other languages besides OCaml as well. I also have some familiarity with Rust, Elm, and F^♯ already, and have read the docs for Reason a couple times. So this is a bit less crazy than it might otherwise be.

Why, though? Mostly because I think it’ll be interesting to compare the implementations of the domain model from the book side by side. It’ll look just a bit different in each language, and I expect to learn a bit more of the feel of each language by doing this. (That side by side comparison is something I’ve done before and found very profitable.) I’ll also turn it into blog posts, which hopefully will be interesting to others!

More to come, and soon.

Becoming a Contributor

Thu, 02 Nov 2017 07:00:00 -0400

Here is the full text of the talk I gave at Rust Belt Rust, as it was prepared; headings correspond to individual slides. You can see the slides as they were presented here. Note that I extemporize fairly freely when actually giving a talk, so this is not a word-for-word equivalent of the talk as delivered, but the gist is the same!

I’ll update this post with the video once it’s available!

family

Hello, everyone! It’s good to see all of you. We only have half an hour, and even if that’s ten to fifteen minutes longer than a normal New Rustacean episode, that’s still not much time, so let’s jump right in! Our theme is “Becoming a Contributor.” There are two prongs to this talk, two big ideas I hope you all walk away with.

Introduction: The Big Ideas

The first thing I hope all of you take away is that there is no reason you cannot contribute meaningfully to the success of Rust – or indeed any open-source project you care about. Anyone can be a contributor. And not “even you” but perhaps “especially you”. The fact that you’re an outsider, or new to programming, or new to systems programming: sometimes that makes you a better contributor. Because you don’t necessarily share the biases of – you’re not wearing the same blinders that – someone who’s been writing systems-level code for 20 years have. So the first idea: you can contribute.

The second idea I hope you take away is just how many ways there are to contribute meaningfully. It has almost become a cliche in the Rust community to say “code isn’t the only thing that matters,” but I want to show you today just how true that is. And I want to make that point again more forcefully, because for all that we often say that, the idea that shipping code is what really matters is the kind of pernicious lie that can come back and bite any of us. It certainly gets to me at times! But it’s a lie, and we’re going to see that in detail. That’s the second big idea: there are an astounding number of ways you can contribute.

Introduction: Why?

There are a lot of things to be passionate about in the world of software development. But at the end of the day, I care about software because I care about people. To borrow a label from Scott Wlaschin – a developer I admire enormously, mostly working over in the F# community – I am a humanist, not a technologist. The technologies are interesting in themselves to a degree; but I mostly care about the ways that technologies can help us serve people more effectively. As software developers, that takes a lot of shapes. But today I want to zoom in on just these two ideas about open-source software:

Introduction: The Big Ideas

So: why these two ideas? For one thing, because I think they are among the most applicable to everyone here. We have an enormous open-source focus. But for another, because they can also serve as windows into the ways we can – and should – think about software more generally. So: let’s talk about how you become a contributor.

Introduction: Outline

We’re going to take this on in the good old grammar-school fashion: who, what, when, where, why, and how. We’re not going to take them in that order though, and we might smash a few of them together.

Introduction
Why bother contributing?
Who is a contributor?
What is a contribution? How can you contribute?
- …so many things they won’t fit on this slide.
When and where to contribute?
Conclusion

Why bother contributing?

The first question we might be asking is: why contribute at all? Why should you be interested in becoming a contributor? And the best answer I can offer is: because there is more work than hands to do it. Always. Every open-source maintainer can tell you the truth of this.

Who is a contributor?

People define this differently, but I have a very simple definition: A contributor is anyone who improves a project.

Who is a contributor? Examples

For example:

submit a patch to fix a typo
add a small correction for a code sample in a project
file an issue instead of just suffering through a problem in silence
everything else we’re going to talk about today

Who is a contributor? Me!

That might sound overblown, but it’s really not. I am literally standing on this stage in front of you today because I submitted some small typo and code sample improvements to “Rust by Example” a few years ago, and realized: I can make a difference in this community. And that gave me the motivation I needed to keep contributing.

Who is a contributor?

I don’t imagine the story is all that different for most people who are open-source contributors in this room. Something got them over the hump, and it was probably something small, insignificant-seeming at the time. They might be particularly skilled in this thing or that thing, but in fact a lot of them are in those roles just because they saw a need and stepped up to fill it. And then kept at it for a long time. But it made them a contributor. And that feeling – of helping build something bigger than you can build on your own – is a good one. I’d go so far as to say it’s part of what humans are meant for. It’s part of us in a deep, deep way.

Who is a contributor?

If you’re inclined to quibble with that definition, I challenge you to ask why? I think, most often, it’s because we feel defensive about wanting to project our own particular kinds of contribution as the most important, or the most valuable. But I’m more of the mindset that, as I read recently, “anyone who would be first… must be last of all, and servant of all.” We should stop worrying about our own prestige and turf-marking, and start rejoicing in the many different ways people are able to make our projects better.

There’s no magic that makes you qualified to be a contributor. There’s just a willingness to serve where you see a need.

What & how can you contribute?

And that takes us into the “what” of all of this, the how. (Yes, I’m combining those two). What is a contribution? How can you contribute? Turns out, this is a long list.

What & how: code

Let’s get this right out of the way up front, because it’s the most obvious: you can write code. You can fix bugs or help implement new features. You can do that even if you’re not an expert – especially in the Rust community. Many Rust projects have gone out of their way to mark issues as good-first-issues, or easy-to-tackle, or mentorship-available. Maybe it’s your first contribution to an open-source project: that’s okay. You can take a stab at it, and the fact that it might not be good is okay. The whole point of these kinds of issues is that they give you a place where you can jump in safely.

That goes equally for everything from the Rust compiler itself to many of the other projects in the ecosystem. Look at the repository, for example! And it’s not just this project. Lots of projects in the Rust ecosystem are like this.

What & how: code – we’re kind here

And no one is going to swear at you or insult for making a mistake here. Not even if you’re working on something important, and not even if you’ve been doing it for a while. That is not. how. we. roll. here. Everyone makes mistakes!

Instead, we want people to show up, knowing nothing: we’re happy to help. Remember: we want people to contribute! So: try opening a PR and let people help you learn how to do it well! In fact, if you haven’t ever opened a PR on a Rust project, find one that looks interesting to you and has an issue tagged that way, and submit a PR before the weekend is out! You can do it!

What & how: code – a caveat

But code is not the only thing that makes you a contributor. I put it up front because I think it’s worth doing – but I also wanted to get it out of the way. In every software community, it’s easy to over-value the code. That might sound crazy, given that it’s open-source software, but the reality is that no one fails to value the code. We do often fail to value all the other things that make an open-source software project actually useful. It’s certainly true that there’s no project without the code. But it’s also the case that there’s no useful software without a lot of other things besides the code, and we often undervalue those.

Filing bugs

So let’s take one step away from code, and talk about what is probably the single easiest way anyone can contribute. File issues. If you’re using a binary and it doesn’t work, open a ticket. If you’re integrating a library and it seems like the API doesn’t do what it should, or if it seems like it’s missing some functionality… well, you can suffer in silence, or you can open a bug ticket! Many times, the author of the software doesn’t know there’s a problem. The only way they can fix it is if they know about it!

filing bugs

Docs

Perhaps the thing most of you will be most persuaded of the utility of is documentation. All of us have faced the difficulty of trying to figure out how to integrate some poorly-documented (or undocumented!) library into our own codebase. That experience, in word, sucks.

So working on documentation is one of the highest-value areas you can contribute to any project. It’s also really hard, in a bunch of ways – harder, in some ways, than writing the code is!

Docs: who?

One kind of documentation is explanation of how things work under the hood. The implementer is the most qualified there! That doesn’t mean they don’t still need help even with that, though! Some people are incredible implementors and terrible explainers; you can often do a great service by serving as an “interpreter” for them – taking their explanations and making the literary tweaks and cleanups and polish that they need.

Another kind of documentation, though, developers and maintainers are often really poorly equipped to write, and that’s introductory documentation. This is the problem of expertise: when you know exactly how something is meant to work, and especially when you’re the one who implemented it, there are things that seem obvious to you which simply aren’t obvious to someone approaching it for the first time. And as hard as you try, you can’t escape that entirely. You can imagine what it might be like not to know something, but there’s no substitute for actually not knowing something.

Docs – how?

What that means is that one of the most valuable things you can do as you learn a new library is write down the things you don’t understand from the docs as you go. And when you figure them out, write that down, too. If nothing else, writing up that experience – filing it as an issue on the bug tracker, or otherwise getting it in the hands of the maintainers – can help them make important changes to things like the order various concepts are introduced, or adding little notes to help people feel comfortable with not knowing something until it can be introduced later, and other things like that. It can help them recognize and fill in gaps in their docs – things they simply assumed but which they didn’t realize they were assuming – and fill those in. At the most extreme, you might even help them realize that some parts of the docs need full rewrites… and the work you’ve done in writing things down might just be the foundation or the actual content of those new docs.

Write down the things you don’t understand from the docs as you go.
When you figure them out, write that down, too.
Then: file an issue or write a PR to improve it!

Docs: varieties

So what kinds of things would we call documentation?

API documentation
READMEs
Tutorials
Books
The Rust Reference

Okay, books are a huge undertaking, but they can genuinely serve as documentation. Especially for large projects. In fact, several of the most important pieces of “documentation” the Rust project itself has are books: “The Rust Programming Language”, “Rust by Example”, and “The Rustonomicon”. But there are also important but totally unofficial books like Daniel Keep’s “A Practical Intro to Macros in Rust 1.0” and “The Little Book of Rust Macros”, or Jorge Aparicio’s book on microcontrollers with Rust.

The Rust Reference: This is a special category, and one that’s especially important to me. The Rust Reference is supposed to be an exhaustive guide to the language, and the value of that being complete and accurate is hard to overstate. It’s also wildly out of date today. I wrote an RFC last year that said, basically, “We need to actually document everything! That includes updating the Reference!” The trick is: it’s a huge undertaking, and while I and a few others made a good start on it earlier this year, that effort got bogged down by life, and it needs to be resuscitated. And it’s not just Rust which could use investment in that area. Other languages and frameworks have the same issue. It’s really important that there be an answer other than “dive into the source and try to figure out what its intent is” – the more central the component is in the ecosystem, the more important that is.

Docs: Translation

Another huge place you can contribute to documentation is translation. For good or ill, English has become the sort of primary language of programming, but that doesn’t mean we should treat it as the only language, or as more important than other languages. Translating documentation is amazing and very needed work, and it’s work that not everyone is really capable of! I’m fluent in English and… ancient Hebrew and ancient Greek. For some reason, there’s not much demand for technical writing in Greek from the era when Plato was alive. So I’m not much use at translation.

translation

But many of you out there are multilingual, and could take docs written in English and convert them for, say, Czech-speaking developers. Perhaps just as importantly, you can go the other direction, and help non-English-speaking maintainers reach a broader audience. Take an amazing project which only has documentation in Amharic (because its developers don’t feel comfortable enough in English to translate it themselves) and translate it to English: use the fact that English is the common language to increase the reach of non-Western developers!

Visual Design

One of the areas where you could move the ball down the field fastest in the Rust community is with visual design. (To be clear, the language design is great!) But our websites could sometimes use some work.

Visual design: it’s not just us

Systems programming language types have historically not spent a lot of time on the presentation of their tools. In part this is just a matter of what these kinds of languages have been oriented towards: if you spend all day hacking on kernel code, you’re likelier to be a person for whom user interface and visual design is less interesting than, say, optimizing memory performance or minimizing the number of cache misses a given approach has. But presentation does matter, and it matters especially as we want to enable more and more people to be able to write this kind of code.

Speaking frankly, though I’ve spent a large chunk of my career to date writing systems-level languages, I’ve found the way a lot of these tools are presented to be a huge turn-off, and at times a barrier even to getting them working for me locally. Perhaps the most egregious example of that was some of the “documentation” – I’m not sure I should even call it that! – for Fortran, when I was first getting started programming back in college. The presentation of the material was essentially hacker-ish in a bad way: no CSS, no attention to organization of the material, no structure to help you find your way through it.

Visual design: how

If you’re an expert or just a talented amateur, please pitch in

You can help here even if you’re not especially comfortable with visual design or even if you’re outright bad at it if you’re willing to spend just a little time on it! For example, you can simply help a team adopt something like Bootstrap. Yes, it’ll look like many other open-source projects out there. But it won’t be horribly, catastrophically ugly and unreadable! Or you can do use one of these simple starter kits:

So don’t think that just because you aren’t a design expert means you can’t help here.

Just as important as the visual design is thinking about and actively designing the information hierarchy of your content. What leads to what? Which pieces go together, and which pieces can be broken up into their own pages or sections within pages? Think about the content like an outline. Many sites don’t have any such structure to them; they’re kind of haphazardly cobbled together. If you can help the maintainers with the structure and organization of their content, that can make an enormous differences as well.

Blogging

One of the other big ways you can help a project may not even end up in the repository at all. You can blog.

I know blogging can seem intimidating, for many of the same reasons that writing documentation can. Technical writing is hard, and it’s a completely different skill from programming. But it doesn’t have to be amazing; it just has to get the information out there – and you’ll get better as you practice.

Blogging: “Easy Mode”

You can start on “easy mode”, too. I mentioned this earlier when talking about documentation, but “just write down what you’re learning” is an incredibly effective technique for generating content. If you look at a lot of the technical blogging I’ve done over the years, it has been nothing more complicated than “here is what I just learned.” And if you want a superb example of this which is very different from mine, take a look at the work that Julia Evans does on her blog! She regularly writes down, in an inimitable way, highly technical ideas she’s just learning. If you want someone to make arcane Linux command line tools seem amazing and approachable, her blog is your ticket.

Just write down what you’re learning.
—Me, just now

Blogging: good examples

But even beyond “what I just learned,” blogging is a superb way for teaching in general. Over the course of this year, for example, Vaidehi Joshi has been writing what is essentially a friendly introduction to computer science on her blog on Medium. This is a totally different style of content (as well as of presentation!) from the kind of “what I just learned” content that Julia Evans writes,but it’s also really effective, because she takes her knowledge and translates it into something others can pick up. That’s obviously more work than just writing down things you just learned, but it can also pay really high dividends as others are able to substantially deepen their knowledge.

Blogging: all the options!

In blogging, as in documentation, there is a whole spectrum of basic teaching content you can contribute! And communities need the whole spectrum for simple introductions to extremely thorough, advanced tutorials.

But blog posts can also be much more versatile than traditional documentation.

They can be one-offs, or series. You can give a topic as much depth, or as little depth, as you care about or think it deserves. I wrote an 18-part series comparing Rust and Swift, and it could have been 30 parts if I hadn’t eventually gotten derailed. That’s not documentation, but there’s a lot people can learn from those kinds of things.
They can introduce a technology, or dig deep into how to use it, or how it’s built. You’re not limited to just one particular tack when blogging. Is your interest in the specific implementation details of some corner of the compiler? Write about that! Is your interest in how a given Rust library solves a specific kind of problem you’ve run into with another library, or with a similar library in another language? Write about that! You get the idea.
They can critique or highlight problems with specific pieces of the ecosystem! A careful, well-articulated, critical blog post can do wonders for showing the problems with a given approach and can even sometimes help suggest the right solutions to those problems. I’ve repeatedly watched, for example, as people have blogged about their struggles getting their heads around the Tokio tooling; the result has been a lot of work by the Tokio team to respond to those problems. The more thoughtful and careful you are in that kind of criticism, the better! Good criticism is incredibly valuable. Because we all have blind spots, and someone else’s perspective can help jar us out of those.
They can show how to integrate different parts of the ecosystem. For example, as part of the “Increasing Rust’s Reach” initiative, Ryan Blecher recently wrote up a detailed walk-through on how to use the Diesel ORM and the Rocket web framework together to build a small blogging engine. That’s huge! It makes it that much easier for someone who’s just starting out with Rust, coming in from something like Python or Ruby, to dive in and get that intensely rewarding feeling of having built something in a relatively small amount of time. That’s also helpful because (almost) no one is building something with just Diesel, or just any crate. A huge part of what every software developer does is about fitting together other pieces of software.
They can invite feedback on your own projects. Talk about what you’re doing, what your stumbling blocks are, what you don’t understand. People will often show up and help you with comments and clarifications!

And that’s just scratching the surface. Blogs are incredibly versatile, and you should lean on that.

Audio and Video

Not just words! Noises and pictures, too!

Audio: podcasts

Not everyone learns the same way.
Lots of people have commutes.

Audio: but there are already podcasts

Everything I’ve talked about so far has been in written form. But audio and video media can also be really helpful. Not everyone learns best by reading. And not everyone has tons of time to sit down and read a book every day. One of the reasons I started the New Rustacean podcast is that it gives people a way to get up to speed on the language while on a daily commute. But there’s still a huge need for more audio and video content in this space!

One podcast is not enough!

New Rustacean

Two podcasts is not enough!

Request for Explanation

Seriously, not even three podcasts is enough!

Rusty Spike

So I’m laying down another challenge: there’s plenty of room for more, and more kinds, of audio content in this ecosystem.

Video

Again: people have different learning styles!

There’s also a huge opening for people to produce good video content. I’ve heard often from people that things like RailsCasts were essential in helping them learn the Ruby on Rails ecosystem. We need video tutorials which might look kind of like that, or like the kinds of things I’m doing on the podcast. If you have any skill that way, and any interest in teaching, you should make Rust videos – there aren’t many out there.

Video: what

There are lots of options here—not just live streaming!

Another, totally different tack you can take with video is live-streaming. Sean Griffin has done this at times, and I’ve actually done it just once, and it’s a ton of fun – and it can be incredibly illuminating for other people to see how you work and how you solve problems. You can also do like I did and live-pair on something. It’s a pain to set up, but it’s also a lot of fun.

And no doubt there are more ideas you have—please just go do them!

Talk to people

Just talking with people matters. And there are lots of places to do it:

IRC/Gitter/Slack/Discourse
Meetups
Conferences

You can also host or help with a local meet-up! For a lot of people, one of the major challenges of learning any new piece of technology is that – even with IRC and Gitter and Slack and so on – you can feel isolated and alone. And people can help you solve problems in person, and make you feel supported in person, in ways that even a great community can’t really manage online. So go to meet-ups, at a minimum. And help the organizers. And if there isn’t a meet-up in your community… you can start one! The #rust-community team has a ton of resources.

Physicality matters. Presence matters. (We know this! We’re at a conference!)

Being inviting

Last but not least in this list of how to be a contributor, I want to take a minute and talk about “being a contributor” to those of you who’ve been contributors for a long time. Some of you have been shipping open-source software for years – some of you even for decades. Much of what I’ve said so far is old hat for you. Maybe not the design bits quite so much! But you’ve been doing this for a long time, and you’re not trying to get over the hump of making your first contribution. You have other things to contribute here:

The most important thing you can do is practice welcome people. The Rust community does this well, in general, but it’s something we need to keep in front of us as a goal as the community grows. It’s easy to get frustrated with newcomers as your project grows, demands on your time increase, and your work as a maintainer seems less like fun and more like a second job. But continuing to actively welcome newcomers in is incredibly powerful. You can make it possible for people to go from zero to really making a difference. And remember: so once were you. None of us started out as magical wizards of Rust and open-source.
The second big thing you can do is mentoring. As I mentioned, I’m now the maintainer of one of the core pieces necessary to make Ember.js and TypeScript play nicely together. But while I’ve done some writing-of-code with that, a much larger part of my current and future work there is about helping other people learn TypeScript well enough to start using it in their apps and add-ons. But the flip-side of that is: even a fair bit of the code I have written, I was able to write because someone more comfortable with some of the infrastructure mentored me through its quirks and oddities.

When & where to contribute

The last thing I want to touch on is when and where to contribute. There are two things I’d suggest you should consider here:

When & where: you

Where are you in the process of becoming comfortable with contributing?

Just getting started?
Already comfortable?

If you’ve never done any open-source work at all before, that’s different than if you’ve gotten pretty comfortable with it in a different ecosystem and are just figuring out where to make yourself useful in this ecosystem.

When & where: if you’re just getting started

If you’re just getting started, I’d pick a big project with lots of those “Help Wanted” and “Mentoring” and “Easy” tags on issues, and let the size of the project help you out. Those are projects that are used to helping people make their first contributions. Crazy as it seems, something like Servo can actually be an easier place to start out that a much smaller project. Sure, the technical lift is higher, but there are also a lot more people actively invested in your success there.

Look for these!
Pick big projects!

When & where: if you’re experienced

On the other hand, if you’re already comfortable contributing and have some idea what you’re best at, you might look around and find smaller projects with fewer contributors which look interesting and could use the help. Because again, there’s always more work to do than hands to do it.

When & where: project lifecycles

The second consideration dovetails nicely with that: where is a given project at in its life-cycle? As enthusiastic as you might be about some project, if it’s a small project and it’s already in a “basically done” state, well… that’s probably a lot less useful a place to invest your time if you’re focusing on code. On the other hand, it’s often the case that projects are “done” in terms of code, but desperately need help with documentation, their web site, etc. Big projects, or projects just starting out, are often better places to dig in if you’re really looking to flex your coding muscles (but both of them also usually have huge needs in terms of all those non-code avenues we talked about).

Where is a given project at in its life-cycle?

small project, basically done?
need docs?
big project, a billion needs?
etc.

Think about those, and then see if you can pick a project that’s a good fit for your current skillset and comfort level and jump in!

Conclusion

And that’s a good place to wrap things up! I hope you’re feeling like you can do this. Because you can. Open-source a project of your own and see where it goes. Write a blog post. Add some docs. Open a PR. Record a podcast. Make some videos. Start a meet up. Become a contributor! And remember:

Anyone can contribute meaningfully.
People can contribute in a stunning variety of ways.

More info

https://www.rust-lang.org/en-US/contribute.html
https://blog.rust-lang.org/2017/09/18-impl-future-for-rust.html
https://internals.rust-lang.org/
#rust, #rust-community, #rust-internals, etc. on irc.mozilla.org

Better Off Using Exceptions?

Mon, 20 Feb 2017 12:00:00 -0500

I saw this post on error-handling in F^♯, “You’re better off using Exceptions” making the rounds on Twitter:

Exception handling is an error management paradigm that has often been met with criticism. Such criticisms typically revolve around scoping considerations, exceptions-as-control-flow abuse or even the assertion that exceptions are really just a type safe version of goto. To an extent, these seem like valid concerns but it is not within the scope of this article to address those per se.

Such concerns resonate particularly well within FP communities, often taken to the extreme: we should reject exceptions Show more…

And I get the argument, and in the specific context of F^♯—especially given how much C^♯-interoperating and therefore exception-throwing-code-interoperating there is there—it’s reasonable.

But it still makes me sad. (To be clear: exceptions were and are a big win over what you get in languages like C. I’ll take them any day over goto or segfault.)

You need to embrace exceptions in F^♯ because F^♯ has exceptions and because many of its libraries rely on exceptions. But my experience with Rust and other non-exception-using languages is that you don’t need exceptions in the general case.

The questions are: whether your language has good support for things like flat-mapping, and whether you’re willing to commit to letting the compiler help you with these problems.

To be sure: there’s more work involved up front to deal with that. But that’s a tradeoff I’m always willing to make. I’d rather have the compiler tell me if I’m failing to account for something than learn because I saw a runtime error report come up in Raygun, especially because that tends to mean an error that affects the user in some way.

Rust’s model gives you something like exceptions for truly unrecoverable errors, “panics.” A panic gives you all the context you’d get from an exception (one of the virtues of exceptions highlighted in that post), but you can only “catch” it at thread boundaries, and it otherwise just kills the program. Because it’s catastrophic, you only use it where you don’t have any way to recover in your immediate context. But where you can recover in your immediate context… using something like a highly descriptive enum (just as suggested at the end of that original post!) is a better option.

It’s well-understood in my circles that you shouldn’t use exceptions for things you can recover from; you should use them for things you can’t recover from. But in most languages which lean heavily on exceptions, you inevitably start using them for control flow. I say: if you can recover from an error… just recover from it! Account for recoverable errors as possible conditions in your program and carry on! If you can’t recover… don’t. Die and let some other part of your system kick things back off.

In summary: yes, if you’re in F^♯, use exceptions. It is the right thing to do in many cases (and you don’t have a choice in many others). But I’m hopeful for a future where we handle recoverable errors locally, and act like Erlang or Elixir otherwise.

The Itch

Mon, 19 Dec 2016 21:45:00 -0500

It took me until just a few weeks ago to put my finger on why typed functional programming, as a style and approach, has appealed to me so much as I started picking it up over the last year. For all its novelty, typed FP feels—over and over again—familiar. Strange to say, but it’s true.

This came home to me again when reading a short post on functors—i.e., mappable types. I’ve written a lot of JavaScript in the last few years, and it has been a source of constant frustration to me that Array implements the map method, but Object does not. Countless times, I have wanted to take an object shaped like { count: <number> } and transform that count. I’m not alone in that. There’s a reason that libraries like Underscore, Lodash, and Ramda all supply utilities to allow you to map over objects. There are also good reasons why it isn’t implemented for on Object.prototype: the reality is that coming up with a predictable and useful API for all Object instances is difficult at best: Objects are used for everything from dictionaries to records and strange combinations of the two. But still: there’s something there.

And reading this post on functors, it struck me what that “something” is: object types are, in principle, functors. Maybe it doesn’t make sense to have a single map implementation for every Object instance out there. But they’re perfectly mappable. I didn’t have a word for this before tonight, but now I do. Over and over again, this is my experience with functional programming.

There’s this familiar feeling of frustration I’m slowly coming to recognize—a mental sensation which is a little like the intellectual equivalent of an itch in a spot you can’t quite reach. You’re reaching for an abstraction to express an idea, but you don’t even know that there is an abstraction for it. You want to map over objects, and you don’t know why that seems so reasonable, but it does. And then someone explains functors to you. It scratches the itch.

Another example. Since I started programming eight and a half years ago, I’ve worked seriously with Fortran, C, C++ PHP, Python, and JavaScript. In each of those languages (and especially in the C-descended languages), I have found myself reaching for enums or things like them as a way of trying to represent types and states in my system in a more comprehensive way. I figured out that you should use enums not booleans a long time before I found the advice on the internet. I was encoding error types as enum values instead of just using ints almost as soon as I started, because it was obvious to me that ErrorCode someFunction() { ... } was far more meaningful than int someFunction() { ... } (even if the context of C meant that the latter often implied the former, and even if it was trivial to coerce one to the other).

Then I read Maybe Haskell, a book I’ve mentioned often on this blog because it was so revelatory for me. This is what I had been reaching for all those years—and then some. Handing data around with the constraints? Yes, please! I had played with unions, enums, structs with enums inside them, anything to try to get some type-level clarity and guarantees about what my code was doing. Haskell showed me the way; and since then Rust and Elm and F# have reinforced it many times over. Tagged unions are a joy. They let me say what I mean—finally.

I can still feel that itch. It’s shifted a little, but it’s still there: reaching for higher abstractions to let me tell the machine more clearly what I intend. Half a dozen times this year, I’ve realized: Here is where dependent types would be useful. They’re far beyond me, but close enough now I can see. I’m sure a year from now, I’ll have find some tools to scratch these itches, only to discover a few more.

Rust development using VS Code on OS X, debugging included

Fri, 18 Nov 2016 20:48:00 -0500

Super handy guide for getting a debugging/IDE environment set up for Rust.

Using Rust for ‘Scripting’

Mon, 14 Nov 2016 22:00:00 -0500

Edit: fixed some typos, cleaned up implementation a bit based on feedback around the internet.

A lightly edited version of this post was syndicated in Hacker Bits, Issue 13.

I. Using Rust Instead of Python

A friend asked me today about writing a little script to do a simple conversion of the names of some files in a nested set of directories. Everything with one file extension needed to get another file extension. After asking if it was the kind of thing where he had time to and/or wanted to learn how to do it himself (always important when someone has expressed that interest more generally), I said, “Why don’t I do this in Rust?”

Now, given the description, you might think, Wouldn’t it make more sense to do that in Python or Perl or even just a shell script? And the answer would be: it depends—on what the target operating system is, for example, and what the person’s current setup is. I knew, for example, that my friend is running Windows, which means he doesn’t have Python or Perl installed. I’m not a huge fan of either batch scripts or PowerShell (and I don’t know either of them all that well, either).

I could have asked him to install Python. But, on reflection, I thought: Why would I do that? I can write this in Rust.

Writing it in Rust means I can compile it and hand it to him, and he can run it. And that’s it. As wonderful as they are, the fact that languages like Python, Perl, Ruby, JavaScript, etc. require having the runtime bundled up with them makes just shipping a tool a lot harder—especially on systems which aren’t a Unix derivative and don’t have them installed by default. (Yes, I know that mostly means Windows, but it doesn’t solely mean Windows. And, more importantly: the vast majority of the desktop-type computers in the world still run Windows. So that’s a big reason all by itself.)

So there’s the justification for shipping a compiled binary. Why Rust specifically? Well, because I’m a fanboy. (But I’m a fanboy because Rust often gives you roughly the feel of using a high-level language like Python, but lets you ship standalone binaries. The same is true of a variety of other languages, too, like Haskell; but Rust is the one I know and like right now.)

Edit the second: this is getting a lot of views from Hacker News, and it’s worth note: I’m not actually advocating that everyone stop using shell scripts for this kind of thing. I’m simply noting that it’s possible (and sometimes even nice) to be able to do this kind of thing in Rust, cross-compile it, and just ship it. And hey, types are nice when you’re trying to do more sophisticated things than I’m doing here! Also, for those worried about running untrusted binaries: I handed my friend the code, and would happily teach him how to build it.

II. Building a Simple “Script”

Building a “script”-style tool in Rust is pretty easy, gladly. I’ll walk through exactly what I did to create this “script”-like tool for my friend. My goal here was to rename every file in a directory from *.cha to *.txt.

Install Rust.
Create a new binary:
```
cargo new --bin rename-it
```

Add the dependencies to the Cargo.toml file. I used the glob crate for finding all the .cha files and the clap crate for argument parsing.

[package]
name = "rename-it"
version = "0.1.0"
authors = ["Chris Krycho <[email protected]>"]

[dependencies]
clap = "2.15.0"
glob = "0.2"

Add the actual implementation to the main.rs file (iterating till you get it the way you want, of course).

extern crate clap;
extern crate glob;

use glob::glob;
use std::fs;

use clap::{Arg, App, AppSettings};


fn main() {
  let path_arg_name = "path";
  let args = App::new("cha-to-txt")
    .about("Rename .cha to .txt")
    .setting(AppSettings::ArgRequiredElseHelp)
    .arg(Arg::with_name(path_arg_name)
      .help("path to the top directory with .cha files"))
    .get_matches();

  let path = args.value_of(path_arg_name)
    .expect("You didn't supply a path");
  let search = String::from(path) + "/**/*.cha";
  let paths = glob(&search)
    .expect("Could not find paths in glob")
    .map(|p| p.expect("Bad individual path in glob"));

  for path in paths {
    match fs::rename(&path, &path.with_extension("txt")) {
      Ok(_) => (),
      Err(reason) => panic!("{}", reason),
    };
  }
}

Compile it.
```
cargo build --release
```
Copy the executable to hand to a friend.

In my case, I actually added in the step of recompiling it on Windows after doing all the development on macOS. This is one of the real pieces of magic with Rust: you can easily write cross-platform code. The combination of Cargo and native-compiled-code makes it super easy to write this kind of thing—and, honestly, easier to do so in a cross-platform way than it would be with a traditional scripting language.¹

But what’s really delightful is that we can do better. I don’t even need to install Rust on Windows to compile a Rust binary for Windows.

III. Cross-Compiling to Windows from macOS

Once again, let’s do this step by step. Three notes: First, I got pretty much everything other than the first and last steps here from WindowsBunny on the #rust IRC channel. (If you’ve never hopped into #rust, you should: it’s amazing.) Second, you’ll need a Windows installation to make this work, as you’ll need some libraries. (That’s a pain, but it’s a one-time pain.) Third, this is the setup for doing in on macOS Sierra; steps may look a little different on an earlier version of macOS or on Linux.

Install the Windows compilation target with rustup.
```
rustup target add x86_64-pc-windows-msvc
```
Install the required linker (lld) by way of installing the LLVM toolchain.
```
brew install llvm
```
Create a symlink somewhere on your PATH to the newly installed linker, specifically with the name link.exe. I have ~/bin on my PATH for just this kind of thing, so I can do that like so:
```
ln -s /usr/local/opt/llvm/bin/lld-link ~/bin/link.exe
```
(We have to do this because the Rust compiler specifically goes looking for link.exe on non-Windows targets.)
Copy the target files for the Windows build to link against. Those are in these directories, where <something> will be a number like 10586.0 or similar (you should pick the highest one if there is more than one):
- C:\Program Files\Windows Kits\10\Lib\10.0.<something>\ucrt\x64
- C:\Program Files\Windows Kits\10\Lib\10.0.<something>\um\x64
- C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64
Note that if you don’t already have MSVC installed, you’ll need to install it. If you don’t have Visual Studio installed on a Windows machine at all, you can do that by using the links here. Otherwise, on Windows, go to Add/Remove Programs and opting to Modify the Visual Studio installation. There, you can choose to add the C++ tools to the installation.

Note also that if you’re building for 32-bit Windows you’ll want to grab those libraries instead of the 64-bit libraries.
Set the LIB environment variable to include those paths and build the program. Let’s say you put them in something like /Users/chris/lib/windows (which is where I put mine). Your Cargo invocation will look like this:
```
env LIB="/Users/chris/lib/windows/ucrt/x64/;/Users/chris/lib/windows/um/x64/;/Users/chris/lib/windows/VC_lib/amd64/" \
cargo build --release --target=x86_64-pc-windows-msvc
```
Note that the final / on each path and the enclosing quotation marks are all important!
Copy the binary to hand to a friend, without ever having had to leave your Mac.

To be sure, there was a little extra work involved in getting cross-compilation set up. (This is the kind of thing I’d love to see further automated with rustup in 2017!) But what we have at the end is pretty magical. Now we can just compile cross-platform code and hand it to our friends.

Given that, I expect not to be using Python for these kinds of tools much going forward.

Again: you can do similar with Haskell or OCaml or a number of other languages. And those are great options; they are in some ways easier than Rust—but Cargo is really magical for this.↩

Rust vs. React Native—What?

Fri, 07 Oct 2016 08:20:00 -0400

I was recently discussing some thoughts I’ve had on building a top-notch application experience in a Slack team I belong to, and noted that I believe that a Rust core with native UIs is a massively winning strategy. A friend in the group responded that he thinks “React + JS is eating the world right now” and that “Rust as awesome for if you want to write a JS vm, or something like that… or a compiler… anything involving lots of speed and stability.” What follows is my response, lightly edited to remove details specific to that friend and to add a few further thoughts.

Here’s the thing: I don’t care what’s eating the world today, for three reasons:

I just want to build the best stuff I can build, and native UIs are still massively better than React and even React Native¹ in innumerable ways. There are clear advantages to React Native + JavaScript, and times when you absolutely should take that approach. But there are also a lot of times and reasons why you shouldn’t. Heck, even if you just want killer performance in browsers, our future includes things like Rust-to-WebAssembly, and that’s a good thing.

What was eating the world five years ago? Ten? Is it still eating the world today? I don’t feel obliged to follow those trends (not least because, not being a consultancy, following those trends doesn’t buy me anything for the things I want to do; your tradeoffs and mine look way different).

I’m actually getting really tired of just treating as acceptable or normative the performance characteristics of browsers. Browsers are awesome. But we can (and should) do a lot better in terms of user experience, and I don’t see browsers catching up to what you can do with e.g. Cocoa (Touch). Sure, that doesn’t matter that much for building yet-another-storefront. (Again, there are different tradeoffs for every single app!) But why in the world are we in a spot now where one of the most popular text editors in the world is slower than any text editor of five years ago? That’s not a necessary decision, and you can (and should) go after the same degree of ease-of-extensibility that Atom has had—perhaps even using things like HTML and CSS for skinning!—while not tying yourself to the browser and its upsides and downsides for everything. We have incredibly powerful machines, and the user experience is often getting slower. I’m looking for ways to change that.

Again, JS+React² may be exactly the right tradeoff for a lot of apps, and given what consultancies (like my friends’s!) are doing, I think doing that with ReactNative for apps is a very good move. It makes good sense business-wise, and it makes good sense in terms of the apps you’re likely to be delivering. Don’t hear me for a second saying Rust is the best for everything. I think it, or something like it, is a very good choice for many things, though, and it shouldn’t be dismissed simply because it’s a very different world from doing Ruby or Elixir or JavaScript.

So much for my initial response. On reflection, I wanted to expand it a bit. So here’s another few hundred words!

Beyond this, I think there’s a bit of a false dichotomy here: the idea that “lots of speed and stability” aren’t values we should be seeking more aggressively for all our apps. Fully granted that not every app needs the same degree of each of those, and moreover that there are a lot of ways to get to those goals. Still: speed and stability are core user experience values. I don’t really care how you get at those goals, whether it’s with Rust, or Elixir or Clojure, or, yes, React with TypeScript or Flow. I do think that Rust is, for the moment at least, uniquely positioned to add real value in this space because it gives screaming performance but with so many niceties we’re used to when writing languages like Python or Ruby and so much of the power you get in languages like OCaml or F♯.³ But at the end of the day, I think all apps should focus much more on speed and stability than they do today. We have supercomputers in our pockets, and we’re often shipping apps that are slower and more finicky.

But I have this dream of a world where apps aren’t needlessly power-hungry or memory-intensive, where every swipe and or click or scroll results in buttery-smooth responses. We won’t get there by saying, “You know, Facebook is doing x so that’s good enough for me.”

Of course every developer, and any given product shop or consultancy, is going to have to make decisions about which stacks it invests in. If you’re primarily shipping web applications, investing in Elixir and React with React Native for your apps is a very sensible move. Most of your clients’ native apps may not need the degree of polished performance you might get from writing their iOS app in Swift and their Android app in Kotlin and the core in Rust (or even C++). That tradeoff is a tradeoff.

But let’s remember that there is real value there, and that some apps do deserve that investment. We should evaluate the tradeoffs at every turn, and our core considerations should enduringly include speed and stability. Don’t dismiss Rust (or Swift, or F♯) out of hand.

Equally importantly, we need to stop assuming that just because something is eating the world today means it’s also the future. Betting big on Flash in the mid-2000s wasn’t a bad move by a long shot. But its massive popularity then wasn’t a good predictor for its future. That goes double, frankly, for projects coming out of Facebook or Google or similar: big companies like that have the resources to drop everything and use a new language, or a new tool, as it suits them. If you don’t believe me, look at the actual open-source records of both of those companies! What’s hot today is far more relevant to a consultancy than to a product shop. And in both cases, choosing tech suitable for the job at hand is more important yet.

My friend gets that, for what it’s worth. He’s making the right moves for his business as the owner of a consultancy. I just want him—and lots of other people—to see where languages like Rust and Swift and F♯ might be worth considering. And speed and stability matter in a lot of places besides just compilers and VMs.

I’m aware that React-Native ultimately binds down to native widgets. It’s still not quite the same.↩
or, frankly, Ember or whatever else; React is great, but it is also overhyped.↩
Swift too, and honestly for a lot of things Swift is an easier experience for not that much less performance than Rust. But as of today you can’t ship core functionality in Swift for Android or Windows.↩

Rust and Swift (xviii)

Sun, 24 Jul 2016 15:10:00 -0400

I am reading through the Swift book, and comparing it to Rust, which I have also been learning over the past few months. As with the other posts in this series, these are off-the-cuff impressions, which may be inaccurate in various ways. I’d be happy to hear feedback! Note, too, that my preferences are just that: preferences. Your tastes may differ from mine. (See all parts in the series.)

Part I: Ownership Semantics vs. Reference Counting

Perhaps unsurprisingly, the Swift book follows on from its discussion of initialization with a discussion of deinitialization, and here the differences between Rust and Swift are substantial, but (as has so often been the case) so are the analogies.

In Rust, memory is, by default, stack-allocated and -deallocated, but with a very impressive system for tracking the lifetime of that data and allowing its to be moved from one function to another. The Rust compiler tracks the ownership of every given item in the program as it is passed from one function to another, allowing other parts of the program to “borrow” the data safely, until a given piece of data goes out of scope entirely. At that point, Rust runs its destructors automatically. As part of its system for managing memory safely, Rust also tracks where and when a program attempts to access any given piece of data (whether directly or via reference), and will refuse to compile if you try to reference data in a place where it has already gone out of scope and been cleaned up (“dropped,” in Rust-speak).

If this was a bit fuzzy, don’t worry: there’s a lot to say here. It’s arguably the most distinctive feature of the language, and it’s also the main thing that tends to trip up newcomers to the language. If you’re interested in further material on the topic, my own most succinct treatment of it is in an early episode of New Rustacean, my Rust developer podcast, and the official documentation is very good. For now, suffice it to say: Rust does extremely rigorous compile-time checks to let you do C or C++-style memory management, but with absolute guarantees that you won’t have e.g. use-after-free bugs, with a default to handling everything on the stack.

It is of course impossible to handle everything on the stack, so there are heap-allocated types (e.g. vectors, a dynamically sized array-like type), which are fundamentally reference (or pointer) types. But those follow the same basic rules: Rust tracks the pointers throughout their uses, and when they go out of scope, Rust automatically tears down not only the pointer but also the data behind it. There are times, though, when you can’t comply with Rust’s normal rules for handling multiple-access to the same data. For those situations, it also supplies some “smart pointer” container types, Rc and Arc, the reference-counted (non-thread-safe) and atomically reference-counted (thread-safe) types. Both types just wrap up a type that you intend to put on the heap with reference-counters, which increment and decrement as various pieces of a program get access to them. Note that, unlike the compiler-level, compile-time checks mentioned earlier, these are run-time counts and they therefore incur a small but real runtime performance penalty. (The distinctions between the two types have to do with how they guarantee their memory safety and what kinds of a guarantees are required for cross-thread safety, and they’re important for writing Rust but not so important for this comparison, so I’ll leave them aside.¹)

In Swift, all class instances (which are pass-by-reference types) are tracked with automatic reference counting and cleaned up automatically when there are no more references to them. Don’t confuse Rust’s “atomically reference-counted” type with Swift’s “automatically reference-counted” type. Unlike Rust’s behavior in having everything checked at compile-time, reference counting is a run-time check in Swift, just as it is with the Rc and Arc types in Rust.² But it happens for all reference types all the time in Swift, not just when specified manually as in Rust. (Value types seem to be always passed by value, though the compiler has some smarts about that so it doesn’t get insanely expensive.) It’s automatic in that the compiler and runtime handle it “behind the scenes” from the developer’s perspective.

Swift’s approach here isn’t quite the same as having a full-on garbage-collected runtime like you’d see in Java, C^#, Python, Ruby, JavaScript, etc. (and so doesn’t have the performance issues those often can). But it also isn’t like Rust’s default of having no runtime cost. It’s somewhere in the middle, with a goal of very good performance but good developer ergonomics. I think it achieves that latter goal: for the most part, it means that you don’t have to think about memory allocation and deallocation explicitly. Certainly there are times when you have to think about how your program handles those issues, but neither is it right up in your face like it is in Rust,³ nor does it come with the costs of a heavier runtime (from startup, to GC pauses, to non-deterministic performance characteristics).⁴

To make it concrete, the following snippets do basically the same thing—but note that the reference counting is explicit in Rust. We’ll start with Rust, doing it the normal way:

struct WouldBeJedi {
    name: String,
    rank: u8,
    description: String,
}

impl WouldBeJedi {
    fn new(name: &str, rank: u8, description: &str) -> WouldBeJedi {
        WouldBeJedi {
            name: name.to_string(),
            rank: rank,
            description: description.to_string()
        }
    }
}

fn main() {
    let trainee = WouldBeJedi::new(
        "Zayne Carrick", 1, "not very competent, but still a great hero");

    // When calling the function, we pass it a reference, and it
    // "borrows" access to the data. But the validity of that access
    // is checked at compile time. `main()` keeps the "ownership"
    // of the data.
    describe(&trainee);

    // When `main` ends, nothing owns the data anymore, so
    // Rust cleans it up. If something were still borrowing the
    // data (say, if we'd passed a reference into another thread),
    // this would actually be a compile error, because references
    // have to be guaranteed to live as long as the thing they
    // point back to. Rust has tools for managing that, as well,
    // its "lifetimes", but we can leave them aside for this example.
}

fn describe(trainee: &WouldBeJedi) {
    // Rust checks at compile time to make sure there are no
    // mutable "borrows" of the data, and therefore knows
    // that it is safe to reference the data here, because it can
    // be *sure* nothing will change it at the same time.

    // Under the covers, this macro will actually call a
    // function with the data we pass it, so Rust actually checks
    // the ownership and borrowing state here, too. Again, all
    // at compile time, and therefore with no runtime penalty.
    println!("{} (rank {}) is {}.",
             trainee.name,
             trainee.rank,
             trainee.description);

    // When we exit the function, Rust notes that it is no
    // longer "borrowing" the data.
}

And here’s the Swift code—note as well that we use a class not a struct here:

class WouldBeJedi {
    let name: String
    let rank: UInt8
    let description: String

    init(name: String, rank: UInt8, description: String) {
        self.name = name
        self.rank = rank
        self.description = description
    }
}

func main() {
    let aTrainee = WouldBeJedi(
        name: "Zayne Carrick",
        rank: 1,
        description: "not very competent, but a great hero")

    // When calling the function, the reference count goes up
    // here, too, but it's implicit, rather than explicit.
    describe(aTrainee)

    // The implicit reference count Swift maintains for `aTrainee`
    // will go from 1 to 0 here, and Swift will do its cleanup of the
    // object data.
}

func describe(_ trainee: WouldBeJedi) {
    // When we enter this function, Swift bumps the reference
    // count, from 1 to 2. Both `main` and `describe` now have a
    // reference to the data.

    // No need for the unwrapping or any of that; Swift handles it
    // all automatically... thus the name of the technology!
    print("\(trainee.name) (rank \(trainee.rank)) is \(trainee.description).")

    // When we exit the function, Swift bumps the reference count
    // back down to 1 automatically.
}

Finally, here is the (much longer, because all the reference counting is done explicitly) reference-counted Rust version:

use std::rc::Rc;

pub struct WouldBeJedi {
    name: String,
    rank: u8,
    description: String,
}

fn main() {
    let trainee = WouldBeJedi {
        name: "Zayne Carrick".to_string(),
        rank: 1,
        description: "not very competent, but a great hero".to_string()
    };
    let wrapped_trainee = Rc::new(trainee);

    // Start by calling `clone()` to get a *reference* to the
    // trainee. This increases the reference count by one.
    let ref_trainee = wrapped_trainee.clone();
    // Then pass the reference to the `describe()` function.
    // Note that we *move* the reference to the function, so
    // once the function returns, the reference will go out
    // of scope, and the reference count will decrement.
    describe(ref_trainee);

    // When `main` ends, several things will happen in order:
    // 1. The reference count on the `wrapped_trainee` will
    //    go to zero. As a result, the `wrapped_trainee`
    //    pointer---the `Rc` type we created---will get
    //    cleaned up.
    // 2. Once `wrapped_trainee` has been cleaned up, Rust
    //    will notice that there are no more references
    //    anywhere to `trainee` and clean it up as well.
    //    (More on this below.)
}

fn describe(trainee: Rc<WouldBeJedi>) {
    // We now have a *reference* to the underlying data, and
    // therefore can freely access the underlying data.
    println!("{} (rank {}) is {}.",
             trainee.name,
             trainee.rank,
             trainee.description);


    // When we exit the function, Rust destroys this *owned*
    // clone of the reference, and that bumps the reference
    // count back down to 1 automatically.
}

Note that if we strip out all the explanatory comments and details, the normal versions of the Rust and Swift code are pretty similar.

Rust—

struct WouldBeJedi {
    name: String,
    rank: u8,
    description: String,
}

impl WouldBeJedi {
    fn new(name: &str, rank: u8, description: &str) -> WouldBeJedi {
        WouldBeJedi {
            name: name.to_string(),
            rank: rank,
            description: description.to_string()
        }
    }
}

fn main() {
    let trainee = WouldBeJedi::new(
        "Zayne Carrick",
        1,
        "not very competent, but still a great hero");

    describe(&trainee);
}

fn describe(trainee: &WouldBeJedi) {
    println!("{} (rank {}) is {}.",
             trainee.name,
             trainee.rank,
             trainee.description);
}

Swift (as usual, is slightly briefer than Rust)—

class WouldBeJedi {
    let name: String
    let rank: UInt8
    let description: String

    init(name: String, rank: UInt8, description: String) {
        self.name = name
        self.rank = rank
        self.description = description
    }
}

func main() {
    let aTrainee = WouldBeJedi(
        name: "Zayne Carrick",
        rank: 1,
        description: "not very competent, but a great hero")

    describe(aTrainee)
}

func describe(_ trainee: WouldBeJedi) {
    print("\(trainee.name) (rank \(trainee.rank)) is \(trainee.description).")
}

Note that in both of these implementations, all the actual cleanup of the memory is handled behind the scenes—this feels much more like writing Python than writing C, especially for complex data types. Not least because this same kind of nice cleanup can happen for complex, heap-allocated types like dynamically-sized vectors/arrays, etc. Both languages just manage it automatically. (The same is true of modern C++, for the most part, but it has a more complicated story there because of its relationship with C, where malloc and free and friends run rampant and are quite necessary for writing a lot of kinds of code.) Most of the time, when you’re done using data, you just stop using it, and both Rust and Swift will clean it up for you. The feel of using either language is fairly similar, though the underlying semantics are quite different.

Part 2: Deconstruction/Deinitialization

Both Rust and Swift recognize that, the ordinary case notwithstanding, there are many times when you do need to run some cleanup as part of tearing down an object. For example, if you had an open database connection attached to an object, you should return it to the collection pool before finishing tear-down of the object.

In Rust, this is accomplished by implementing the Drop trait and supplying the requisite drop method. Imagine we had defined a Jedi type, with a bunch of details about the Jedi’s lightsaber (including whether the Jedi even has a lightsaber. We know from the Star Wars movies that lightsabers turn off automatically when the Jedi dies, or even just drops it for that matter. We can implement all of this in Rust using just the Drop trait. Here’s a pretty full example.⁵ (Note that both of these implementations draw heavily on material I covered in previous posts.)

#[derive(Debug)]
enum Color {
    Red,
    Blue,
    Green,
    Purple,
    Yellow
}

enum SaberState {
    On,
    Off,
}

struct Lightsaber {
    color: Color,
    blades: u8,
    state: SaberState
}

impl Lightsaber {
    pub fn new(color: Color, blades: u8) -> Lightsaber {
        if blades > 2 {
            panic!("That's just silly. Looking at you, Kylo.");
        }

        Lightsaber { color: color, blades: blades, state: SaberState::Off }
    }

    pub fn on(&mut self) {
        self.state = SaberState::On;
    }

    pub fn off(&mut self) {
        self.state = SaberState::Off;
    }
}

struct WouldBeJedi {
    name: String,
    lightsaber: Option<Lightsaber>,
}

impl WouldBeJedi {
    pub fn new(name: &str, lightsaber: Option<Lightsaber>) -> WouldBeJedi {
        WouldBeJedi { name: name.to_string(), lightsaber: lightsaber }
    }

    pub fn describe(&self) {
        let lightsaber = match self.lightsaber {
            Some(ref saber) =>
                format!("a {:?} lightsaber with {:} blades.", saber.color, saber.blades),
            None => "no lightsaber.".to_string()
        };

        println!("{} has {}", self.name, lightsaber)
    }
}

// Here's the actually important bit.
impl Drop for WouldBeJedi {
    fn drop(&mut self) {
        if let Some(ref mut lightsaber) = self.lightsaber {
            lightsaber.off();
        }
    }
}


fn main() {
    let saber = Lightsaber::new(Color::Yellow, 1);
    let a_jedi = WouldBeJedi::new("Zayne Carrick", Some(saber));
    a_jedi.describe();
}

We can do much the same in Swift, using its deinitializers, which are fairly analogous to (but much simpler than) its initializers, and fulfill the same role as Rust’s Drop trait and drop() method.

enum Color {
    case red, blue, green, purple, yellow
}

enum SaberState {
    case on, off
}

struct Lightsaber {
    let color: Color
    let blades: UInt8
    var state: SaberState = .off

    init?(color: Color, blades: UInt8) {
        if blades > 2 {
            print("That's just silly. Looking at you, Kylo.")
            return nil
        }

        self.color = color
        self.blades = blades
    }

    mutating func on() {
        state = .on
    }

    mutating func off() {
        state = .off
    }
}

class WouldBeJedi {
    let name: String
    var lightsaber: Lightsaber?

    init(name: String, lightsaber: Lightsaber?) {
        self.name = name
        self.lightsaber = lightsaber
    }

    deinit {
        self.lightsaber?.off()
    }

    func describe() {
        let saberDescription: String
        if let saber = self.lightsaber {
            saberDescription = "a \(saber.color) lightsaber with \(saber.blades) blades."
        } else {
            saberDescription = "no lightsaber."
        }

        print("\(name) has \(saberDescription)")
    }
}

func main() {
    let saber = Lightsaber(color: .yellow, blades: 1)
    let aJedi = WouldBeJedi(name: "Zayne Carrick", lightsaber: saber)
    aJedi.describe();
}

This is a bit briefer, but that’s mostly down to Swift’s shorthand for optionals (the ? operator), which we’ll get to in a future post.

Curiously, struct and enum types cannot have deinitializers in Swift. I expect this has something to do with their being value types rather than reference types, but the book offers no comment. (If a reader knows the answer, I’d welcome clarification.)

Much as in the discussion of of initializers, the usual patterns with Rust and Swift’s approach come into play. Rust opts to build the pattern on the same basic language machinery (traits). Swift uses a bit of syntactical sugar dedicated to the purpose. It’s undeniable that the Swift is a bit briefer.

However, there are a couple upsides to Rust’s approach. First, it is applicable on all types, where Swift’s applies only to classes. Second, there is no additional syntax to remember. Drop is just a trait like any other, and drop a method like any other. Third, then, this means that you can run it explicitly elsewhere if you need to, and as a result you can define whatever kind of custom deconstruction behavior you might need. If we’d created a_jedi above in Rust, we could simply write a_jedi.drop() anywhere:

fn prove_incompetent(a_jedi: WouldBeJedi) {
    // make some series of grievous mistakes which mean
    // you're no longer able to be a Jedi and as such,
    // among other things, lose your lightsaber...
    a_jedi.drop();
    // other stuff
}

Or (going a bit more abstract) we could define a daring_derring_do() method which called drop() itself:

impl WouldBeJedi {
    pub fn daring_derring_do(self) {
        // do some other operation, like freeing slaves from
        // a secret colony of slavers. But if it fails...
        self.drop();
    }
}

Or, really, define any behavior which culminated in a drop() call. That’s extremely powerful, and it’s the upside that comes with its just being a trait whose behavior we have to define ourselves.

That takes us back to one of the fundamental differences in design between the two languages. Rust goes out of its way to leave power in the hands of the user, at the cost of requiring the user to be a bit more explicit. Swift prioritizes brevity and productivity, but it gets there by taking some of the power out of the hands of the developer. Neither of these is wrong, per se. They’re just aiming for (and in this case, I think, fairly successfully landing in) somewhat different spots on a spectrum of tradeoffs.

Previous: More on initializers!

I did, however, cover them quite recently on my podcast. Yes, this is another shameless plug.↩
Mostly, anyway. I believe the Swift compiler also does some degree of static analysis similar to that done by Rust—though to a much lesser extent and, speaking purely descriptively, much less rigorously (it just has different goals). Swift then uses that analysis to handle things at compile time rather than via reference counts if it’s able to determine that it can do so.↩
We could, if we so desired, get this same basic behavior in Rust. We can easily imagine a world in which every type was automatically wrapped in Rc or Arc, and in fact, I’d be very interested to see just such a language—something which was only a thin layer over Rust, keeping all its semantics but wrapping some or all non-stack-allocated types in Rc or Arc as appropriate. (Something like this, but done behind the scenes rather than manually opted into.) You’d incur some performance coasts, but with the benefit that you’d have an extremely ergonomic, practical, ML-descended language quite appropriate for slightly higher-level tasks, and without the radical shift required by switching to a lazily-evaluated, purely functional language like Haskell.↩
Notably, those tradeoffs are often entirely worth it, and high-performance VMs have astoundingly good characteristics in many ways. The JVM, the CLR, and all the JavaScript VMs have astonishingly excellent performance at this point.↩
I might have gotten slightly carried away in the details here. I’m just a little bit of a nerd.↩

Rust and Swift (xvii)

Thu, 30 Jun 2016 23:00:00 -0400

In the last part, I talked through the first chunk of the Swift book’s material on initializers. But it’s a long section, and I definitely didn’t cover everything. (I also got a few bits incorrect, and thankfully got great feedback to tighten it up from Twitter, so if you read it right after I posted it, you might skim back through and find the places where I added “Edit: …”)

Picking up from where we left on, then. Swift has a number of further initializer types, some of which map rather directly to the way initializers work in Rust, and some of which have no direct analog at all.

In the first category are the memberwise initializers Swift supplies by default for all types. The most basic init method just uses the names of the members of any given struct or class type in Swift (as in the previous section, I’m going to use the types the Swift book uses for simplicity):

struct Size {
    var height = 0.0, width = 0.0
}

someSize = Size(height: 1.0, width: 2.0)

This actually looks almost exactly like the normal way we construct types in Rust, where the same basic pattern would look like this:

struct Size {
    height: f64,
    width: f64,
}

some_size = Size { height: 1.0, width: 2.0 }

There are two big differences between the languages here. The first, and most immediately apparent, is syntactical: in this case, Rust doesn’t have a function-call syntax for creating instances, and Swift does. Swift’s syntax is similar to one of the several C++ constructor patterns, or especially to Python’s initializer calls (if we made a point to be explicit about the keyword arguments):

class Size:
    height = 0.0
    width = 0.0
    def __init__(height, width):
        self.height = height
        self.width = width

someSize = Size(height=1.0, width=2.0)  # unnecessarily explicit

The second, and more significant, is that the default, memberwise initializer in in Swift is only available if you have not defined any other initializers. This is very, very different from Rust, where there’s not really any such thing as a dedicated initializer—just methods. If we defined Size::new or Size::default or Size::any_other_funky_initializer, it wouldn’t make a whit of difference in our ability to define the type this way.¹ However, and this is important: because Rust has field-level public vs. private considerations, we cannot always do memberwise initialization of any given struct type there, either; it is just that the reasons are different. So:²

mod Shapes {
    struct Rectangle {
        pub height: f64,
        pub width: f64,
        area: f64,
    }
}

fn main() {
    // This won't work: we haven't constructed `Size::area`, and as we noted
    // last time, you cannot partially initialize a struct.
    let some_size = Shapes::Size { height: 1.0, width: 2.0 };

    // But neither will this, because `area` isn't public:
    let some_other_size = Shapes::Size { height: 1.0, width: 2.0, area: 2.0 };
}

Swift lets you refer to other initializers on the same type (reinforcing that init() is basically a kind of method, albeit one with some special rules and some special sugar). You do that by calling self.init(), and—very importantly—you can only call it from within another initializer. No funky reinitializations or anything like that. The net result is that if you have a couple different variations on ways you might initialize a type, you still get the benefit of reusability; you don’t have to reimplement the same initialization function over and over again. Do whatever additional setup is required in any given instance, and then call a common base initializer.

With Rust, again, we just have methods, so you could of course call them wherever you like. However, those methods are distinguished as being type-level or instance-level methods by their signatures, rather than by keyword. If the first argument is (some variant on) self, it’s an instance method, otherwise, a type-level method. This eliminates any potential confusion around the initializers:

struct Foo {
    pub a: i32
}

impl Foo {
    pub fn new(a: i32) -> Foo {
        Foo { a: a }
    }

    pub fn bar(&self) {
        // yes:
        let another_foo = Foo::new();
        // no (won't even compile):
        // let self_foo = self.new();
    }
}

You can (of course!) build up a type through multiple layers of methods which are useful to compose an instance together. This is what the builder pattern is all about. There are definitely times when you want to be able to tweak how your initialization plays out, and being able to do that without just passing in some hairy set of options in a special data type is nice.

One other important qualification on the Swift initializers: those default, memberwise constructors you get for free? You only get them for free if you don’t define your own initializers. (The closest analogy to this in Rust is that you’ll have issues if you try to both #[derive(Default)] and impl Default for Foo, since both will give you an implementation of Foo::default().) You can get around this in Swift by using an extension. We’ll come back to that in a future post.³ You can also get around it by supplying a parameter-less, body-less initializer in addition to any other initializers you supply, so: init() {}. (This, frankly, seems like a hack to me. It’s a useful hack, given the other constraints, but these kinds of things pile up.) Similarly, you can just reimplement member-wise initializers yourself if you have a reason to (say, if you’ve implemented any others and therefore the defaults no longer exist).

Now things take a turn into Swift-only territory again as we look at initialization in the context of inheritance. (As mentioned last time: Rust will eventually get inheritance-like behavior, but it’s coming much later, and is not going to be exactly like classical inheritance. Rust strongly favors composition over inheritance, where Swift lightly does but still supports the latter.)

Swift has two kinds of initializers for class initializers. One, a designated initializer, is required; a designated initializer must fully initialize every property on a class, and call the superclass initializer (assuming there is one). These can be inherited, but again: they are required.

There are also convenience initializers, which provide variant APIs for setting up any given class. These (by definition, given what we said a moment ago) must call a designated initializer along the way. These could be useful in a lot of different scenarios: setting up variants on the class (as in our temperature examples from before), doing alternate setup depending on initial conditions, etc.

The only difference between the two syntactically is that convenience initializers get the convenience keyword in front of the init declaration, so:

class Foo {
    var bar : Int
    let quux: String
    // designated
    init(_ bar: Int, _ quux: String) {
        self.bar = bar
        self.quux = quux
    }

    // A convenience method which only takes the string.
    convenience init(_ quux: String) {
        self.init(0, quux)
    }
}

The Swift book gives a set of rules about how these delegated and convenience initializers must behave. The short version is that convenience initializers (eventually) have to call a delegated initializer from their own class, and designated initializers have to call a designated initializer from the superclass. This is an implementation detail, though: from the perspective of a user of the class, it doesn’t matter which initializer is called.

The other important bit about Swift class initialization is that it is a two-phase process, which you might think of as “primary initialization” and “customization.” The primary initialization sets up the properties on a class as defined by the class which introduced them. The following sample should illustrate how it plays out:

class Foo {
    let plainTruth = "Doug Adams was good at what he did."
    let answer = 0

    init() {
        baz = answer / 2
    }
}

// Bar inherits from Foo
class Bar: Foo {
    let question = "What is the meaning of life, the universe, and everything?"
    let answer = 42

    init() {
        super.init()  // calls Foo.init()
    }

    convenience init(newQuestion question: String, newAnswer answer: Int) {
        self.question = question
        self.answer = answer
        self.init()  // calls own `init()`
    }
}

When building a Bar via either the designated or convenience initializer, plainTruth and answer will be set up from Foo, then question will be set and answer will be reassigned in Bar. If the convenience initializer is used, then it will also override those new defaults with the arguments passed by the caller, before running the designated initializer, which will in turn call the superclass designated initializer. The machinery all makes good sense; I appreciate that there are no weird edge cases in the initialization rules here. (There are a bunch of special rules about which initializers get inherited; I’m just going to leave those aside at this point as they’re entirely irrelevant for a comparison between the languages. We’re already pretty far off into the weeds here.)

Obviously, none of this remotely applies to Rust at all. Not having inheritance does keep these things simpler (though of course it also means there’s a tool missing from your toolbox which you might miss). And of course, the rules around method resolution are not totally trivial there, especially now that impl specialization is making its way into the language. But those don’t strictly speaking, affect initialization.

To account for the case that initialization can fail, Swift lets you definite failable initializers, written like init?(). Calling such an initializer produces an optional. You trigger the nil valued optional state by writing return nil at some point in the body of the initializer. Quoting from the Swift book, though, “Strictly speaking, initializers do not return a value…. Although you write return nil tro trigger an initialization failure, you do not use the return keyword to indicate initialization success.” These failable initializers get the same overall behavior and treatment as normal initializers in terms of delegating to other initializers within the same class, and inheriting them from superclasses.

class Foo {
    let bar: Int
    init?(succeed: Bool) {
        if !succeed {
            return nil
        }

        bar = 42
    }
}

let foo = Foo(true)
print("\(foo?.bar)")  // 42
let quux = Foo(false)
Print("\(foo?.bar)")  // nil

This is another of the places where Swift’s choice to treat initialization as a special case, not just another kind of method, ends up having some weird side effects. If init calls were methods, they would always just be returning the type. This is exactly what we see in Rust, of course. To be clear, there are reasons why the Swift team made that choice, and many of them we’ve already touched on incidentally; the long and short of it is that inheritance adds some wrinkles. These aren’t constructors, they’re initializers. The point, per the Swift book, is “to ensure that self is fully and correctly initializer by the time that initialization ends.” If you’re familiar with Python, you can think of Swift initializers as being quite analogous to __init__(self) methods, which similarly are responsible for initialization but not construction. When we build a type in Rust, by contrast, we’re doing something much more like calling Python __new__(cls) methods, which do construct the type.

Edit: interestingly, I’m informed via Twitter that Swift initializers can also throw errors. (Thanks, Austin!) The Swift book doesn’t mention this because it hasn’t gotten to error-handling yet (and so, neither have we).⁴

You can of course write failable constructors in Rust, too:

struct Foo {
    bar: i64,
};

impl Foo {
    pub fn optional_new(succeed: bool) -> Option<Foo> {
        if succeed { Some(Foo { bar: 0 }) }
        else { None }
    }
}

let foo = Foo::optional_new(true);
match foo {
    Some(f) => println!("{}", f.bar),
    None => println!("None"),
};

There are conditions in both languages where you’d want to do this: places where an initialization can fail, e.g. trying to open a file, or open a websocket, or anything where the type represents something that is not guaranteed to return a valid result. It makes sense then that in both cases, returning an optional value is the outcome. Of course, Rust can equally well have an initializer return a Result<T, E>:

struct Waffles {
    syrup: bool,
    butter: bool,
}

impl Waffles {
    fn properly(all_supplies: bool) -> Result<Waffles, String> {
        if all_supplies {
            Ok(Waffles { syrup: true, butter: true } )
        }
        else {
            let msg = "Who makes waffles this way???";
            Err(msg.to_string())
        }
    }
}

let waffles = Waffles::properly(true);
match waffles {
    Ok(_) => println!("Got some waffles, yeah!"),
    Err(s) => println!("{:}", s),
};

This is simply not the kind of thing you can do in Swift, as far as I can tell. The upside to Swift’s approach is that there is one, standard path. The downside is that if you have a scenario where it makes sense to return an error—i.e., to indicate why a class failed to initialize and not merely that it failed—you’re going to have to jump through many more hoops.⁵ Edit: See above; Swift can do this. Moreover, the underlying semantics aren’t especially different from Rust’s. However, it does introduce yet more syntax, rather than just being a normal return. But we’ll talk about that in more detail when we get to error-handling.⁴ The downside for Rust is that there’s no shorthand; everything is explicit. The upside is the flexibility to do as makes the most sense in a given context, including defining whatever types you need and returning them as you see fit. If you need a type like PartialSuccessPossible<C, P, E> where C is a complete type, P a partial type, and E an error, you can do that. (I’m not saying that’s a good idea, for the record.) That in turn flows out of building even higher level language features on lower-level features and not introducing new syntax for the most part. Trade-offs!

And with that, we’re done talking about initializers. This was a huge topic—but it makes sense. If you don’t nail this down carefully, you’ll be in for a world of hurt later, and that goes whether you’re designing a language or just using it to build things.

Previous: Initialization: another area where Swift has a lot more going on than Rust.
[**Next: Deinitialization: ownership semantics and automatic reference counting][18]

Also recall that in Rust, we would set the default values either by using the #[derive(Default)] annotation or by implementing the Default trait ourselves.↩
I’m including a module because of a quirk around the public/private rules: within the same module, area isn’t hidden and you can actually go ahead and initialize the object.↩
Depending on how you think about extensions, either Rust doesn’t have anything quite like them… or every type implementation is just an extension, because impl allows you to extend any data type in basically arbitrary ways (a few caveats of course). More on all of this when we get there.↩

Here’s a preview of what that would look like, though (fair warning, there’s a lot going on here we haven’t talked about!):

enum Setup {
    case succeed
    case error
    case fail
}

enum BarSetupError: ErrorProtocol {
    case argh
}

class Bar {
    let blah: Int
    init?(setup: Setup) throws {
        switch setup {
        case .succeed:
            blah = 42
        case .error:
            throw BarSetupError.argh
        case .fail:
            return nil
        }
    }
}

do {
    let bar = try Bar(setup: .succeed)
    print("\(bar!.blah)")

    let baz = try Bar(setup: .fail)
    print("\(baz?.blah)")

    let quux = try Bar(setup: .error)
    print("\(quux?.blah)")
} catch BarSetupError.argh {
    print("Oh teh noes!")
}

The output from this would be 42, nil, and Oh teh noes!.↩

~~It’s conceivable this is actually possible, but nothing in The Swift Programming Language even hints at it, if so.~~ See above!↩

Vectors and Iterator Access in Rust

Thu, 16 Jun 2016 20:59:00 -0400

In the midst of doing my reading and research for New Rustacean episode 15 (which will be out fairly soon after I post this), I bumped into this little tidbit. It doesn’t fit in the episode, so I thought I’d share it here.

When you’re dealing with vectors in Rust, a common misstep when working with them via iterators is to move them when you only to borrow them. If you write for i in x where x is an iterator, you’ll move the iterator into the looping construct. Instead, you should nearly always write for i in &x to borrow a reference to the iterator, or for i in &mut x if you need to get a mutable reference to it.

Rust and Swift (xvi)

Tue, 07 Jun 2016 23:30:00 -0400

Thanks to ubsan, aatch, and niconii on the #rust-lang IRC for a fascinating discussion of the current status of Rust’s initialization analysis, as well as some very interesting comments on what might be possible to do in the future. Everything actually interesting about Rust in this post comes from the conversation I had with them on the evening of March 13.

The rules various languages have around construction and destruction of objects are extremely important for programmer safety and ergonomics. I think it’s fair to say that both Swift and rust are actively trying to avoid some of the mistakes made in e.g. C++ which poorly affect both its safety and its ease of use for developers, albeit it in some superficially different ways. Both languages also support defining how types are destroyed, which we’ll come back to in a future discussion.

The basic aim both Rust and Swift have in this area seems to be the same: avoid partially initialized objects. (You don’t want partially initialized objects. Ask Objective C developers.)

Swift does this via its rules around initializers. Rust does it by requiring that all the values of a type be initialized at its creation. So, for example, the following looks like it should work, but it doesn’t. You can initialize the variable piecemeal, but you cannot use it:

#[derive(Debug)]  // to make it printable.
struct Foo {
    pub a: i32,
    pub b: f64,
}

fn main() {
    // This will compile, but `foo` will be useless.
    let mut foo: Foo;
    foo.a = 14;
    foo.b = 42.0;

    // This would actually fail to compile. Surprising? A bit!
    // println!("{:?}", foo);

    // This will work, though, because it fully constructs the type.
    let foo2 = Foo { a: 14, b: 42.0 };
    println!("{:?}", foo);
}

(The reasons why this is so are fairly complicated. See the addendum at the end for a brief discussion.)

In any case, this means that especially with more complex data types, providing standard constructor-style methods like new or default is conventional and helpful. (If the type has non-public members, it’s also strictly necessary.)

Swift has a number of options for initializers, which correspond to things you in most cases can do in Rust, but in a very different way.

First, Swift allows you to overload the init method on a type, so that you can have different constructors for different starting conditions. (This is, to my recollection, the first time any kind of overloading has come up so far in the Swift book—but that could just be my memory failing me. Certainly I haven’t referenced it in any previous discussion, though.)

The example offered by the Swift book is illuminating for the different approaches the languages take, so we’ll run with it. Here’s a class defining a Celsius type in Swift:

struct Celsius {
    let temp: Double

    init(fromFahrenheit f: Double) {
       temp = 1.8 * (f - 32.0)
    }

    init(fromKelvin k: Double) {
        temp = k - 273.15
    }
}

// Create an instance each way
let freezing = Celsius(temp: 0)
let balmy = Celsius(fromFahrenheit: 75.0)
let absoluteZero = Celsius(fromKelvin: 0.0)

Note the internal and external parameter names. This is a common idiom Swift keeps (albeit with some non-trivial modification, and with more to come). More on this below; first, the same basic functionality in Rust:

struct Celsius {
    temp: f64
}

impl Celsius {
    fn from_fahrenheit(f: f64) -> Celsius {
        Celsius { temp: 1.8 * (f - 32.0) }
    }

    fn from_kelvin(k: f64) -> Celsius {
        Celsius { temp: k - 273.15 }
    }
}

// Create an instance each way
let freezing = Celsius { temp: 0 };
let balmy = Celsius::from_fahrenheit(75.0);
let absoluteZero = Celsius::from_kelvin(0.0);

(Note that there might be other considerations in implementing such types, like using a Temperature base trait or protocol, or employing type aliases, but those are for later entries!)

You can see a point I made about Swift’s initializer syntax back in part x: the way Rust reuses normal struct methods while Swift has the special initializers. Neither is clearly the “winner” here. Rust gets to use existing language machinery, simplifying our mental model a bit by not adding more syntax. On the other hand, the addition of initializer syntax lets Swift use a fairly familiar type construction syntax even for special initializer cases, and a leaves us with a bit less noise in the constructor method. Note, though, that initializers in Swift are special syntax; they’re not just a special kind of method (as the absence of the func keyword emphasizes)—unlike Rust, where initializers really are just normal struct or instance methods.

The Swift book notes this distinction:

In its simplest form, an initializer is like an instance method with no parameters, written using the init keyword.

The new keyword is the thing I could do without. Perhaps it’s just years of writing Python, but I really prefer it when constructors for types are just sugar and you can therefore reimplement them yourself, provide custom variations, etc. as it suits you. Introducing syntax instead of just picking a standard function to call at object instantiation means you lose that. At the same time, and in Swift’s defense, I’ve only rarely wanted or needed to use those facilities in work in Python. It’s a pragmatic decision—and it makes sense as such; it’s just not where my preference lies. The cost is a bit higher than I’d prefer relative to the gain in convenience.

Back to the initializers and the issue of overloading: the external parameter names (the first parameter) is one of the main ways Swift tells apart the initializers. This is necessitated, of course, by the choice of a keyword for the initializer; Rust doesn’t have any need for this, and since Rust doesn’t have overloading, it also can’t do this. In Rust, different constructors/initializers will have different names, because they will simply be different methods.

[Edit: I’m leaving this here for posterity, but it’s incomplete. See below.] One other important thing falls out of this: the external parameter names are required when initializing a type in Swift. Because those parameter names are used to tell apart the constructor, this is not just necessary for the compiler. It’s also an essential element of making the item readable for humans. Imagine if this were not the case—look again at the Celsius example:

struct Celsius {
    let temp: Double

    init(fromFahrenheit f: Double) {
       temp = 1.8 * (f - 32.0)
    }

    init(fromKelvin k: Double) {
        temp = k - 273.15
    }
}

// Create an instance each way
let freezing = Celsius(0)
let balmy = Celsius(75.0)  // our old fromFahrenheit example
let absoluteZero = Celsius(0.0)  // our old "fromKelvin example

We as humans would have no idea what the constructors are supposed to do, and really at this point there would necessarily just be one constructor unless the later options took elements of another type. That would be fairly similar to how overloading works in C++, Java, or C^♯, and while method overloading in those langauges is very powerful, it can also make it incredibly difficult to figure out exactly what method is being called. That includes when the constructor is being called. Take a look at the long list of C^♯ DateTime constructors, for example: you have to either have this memorized, have the documentation open, or be able simply to infer from context what is going on.

Given the choice of a keyword to mark initializers, then, Swift’s rule about external parameter name usage wherever there is more than one initializer is quite sensible.

[Edit: several readers, most notably including Joe Groff, who works on Swift for Apple, pointed out that Swift does support overloading, including in init() calls, and uses types to distinguish them. Moreover, you can leave off the label for the parameter. My initial summary was simply incorrect. I think this is a function of my not having finished the chapter yet.]

Second, both languages support supplying default values for a constructed type. Swift does this via default values defined at the site of the property definition itself, or simply set directly from within an initializer:

struct Kelvin {
    var temp: Double = 0.0  // zero kinetic energy!!!
    init () {
        temp = 305.0  // Change of plans: maybe just freezing is better
    }
}

In Rust, you can not supply default values directly on a property, but you can define any number of custom constructors:

struct Kelvin {
    temp: f64,
}

impl Kelvin {
    fn abs_zero() -> Kelvin {
        Kelvin { temp: 0.0 }
    }

    fn freezing() -> Kelvin {
        Kelvin { temp: 305.0 }
    }
}

We could of course shorten each of those two one line, so:

fn abs_zero() -> Kelvin { Kelvin { temp: 0.0 } }

The Rust is definitely a little noisier, and that is the downside of this tack. The upside is that these are just functions like any other. This is, in short, exactly the usual trade off we see in the languages.

Rust also has the Default trait and the #[derive(default)] attribute for getting some basic defaults for a given value. You can either define a Default implementation yourself, or let Rust automatically do so if the underlying types have Default implemented:

struct Kelvin {
    temp: f64,
}

// Do it ourselves
impl Default for Kelvin {
    fn default() -> Kelvin {
        Kelvin { temp: 305.0 }
    }
}

// Let Rust do it for us: calling `Celsius::default()` will get us a default
// temp of 0.0, since that's what `f64::default()` returns.
#[derive(default)]
struct Celsius {
    temp: f64,
}

This doesn’t get you quite the same thing as Swift’s initializer values. It requires you to be slightly more explicit, but the tradeoff is that you also get a bit more control and flexibility.

There’s actually a lot more to say about initializers—there are many more pages in the Swift book about them—but this is already about 1,700 words long, and I’ve been slowly chipping away at it since March (!), so I’m going to split this chapter of the Swift book into multiple posts. More to come shortly!

Addendum: No Late Initialization in Rust

Returning to the first Rust example—

#[derive(Debug)]  // to make it printable.
struct Foo {
    pub a: i32,
    pub b: f64,
}

fn main() {
    // This will compmile, but `foo` will be useless.
    let mut foo: Foo;
    foo.a = 14;
    foo.b = 42.0;

    // This would actually fail to compile. Surprising? A bit!
    // println!("{:?}", foo);
}

You can’t do anything with that data for a few reasons (most of this discussion coming from ubsan, aatch, and niconii on the #rust-lang IRC back in March):

Rust lets you “move” data out of a struct on a per-field basis. (Rust’s concept of “ownership” and “borrowing” is something we haven’t discussed a lot so far in this series; my podcast episode about it is probably a good starting point.) The main takeaway here is that you could return foo.a distinctly from returning foo, and doing so would hand that data over while running the foo destructor mechanism. Likewise, you could pass foo.b to the function created by the println! macro
Rust allows you to re-initialize moved variables. I haven’t dug enough to have an idea of what that would look like in practice.
Rust treats uninitialized variables the same as moved-from variables. This seems to be closely related to reason #2. The same “I’m not sure how to elaborate” qualification applies here.

I’ll see if I can add some further comments on (2) and (3) as I hit the later points in the Swift initialization chapter.

Rust and C++ function definitions

Fri, 03 Jun 2016 18:01:00 -0400

I just put my finger on one of the (many) reasons Rust reads better than C++: the visual consistency of its function definitions. Compare—

Rust has:

fn foo() -> i32 { /* implementation */ }
fn bar() -> f32 { /* implementation */ }

C++ has:

int foo() { /* implementation */ }
double bar() { /* implementation */ }

That consistency adds up over many lines of code. There are many other such choices; the net effect is that Rust is much more pleasant to read than C++.

Note: I’m aware that C++11 added the auto foo() -> <type> syntax. But this actually worsens the problem. A totally new codebase which uses that form exclusively (which may not always be possible, because the semantics aren’t the same) would have roughly the same visual consistency as Rust in that particular category. (Plenty of others would still be a mess.) But the vast majority of C++ codebases are not totally new. Adding the form means your codebase is more likely to look this this:

int foo() { /* implementation */ }
auto quux() -> uint32_t { /* implementation */ }
double bar() { /* implementation */ }

That is, for the record, more visual inconsistency—not less!

Ember.js: "Introducing Subteams"

Tue, 24 May 2016 19:10:00 -0400

In which one tech I really like (Ember.js) steals a great idea from another tech I really like (Rust).

Rust and Swift (xv)

Sat, 12 Mar 2016 14:45:00 -0500

The next chapter in the Swift book focuses on inheritance, a concept which does not yet exist in Rust.

Swift embraces classical inheritance for class data types. As noted previously, Rust’s struct covers much of the ground covered by Swift’s struct and class types together (value and reference types, etc.). However, what Swift’s class types bring to the table is inheritance-based (and not just composition-based) extension of types.

This is a bit of an interesting point: it is an area where, as of today, Swift can do something that is flat impossible in Rust—a rarity.

However, the status quo will be changing sometime in the next year or so, as there is a Rust RFC which has been accepted and is in the process of being implemented which paves the way for inheritance. (Discussions are ongoing as to the best way to implement it for Rust. Classical inheritance with vtables as in Swift is probably not going to be the approach.)

The reason Rust’s core team chose to proceed without inheritance for the 1.0 release of the language last May is simple: at a philosophical level, they prefer (as in general most developers increasingly acknowledge that we should all prefer) composition over inheritance. Prefer, not universally choose, because there are situations in which inheritance is the correct choice. But there is a reason that programming with interfaces rather than via sub-classing is a “best practice” for many scenarios in languages like Java or C#.

Rust’s trait system gives you composition in some remarkably powerful ways, allowing you to do things that in C++, for example, have to be accomplished via a combination of inheritance and overloading. Swift, likewise, supplies a protocol system and allows extensions to define further behavior on top of existing data structures. From what I’ve gathered, those approaches are preferred over inheritance in Swift for the same reason Rust shipped 1.0 without it!

But Swift does have inheritance, so it’s worth seeing how it works.

First, any class which doesn’t declare a parent from which to inherit is a base class. This is an important difference from, say, Python, where all classes inherit from Object (leaving aside custom metaclasses).

The syntax choices Swift has made around sub-class declarations are sensible and readable: class SubClass: ParentClass is eminently readable and doesn’t have any obvious points of overlap with other elements in the language.

Indeed, many of the choices made around classes are quite sensible. Overrides, for example, are made explicit via the override keyword. While I’ve sometimes poked fun at Swift’s tendency to add keywords everywhere, this seems like a reasonable place to have one, and it’s nice that overrides are explicit rather than implicit. The same is true of the use of super to refer to the superclass. I’m not sure of the implementation details, but super appears to act as just a special/reserved name for an object: all the syntax around it is normal object instance syntax, which is as it should be.

The limitations around overriding properties all make sense. You can override a read- or write-only parent property as both readable and writable, but you can’t override a readable or writable property not to be readable or writable respectively. Presumably this is because the method lookup for properties always checks up the inheritance chain for getters or setters, so if one is present, you can’t just get rid of it. (You could of course override with a no-op function that spews a warning or some such, but that would pretty clearly be an abuse of the parent API. There might be times you would do that with a third-party library parent class, but in your own code it should be avoided: it indicates a problem in your API design that you need to address instead.)

Finally, we have Swift’s final keyword—and yes, pun intended. It marks whatever block-level item it is attached to—whether class, method, or property—as non-overridable. Attempts to override an item marked final are compile-time failures. (The same kind of thing exists in Java and C#.) In and of itself, this isn’t especially interesting. It is interesting to ponder whether you should make classes subclass-able or not in your API design. There has been an active debate, in fact, whether classes in Swift should become final by default in Swift 3.0, rather than open by default. The debate centers on the danger of unintended consequences of overriding, which ultimately takes us back around to the preference for composition, of course.

All of this, among other things, raises the very interesting question of what this will look like in Rust when, eventually, we get inheritance there. After all, we know it will be quite different in some ways:

It presumably won’t involve a distinct data type constructor, a la Swift’s distinction between struct and class: there may be syntactic sugar involved, and there will definitely be new functionality present, but it will certainly be built on the existing language features as well. There’s a good chance it will basically look like just a special case of impl SomeTrait for SomeStruct, which would fit very well with the ways Rust solves so many other problems.
Rust doesn’t have many of the things which Swift takes care to special-case for overriding with final, but it will need to address that case for inherited methods and data in some way. (The proposal linked above uses a distinction between default and blanket implementations for trait specialization to pull this off; if those words don’t mean anything to you, don’t worry: I’ve read that post and RFC half a dozen times before I got a really solid handle on all the pieces involved.)
It will be a relative latecomer to the language, rather than baked in from the start, and therefore will likely seem a secondary way of solving problems, especially at first. (This is, I think, both intentional and good.)

Rust and Swift (xiv)

Thu, 10 Mar 2016 21:25:00 -0500

Rust and Swift both support defining subscript access to a given data type, like SomeType[accessedByIndex]. Unsurprisingly, given everything we’ve seen so far, Rust does this with traits, and Swift with a keyword.

In Rust, you can define subscript-style access to a type by implementing the Index and/or IndexMut traits, which allow indexing into a given location in a kind of type. The implementation simply requires one function, which is called when you use the [] operator. That function, index or index_mut, implements how to do the lookup for the specific type. The impl block indicates not only that Index or IndexMut is being implemented, but also the type of the key used: impl Index<Bar> for Foo { ... }, where access would look like a_foo[some_bar].

The two kinds of traits and corresponding methods define the behavior for immutable and mutable data type, as their name suggest.

Since the trait is defined generically, you can implement whatever kinds of accessors you like to the same underlying data structure, including generics accessors with trait bounds.

It is perhaps telling that in Rust you just find these traits in the general std::ops module, where all the core language operations and associated operators are defined. Rust doesn’t do “operator overloading” so much as it simply provides operators as one more class of trait potentially applicable to your type. (The family resemblance to Haskell’s type classes and similar in other languages is obvious.)

In Swift, you define indexing behavior with the subscript keyword. Subscripts act very similarly to Swift’s computed properties. They can be made read- or write-only by including or excluding get and set function definitions, just like computed properties.

The behavior is in fact so closely aligned with the computed property syntax and behavior that I initially wondered if it wasn’t just a special case. It is not (though I’m sure much of the parsing machinery can be shared). As the designation of subscript as a keyword strongly implies, and unlike in Rust, this is a separate language construct, not building on existing language machinery.

Swift, like Rust, allows you to define arbitrary accessors. However, since the behavior relies on the subscript construct rather than generics and protocols (Swift’s equivalent to Rust’s traits), you define different kinds of accessors via multiple subscript blocks. (Presumably these could take generic arguments, but I haven’t tested that to be sure.)

Both languages proceed to use these as ways of accessing types as makes sense—e.g. for not only arrays or vectors, but also dictionaries in Swift and HashMap types in Rust.

Since you can define the behavior yourself, you can also use complex types as keys. The languages approach this a bit differently, though. In Rust, if you wanted a compound key, you would need to define either a simple container struct or use a tuple as the argument. In Swift, because it uses the same basic syntax as computed properties, you can just define as many method arguments, of whatever type, as you want.

Takeaway: Rust uses traits; Swift uses a keyword. We probably could have guessed that when we started, at this point!

Static Site Generators and Podcasting

Sun, 28 Feb 2016 12:50:00 -0500

Presently, I publish both Winning Slowly and New Rustacean ¹ using what is admittedly a bit of a quirky approach. It works well for me, and I think it’s worth documenting for other nerdy types out there, but if you’re just getting going with podcasting and you’re looking for the easy way to do it, let me warn you: this isn’t it. Something like SoundCloud and a blog for show notes, or WordPress with Blubrry PowerPress is what you want instead. This approach works extremely well for statically-generated sites, however, and I imagine a few people out there might find it useful.

The short version

Generate the feeds with Feeder.
Generate the site statically with something else (and it really doesn’t matter what).
Copy the feed into the generated site.

The long version

I generate the sites themselves with Pelican and cargo doc, respectively. I was already comfortable with Pelican because it’s what I use to generate this site (with a few tweaks to the standard configuration, especially using Pandoc rather than the Python Markdown implementation), so I ran with it for building the Winning Slowly site, and it has worked quite well for building the site itself. It just gets built locally and deployed via GitHub Pages.

However, it does not have built-in support for generating podcast feeds, even just the general case with enclosures. iTunes podcast support would have taken a lot of work to add.² Instead, I chose to build the RSS feed semi-manually. Semi-manually, because doing it totally manually is a recipe for making mistakes. XML is many things, but “easy to write correctly by hand” is not one of them. I use Feeder to manage the feeds, and it makes sure that the enclosure and iTunes elements are set correctly.

The biggest upside to this is that I can use Pelican without modification to how it generates feeds (apart from optionally turning them off entirely). It just copies the feed I generate to the output file during its normal build process. As suggested above, I also don’t generate the other feeds which Pelican supports, as we have no need for them; we only care about the podcast feed.

This process works equally well, with very little modification, for New Rustacean. In that case, I’m generating the content by running Rust’s documentation tool, cargo doc³ to render the “API docs” which serve as show notes. Notice the family resemblance between my “show notes” and, say, the Diesel docs, which are both generated the same way. This is not a normal way of building a podcast website; you can hear me explain why I did it this way in New Rustacean e001: Document all the things! In any case, I just take the show note-relevant parts of the documentation and put it in Feeder, generate the feed, and copy that as part of the build process.

That’s it!

And, incidentally, Sap.py and my sermons feed.↩
If I stick with Pelican long-term, I might look into adding it anyway, but honestly, I don’t love Pelican. The reasons have little to do with Pelican for itself, and a lot more to do with my particular and somewhat peculiar needs. That’s a post for another day. In any case, I’m likelier to use another generator—even one I write myself!—than to do the work to make Pelican do what I want.↩
Technically, Rust’s documentation tool is rustdoc, which cargo doc wraps around. I never actually use rustdoc directly, though.↩

Rust and Swift (xiii)

Sun, 28 Feb 2016 11:15:00 -0500

Rust and Swift both have methods which are attached to given data types. However, whereas Rust takes its notion of separation of data and functions rather strictly, Swift implements them on the relevant data structures (classes, structs, or enums) directly. In other words, the implementation of a given type’s methods is within the body of the type definition itself in swift, whereas in Rust it is in an impl block, usually but not always immediately adjacent in the code.

This goes to one of the philosophical differences between the two languages. As we’ve discussed often in the series, Rust reuses a smaller set of concepts—language-level primitives—to build up its functionality. So methods on a type and methods for a trait on a type are basically the same thing in Rust; they’re defined in almost exactly the same way (the latter includes for SomeTrait in the impl expression). In Swift, a method is defined differently from a protocol definition, which we’ll get to in the future. The point is simply this: the two take distinct approaches to the relationship between a given type definition and the implementations of any functions which may be attached to it.

Another important difference: access to other members of a given data type from within a method is explicit in Rust and implicit in Swift. In Rust, the first parameter to an instance method is always self or &self (or a mutable version of either of course), much as in Python. This explicitness distinction is by now exactly what we expect from the two languages.

Both use dot notation, in line with most other languages with a C-like syntax, for method calls, e.g. instance.method() in Swift and instance.method() in Rust. The latter is just syntactical sugar for T::method(&instance) or T::method(instance) where T is the type of the instance (depending on whether the item is being borrowed or moved). Given its implicit knowledge of/access to instance-local data, and the distinctive behavior of Swift methods (see below), I don’t think the same is, or even could be, true of Swift.

All of Swift’s other behaviors around functions—internal and external names, and all the distinctions that go with those—are equally applicable to methods. Similarly, with the sole change that the first parameter is always the instance being acted on, a Rust methods follow all the same rules as ordinary Rust functions (which is why you can call the struct or enum method with an instance parameter as in the example above).

Swift does have a self—it is, of course, implicit. It’s useful at times for disambiguation—basically, when a parameter name shadows an instance name. This will look familiar to people coming from Ruby.

The strong distinction Swift makes between reference and value types comes into play on methods, as you might expect, as does its approach to mutability. Methods which change the values in value types (struct or enum instances) have to be declared mutating func. This kind of explicit-ness is good. As we discussed in Part 10, Rust approaches this entire problem differently: types are not value or reference types; they are either mutable and passed mutably (including as mut self or &mut self), or they are not. If an instance is mutable and passed mutably, a method is free to act on instance data. And in fact both languages require that the instance in question not be immutable. In fact, everything we said in Part 10 about both languages applies here, just with the addendum that private properties are available to methods.

The distinction, you’ll note, is in where the indication that there’s a mutation happens. Swift has a special keyword combination (mutating func) for this. With Rust, it’s the same as every other function which mutates an argument. This makes Rust slightly more verbose, but it also means that in cases like this, the existing language tooling is perfectly capable of handling what has to be a special syntactical case in Swift.

Both Swift and Rust let you out-and-out change the instance by assigning to self, albeit in fairly different ways. In Swift, you’d write a mutating method which updates the instance proper like this:

struct Point {
    var x = 0.0, y = 0.0
    mutating func changeSelf(x: Double, y: Double) {
        self = Point(x: x, y: y)
    }
}

In Rust, you’d need to explicitly pass a mutable reference and dereference it. (If you tried to pass mut self instead of &mut self, it would fail unless you returned the newly created object and assigned it outside.) Note that while the full implementation here is a couple lines longer, because of the data-vs.-method separation discussed earlier, the implementation of the method itself is roughly the same length.

pub struct Point {
    pub x: f64,
    pub y: f64,
}

impl Point {
    pub fn change_self(&mut self, x: i32, y: i32) {
        *self = Point { x: x, y: y };
    }
}

Note that though you can do this, I’m not sure it’s particularly Rustic. My own instinct would be to get a new Point rather than mutate an existing one, in either language, and let the other be cleaned up “behind the scenes” as it were (with automatic memory management in Swift or the compiler’s automatic destruction of the type in Rust)—purer functions being my preference these days.

You can do this with enum types as well, which the Swift book illustrates with a three-state switch which updates the value type passed to a new value when calling its next() method. You can do the same in Rust, with the same reference/dereference approach as above.

Here’s a three-state switch in Swift:

enum ThreeState {
    case First, Second, Third
    mutating func next() {
        switch self {
        case First:
            self = Second
        case Second:
            self = Third
        case Third
            self = First
        }
    }
}

And the same in Rust:

enum ThreeState { First, Second, Third }
impl ThreeState {
    pub fn next(&mut self) {
        match *self {
            ThreeState::First => *self = ThreeState::Second,
            ThreeState::Second => *self = ThreeState::Third,
            ThreeState::Third => *self = ThreeState::First,
        }
    }
}

Both languages also have what Swift calls “type methods”, and which you might think of as “static class methods” coming from a language like Java or C♯. In Swift, you define them by adding the static or class keywords to the func definition. The class func keyword combo is only applicable in class bodies, and indicates that sub-classes may override the method definition.

struct Bar {
    static func quux() { print("Seriously, what's a `quux`?") }
}

func main() {
    Bar.quux()
}

In Rust, you simply drop self as a first parameter and call it with :: syntax instead of . syntax:

struct Bar;
impl Bar {
    pub fn quux() { println!("Seriously, what's a `quux`?"); }
}

fn main() {
    Bar::quux();
}

As usual, Rust chooses to use existing language machinery; Swift uses new (combinations of) keywords.

Rust and Swift (xii)

Sat, 27 Feb 2016 22:30:00 -0500

A note on publication: I had this drafted in early January and simply forgot to publish it. Whoops!

As noted in my discussion of the product types in Rust and Swift, Swift distinguishes between classes and structs, with the former being reference types and the latter being value types. All structs are value types in Rust. (That you can wrap them in a pointer for heap-allocation with one of the smart pointer types, e.g. Box or Rc or Arc, doesn’t change this fundamental reality.) This underlying difference gives rise to one the big difference between Swift classes and Rust structs: a constant class instance in Swift can still have its fields mutated; not so with a Rust struct instance. But also not so with a Swift struct instance, as it turns out! There isn’t a straightforward way to do this with Box<T> in Rust; you could do it with something like an Rc<T> or Arc<T>, though.
Swift’s lazy keyword, and associated delayed initialization of properties has, as far as I know, no equivalent whatsoever in Rust. And while I can see the utility in principle, I’m hard-pressed to think of any time in my working experience where the behavior would actually be useful. Rather than having lazy properties, I would be far more inclined to separate the behavior which should be initialized at a later time into its own data structure, and supplying it via inversion of control if it is necessary for an actions taken by other data structures. (This seems—at first blush at least—to be a way of supporting the un- or partially-initialized data types possible in Objective C?)
Swift has computed properties, a concept familiar to Python developers (and relatively recently introduced in JavaScript). These can be quite handy, as they let you define a property to be accessed like any other (someInstance.theProperty) while being defined with functions which compute the value dynamically. A common, trivial example: if you defined a Person with firstName and lastName members, you could define a computed property, fullName, which was built using the existing values.
Rust doesn’t have computed properties at all. This is because of its design decision to deeply separate data from behavior, essentially stealing a page from more pure-functional languages (Haskell etc.). This is (one reason) why you don’t define the implementation of a struct method in the same block as the members of the struct. See an excellent explanation here.
It’s also closely related the way Rust favors composition over inheritance (by making the latter impossible, at least for now!). By separating impl from struct and enum, Rust makes it not only straightforward but normal to define new behavior for a given item separately from the data description. This, combined with the use of traits (like Swift’s protocols) as the primary way of sharing behavior between objects, means that you don’t have to worry about conforming to some interface when you define a given type; it can always¹ be defined later, even by entirely other modules or even other crates (packages).
In any case, the result is that it’s not at all Rustic² to have something like getters or setters or computed properties. It makes sense to have them in Swift, though, which has a more traditionally object-oriented type system (though with some neat additions in the form of its protocol type classes, which are analogous to Rust’s traits—but we’ll come to those in a future post). This is a wash: it’s just a function of the slightly different approaches taken in object design in the two systems. If you have a Swift-style type system, you should have computed properties. If you have a Rust-like type system, you shouldn’t.
I’m shocked—utterly shocked!—to find that Swift provides a default newValue argument for setters for computed properties, and shorthand for defining read-only properties. By which I mean: I find this kind of thing entirely unsurprising at this point in Swift, but I don’t like it any better. Making so much implicit just rubs me the wrong way. Once you know the language, it’s fine of course: you’ll recognize all the patterns. It just seems, in an interesting way, to add cognitive load rather than reducing it. That may just be me, though!
Interestingly, Swift also allows you to set watchers on given properties—functions called with the new or the removed value whenever the value of the computed property is updated or touched for any reason. It has two of these built in: willSet and didSet. You can override these to get custom behavior when a normal property is about to change. (You can of course just implement the desired behavior yourself in the set method for a computed property.)
Since Rust doesn’t have properties, it doesn’t have anything analogous. I can’t think of a particularly straightforward way to implement it, either, though you might be able do some chicanery with a trait. Of course you can always define a setter method which takes a value and optional callbacks for actions to take before and after setting the value; the thing that’s nice in Swift is that it gives you these as built-in capabilities within the language itself. (Now I’m wondering if or how you could implement an Observable trait, though! Might have to play with that idea more later.) It’s worth remembering , in any case, that Rust doesn’t have these because it doesn’t have properties.
Curiously, Swift provides the same functionality for “global” and “local” variables in a given context. In both cases, this is suggestive of the underlying object model for both modules and functions in Swift.
Now I’m curious what the representation of a module is in Swift; is it part of the general object system in some way?
This likewise gets me asking: what is a module in Rust? It’s a block item, clearly, and accordingly defines a scope (as do functions, if and match expressions, and so on). It’s not a compilation unit (as it is in C or C++). What other machinery is attached to it?
Both of these questions can be answered by reading the source code for the languages (Rust, Swift), of course. Putting that on my to-do list.
Swift also has type properties: values common to all instances of a given type. These are directly analogous to class properties (or class attributes) in Python or prototype properties in JavaScript.
Rust doesn’t have anything like this to my knowledge. You could accomplish something similar using a module-level variable with a 'static lifetime,³ much as you could in C—but that wouldn’t be an item on the type itself, of course.
The static declaration of item in Swift suggests what a possible implementation might look like in Rust: defining a member like a_static_long: 'static i64. There might be some interesting challenges around that, though; I don’t know enough to comment meaningfully. At the least, it seems like it would be an odd fit with the rest of the memory management approach Rust takes, and it would make it a bit harder to reason correctly about the behavior of data in a given type. (There are certainly issues there around mutability guarantees and lifetime checking!)
Because of the differences in underlying approach to data types and implementation, this is one of the areas where the superficially (and sometimes actually) similar languages diverge a lot.

leaving aside details about trait specialization still being hashed out in Rust↩
This is now my preferred term for “idiomatic Rust”—directly analogous to “Pythonic,” but with the upside of being an actual word, and one with pleasantly evocative connotations to boot.↩
There’s nothing analogous to Rust’s concept of explicit lifetimes in Swift, as far as I can tell. The static keyword in Swift, like that in C, Objective-C, and C++, is sort of like Rust’s 'static lifetime specifically, for variables at least—but Rust’s lifetime is substantially more sophisticated and complex than that analogy might suggest.↩

“I Don't Know When I'd Use That”

Sun, 17 Jan 2016 10:00:00 -0500

I was reading an interesting Stack Overflow discussion of the value of higher-kinded types (hereafter HKTs), and noted someone repeatedly commenting, “But when would you use this in a real app?” To put it the way another blog post about HKTs (in Rust), they are “a feature people do not really know what to do with.”

Don’t get me wrong: I’m sympathetic to that desire for concrete examples. I’m interested in these kinds of things not primarily for their intellectual value but for their pragmatic value (though I don’t think those two are as distinct as many people do). I’d also love to see some more real-world examples in those discussions. All too often, the discussions of types in Haskell end up being quite abstract and academic—no surprise, given the language’s origin. But I’m also aware that quite often it’s difficult to see how a given kind of abstraction is useful without jumping into a language which has that abstraction available and using it.

People often get turned off by Haskell (and other similarly high-abstraction languages like Scala) because of challenging terms like monad, applicative, functor, and so on. And again: I get that. To grok Haskell, you need to wrap your head around a lot of math ideas—mainly various properties of sets.

But I remember feeling the same way six years ago when I started playing with JavaScript and jQuery and every tutorial out there simply assumed existing familiarity and comfort with functions as arguments or return values. Coming from the world of Fortran and C, my head ached for weeks as I tried to make sense of what I was seeing. Even when I finally got it, I didn’t like it. Over the last several years, though, I’ve become increasingly comfortable and even reliant on closures, composition of functions to transform data, and so on as I worked regularly in Python and JavaScript.

That experience has taught me that my current inability to see the utility of a given abstraction means little about the abstraction. It’s primarily an indicator of my own inexperience.

To the question of the utility HKTs in general—in Haskell, Rust, or somewhere else—I don’t have the knowledge myself (yet) to supply a good answer. Heck, I can’t even explain them very well. (Other people can, though!) But I can say that reading Maybe Haskell showed me clearly that such things can be very useful. Even if I am not yet comfortable using that tool, I see how learning to use it would be profitable in the long-term. And like any good tool, even if you don’t need it every day… when you want it, you really want it.

Women in Rust

Sun, 10 Jan 2016 15:25:00 -0500

I posted these bullet points last night as a series of tweets on my main account.

∞ January 9, 2016 21:11

A thing I’d really, really like to see change—this is from the New Rustacean Twitter data. Unsurprising, but awful:

@newrustacean Twitter follower gender data
∞ January 9, 2016 21:12

Takeaway: the @rustlang community has many strengths, but like every tech community, we need to improve here—a lot.
∞ January 9, 2016 21:14

Standing offer: if you’re a female @rustlang dev, I’d love to feature your experience learning Rust on the show.
∞ January 9, 2016, 21:15

I’ll be doing some interview @newrustacean episodes soon-ish—I want as many female voices in the mix as possible.

Rust and Swift (xi)

Sun, 10 Jan 2016 10:00:00 -0500

I’ve still been (slowly) working through the Swift book and comparing Swift and Rust; I have another draft started which I’ll hopefully finish this week. And I still find the comparison deeply profitable. The two languages continue to evolve in interesting ways, and the comparison is all the more interesting now that Swift is open-source and its future open for community input (just as Rust is).

Something I’ve been thinking about for several months, and which the brief discussion of Swift, Go, and Rust at the end of the latest Accidental Tech Podcast brought back to my mind, is the question of what the next generation of systems-level programming language should be. And my answer is: there shouldn’t be just one. The best possible thing for the space, in many ways, is for there to be a healthy diversity of options and lots of competition in the space. We don’t want to have ten different systems programming languages to deal with, I think—but three or four or five would be much preferable to having one or two (closely related) as we have in the decades of C and C++ dominance.

Don’t get me wrong: both languages (and perhaps especially C) do many things exceptionally well. For all that they are (justly) maligned for some of their problems, the longevity of both C and C++ has a great deal to do with how well they fit the problem domain, and how much they’ve empowered developers to accomplish within that space (which is very, very large).

The problem, though, at least as I see it, is that the existence of only two really serious systems programming languages for the last several decades has led a lot of developers to think that C and C++‘s ways of solving problems are the only way to solve problems. The languages we use shape the way we think about possible solutions, and when a given language doesn’t recognize entire classes of different approaches, that deeply limits developers’ ability to tackle certain issues. (See also the interesting CppCast interview with D’s Andrei Alexandrescu in which he makes similar points.)

The most obvious thing missing from both is the ability to do truly functional-style programming. C of course is also lacking classes and thus is much more difficult to use for any sort of object-oriented programming.¹ Neither has anything remotely like Rust’s traits or Swift’s extensions; C++ has only gotten lambdas recently.

All of this comes out to mean that the set of tools available to systems programmer has necessarily been missing any number of things available in languages outside that context. In some cases, this may be a necessary consequence of the kinds of programming being done: when you need totally deterministic memory and compiler behavior, dynamic typing and a non-trivial runtime are simply not options. But in many cases, they are simply a function of the history of the languages’ development and history. Being an ALGOL descendant, and especially a C descendant, means there are some fundamental choices about the language which will differ from those made in a language descended from ML.

All of which is to say: C and C++ have been really useful tools in many ways, but having only C and C++ available for serious systems programming work over the last decades has left many developers blind to or simply unaware of the real advantages other paradigms might offer them.

So going forward, I don’t want there to be a winner in the systems programming space. I’d rather see D, Rust, Swift, Go, and maybe even a few other contenders all stay strong—finding their own niches and continually pushing each other and learning from each other. That will give us a space in which different languages are free to try out different approaches to the same problems, without being tied to the specific constraints faced by other languages. Built-in greenthreading? Go! Hindley-Milner types, memory safety, and zero runtime? Rust! Something in beween, highly expressive and with different type systems and tradeoffs around memory management, etc.? Swift, or D!

Having a robust, thriving set of competitors in the market will be good for the languages themselves. But it will also be good for developers. It will take off some of the blinders that come from a single language (or a pair of very closely related languages) dominating the ecosystem. It will make it likelier that people will be more familiar with different programming paradigms. And that can only be a good thing, as far as I’m concerned.

It is of course entirely possible to do non-classical OOP; the point is that C entirely lacks language-level facilities for OOP, inheritance, etc.↩

Thoughts on 2015 (and 2016)

Sat, 26 Dec 2015 13:30:00 -0500

As we come to the end of the year, I have been reflecting on the things I set out to do this year, and on my hopes for the coming year. At the start of the year, I posted a number of goals for my “public” life this year, and I also wrote up a number of personal goals for myself. Goals are well and good, but if I do not evaluate how I did on them, and think about areas I succeeded and areas I failed, and on how I might do better in the future, those goals will not make much difference. (Much difference, I say, because I have long found that even just having goals makes a difference in how I approach the year.)

At the start of the year, I posted a list of “Public-ish Plans”. My self-evaluation on those counts isn’t amazing. The Winning Slowly goals, I managed: we have separate pages for each season, and we recorded two more seasons—each one better than those before. Hosting things on Digital Ocean and migrating my wife’s blogs off of Blogger and WordPress, not so much (read: not at all, though I did start writing a Ghost theme for her current WordPress site… and haven’t touched it in at least six months.) I wrote some music this year, but not three minutes worth—you can hear all 37 seconds of it on SoundCloud. I wrote poetry; I managed to average about one poem a month starting in March. I wrote a few essays, but nothing close to one per month. I posted a whopping two book reviews (out of the six I hoped for), and both of those were written for school. I managed to add a picture to the About page, but I didn’t even come close to blogging about the family on a monthly basis.

In sum: about 50/50 on those goals.

That said, I managed quite a few other things not on that list this year. I started learning Rust, and started a podcast about it which is easily the most successful online endeavor I’ve ever undertaken, with a good 500 regular listeners. (That’s a small crowd on the internet, but massively more than any writing I’ve done, and actually larger than Winning Slowly’s current audience.) I have basically carried home a major transition effort for my main software development client, and helped them bring a new developer up to speed. I landed a new software development job, doing things I’m much more passionate about, which I’ll be starting in mid-January. I ran a triathlon (and placed third in my age group), and I set another personal record in the half-marathon I ran this fall.

One of the lessons I take away from this last year, then, is that it’s important to set goals, but it’s also important to let those goals change over time. Some of those goals are still things I’d like to accomplish—like migrating us to DigitalOcean, and getting Jaimie’s sites off of Blogger especially. Another (fairly obvious one) is prioritizing. I had a lot of major goals for last year, and in retrospect, I think I had too many. It’s hard to keep all of those in sight of the course of the year, especially with other professional and scholastic demands to meet (themselves often good in their own right).

With all of these things in mind, I’m planning to approach 2016 a little differently. I haven’t made formal goals yet, but I have come up with the basic outline I want to use going forward.

First, I am going to set a single goal in each of five major categories in my life:

spiritual: everything in my walk with God, including my own personal devotions, my involvement in the life of the church, and my “ministry” actions in general
family: both quantity and quality time spent with my wife and my quickly-growing-up little girls
personal: podcasting, blogging, and writing for other outlets
professional: working in my new job and as a consultant, and carrying on toward the conclusion of my M. Div.
health/fitness: continuing to stay healthy, including eating well and continuing to stay fit by running and doing triathlon work

Note that this list is intentionally unordered.¹ My spiritual life remains the highest priority, because if my walk with God falters, everything else will go amok. Beyond that, however, the amount of time and effort I invest in each category not only can but should vary over time. Family will broadly remain in the second of those slots, though there may be days or the occasional week where one of the other concerns very temporarily takes a higher priority. The others will adjust relative to each other as need be: there will be times when school requires more, and so my own writing gets less time, and there will be times when I have more flexibility and so am able to devote more to those personal interests, and so on. The goal here is not the mythical notion of “balance” but rather faithfulness, which has some superficial similarities but ultimately plays out rather differently.

I’m hoping, in light of those goals, to set annual, monthly, and daily goals in each of those categories. The daily goals should help me move toward the monthly goals, and the monthly goals toward the yearly goals. I only get to set one goal in each of those categories for each tier: at five goals, that’s already plenty! I hope that evaluating each day will help me be more focused and faithful, and that situating daily and monthly goals each in light of larger goals will help me actually accomplish those larger goals. We’ll see how it goes, of course. I’ll be back in a week or so with whatever goals I decide to make public in those categories, and again in a year with an evaluation rather like this one.

Under the covers, it’s literally an HTML unordered list.↩

Rust and Swift (x)

Sun, 06 Dec 2015 11:25:00 -0500

Swift and Rust both have “product types” as well as the enum “sum types.” In Rust, these are struct types; Swift splits them into classes and structs.
“Product types” will be much more familiar to programmers coming from a C-like background, or indeed most object-oriented programming languages: these are the same basic kind of thing as classes, structs, and objects in other languages. These include all the value types which compose them, unlike sum types—enum—which have only one of the value types which compose them.
Right off the bat, I note the Swift book’s somewhat amusing reticence to call out C and C-descended languages:

Unlike other programming languages, Swift does not require you to create separate interface and implementation files for custom classes and structures.

Because there’s such a long list of languages not directly descended from C which do that, right? 😉
Rust differs not only from Swift but from every other modern language I have used in not having a constructor syntax for its instantiations. Whereas C++ has new NameOfType() and Python and Swift both have NameOfType(), “constructors” for Rust structs are just functions which return an instance constructed using literal syntax, by convention NameOfType::new().
Let’s make a struct defining a location in a plane, you might do this in Swift (leaving aside initializer values; I’ll come back to those later). These definitions look very similar. Swift:
```
struct Point {
    var x: Double var y: Double
}
```
Rust:
```
struct Point {
    x: f64,
    y: f64,
}
```
Creating the types looks a little different, though. Here’s a constructor in Swift:
```
let point = Point(x: 0, y: 0)
```
And the two ways we could construct the type in Rust, a literal constructor (fairly similar to constructing dict literals in Python or object literals in JavaScript):
```
let point = Point { x: 0.0, y: 0.0 };
```
Or a constructor method, new:
```
// "Constructor"
impl Point {
    fn new(x: f64, y: f64) -> Point {
        Point { x: x, y: y }
    }
}

let another_point = Point::new(0, 0);
```
Observe: these two things in Rust are the same under the covers (though if Points had non-public internals, they would be non-trivially different: you couldn’t construct it with its private members externally). As usual, Rust opts to keep the language relatively small in these core areas. Given the plethora of ways you can construct something in e.g. C++, I count that a big win.
Another difference: Swift has syntax for default values; Rust uses a trait instead. In Swift, you simply supply the default value in the definition of the struct or class:
```
struct Point {
    var x = 0.0 var y = 0.0
}

let point = Point()
```
In Rust, you use std::default::Default, which provides a standard value for a given type, and for simple types can be supplied by the compiler even for custom types. Here is the equivalent Rust code:
```
use std::default::Default;

#[derive(Default)]
struct Point {
    x: f64,
    y: f64,
}

let point = Point::default();
```
This is reasonable enough, but we can also supply our own custom implementation if we so desire:
```
use std::default::Default;

struct Point {
    x: f64,
    y: f64,
}

impl Default for Point {
    fn default() -> Point {
        Point { x: 0.0, y: 0.0 }
    }
}

let point = Point::default();
```
Of course, this is trivial for this type, but you can see how it could be useful for more complex types.
The tradeoffs here are our usual suspects: Rust’s re-use of an existing concept/tool within the language (trait) vs. Swift’s use of syntax. Rust is slightly more explicit, making it obvious that a default value is being created—but Swift is perfectly readable and the syntax is consistent with many other languages, and it is shorter.

Both languages use . syntax for member access. Swift:

println("The point is: \(point.x), \(point.y)")

Rust:

println!("The point is {:}, {:}", point.x, point.y);

Swift lets you define items within a struct as mutable or constant. So you can create a variable struct instance, with some of its items immutable:
```
struct PointOnZAxis {
    var x: Double var y: Double let z = 0.0
}

var point = PointOnZAxis(x: 4.0, 5.0)
point.x = 5.0 point.y = 6.0
// This wouldn't compile, though:
// point.z = 1.0
```
This is pretty handy for a lot of object-oriented programming approaches.
And Rust doesn’t have it. There are ways to accomplish the same thing; this isn’t the end of the world. Still, it’s an interesting omission, and it’s very much by design. Rust used to have this feature, and dropped it—and for good reason. Say you had a mutable field in a mutable struct, and then an immutable reference to it; should the mutable field be mutable, or immutable, with that reference?

The Rusty way to do this is to differentiate between public and private data. The above examples don’t make the public/private distinction particularly clear, because they assume everything is within the same module. However, many times, this will not be the case.

mod geometry {
    pub struct Point {
        x: f64,
        pub y: f64,
    }

    impl Point {
        pub fn new() -> Point {
            Point { x: 0.0, y: 0.0 }
        }

        pub fn set_x(&mut self, x: f64) {
            self.x = x;
        }
    }
}

fn main() {
    // Won't compile: the `x` field is private.
    // let mut p = geometry::Point { x: 0.0, y: 0.0 };

    // Will compile: the `new` method is public.
    let mut p = geometry::Point::new();

    // Won't compile: `x` isn't public.
    // p.x = 4.0;
    // You can use the setter, though:
    p.set_x(4.0);

    // You *can* set `y` directly, though, because it's public.
    p.y = 14.0;

    // You can't set fields either way if the instance is immutable.
    let q = geometry::Point::new();

    // This fails because `set_x` requires a mutable reference, but `q` is
    // immutable.
    // q.set_x(4.0);

    // This fails because `q` is immutable, and so all its fields are, too.
    // q.y = 14.0;
}

This is an interesting way of handling this issue. Rust takes the fairly standard use of information hiding (one of the basic principles of most object-oriented programming techniques) and combines it with the language’s normal mutability rules to make it so that the mutability of any given instance data is quite clear: all public members are just as mutable as the struct. If a member isn’t potentially publicly mutable, it isn’t publicly accessible. I really like this, though it took some mental readjustment.
There’s one other difference here, and it’s actually one of the areas Swift and Rust diverge substantially. Rust has struct for all product types; Swift splits them into struct types and class types.
Swift classes have inheritance; there is presently no inheritance in Rust.
Additionally, whereas Rust determines whether to use pass-by-reference or-value depending on details of the type (whether it implements the Copy trait) and expected arguments to a function, Swift makes that distinction between class (pass-by-reference) and struct (pass-by-value) types. Quirky.
Not bad, per se. But quirky.

Edit: I recently bumped into some discussion of data types in C♯ along with C, C++, and Java (here) and discovered that Swift is stealing this idea from C♯, which makes the same copy/reference distinction between struct and class.
One consequence of this: in Rust, you’re always rather explicit about whether you’re accessing things by value vs. by reference. Not so in Swift; you have to remember whether the item you’re touching is a struct type or a class type, so that you can remember whether a given assignment or function call results in a reference or a copy. This is necessary because Swift doesn’t let you make that explicit (trying to hide the memory management from you). And it’s not alone in that, of course; many other high-level languages obscure that for convenience but still require you to think about it in certain circumstances. I’ve been bitten in the past by the value/reference distinction when thinking through the behavior of Python objects, for example, so that’s not a critique of Swift. Moreover, having the distinction between struct and class types does let you be more explicit than you might in e.g. Python about how given data will be handled.
I won’t lie, though: I like Rust’s approach better. (Shocking, I know.)
All that nice initializer syntax for Swift struct types is absent for its class types, which seems strange to me.
Swift supplies some syntax for object identity, since it’s useful to know not only whether two class instances have the same data, but are in fact the same instance. You can use === and !==. Handy enough. To get at this kind of equivalence in Rust, you have to use raw pointers (which are often but not always unsafe; you can do this specific comparison without being unsafe, for example) to check whether the memory addresses are the same.

Rust and Swift (ix)

Mon, 09 Nov 2015 22:20:00 -0500

Right off the bat when looking at the definitions for Swift’s and Rust’s enum types, a difference pops out: the use of the keyword case to introduce an enum member in Swift. In one sense, this overloads that keyword, but in another sense it’s fine: pattern matching and enums go hand in hand, so the use in both cases is fairly natural. Rust doesn’t have any special syntax to designate the elements of an enum; they’re just separated by commas.
I am not at all shocked to find that Swift has a variant syntax for its unit type case declarations, where a single case keyword precedes a list of comma-separated cases defined on a single line. (At this point, I would be more surprised not to find a variant syntax for something in Swift!)
Something truly wonderful about both Rust and Swift: enumerated types aren’t just wrappers around integer values. They’re real types of their own. This is powerful.
Rust and Swift also share in having enumerated types that can hold values. The most prominent of these so far in the Swift book are optionals, the Optional enum type, corresponding very closely to Rust’s Option type. Having had these for a bit in playing with Rust, and having gotten familiar with the utility of types like these while reading Maybe Haskell—a delightful book which introduces Haskell and functional programming using Haskell’s Maybe type—I now miss them profoundly in languages which don’t have them. (Which is to say: every language I use on a regular basis professionally: C, C++, Python, JavaScript, etc.).
Swift’s enum types don’t have integer values by default—but they can have them if you define a type and assign a value to each enum case at the definition. These “raw values” are distinct from the “associated values” noted just above. I expect these exist primarily for ease of interoperation with Objective-C.
Rust doesn’t have anything like this, at least that I can think of. The main place it would be useful would be for foreign function interfaces (as in Swift), and this is one of several such gaps in Rust, along with the lack of a straightforward way to map to C’s union types. ~~There are trade offs in terms of adding the functionality to the language, though, as it substantially increases the complexity of what an enum value can be, I think.~~

Edit: This was incorrect. From the Rust Reference section on Enumerations:
Enums have a discriminant. You can assign them explicitly:
```
enum Foo {
    Bar = 123,
}
```
If a discriminant isn’t assigned, they start at zero, and add one for each variant, in order.

You can cast an enum to get this value:
```
let x = Foo::Bar as u32; // x is now 123u32
```
This only works as long as none of the variants have data attached. If it were Bar(i32), this is disallowed.
Initialization of Swift’s raw-valued enum type is quite similar, and pleasantly so, to Python’s initialization of enums.
In a surprising change from the usual, Swift’s syntax for binding variable names when pattern matching against an enum is more verbose than Rust’s, requiring the use of either a leading let on the case statement if all the elements are of the same type, or a let in front of each element otherwise:
```
var matchedValue: String
let matchee = 3.14159
switch matchee {
case 3.14159:
    matchedValue = "pi"
case _:
    matchedValue = "not pi"
}
```
In Rust, a matched pattern can simply bind its value directly:
```
let matchee = 3.14159;
let matchedValue = match matchee {
    3.14159 => "pi".to_string(),
    _ => "not pi".to_string()
};
```
Swift has the ability to do recursive enumerations with its indirect type. This is conceptually interesting, but off the top of my head I can’t think of a time when this would have been useful at any point since I started programming seven and a half years ago. The book’s example of a recursive function aliasing arithmetic expressions is fine, but not particularly illuminating to me. I suspect, though, that it might make more sense if I were more familiar with pure functional programming paradigms.

Edit: a friend points out:

Indirect enums are useful for recursive types in general. There are a lot of these: Lists, trees, and streams are the big ones that come to mind.
All those same lines: Rust does not have the ability to have recursive enumerations at present (or recursive struct types, for that matter), at least without heap-allocating with Box along the way. You can construct such a type, in other words, but you have to be explicit about how you’re handling the memory, and it can’t be stack-allocated.
- For an example of a recursive enumeration type (as well as an interesting/hilarious example of how you can easily confuse the compiler if you do this wrong), see this Rust forum post.
- For some discussion on stack- and heap-allocated memory in Rust, I’ll shamelessly promote my Rust podcast, New Rustacean: take a listen to e005: Allocate it where?

Rust and Swift (viii)

Sun, 18 Oct 2015 11:50:00 -0400

Rust and Swift handle function definition fairly similarly, at least for basic function definitions. In fact, for most basic functions, the only difference between the two is the keyword used to indicate that you’re declaring a function: fn in Rust and func in Swift.
Likewise, both return an empty tuple, (), called the unit type in Rust or Void in Swift. Note, however, that this unit/Void type is not like C(++)’s void or Java’s null: you cannot coerce other types to it; it really is an empty tuple.
Type declarations on functions are basically identical for simple cases, though they vary into the details as you get into generics and constraints in generics.
I have no idea why the Swift team chooses to represent function names like this: function_name(_:second_param:third_param:<etc.>). Perhaps it’s a convention from other languages I’m simply unfamiliar with, but it seems both odd and unhelpful: eliding the first parameter name obscures important information. Also, why use colons for the delimiter?

Edit: I’m informed via Twitter and App.net that this reflects how function names work in Objective C, and derives ultimately from Smalltalk.
Being able to name the items in a returned type in Swift is quite handy; it’s something I have often wanted and had to work around with dictionaries or other similar types in Python.
We’ll see how I feel once I’ve been writing both for a while, but initially I strongly prefer Rust’s more-obvious (if also somewhat longer) -> Option<i32> to return an optional integer to Swift’s -> Int?. I am quite confident that I’ll miss that trailing ? somewhere along the way.
I’m sure there’s a reason for Swift’s internal and external parameter names and the rules about using _ to elide the need to use keyword arguments (but automatically eliding the first one) and so on… but I really can’t see the utility, overall. It seems like it would be better just to have Python-like args and keyword args.
That’s doubly so given that Swift’s rules for default-valued parameters map exactly to Python’s: they need to go at the end, after any parameters which don’t have default values.
Swift’s variadic parameters are nice—though of course limited, since if you have more than one, the compiler may not know how to resolve which destination parameter a given argument belongs with. (I imagine the compiler could be extended to be able to handle multiple variadic parameters as long as they were all of different types, but that’s probably not worth the work or the potential confusion it would introduce.) In any case, it’s a small nicety that I do wish Rust had.
Swift’s variable parameters are… interesting. I can see the utility, sort of, but (probably from years of habit with C and Python and pass-by-reference types), it’s just not a pattern that makes a lot of sense to me right now. No doubt I’ll get used to them in idiomatic Swift, but while Rust doesn’t have a similar feature, I suspect I won’t miss it.
In/out parameters—that is, mutable pass-by-reference types—are available in both languages. The syntax is very different here, as are the semantics.

Swift has the inout keyword, supplied before a parameter definition:
```
func adds4ToInput(inout num: Int) {
    num += 4;
}
```
Rust has instead a variation on every other type definition, declaring the type in this case to be a mutable reference:
```
fn adds_4_to_input(num: &mut i32) {
    num += 4;
}
```
As usual, in other words, Swift opts to use new syntax (in this case, a dedicated keyword) while Rust opts to use the same syntax used everywhere else to denote a mutable reference. In fairness to Swift, though, this is something of a necessity there. From what I’ve seen so far, Swift generally doesn’t (and perhaps can’t?) do pointers or references explicitly (though of course it’s handling lots of things that way under the covers); arguments to functions are a special case, presumably present primarily for interoperability with Objective-C.
Swift’s function type definitions, as used in e.g. function parameter definitions, are quite nice, and reminiscent of Haskell in the best way. Rust’s are pretty similar, and add in its trait usage—because functions types are traits. Once again, I really appreciate how Rust builds more complicated pieces of functionality on lower-level constructs in the language. (Swift may be doing similar under the covers, but the Swift book doesn’t say.)
Again, though, the downside to Rust’s sophistication is that it sometimes bundles in some complexity. Returning a function in Swift is incredibly straightforward:
```
func getDoubler() -> (Int) -> Int {
    func doubler(number: Int) -> Int {
        return number * 2
    }

    return doubler
}

func main() {
    let doubler = getDoubler()
    println("\(doubler(14))")  // -> 28
}
```
Doing the same in Rust is a bit harder, because—as of the 1.3 stable/1.5 nightly timeframe—it requires you to explicitly heap-allocate the function. Swift just takes care of this for you.
```
fn get_doubler() -> Box<Fn(i32) -> i32> {
    fn doubler(number: i32) -> i32 {
        number * 2
    }

    Box::new(doubler)
}

fn main() {
    let doubler = get_doubler();
    println!("{:}", doubler(14));  // -> 28
}
```
If you understand what’s going on under the covers here, this makes sense: Rust normally stack-allocates a function in a scope, and therefore the doubler function goes out of scope entirely when the get_doubler function returns if you don’t heap-allocate it with Box::new.
In both languages, closures and “ordinary” functions are variations on the same underlying functionality (as it should be). In Rust’s case, functions and closures both implement the Fn trait. In Swift’s case, named functions are a special case of closures.
The Swift syntax for a closure is, well, a bit odd to my eye. The basic form is like this (with the same “doubler” functionality as above):
```
{ (n: Int) -> Int in return n * 2 }
```
For brevity, this can collapse down to the shorter form with types inferred from context, parentheses dropped and the return keyword inferred from the fact that the closure has only a single expression (note that this wouldn’t be valid unless in a context where the type of n could be inferred):
```
{ n in n * 2 }
```
The simplicity here is nice, reminiscent in a good way of closures/lambdas in other languages.¹ The fact that it’s a special case is less to my taste.
Rust’s closure syntax is fairly similar to Swift’s brief syntax. More importantly, there’s no special handling for closures’ final expressions. Remember: the final expression of any block is always returned in Rust.
```
|n| n * 2
```
If we wanted to fully annotate the types, as in the first Swift example, it would be like so:
```
|n: i32| -> i32 { n * 2 }
```
There are even more differences between the two, because of Rust’s ownership notion and the associated need to think about whether a given closure is being borrowed or moved (if the latter, explicitly using the move keyword).
Swift has the notion of shorthand argument names for use with closures.² The arguments to a closure get the default names $0, $1, etc. This gets you even more brevity, and is quite convenient in cases where closures get used a lot (map, sort, fold, reduce, etc.).
```
{ $0 * 2 }
```
If that weren’t enough, Swift will go so far as to simply reuse operators (which are special syntax for functions) as closures. So a closure call could simply be + for a function expecting a closure operating on two numbers; Swift will infer that it needs to map back to the relevant method definition on the appropriate type.
The upside to this is that the code can be incredibly brief, and—once you’re used to it, at least—still fairly clear. The downside to this is yet more syntax for Swift, and the ever-growing list of things to remember and ways to write the same thing I expect will lead to quite a bit of instability as the community sorts out some expectations for what is idiomatic in any given instance.
And if that weren’t enough, there is more than one way to supply the body of a closure to a Swift function that expects it: you can supply a block ({ /* closure body */ }) after the function which expects it. Yes, this can end up looking nearly identical to the form for declaring a function:
```
someFunctionExpectingAnIntegerClosure() { n * 2 }
```
But you can also drop the parentheses if that’s the only argument.
```
someFunctionExpectingAnIntegerClosure { n * 2 }
```
In terms of the mechanics of closures, and not just the syntax, the one significant difference between Rust and Swift is the same one we’ve seen in general between the two languages: Swift handles the memory issues automatically; Rust makes you be explicit about ownership. That is, as noted above about the closures themselves, in Rust you may have to move ownership to get the expected behavior. Both behave basically like closures in any other language, though; nothing surprising here. Both also automatically copy values, rather than using references, whever it makes sense to do so.
Swift autoclosures allow for lazy evaluation, which is neat, but: yet more syntax! Seriously. But I think all its other closure syntaxes also allow for lazy evaluation. The only reason I can see to have the special attribute (@autoclosure) here is because they added this syntax. And this syntax exists so that you can call functions which take closures as if they don’t take closures, but rather the argument the closure itself takes. But of course, this leads the Swift book to include the following warning:

Note: Overusing autoclosures can make your code hard to understand. The context and function name should make it clear that the evaluation is being deferred.

Yes, care needed indeed. (Or, perhaps, you could just avoid adding more special syntax that leads to unexpected behaviors?)
Good grief. I’m tired now. That’s a half-dozen variants on closure syntax in Swift.
Remember: there’s still just one way to write and use a closure in Rust.
This takes me back to something I noticed early on in my analysis of the two languages. In Swift, there’s nearly always more than one way to do things. In Rust, there’s usually one way to do things. Swift prefers brevity. Rust prefers to be explicit. In other words, Swift borrows more of its philosophy from Perl; Rust more from Python.
I’m a Python guy, through and through. Perl drives me crazy every time I try to learn it. You could guess (even if you hadn’t already seen) where this lands me between Rust and Swift.

This post is incredibly long, but I blame that on the (frankly incredible) number of variants Swift has on the same concept.

Compare the closure syntaxes especially in Ruby and ES6+.↩
For a similar example in another up-and-coming language, see Elixir, which does almost exactly the same but with & in place of $.↩

Rust and Swift (vii)

Sat, 19 Sep 2015 15:00:00 -0400

I am reading through the Swift book, and comparing it to Rust, which I have also been learning over the past month. As with the other posts in this series, these are off-the-cuff impressions, which may be inaccurate in various ways. I’d be happy to hear feedback! Note, too, that my preferences are just that: preferences. Your tastes may differ from mine. (See all parts in the series.)

Both Rust and Swift have pattern-matching, and with what appears to be fairly similar basic behavior. (I touched on this briefly in my first post in the series.) In Rust this goes under the match construct, with matches specified like <pattern> => <expression|statement>, optionally with guards specified with if expressions. In Swift, patterns are matched using the switch construct, with matches specified like case <pattern>: <expression|statement>, optionally with guards specified with where expressions. (where is also used in Rust, but for generic constraints, not pattern match guards.)
Both languages allow you to bind names to a matched pattern: Swift with case let <name> and Rust simply by using the name in a normal destructuring expression as part of the match definition.

Edit: that’s not quite right. In Rust, you use the @ operator with the variable name you want to bind in the match.

Edit the second: I was mixed up, because Rust actually has both of those options. You can either match directly, e.g. when getting the value of an Option type: Some(value) as the pattern will bind value. But if you need to bind a specific part of more complicated data structure, the @ operator is present to let you do it in a fairly straightforward way.
Both languages allow for the use of _ as a “wildcard” in match definitions. Since match definitions in Rust use the patterns directly, the equivalent of Swift’s C-like default is simply a wildcard match pattern (_ => <-expression|statement>).

One significant difference: like its if blocks, Rust’s match blocks are expressions, so they can be assigned. I.e., you can write this:

let test = 5u32;
let description = match test {
    0..10 => "less than ten",
        _ => "greater than ten",
}
println!("{?:}");  // "less than ten"

Swift doesn’t let you do this; the same thing there would be written like this:

let test: UInt32 = 5
var description: String
switch test {
    case 0..<10:
        description = "less than ten"
    default:
        description = "greater than ten"
}
println("\(description)")

Both languages have break statements, but in Rust they’re only used in loop constructs, while Swift (like C) uses them to escape cases as well. The Swift book gives an example of one place they’re necessary in a switch: to match a case and do nothing there (e.g. default: break). In Rust, you would simply supply an empty block for that scenario (e.g. _ => {}).
Correctly, both languages force you to match exhaustively on relevant patterns. If you’re matching an enumerated type, for example, you must handle every enumerated value. You can of course do this with wildcard patterns or with Swift’s default, but the good thing is that both languages will refuse even to compile if a given pattern isn’t matched.
Swift’s default behavior around its switch statements is sane: it does not automatically fall through into the next statement. It does let you do this, without checking the condition on the next statement (as in C), using the fallthrough keyword. Rust, by contrast, simply doesn’t allow this at all.
Both languages supply named control statements (loops, etc.), with slightly different syntax for naming them. Rust’s, curiously, shares its syntax with lifetime definitions—more on those in a future post.
I don’t believe Rust has anything quite like Swift’s guards, which allow you to leave normal or expected control flow in the main body of a block, with a secondary block for cases where the guard isn’t matched. This isn’t a huge deal, but it does fit as a nice convenience into the typical if let pattern in Swift. Basically, it just lets you elide an empty if block and supply only the else block.

Edit: a friend points out that Swift guards also require you to exit the current scope, so it’s unambiguous what you’re doing if you use them.

Rust and Swift (vi)

Sat, 19 Sep 2015 09:00:00 -0400

It kind of feels like this summarizes a lot of things about the overall design of Swift:

Although the two forms are functionally identical, the shorthand form is preferred and is used throughout this guide when referring to the type of an array. —The Swift Programming Language (Swift 2 Prerelease)

The documentation for the various types in Rust’s std::collections module is hilarious and great. Highly recommended.

One thing that jumped out at me reading this chapter of the Swift book (though I don’t think it’s been explicitly discussed yet): Rust doesn’t have named parameters; Swift does. There are good reasons for that in both cases, but I suspect this is one of the small details I’ll miss the most in Rust. I’ve been spoiled by Python.

Swift’s Array type is analogous to Rust’s Vec type (usually created with the vec! macro), not its Array type. Rust Vecs and Swift Arrays are dynamically sized and created on the heap, whereas Rust’s Arrays are statically sized and created on the stack. Syntax for creating Arrays in both languages is quite similar (though the results are different):

Swift:
- Fixed size: let an_array: [Int] = [1, 2, 3]
- Variable size: var an_array = [1, 2, 3]
Rust:
- Array: let an_array: [i32, 3] = [1, 2, 3];
- Vector: let a_vector: Vec<i32> = vec![1, 2, 3];

That’s the long form, of course; both languages have type inference, so you’d rarely write it like that. The usual form would be with the type in all of those cases:

Swift:
- Fixed size: let an_array = [1, 2, 3]
- Variable size: var an_array = [1, 2, 3]
Rust:
- Array: let an_array = [1, 2, 3];
- Vector: let a_vector = vec![1, 2, 3];

Rust also adds the concept of “slices,” which provide access to segments of arrays, and are heap-allocated as pointers to a given item in the array and a length (number of elements) included.

Array operations in Swift are all pretty reasonable, and surprisingly descriptive. They remind me in a good way of Python’s list methods.

There are a lot of ways to interact with Vecs in Rust. (That’s not a bad thing.) A bit surprising to me was the absence of an enumerate method, on Vec itself, but then I discovered that it exists in the IntoIter struct in the same module, which fully implements the Iterator trait. As a result, it has an enumerate function returning an Enumerate struct instance. (Under the covers, I suspect Swift Arrays just implement an Iterable protocol, which is similar to this approach in some ways.)

This makes a point I’m coming back to fairly often: Rust doesn’t necessarily put everything on a single object definition, but rather into a set of related struct or enum types and traits. This is really powerful, but it’s going to take some mental adjustment. In this way, Swift’s structure and semantics are much more like the languages I’m used to than Rust’s are (but even there, the use of protocols gives it considerable new flexibility).

Note that I said semantics, not syntax. Swift and Rust are a great example of how very similar syntax can mask differences in semantics. (For another such example, compare JavaScript’s syntax and semantics to Java’s: they’re superficially similar syntactically, and light years apart semantically.)

Swift’s Set type and Rust’s roughly analogous HashSet both have a contains method which behaves much like Python’s in keyword. Indeed, and perhaps unsurprisingly, the two types implement many of the same methods in general. This is perhaps to be expected given that the language around sets (as a mathematical concept being mapped down into a representation in a program) is quite standardized.

Because of their stricter typing systems, both Rust and Swift require you to specify the types used in their mapping constructs (Rust has HashMap and Swift has Dictionary), though of course both can infer this as well in certain cases. At the most basic level, you can’t use arbitrary (hashable) types as keys in mixed fashion like you can in e.g. Python’s dict type, but in practice this shouldn’t matter, for two reasons:

It’s generally inadvisable to use different types for keys in the same dictionary anyway. To me, at least, that usually indicates the need to step back and think more carefully about the types and data structures I’m using.
For the occasional case where it is appropriate, I wonder if you could declare the type as generic in either Rust or Swift. I’m putting this down as a TODO item for myself to find out!

I really wish that Swift used the Python-style curly-brace delimited syntax ({'key': 'value'}) for its dictionary literal initializers. I can see, from a syntax reason, why it doesn’t: that would overload the block syntax (which Python can avoid because it’s white-space delimited). But it’s really convenient.

Along similar lines, I can see why the Swift designers chose to make all iterables have literal initializers using braces ([...]); it makes parsing fairly straightforward. However, the result is that it’s pretty difficult to see at first glance what you’re dealing with. It could quite easily be an Array, a Set, or a Dictionary.

This highlights a too-little-appreciated aspect of programming language design: readability. However much we programmers enjoy writing code, the reality is that we will all spend a great deal of our time—probably even a majority of it—reading it instead. Thus, while we should care about conveniences for writing code, and being overly verbose can be a pain, we should also concern ourselves with the ease of comprehending code when it is read, and the syntax and conventions a language embraces are a big part of this.

The Dictionary type in Swift is a pretty close analog to Python’s dict, right down to several of the method names. the same is true of Rust’s HashMap. That’s not a bad thing by any stretch of the imagination.

Rust and Swift (v)

Sat, 12 Sep 2015 13:45:00 -0400

I’ve been working on learning Swift over the past couple weeks, and had spent the month prior to that doing a deep first dive on Rust. This kind of approach, learning two languages basically at the same time, is entirely new to me, and for good reason. Programming languages are not trivial to learn, and to learn them meaningfully one must practice with them a great deal.

I’m doing this largely of necessity. I’m hoping to build an application with a very capable, performant cross-platform core language (Rust), but planning to ship a native OS X app (first) when all is said and done. My desire to make the core libraries portable rules out Swift immediately. To be frank, so does the fact that it’s an Apple language: I am happy to use Apple’s tools on its platform, but I don’t want to shackle myself to their choices in the long run. Too, having good Rust experience is likely to be valuable in many other contexts.

So I need to learn both.

And, while I wouldn’t ordinarily recommend this course of action—indeed, unless you already have a fair bit of programming experience and already know several languages, I’d actively recommend against it—I’m finding it enormously profitable. The languages have been designed in roughly the same time frame, cite many of the same influences, and overlap substantially in terms of audience and goals. Yet they are, as this series has already highlighted, quite different languages in many ways.

Learning them in parallel is helping me see the trade-offs each one has made, and force me to think about why they differ in the ways they do. In particular, I think I have a much better idea what’s going on “under the covers” in each language and therefore know what to expect of them better. This, in turn, has dramatically deepened my grasp of the languages relative to the amount I’ve been looking at them, compared to previous language-learning efforts. (It also helps that I’ve already learned a number of languages, of course, and that I’ve been pushing my brain into the learning-programming-languages space via reading about Haskell, functional patterns in JavaScript, and so on this year.)

I have a long way to go in both languages, of course. Reading on nights and weekends, and the little bit of playing I’ve been able to do with each of them, is no replacement for just sinking my teeth into a project and finding the pain points. Nonetheless, I’m really glad to be learning these two languages together. If you’re up for a challenge, try it sometime! You’ll be surprised how much you learn.

If-expressions in Rust

Sat, 12 Sep 2015 11:05:00 -0400

I love the fact that all if statements in Rust are expressions. It gives you a great deal of expressitivity in the language.

Let’s contrast with Python (which I love, for the record). In Python, you can do something like this:

some_condition = True
if some_condition:
    a_value = "Yeah!"
else:
    a_value = "Oh, sads."

Those are statements in the body of the if/else block; you can’t assign the block itself to a_value. However, like C, C++, Java, etc., Python does provide an expression-type conditional, a ternary expression.

So you can also do this:

some_condition = True
a_value = "Yeah" if some_condition else "Oh, sads."

This expression form of the if block is what all Rust if blocks are. So in Rust, the normal long form is:

let some_condition = true;
let a_value = if some_condition {
    "Yeah!"
}
else {
    "Oh, sads."
}

(You could also write this with a let mut a_value and then set its value inside the conditional blocks, but that’s not at all good form in Rust.)

And of course, you can shorten that rather nicely where the expressions are brief enough:

let some_condition = true;
let a_value = if some_condition { "Yeah!" } else { "Oh, sads." }

But this gets really nice when you have more complicated work to do in a Rust conditional. It doesn’t matter how many things going on inside an if expression; it’s still an expression. As such, you can also write this:¹

let some_condition = true;
let a_value = if some_condition {
    let the_answer = 42;
    let theme = "Take my love, take my land...";
    "Yeah!"  // An expression!
}
else {
    let the_question = "What do you get when you multiply six by nine?";
    let song = "You can't take the sky from me!";
    "Oh, sads."  // An expression!
}

Obviously this is totally contrived and silly; the point is that no matter what the internals are, if blocks are expressions, and their final expressions can be assigned like any other.

As a note: I got here because I was originally thinking you couldn’t do a one-liner like you can in Python. As shown above, that’s totally false, and in fact the Rust version is much more capable than Python’s, because you don’t need a dedicated ternary when all if blocks are expressions. Rust used to have a C-style ternary (<condition> ? <value if true> : <value if false>) but it was removed during the lead-up to the 1.0 release—a decision I wholeheartedly affirm.

Note that under normal conditions the compiler won’t actually accept this because of the unused names.↩

Rust and Swift (iv)

Thu, 10 Sep 2015 21:05:00 -0400

Both Swift and Rust directly address the issue of having to worry about memory allocation and safety. They do it in different ways, though: Swift by automatic reference counting, Rust by its concept of ownership. For a lot of day-to-day development, I can see the Swift approach being a win for the same reason a language like Python or Ruby is: having that all handled for you is nice. Having the power Rust gives you comes at the price of increased cognitive load from having to reason about ownership.

To put it another way: all programming languages have to make trade-offs. Although I like Rust’s better than Swift’s so far, I’ve no doubt I will find any number of things to appreciate about Swift over Rust. You can’t have everything.

This caught my attention in part because dealing with things like strings (or other pass-by-value types) in Swift is rather more straightforward than in Rust. The outcomes are much the same, but since all Strings in Swift are passed by value (never by reference), you simply don’t have to think about modification—even safe modification!

Rust of course had the Copy trait which lets you do this, but the point is that the “ergonomics” are slightly nicer in Swift.

Also, the string interpolation Swift does is nice. That’s one thing I really wish Rust had. It’s Python-style string formatting macro is great, but being able to interpolate values ("strings with \(variables)" or even "embedded expressions like \(2 + 4)") is very nice.

Swift’s approach to strings in general seems well-thought-through and gives appropriate levels of attention to the details which make handling complex or non-Western languages much more manageable. As a typography geek, I appreciate this a great deal.

That said, since Swift’s strings do handle all those edge cases for Unicode, you lose some standard string access patterns and lose much (maybe all?) insight into the internal structure of the string. That may be good, and may be bad, depending on the circumstance. Like I said: trade-offs.

Actually, on reading further, the way Swift handles Unicode strings is pretty nice. It does give you insight into those, via specific methods for different representations. I particularly appreciate that it’s you deal with them as the standalone String type as well as giving you direct access to the code points—and not just one Unicode code point set, but any of UTF8, UTF16, or UTF32 (Unicode scalars). Trust Apple to pay close attention to text.

Rust’s strings are good, but not quite as sophisticated (presumably for simplicity around the memory mapping). All Rust String or str instances are composed of UTF32 Unicode scalars, encoded as UTF8 sequences. It doesn’t have some of the convenience methods Swift does for getting any of the other representations. That said, I expect this should show up rarely if at all in my ordinary usage. Importantly, the fundamental storage is the same: both use scalars.

This was the first section where it didn’t feel like Rust was just a clear overall “winner” over Swift. Some of the trade-offs between the language designs are more apparent here, and I do appreciate the “ergonomics” of Swift in a number of these things.

Rust and Swift (iii)

Mon, 07 Sep 2015 11:55:00 -0400

I just hit operators in the Swift book. First question: are operators special syntax, or are they sugar for protocols? (Every modern language I use or even have played with handles them as sugar for another language construct—Python, Ruby, Io, Elixir, and Rust, to name just a few ranging over a substantial variety of ages and styles.)

Oh. I did the requisite digging, and operators are functions (which is okay) defined in the ~~global namespace (:sigh:)~~ Swift module.¹ I say “okay” rather than good because the justification offered is that this is the only way to make the operators work as binary operators between existing instances of types. But that elides the fact that, if that’s the case, it is so because of other language design decisions. This seems like a perfect place to use a protocol, but perhaps (unlike Rust’s trait) they’re not sufficiently capable to handle this? That’s an open question; I have no idea about the answer.

Interestingly, Rust has several fewer operators than Swift, even apart from those mentioned in my previous post. It drops the pre- and post-increment operators entirely (as does Python), since their results can always be accomplished in other ways with less potential for confusion. Swift keeps them, no doubt in part because most (Objective) C programs are deeply familiar with them and with idioms associated with them.

I learned a few new things about Rust’s operators as well: the Boolean || and && operators and its bitwise | and & operators differ not only in that the former are short-circuit operators and the latter are not. Obviously you can also do things like bit-wise flag operations with the latter, but the reference emphasizes the short-circuiting behavior. This makes perfect sense, but it wasn’t something I’d ever considered explicitly before.

There is no ternary operator in Rust, because of how it handles the relationship between expressions and statements. Swift keeps it. That’s an interesting reflection of differences in design: Rust dropped it because if blocks are expressions, so it’s redundant, and they have had a goal of removing unnecessary features. (See the discussion on dropping the ternary operator—with an interesting aside from Brendan Eich on JavaScript—here). Note that this is not a criticism of Swift, just an observation, though I do really like Rust’s expression-driven approach.

The ?? “nil coalescing operator”, on the other hand, I actively dislike. This seems like shorthand for the sake of shorthand, partly necessitated by the existing drive toward shorthand with optional types in Swift. Sometimes brevity can lead to decreased clarity. Eliding too much, or subsuming it into shorthand, makes the language harder to hold in your head and requires you to slow down more for parsing each line.

Nothing surprising (or different) between the standard boolean operators in the two languages.

I wonder how many times the word “concise” (or synonyms of it) appear in the Swift book? It’s increasingly clear to me reading that brevity is one of the primary design goals. Maybe it’s just me, but that actually seems a little weird. Brevity is good so far as it goes, but legibility is much better.

See edit in discussion of functions and global namespace in part ii.↩

Rust and Swift (ii)

Sun, 06 Sep 2015 10:20:00 -0400

At first blush, I find the extra syntax around optionals in Swift more confusing than helpful. I think this comes down to my preference for a more Python-like approach: “Explicit is better than implicit” and “There should be one– and preferably only one –obvious way to do it” both militate against the multiple different ways you can handle optional values in Swift. Optional types are created in one of two ways:

with the ? operator on a type definition, creating an explicitly wrapped type which must be checked in some way.
with the ! operator on a type definition, creating an “implicitly unwrapped optional” by forcibly unwrapping it (and creating a runtime error if the optional is empty)

After creating an optional, you can get at its contents by:

using the if let or while let constructs to bind the optional value’s non-nil value for a block
using the ! operator on a variable name, explicitly unwrapping it (and creating a runtime error if the optional is empty)

By contrast, in Rust you always have to explicitly unwrap the item, using the unwrap method or pattern matching. There are no implicitly unwrapped types. Moreover, there is no special syntax around creating optional types in Rust: you just declare them with an Option type or another type that impls the Option behavior. The “shortcut” behavior around error handling, try!, isn’t special syntax, but application of another standard language construct (in this case, a macro).

The discussion of assert in the Swift book re-raises the question about the global namespace:

“You write an assertion by calling the global assert(_:_:) function.”

This continues to suggest strongly that Swift does in fact have a true global namespace, not an automatically-imported prelude. That can make a big difference for applications in certain spaces (e.g. systems programming), when you might have good reason to want to replace the standard library’s approach with a different one. (See Rust’s #[no_std] docs and the related RFC.)

Edit: “strongly suggests” or no, I have now been reliably informed that I was mistaken—and am happy to have been wrong here. As in Haskell, these functions are implicitly imported and belong to the Swift module.

In Rust, assert! is a macro, not a function, which is an interesting but perhaps not especially important distinction in this particular case. (It might be, though; I’d have to see the implementation of each to see how they play out differently.)

In any case, this also highlights another large difference between the two: testing is front and center in Rust, and barely receives a mention so far in the Swift book (and isn’t in the table of contents). Having language-level support for testing is a big deal.

Language tour and first chapter of the language guide down, my sense is that Swift is a substantially better language than C or C++ (and presumably than Objective C, but since I don’t know that language I can’t speak to it) for app design, but that Rust is a better language yet. Both far more modern than their predecessors, but they approach the same problems in surprisingly different ways, relatively similar syntax notwithstanding. So far, I like the Rust approach better.

In particular, more syntax is not my preferred way to tackle these things. Providing good language constructs and primitives on which to build seems better in many ways:

It substantially reduces the cognitive load for the developer, by keeping the number of constructs small and simply varying how they are applied.
It increases the quality of those primitives, because it forces the language deadness to make sure they actually address the full problem space.
It lets developers approach the same problem in ways the language design team may not have anticipated, and over time the community may find shared conventions that improve on the std approach, and nothing has to change in the language spec (or the compiler!) to adopt those changes.
In general, then, it makes change much easier to manage, and change can be community-driven rather than requiring the language design team to manage it.¹

This may of course be intentional on Apple’s part with Swift. Maintaining tight control over its tooling is very typical of modern Apple.↩

Rust and Swift (i)

Fri, 04 Sep 2015 22:59:00 -0400

I started writing these responses in a Slack channel of developers I participate in as I worked through the Swift book. I realized after a bit that it would make a better blog post than chat room content, so here we are. This is all entirely off-the-cuff: me just thinking out loud as I read; this is by no means expert opinion.

I later turned this into the first part of a whole series comparing Rust and Swift!

..< – seriously?

That has to be one of the most annoying operators I’ve ever seen. It ends up with cognitive noise because <name initially processes as “starting a generic” and you have to re-parse it visually and mentally.
After the first chapter of the Swift book, my impression is “a poor man’s Rust”; my gut feel based on that first pass and everything I’ve seen and read about Swift over the past two years is that it’s roughly what you would get if you took Rust’s syntax and replaced Rust’s hard safety goals with the aim of mapping to ObjC semantics. (To be fair to Apple, that interoperability was probably necessary.)
An example that jumps out at me as immediately illustrative of the difference in approach the languages take is the way you pass structures by reference vs. copy. In Swift, that’s done via two completely distinct language constructs, structs and classes respectively.

In Rust, there is just the struct type to handle both of those. They’re immutable unless you declare them with mut, and you can pass them via copy simply by implementing the Copy trait (which seems roughly analogous to Swift’s protocol, but I’ve not yet dug deeply enough to see how they differ). Those things aren’t baked into the language, but use simpler language building blocks to define behavior into the library.
I saw someone do a write up a while back arguing that Go isn’t a bad language, it just isn’t a good language. My first impression of Swift, after having spent the last month with Rust, is very much along those lines.
Huh. Here’s something that I appreciate about Rust, Haskell, and others now that I didn’t before: there’s a difference between implicitly/automatically importing a prelude or a given set of standard library functions, and having actually global functions. Does Swift actually have functions like print in a global namespace, as the book seems to imply, or they being imported automatically a la Rust/Haskell/etc.?

Edit: it appears Swift does likewise, but that you can’t access the relevant module directly. Which is halfway there.
Hmm. Why have Double and Float—just for ObjC interop, I guess?

Edit: follow-up from a conversation with a friend: it’s because you have 32- and 64-bit architectures out there; sometimes you don’t want 64 bits of floating point precision for that reason. Note that Rust also has this distinction; you can declare things as f32 or f64.
Extending the above note on classes and structs and protocols vs. Rust’s approach: the same thing is true about extension, which is a distinct concept from implementing a protocol; again, in Rust these are both just handled with a single language construct, impl. That’s not because impl is overloaded, but rather because the underlying language machinery is the same for the two things. (edited)
(I’ve a feeling learning Swift is going to turn me into even more of a Rust fanboy.)
Reading the two books in close sequence like this is proving really productive mentally for thinking about how the two handle the same issues. I’ve never done anything quite like this before, and it’s fascinating.
I have an increased appreciation for Rust’s use of semi-colons to turn expressions into statements, and thereby to distinguish clearly between the two (among other things, allowing for implicit return of anything that’s an expression).
Another interesting comparison: Rust’s match and Swift’s switch and case fill the same role of pattern matching. I’m curious to see how they differ. Does Swift do matching on arbitrary expressions?

Also, I see where the syntax choices came from in both, and while I slightly prefer Rust’s, I think both make reasonably good sense; Swift’s will understandably be more familiar to C and ObjC programmers, and that’s a perfectly defensible approach. Seen that way, it is expanding on the C-style construct (even if it’s actually doing something substantially more sophisticated than that under the hood by being a form of actual pattern matching).

Next: Basic types and the syntax around them.

High- and Low-Level Programming Languages

Fri, 07 Aug 2015 20:00:00 -0400

It occurred to me while listening to Edwin Brady talk about Idris on the Type Theory Podcast,¹ having just spent a few weeks starting to learn Rust: “low-level” has at least two meanings in software. One is whether something has manual memory management or is garbage collected, reference counted, or otherwise manages memory itself. This is what people often mean when they talk about C, C++, etc. as being “low-level” and languages like Python or Ruby or C♯ being high-level.

But then you toss in a language like Rust, and things start to get a little more complicated. Rust can do the same kind of direct memory management that makes C or C++ a good language for things like writing operating system kernels. [1,2,3] But it is also memory-safe, at least in ordinary usage. Like C♯, you have to be explicit about any unsafe code, with the unsafe keyword on any blocks that do memory management that isn’t safe. And the vast majority of Rust code is safe.

More than that, though, Rust feels like a high-level language. It gives you higher-kinded functions, generics, traits-based composition of types, hygienic macros, and the implementation of many important parts the essentials of the language in the library. If you need to patch something, or extend something, you can do that in a straightforward way. In short, it gives you lots of good abstractions like you would expect in a high-level language.

Rust is low-level in that you can write (and people are writing) systems-level programs in it. It is high-level in that it lets you express things in ways normally associated with languages like Haskell or OCaml or Python or Ruby. To put it simply: it’s low-level in its ability to address the computer, and high-level in the abstractions it hands to a programmer. That’s a powerful combination, and I hope more languages embrace it in the years to come.

Yes, I know that’s insanely nerdy. What did you expect?↩

Chris Krycho - Rust

Appearance: Corecursive #34

JavaScript is C

Review: The Rust Programming Language

Scales of Feedback Time in Software Development

Rust is Incredibly Productive for CLIs

Aesthetics and Programming Languages

Exploring 4 Languages: Integrity and Consistency

A simple example: WidgetCode

Rust

Elm

F♯

Reason

Numeric validation: UnitQuantity

Rust

Elm

F♯

Reason

Aside: On Documentation

Summary

Exploring 4 Languages: Starting to Model the Domain

Simple values

Complex data

Workflows and functions

Summary

Exploring 4 Languages: Project Setup

Rust

Elm

F♯

ReasonML

Comments on the setup processes

Exploring 4 Languages

Becoming a Contributor

Introduction: The Big Ideas

Introduction: Why?

Introduction: The Big Ideas

Introduction: Outline

Why bother contributing?

Who is a contributor?

Who is a contributor? Examples

Who is a contributor? Me!

Who is a contributor?

Who is a contributor?

What & how can you contribute?

What & how: code

What & how: code – we’re kind here

What & how: code – a caveat

Filing bugs

Docs

Docs: who?

Docs – how?

Docs: varieties

Docs: Translation

Visual Design

Visual design: it’s not just us

Visual design: how

Blogging

Blogging: “Easy Mode”

Blogging: good examples

Blogging: all the options!

Audio and Video

Audio: podcasts

Audio: but there are already podcasts

Video

Video: what

Talk to people

Being inviting

When & where to contribute

When & where: you

When & where: if you’re just getting started

When & where: if you’re experienced

When & where: project lifecycles

Conclusion

More info

Better Off Using Exceptions?

The Itch

Rust development using VS Code on OS X, debugging included

Using Rust for ‘Scripting’

I. Using Rust Instead of Python

II. Building a Simple “Script”

A simple example: `WidgetCode`

F^♯

Numeric validation: `UnitQuantity`

F^♯

F^♯