In my last article on Inko, I implemented several data structures to demonstrate how Inko’s single ownership model works.
In this article, I will expose a big lie in that article and also dive into how Inko safely handles concurrency.
Why Concurrency is Hard Truth be told, concurrency is hard for a lot of reasons, but the one that comes up most often is concurrent memory access. If you have two threads of execution running at the same time, and they both read from and/or write to a variable, the variable is likely to end up with incorrect or garbage data.
I briefly described Inko’s unique memory management model in my previous article. In this one, I want to go into a little more detail on single ownership and move semantics by implementing a few linked lists, and a couple graphs. This is a tutorial about Inko and not about data structures, so I am assuming that you have a passing knowledge of the data structures in question (or know how to use a search engine to get that passing knowledge).
I’ve spent much of my free time (if there is such a thing) over the past few years researching various esoteric programming languages for no reason whatsoever. Some of my favourites include Rescript and Gleam, which target the Javascript and Erlang ecosystems, respectively.
But I’ve really been looking for something a little more native. It seems to me that there is a big gap on the language spectrum, somewhere between Rust and Go:
UPDATE: I’ve updated the Inko Formula on Homebrew to 0.11.0, so you may just want to use brew install inko instead. That said, There are a few bugfixes on Inko that didn’t make it to the 0.11.0 release, so you may want to build off the main branch instead.
I have a blog article in progress about why I’m super excited about the Inko Programming Language. It’s nowhere near completion, however, and I wanted to share how I got the latest version Inko running on MacOS (Ventura).
