I’m working on a new book! This one will be published online with plenty of begging for support on my Patreon. If there is sufficient interest, I’m planning physical and ebook editions later this year.
LazyVim for Ambitious developers is a book for the modal-editor-curious out there. Vim and Neovim have a reputation for being hard to learn and configure. LazyVim really negates that reputation, but its documentation still assumes that you have a lot of prior knowledge with Vim and Neovim.
Dexie Cloud was released publicly today, and I love this product so much that I want to lend my voice to the marketing effort.
Dexie.js is an incredible library for interacting with IndexedDB in the browser. It wraps the sometimes-obtuse (and oft-buggy) IndexedDB APIs with much more developer-friendly interfaces. And it is fully reactive; if you change something in the database, your React, Svelte, Vue, Angular, or Solid.js (Solid support is weak) app will live update all by itself! It’s a truly heavenly coding experience.
However, web users do not live in a vacuum, and storing things in IndexedDB is fraught. The browser may delete that data on a whim, and who among us only has one device these days? You might be able to use IndexedDB as a cache, but it can’t be your source of truth.
Until today.
My wife and I have been working on Fablehenge—a writing app for novelists—for several years. It had been a free time project where we’d push hard over a few weekends, then let it sit idle for a couple months perhaps tinkering in the evenings when we had a bit of time.
At the beginning of this year, I decided to take a sabbatical, which was supposed to involve cutting new hiking trails and woodworking. While it has done that, I found I’ve also been working on Fablehenge (more or less) full time.
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.
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).
Throughout my career, I’ve at least tried most of the available programming editors. More than two decades ago, I heard about the vi-vs-emacs debate, and made a pact with myself to use both for at least a year before deciding which I preferred.
I started with vim, switched to emacs after a year, and decided I preferred vim. I joined the sublime-text bandwagon for a year or two in the early 2010s, switched back to vim in the middle of the decade, and eventually did the big switch to vscode.
This is the sixth in a series of articles exploring the Gleam programming language. In this one, I’m setting aside my little password cracking project to look at gleam for frontend development.
I love Rescript for frontend development, it’s a very practical functional programming language, and I’ve written a lot on the topic. So this article will also be a bit of a comparison of Gleam and Rescript. This isn’t really a fair comparison as Rescript is a mature language, and Gleam’s Javascript support is super brand new. I do not expect Gleam to supersede Rescript as my favourite frontend language, but stranger things have happened.
This is the fifth in a series of articles exploring the Gleam programming language. In the most recent article, we started exploring how Gleam interfaces with ERLang’s powerful OTP concurrency framework to brute force some passwords. However, it was suboptimal, partially because I didn’t know what I was doing, and partially because I didn’t have time to go into some of the deeper details. I also had a super valuable tip from the Gleam discussion group that I wanted to go into.
