In 2021 I started working on the current Go implementation of my own experimental programming language called Lithia. Now it is available in version v0.0.19. Infrequently I also wrote some words about it on this blog. It has been designed to be an experiment, that is able to teach some lessons and that can be fulfilled.

Acorn is an application deployment framework for k8s, that tries to simplify instead of introducing another layer of indirection. I won’t cover all details and problems it tries to solve here, instead I’d like to share some experiences and thoughts.

My experience with Acorn and Kubernetes

Before we dive right in, I’d like to let you know about my level of experience with Kubernetes and Acorn.

I started having a look on Acorn in August 2022 and played around with it. I did not have production experience with Kubernetes, but I started learning and playing around with it a few months before.

Did you ever want to access the contents of an auxiliary file from within your repository to access the contents at runtime? This file could include some static settings like the version of the application, translations for user-facing texts, GraphQL requests or SQL queries. The typical solution to this problem is shipping your binary with the auxiliary files.

But this solution comes with great costs. You cannot ship one single executable anymore. Those files need to sit somewhere in the filesystem. And they might be misplaced, outdated or even missing.

Two years ago, I created Puffery for iOS, which allows sending push notifications to your iOS devices.

You can follow other’s channels and directly receive updates. There is no algorithm that decides wether you should receive notifications or not.

From the beginning scripting is part of puffery’s DNA: you were able to send messages with Siri Shortcuts and a simple curl command.

If you want to take a deeper look, feel free to check out the GitHub repository including the Swift Server written in Vapor, and the iOS app built with SwiftUI in a single mono-repo.

…

Once you have decided you want to create your own programming language, you need to create a broader concept. Every programming language is unique in its own way. Your goal is to find out in which way. And you need to find your reason why you want to create it in the first place.

• Do you want to solve a particular problem?
• Is it for learning purposes?
• For who do you build the language?
• Who should use it?

Keep the answers in mind during the whole design process: they will guide you into the right direction.

This is planned to be a series of blog posts about designing and developing my own programming language, where I want to share some pitfalls, my learnings, design decisions, experience and the development process.

While this series will not teach you how to write your first own programming language on its own, it might be supplementary.

After years of playing with the idea of writing my own programming language, I finally started. In the past I read books and blog posts about creating my own compiler, and I actually have written some parsers, but I never implemented the whole language itself. I know some theory, but I do not know how to actually apply it in practice.

Back in 2019 I wrote an article about how to debug your Swift Package Manager projects in Visual Studio Code. In late december 2021, the Swift Server Working group released a brand new extension for vscode, which dramatically improves debugging your Swift code. Especially for linux! Time for an update!

Running, debugging and developing your targets in Visual Studio Code is not prepared by default. Especially for us Swift developers this might come unexpected, especially in comparison to Xcode. In VS Code we require extensions and configs for this purpose.

A few months ago Swift 5.5 has been released and made async/await available. And in 4.50.0 Vapor added support for it, too!

If you are still on Vapor 3, you first need to upgrade your server to Vapor 4.

Now we can migrate most usages of Swift NIO’s EventLoopFuture with async. But we don’t have to! This is not a breaking change. I recently performed this upgrade for the server of my app Puffery and as both, the client and the server are open source I will include links to the respective git commits.

When developing Swift in Visual Studio Code there were a few cases, where I preferred Xcode. Beside the obvious cases like iOS Development, managing certificates and provisioning profiles, there was one big case left: Writing unit tests.

With perfect TDD (unit tests first, then code) this is no real problem, but if you want to write tests for already existing code, it is essential to get feedback about your current progress and test coverage.

The past few days I created a new server using Vapor and hit vapor new <project> --auth which created a Vapor 3 server. Later I upgraded the young project to Vapor 4, but found some lack of practical information about the upgrade on the internet. So here I share my subjective experience and try to give you some tips.

The app itself is relatively simple:

• it has user authentication and registration
• users don‘t have any profile and cannot interact with each other
• on certain events, we notify multiple users on all of their devices
• users have their personal list of notifications

After a while, when most parts of the MVP were finished, I wanted to add vapor/apns, which required the new Vapor 4. But hasn’t Vapor 4 been released recently? Yes, but it seems like the Vapor team probably decided to keep Vapor 3 the default until the documentation and all surrounding has been finished (which is a good thing!).