DEV Community: Valentin Knabel

Switching From Let's Encrypt to Actalis

Valentin Knabel — Mon, 02 Mar 2026 15:41:56 +0000

In my ongoing efforts to reduce the reliance on US companies and services, I decided from Let’s Encrypt to the Italian Actalis. Sure, Let’s Encrypt works fine, is non-profit and had a huge impact on today’s internet security, but nonetheless it is still US based and required to comply with US law and government requests. This could also include breaking the chain of trust for certificates while prohibiting to share this information with the public.

Actalis, on the other hand, complies to European laws, regulations and standards.

I operate a Kubernetes cluster with cert-manager and DNS01 challenges. Actalis provides these too, making the switch fairly easy.

Create an Actalis account.
Copy your ACME Key ID and the HMAC.
Create a new secret in Kubernetes with these values.
Create a new Issuer or ClusterIssuer in Kubernetes, referencing the secret created in step 3.
Reference the new issuer in your Certificate resources.

---
apiVersion: v1
kind: Secret
metadata:
 name: actalis-eab
 namespace: cert-manager
stringData:
 # no trailing `=` in the HMAC
 hmac: "$YOUR_HMAC"

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
 name: actalis-prod
spec:
 acme:
 email: "$YOUR_EMAIL"
 server: https://acme-api.actalis.com/acme/directory
 privateKeySecretRef:
 name: actalis-dns01-account-key
 externalAccountBinding:
 keyID: "$YOUR_KEY_ID"
 keySecretRef:
 name: actalis-eab
 key: hmac
 solvers: # if you are switching, just keep it as is
 - dns01: # due to my setup only DNS01 challenges make sense
 cloudflare:
 apiTokenSecretRef:
 name: cloudflare-credentials
 key: api-token

Perfect, now we’ve got Actalis set up and we can start issuing certificates.

But there is one downside: Actalis does not support multiple domains per certificate in the free plan. Splitting these into multiple certs and secrets does solve this fairly easily though.

I understand if this is a deal breaker for some, but in the end, these are just a few lines that are simple and easy to maintain.

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: first-domain
spec:
 secretName: first-domain-tls
 issuerRef:
 name: actalis-prod
 kind: ClusterIssuer
 dnsNames:
 - first.domain # only one dns name supported
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: second-domain
spec:
 secretName: second-domain-tls
 issuerRef:
 name: actalis-prod
 kind: ClusterIssuer
 dnsNames:
 - second.domain # and here is the second one
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: both-domains
spec:
 # here we need to supply both certs
 tls:
 - secretName: first-domain-tls
 hosts:
 - first.domain
 - secretName: second-domain-tls
 hosts:
 - second.domain
 # the rules stay untouched
 rules:
 - host: first.domain
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: service-http
 port:
 name: http
 - host: second.domain
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: service-http
 port:
 name: http

And that’s it! For more services and ideas you could get rid of big tech and the US, check out Sovereignity.

The Grand Redesign

Valentin Knabel — Thu, 26 Feb 2026 21:13:55 +0000

Nine years ago I launched this blog to share some thoughts about software development. Most of the time I have been very strict about content that I posted. If it wasn’t tech, I didn’t post it.

Over the years my priorities shifted. I even started a new blog to open up a new niche. But in the end I decided to not restrict myself in terms of topics. Let’s see where this leads me to.

How it started

Back in February 2017, that’s nine freaking years ago, I launched this blog. I just picked some template and some static site generator to get started. The blog was built using Gatsby with some simple theme.

The problem with Gatsby

With the years I was increasingly frustrated with Gatsby. I wanted a simple blog, nothing too crazy client side stuff. But essentially that was the focus of Gatsby: web workers and lots of JavaScript.

When I left day to day web development, I also switched to Hugo. After all the hassle this was a breeze! I picked a new theme that was simple, but less basic and had a touch of color.

Essentially I was pretty happy with my site. But as teased above not with the topics I was writing about. I started a new website Aroid Garden about houseplants, but also lost focus there due to personal reasons. Eventually I sunsetted it.

Why the redesign?

Now I decided to transform my former tech blog to a personal one. If I want to write something down, I don’t want to think about wether the topic fits or not. Writing is a habit that must be built and maintained, but I regularly focus on other stuff than tech.

Though the markdown-style design just doesn’t fit the new content I want to share. That’s why I decided to go with the redesign. As it’s been a great choice I sticked to Hugo, but couldn’t find a theme that fit my needs, so I rolled my own. For technical details about this site see Colophon, which will be updated in the future.

I know there are still some rough edges around the design, but better ship, than procrastinate.

What about the content?

When mixing many topics, it makes sense to provide ways to navigate and filter it more easily.

refactored the tags that grew over the years (I had go and golang)
separate RSS feeds for the blog, library and one for all content

I also provide additional content like:

a book library to share book recommendatations
a now page to share what I’m currently doing
the colophon to share technical details about the site
my list of projects
and sovereignity to share my efforts to regain control over my data and online presence

Also some updated content:

the about page was just outdated
I imported the Aroid Garden posts to the plants tag, though the layout isn’t optimized for it

In the end, when you have a look at Home, you cannot come around to see that my content has changed. And that this is just the beginning.

Discontinuing of Projects

Valentin Knabel — Fri, 02 Jan 2026 00:00:00 +0000

Starting with this year, I have decided to discontinue all of my open source projects.

Most notably this affects my VS Code extensions for Swift. I archieved the reposiroties and requested to deprecate the extensions in the Visual Studio Marketplace.

Also I decided to stop my work on my toy programming language.

Reasoning

Since a few years I shifted my focus from Swift development to Go and Kubernetes and switched my main editor from VS Code to Helix.

And I found joy in so many different things that can be done without computers. Doing some side projects just isn’t worth the hassle for me anymore.

Occasionally I will still write some blog posts and update my non-archived repositories.

Blushlog: Going Virtual

Valentin Knabel — Sun, 28 Sep 2025 00:00:00 +0000

A few years ago while I started working on Lithia, I decided to use whatever takes me to my goal. Getting finished was the primary focus. And I did.

With Blush I want to take less compromise and build a better language. Performance and portability aren’t completely irrelevant anymore.

This blog post is part of a Journey about creating a new programming language.

The Tree Walker

For Lithia I chose to implement a tree walker interpreter. It is simple to implement and easy to understand. The downside is that it’s slow.

Here the interpreter walks the abstract syntax tree (AST) and executes the program directly. This means that every time a function is called, the AST nodes for that function have to be traversed again.

In this approach every node in the AST has an evaluate method that takes the current context as a parameter. The context holds variable bindings and other state information.

Variables and constants were stored in a map. During every variable access, a lookup with the string name of the variable had to be performed. In case of a miss, a parent context had to be checked as well until the variable was found or the global context was reached.

let a = "global"

func do { =>
 let b = "local"

 print a // lookup "a" in current context -> miss -> lookup "a" in parent context -> hit
 print b // lookup "b" in current context -> hit
}

do // looks up the function "do" and calls it

Additionally checking the type of a value wasn’t trivial as well as the types had to be looked up by name as well.

Furthermore Lithia leverages lazy evaluation, which means that expressions are not evaluated until their value is needed. This adds additional overhead as every expression has to be wrapped in a thunk (a parameterless function).

And this makes the second problem of this clear: everything is hidden behind pointers and in general everything is kind of costly. Not necessarily in terms of complexity, its just slow like hashing strings multiple times per variable access, checking if everything has been evaluated and last but not least it can’t be cached efficiently by the CPU.

The Bytecode Interpreter

Blush takes a different approach to this. It defines a virtual machine (VM) that executes bytecode instructions. Blush’s VM is stack based, which is comparable for a simple calculator or a deck of cards: each operation works on the topmost elements of the stack.

The bytecode itself is separated of all constants. Instead these are in a separate array or slice while the bytecode references them by index. In case of the expression 40 + 2, the constant 40 is at index 0 and 2 is at index 1. The human readable bytecode to add these two numbers is then:

# 1 + 2
Cons 0 # Pushes the constant at index 0 (40) onto the stack
Cons 1 # Pushes the constant at index 1 (2) onto the stack
Add
# Result: 42

The actual bytecode currently looks like this: 01 00 00 01 00 01 10. Neat, huh?

The VM iterates over the bytecode instructions and executes them one by one. Here Cons loads the constant with the fitting index onto the stack. Add pops the top two elements from the stack, adds them and pushes the result back onto the stack. That way the stack of the VM grows and shrinks as needed.

When it comes to variables, the VM uses a different approach as well: each variable gets an index assigned at compile time. That way variable access is just a matter of looking up an index of a single array.

Now let’s get back to our example from above:

let a = "global" // globals[0] = constants[0]

func do() { // functions are constants: constants[1]
 let b = "local" // locals[0] = constants[2]

 print(a) // globals[0]
 print(b) // locals[0]
}

do() // constants[1]()

No more string lookups. No more parent contexts. Just direct index access. And the best part of this: the CPU can cache this data much more efficiently.

What about laziness? Almost everything is now eagerly evaluated. Expressions are evaluated as soon as they are encountered. Though there are a few exceptions like logical operators (&&, ||) which skip their right hand side if the result is already determined by the left hand side. This is common and does not add much overhead.

But in Blush globals are still initialized lazily. More on this in a future blog post.

Why that hassle?

Interpreters are much easier to implement and to understand. Is this actually worth it?

Glad you asked! I made some micro benchmarks for Lithia and Blush. In this case I wrote a simple recursive Fibonacci function in both languages and measured the time it takes to compute for several numbers.

Microbenchmarks can be misleading and do not reflect real world performance. But as long as we keep all tests as similar as possible, we can get a rough idea of the performance difference.

Here is the Lithia version:

func fib { n =>
 if (n < 2), n, (fib n - 1) + (fib n - 2)
}

Here is the Blush version:

func fib(n) {
    return if n < 2 {
        n
    } else {
        fib(n-1) + fib(n-2)             
    }
}

As both languages are implemented in Go, I used the builtin Go benchmarking for both to keep it as similar as possible.

And these are the results on my machine:

Input	Repetitions	Lithia	Repetitions	Blush	Factor
28	1	5,338 sec	1,000,000,000	0.1101 ns	4,848,486
30	1	13,990 sec	1,000,000,000	0.2860 ns	4,891,832
32	1	36,805 sec	1,000,000,000	0.7305 ns	5,038,386
40	0	(too long)	1	34,238 sec	(too long)

When I first saw these results, I had to check if I messed something up. We are comparing seconds with nanoseconds here. That’s why I added another run with fib(40) for Blush to validate the tests. And they were right. Blush is nearly five million times faster than Lithia in this case.

To get some more context, I also measured the Python and Ruby fib(40) and got around 10 to 17 seconds here. Although these numbers are not accurate and probably estimated too high, they give a rough idea of the performance difference. Blush is multiple times slower than these languages, but still in the same ballpark, while Lithia is outclassed by magnitudes.

Blush is still in early development. Through optimization, new language features but also additional safe guards the performance profile will change over time. And probably not always for the better. Also this is just a microbenchmark that is not in favor of Lithia. Real world performance might be different. Take these numbers with a grain of salt.

But yes, this was worth the hassle. In case you are curios about what’s up next or want a nerd talk, feel free to reach out to me @mastodon.social@vknabel.

Blushlog: A new Beginning

Valentin Knabel — Tue, 16 Sep 2025 00:00:00 +0000

After a long time of procrastination I finally resumed my work on my new programming language. Back then I wrote about the current state of Lithia and how I arrived in a dead end regarding the language design. Sure I proposed some large changes, but if a lazy evaluated programming language with a parensless call syntax becomes a strict evaluated programming language with a regular call syntax and multiple additional features, is it still the same ~~boat~~ … language?

Literally every line of code would break. That’s why I decided to create a new, currently private, repository for my new programming language called Blush.

This blog post is part of a Journey about creating a new programming language.

What will Blush be like?

Similarly to Lithia, Blush will still be simple, but it will still be much more feature rich than Lithia.

First to get the boring stuff out of the way:

Blush will be dynamically but strongly typed as Lithia is.
Blush will be strict evaluated while Lithia is lazy evaluated.
The call syntax might now look slightly familiar as f(a, b) instead of f a, b.

Annotations

Regarding the type system Blush adds the new annotation types to Lithia’s data and enum types. An annotation is declared like a data type, but can be instantiated with an @ before declarations.

annotation Countable {
 @Returns(Int)
 length(@Has(Countable) value)
}

@Countable({ v -> v.length })
data Bag {
 @Array items
}

In contrast to decorators in other languages, annotations only store data. They cannot change the behavior of functions or types. To use annotations, a new reflection API will be provided.

import reflect

@Returns(Int)
func count(@Has(Countable) value) {
 return reflect.typeOf(value).annotation(Countable).length(value)
}

The effectively replaces the old but common witness pattern in Lithia with a more flexible and powerful system without introducing other new concepts like interfaces.

As you might have noticed, the new annotations can but don’t have to be used to provide type hints. In the long term these should be checked by the compiler and fuel the language server to provide better IDE support.

Control Flow

In Lithia there were no control flow constructs like if statements or for loops except the type expression. Instead everything was expressed via functions and recursion. This was slow and cumbersome.

Blush now comes with classic if and switch statements as well as for loops.if statements will support multiple branches and else if as well as inline variable declarations.

if condition {
 doSomething()
} else if otherCondition {
 doSomethingElse()
} else {
 defaultCase()
}

switch statements will support type matching as well as value matching.

switch value {
case @SomeType:
 doSomething(value)
case 42:
 doSomethingElse()
case _:
 defaultCase()
}

for loops will support iterating over ranges, arrays, maps and custom iterators and infinite loops with for { }.

for {
 if condition {
 break
 }
}

for i in Range(0, 10) {
 println(i)
}

In contrast to other languages, there will also be if, switch and for expressions that can be used inline to assign values. In there only variable declarations and one expression per branch are allowed.

let filtered = for num -> items {
 if num % 13 == 0 {
 break
 } else if num % 2 == 0 && num % 3 == 0 {
 "fizzbuzz"
 } else if num % 2 == 0 {
 "fizz"
 } else if num % 3 == 0 {
 "buzz"
 } else {
 continue
 }
}

A few more things

Blush will come with a working package manager out of the box, it will have a new design and mascot (you might have noticed) and in the long term the language server and tooling will be much better and more accurate than Lithia’s.

A much better performance is also a goal, but don’t expect miracles here. Lithia was just really slow.

What is the current state?

As of now, Blush is still in a very early stage. Blush can parse lots of the syntax although large parts are still missing. Though the execution side is still in its infancy and only supports a few basic mathematical operations, arrays, bools, and if statements and expressions. Variables and functions will be the next big step.

At the tooling side, the core of the package manager is already present.

I guess I have quite a long way to go, but I am excited to finally work on a new programming language again. If you want to follow along or want a quick chat, feel free to reach out to me @mastodon.social@vknabel.

metalstack.cloud v0.2.1

Valentin Knabel — Wed, 14 Feb 2024 13:50:53 +0000

We are excited to announce the latest release of metalstack.cloud, version 0.2.1! This release includes several enhancements, bug fixes, and new features across various components of the metalstack.cloud ecosystem.
From now on, you will find release notes in this part of our documentation section.

The first new feature of this release is the creation of Access Tokens.
These allow a safe and secure programmatic access to our APIs. They may only access specific organizations, projects and endpoints. Access tokens created from the web console are only valid for one specific project.

And beside the metal terraform provider we also introduce a new developer tool: the fully featured metalstack.cloud command line interface which already uses the new access tokens.

Besides these new features and projects, new patch releases for all supported Kubernetes versions from v1.21.6 to v1.26.2 are now available.

We encourage users to explore these updates and provide feedback. For more detailed information, refer to the individual GitHub repositories linked above.
Thank you for your continued support, and we look forward to delivering more exciting features in future releases!

The current state of Lithia after 2 years

Valentin Knabel — Thu, 18 Jan 2024 16:45:00 +0000

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.

For a programming language being able to teach lessons, a Standard Library and of course some programs need to exist. Only the experience of its developers can lead to conclusions. Now it’s time to derive those!

This blog post is part of a Journey about creating a new programming language.

The current state

But first let’s have a look on the current state of Lithia.

Lithia has all planned features implemented. You can define data-structures, enums similar to unions, functions, constants, modules and imports, closures, partial application of parameters and lazy evaluation. The standard library currently consists of 19 modules providing base types, helpers around comparisons, strings, results and more, file system access and a micro-framework to write unit tests in and for Lithia. Every module is fully documented and is generated by a Lithia script.

To declare packages and to make project-based scripts easily accessible, there is the Potfile (comparable to package.json, Package.swift, go.mod, Gemfile & Taskfile).

Although the performance of the Lithia interpreter has largely improved in the early days but it’s still slow and leaves room for improvements.

Developing Lithia is fueled by the Visual Studio Code extension which relies on the Language Server within the Lithia binary and does not need to be installed separately. It provides syntax highlighting, diagnostics and autocompletion. Additionally to the LSP there is a tree-sitter grammar which can be used in other modern editors.

The Developer Experience

Obviously the development experience in such a young programming language doesn’t reach the ease of use of mature ones. But for a scripting it provides decent autocompletion. Though there are no formatters or linters, yet. And currently there is no debugger support, which is a bummer. In practice this at least encourages the use of unit testing.

Lithia has a dynamic but strict type system, which may lead to runtime errors, which is okay for scripting. But the mix of lazy evaluation often further delays and hides these runtime errors and make debugging unnecessarily hard. Especially when adding concurrency. This needs to change.

Another option for improvement is the current parens-less call syntax: instead of f(g(x), y) you write f g x, y. With great syntax highlighting this is something you get around, but syntax should be self-explanatory.

What’s also missing is a real package manager although git submodules at least provide a workaround for this.

Summary

In general Lithia as an experiment was successful and lead to really great results. The simplicity but power of the type system is a breeze. But Lithia needs a change. And at its core lazy evaluation needs to be dropped, while the overall tooling should evolve. But what’s still missing is the perfect use case that perfectly fits Lithia’s language features. The upcoming release v0.1.0 should provide answers and solutions for those pain points.

If you wish, check out the open source repository of Lithia. If you have any questions don’t hesitate to ask me on @mastodon.social@vknabel or join the Lithia discussions.

Happy coding!

24hrs format for html inputs in Firefox

Valentin Knabel — Thu, 17 Aug 2023 00:00:00 +0000

My system language on my linux machine is set to English, but as a German raised with 24-hour days, I simply cannot wrap my head around to get the 12-hours am/pm format intuitively. By the time I learned that am is in the morning and pm is in the evening. But when it comes to 12:00 as the mid of the day and 0:00 in the night, I'm lost.

Of course I have already set the time format to 24-hours in my system settings (Ubuntu Date & Time > Time Format set to 24-hour), but Firefox still uses the 12-hours format for html inputs with type="time".

As a solution you open about:config and set intl.regional_prefs.use_os_locales to true.
Now simple <input type="time"> will use the 24h format!

Designing and scoping my programming language Lithia

Valentin Knabel — Fri, 22 Jul 2022 00:00:00 +0000

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.

In my case, I designed Lithia for myself to learn and explore all sorts of tooling around programming and to create them myself. And that's also the focus of the language: tooling around itself. Learning by doing is king here.

This blog post is part of a Journey about creating a new programming language.

My initial take on designing Lithia

I really like functional programming, but I value being able to perform changes imperatively when I need to. I like the idea of lazy evaluation and being able to create infinite data structures, but to only execute needed parts. And the stronger your type system is, the more errors can be caught at compile time. Some downsides like verbosity can be reduced by type inference.

Writing functional algorithms really work well with enumerations where every case may have attributes or associated values. It should also be possible to add scoped methods to already declared classes or data types.

And generics are great, let‘s stuff generics in there. Great nice language. How long will I take to implement it? Well…, scrap that.

Let‘s start all over.

Every programming language special on its own way. To define each characteristic of it, you not only need to know the language features, but the intentionally missing ones, naming conventions, typical patterns, the standard library and how everything is tied together.

That all defines the programming language. Everything is a tradeoff. For example, every piece of syntactic sugar makes your language more expressive, but harder to read. Every new feature needs to be learned and understood correctly. And every feature may be used in the wrong places or not at all.

What language is worth to implement?

Let‘s be honest: programming languages tend to be on the bigger side of projects and we all have limited time, energy and motivation. And there are plenty of programming languages out there.

Where does your language fit between all those other already finished languages? Are you solving niche problems? Are you experimenting with new language concepts or are you mixing seemingly unrelated paradigms? And more importantly: why do you want to implement it yourself? Are you able to even finish it? How do you keep your motivation up in the long term?

If you decided to start working on a compiler or interpreter, be sure to be able to finish it and expect you will be the only one using it.

So what‘s my case? Lithia does not solve a particular problem, but it enables me to learn about the inner workings of compilers, interpreters and the tooling around it. I want a green field to build all kinds of tooling. And in case there is a limitation or bug, I can fix or embrace and document it. What can be achieved in a specific field is not limited by external factors, only by my time, energy and motivation.

It’s about the scope and milestones

We know, the planned Lithia is not going to be able to compete with whole language ecosystems or programming languages that shine through lots of features. I wouldn’t be able to finish it.

Instead, the scope must be reduced. Even more as the language should be accompanied by tooling, coming with a huge scope increase!

But great tooling requires meta data like types to operate on and the compiler needs to support all that.

There need to be compromises.

And I need continuous wins to keep my motivation high. Once there is a basic implementation, I want to do some simple stuff, while working on a complex subsystem.

Lithia needs to shine through the absence of many features. Instead it should focus on few key concepts, that support requirements for tooling. And after all, it should be a language I like to program in.

To sum up, Lithia…

is a simple language with only a few features
supports tooling
allows a few quick wins
is conceptually attracting

Lithia is an experiment

I personally prefer mostly functional programming languages with a shot of imperative programming. In that context I also favour lazy over strict evaluation and love currying.

Lazy vs strict evaluation: expressions will only be evaluated if their value is actually needed in lazy evaluation. With strict evaluation they will always be evaluated.

Currying: let’s imagine you have a function with two parameters, but you currently have just the first parameter. With currying you can pass just the first one and you will receive a function that accepts the second parameter. Without currying you‘d need to manually create that function.

Lithia won’t allow direct mutations of variables. There will only be constants. I didn’t want to explicitly forbid any mutations, but at this stage I didn’t know how they fit into the language, yet.

Why? lazy evaluation and directly mutating variables might lead to weird behaviour. And what about types of a variable? May they change at any time?

The type system should be easy to bootstrap, but should enable static analysis in the future.

That’s my baseline.

Type System

Variables, parameters and functions won't have an explicit type annotation like Java's String name, Swift's let name: String or Go's var name string. If there would be type annotations, Lithia would need to enforce them right from the beginning.

Instead Lithia should have an easy to bootstrap dynamic type system, that still enables static analysis. The easiest way is not to allow structural manipulation of types.

How far can we get with type inference?

Base Types

There are two basic kinds of types to support:

types like classes and structs with independent properties.
types like enums that list all possible values. In some languages enums may have associated properties, thus mixing sum and product types.

Another aspect are reference and value types and semantics. How should changes propagate through the different parts of your program?

In Lithia there will be one type with properties called data without any inheritance or methods like classes have. They will have a list of untyped properties.

Don't worry if upcoming code snippets look unfamiliar – we will cover the syntax in another article.

data Example {
  firstProperty
  secondProperty
}

But here is an optimisation for tooling: if you want to store a function within your data, you can add all its parameters firstProperty param, and, more. When the tooling and the compiler mature, they can detect errors and improve autocompletion.

In Lithia, the enum type breaks with common interpretations. Here an enum isn’t a direct list of possible values, but a list of possible types, called a union.

This change from individual values to more generic types should make the currently rather static language feel more dynamic and like a scripting language for lovers of strong typing.

The type switch

Now that we have enums, we need to resolve those types. A type switch maps every type to a function. It requires the enum definition and returns a function that receives the value.

let increaseOptional = type Optional {
  Some: { some => some.value + 1 },
  None: { none => none }
}
increaseOptional (Some 1)
increaseOptional None

The goal is to provide functions to work on the enums within one module, that are reusable and higher level. This should reduce the amount of external type switches.

Standard Library

The stdlib is a great place to get quick wins from once the most basic implementation of the language has been finished.

In Lithia the interpreter’s responsibility ends early. It defines Strings, Characters, numeric types, Functions and some more basic types.

The Standard Library called prelude starts with famous types like Boolean and List.

In here there are many possibilities:

Testing
Docs generation
Sorting
All kinds of basic data manipulations
And much, much more!

What didn’t make it to Lithia

The list of all features that did not find any place in Lithia is longer than what did. All have their particular reasons and their absence fit into the concept of Lithia. Here are some honorable mentions:

Interfaces / protocols
Extensions / adding new methods to existing types
Methods
Type casts and direct type testing
Custom operators
Overloading
Variational arguments
Exceptions

Summary

In this post, I summarised my take on creating your own programming language. Don’t do it for glory, do it for yourself and the experience you gain.

Design your scope and concept. Make sure you stay motivated until the end. Don’t hesitate to reevaluate your decisions. Take tiny steps.

If you wish, check out the open source repository of Lithia. If you have any questions don't hesitate to ask me on @mastodon.social@vknabel or join the Lithia discussions.

Happy coding!

Starting the journey about creating a new programming language

Valentin Knabel — Fri, 22 Jul 2022 00:00:00 +0000

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.

I felt stuck between theory and simple proof of concept implementations like creating another Lisp.

What's in this series?

These are all finished blog posts so far.

Designing and scoping my language Lithia

My motivations and background

As soon as I learned programming, I was inspired by all the tooling like linters, editors and the compiler itself. All developed in order to develop. They were those magical blackboxes, that felt beyond everything I could achieve.

Later I played around with various language features and writing my own standard library replacement for existing languages. Lots of fun, but not productive.

With the years, I learned new paradigms like object orientation, logical, constraint and functional programming. And beyond those big paradigms, there are many different concepts that define the languages character like the module system, dependencies, inheritance, generics, operator overloading, interfaces, type classes, strong or weak typing, dynamic or static, side-effects, monads and many more.

I started experimenting with new programming language concepts, mixing a few and thinking about the consequences. How do these features integrate and what does it mean for a different group of features? And which syntax do you need to support the special characteristics?

For fun, I worked on small libraries and tooling in existing programming language ecosystems. Nothing special or widespread.
I read about compilers and interpreters and even though I implemented small lisp-like languages and custom parsers, I felt like I couldn’t write a compiler on my own.

I kept the wish to design and create my own programming language from ground up. With tooling. I want to learn every aspect of it. Run into problems. Solve them and gradually increase the maturity of the language, the tooling and the compiler.

That being said, I don’t want my language to be used in wild, heck I encourage you to not use it. The journey and what we learn along the way is the treasure.

Summary

I decided to create yet another programming language and let’s be honest: nobody will ever use it and I’m fine with it. But anyway I will still provide tooling and documentation for it.

I will update and link all my compiler and language design blog posts here.

If you wish, check out the open source repository of Lithia. If you have any questions don't hesitate to ask me on @mastodon.social@vknabel or join the Lithia disussions.

Happy coding!

Debugging Swift in VS Code in 2022

Valentin Knabel — Tue, 08 Feb 2022 00:00:00 +0000

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 and debugging 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.

First we need to install the mentioned extension: Swift for Visual Studio Code.

Now let’s create a new project on open it in VS Code!

$ swift package init --type executable
Creating executable package: MyProject
Creating Package.swift
Creating README.md
Creating .gitignore
Creating Sources/
Creating Sources/MyProject/main.swift
Creating Tests/
Creating Tests/MyProjectTests/
Creating Tests/MyProjectTests/MyProjectTests.swift

$ code . # if not found: open -a "Visual Studio Code" .

The Swift extension for VS Code will now generate some launch configurations within a .vscode/launch.json file. It generates release and debug LLDB-launch-configurations for each target and one launch configuration for each test target. Previously this step would have been manual.

As we currently have one target MyProject and one test target MyProjectTests, we will have the following launch configurations:

Also note, that the preLaunchTasks have been created, too!

{
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug MyProject",
      "program": "${workspaceFolder:MyProject}/.build/debug/MyProject",
      "args": [],
      "cwd": "${workspaceFolder:MyProject}",
      "preLaunchTask": "swift: Build Debug MyProject"
    },
    {
      "type": "lldb",
      "request": "launch",
      "name": "Release MyProject",
      "program": "${workspaceFolder:MyProject}/.build/release/MyProject",
      "args": [],
      "cwd": "${workspaceFolder:MyProject}",
      "preLaunchTask": "swift: Build Release MyProject"
    },
    {
      "type": "lldb",
      "request": "launch",
      "name": "Test MyProject",
      "program": "/Applications/Xcode.app/Contents/Developer/usr/bin/xctest",
      "args": [".build/debug/MyProjectPackageTests.xctest"],
      "cwd": "${workspaceFolder:MyProject}",
      "preLaunchTask": "swift: Build All"
    }
  ]
}

Now we are ready to start debugging! Let's open Sources/MyProject/main.swift, and add a breakpoint before executing print("Hello, world!") by left-clicking the empty space before the line number.

Next, switch to the Run and Debug tab on the left, make sure Debug MyProject is selected, and click the green run button.

Now your project will be compiled, run and stops at the breakpoint!

Sadly this approach currently does not work when debugging iOS or macOS apps, but Swift Package Manager projects and CLIs work great! I hope you enjoy your increased productivity!

Adopting Swift Async Await in Vapor

Valentin Knabel — Sun, 14 Nov 2021 00:00:00 +0000

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.

_ Puffery is an app to send messages into channels using Shortcuts or HTTP. This will trigger a push notification to all clients that have subscribed. Within the app you can view your messages and channels._

I wouldn't recommend to directly replace all occurrences of EventLoopFuture. If you aren't going to touch specific code paths in a while, there is no need to migrate those. But we'll come back to that later.

Upgrading to Swift 5.5

If you haven't already, you need to upgrade your Swift Tools Version within your Package.swift-manifest:

// swift-tools-version:5.5
import PackageDescription

Now a few lines later we need to upgrade to a newer macOS version, because async/await not only requires Swift 5.5, but also macOS 12 Monterey. Make sure you have upgraded accordingly. Otherwise you'd need to work on a linux machine or within a docker container.

let package = Package(
    name: "PufferyServer",
    platforms: [
        .macOS(.v12), // upgrade to .v12
    ],

Next up, we need to bump our dependencies. As we want to rely on special features of the new Vapor, we explicitly go from: "4.50.0". Repeat this with other dependencies like Fluent.

        // ...
    dependencies: [
        // ...
        .package(url: "https://github.com/vapor/vapor.git", from: "4.50.0"), // upgrade to 4.50.0
        // ...
        ],

Now, to silence a warning, we need to explicitly declare our Run target as executableTarget.

    targets: [
        // ...
        .executableTarget(name: "Run", dependencies: ["App"]),
        // ...
        ]
)

If you use a Dockerfile, build FROM swift:5.5 as build. Also if present don't forget to update your .swift-version-file and your CI.

Now update your packages using swift package update. If you use Xcode, also update your dependencies using File > Packages > Update to Latest Package Versions to keep them in sync. In theory swift build and swift test should run without any errors. If it does, fix those and proceed.

git commit -am "Upgraded PufferyServer to Swift 5.5"

Adopting Async Await

Now that we upgraded our new Swift version and updated our dependencies, let's get started with our migration.

We will incrementally do tiny steps and migrate every function after another. But it doesn't make sense to migrate all functions immediately. If you haven't touched specific files in a while, there is no need to do so now. A great example are your database migrations. You won't touch them anyways. Just write new ones with async/await and you are fine.

In my opinion, controllers are the easiest place to get started. Later you can tackle migrate Jobs or ScheduledJobs. Then your services and your repositories.

The easiest places to upgrade will most likely be your Fluent queries: there are overloads for .find() and .all() to return EventLoopFuture and async throws.

Migrate the function signature

- func messagesForAllChannels(_ req: Request) throws -> EventLoopFuture<[MessageResponse]> {
+ func messagesForAllChannels(_ req: Request) async throws -> [MessageResponse] {

Now fix all issues within the function. Then fix the errors of all callers.

If you temporarily converted invocations of this method from EventLoopFuture to an async function using .get(), it is now time to remove it.

Migrate Protocol Methods if directly affected

Most protocols need to be prefixed with Async like AsyncJob or AsyncScheduledJob. Then you can replace all function signatures.

I need async, but I have an EventLoopFuture

To convert a not yet converted EventLoopFuture, we call EventLoopFuture<V>.get() async throws -> V. You can migrate the function later.

try await theEventLoopFuture.get()

I need an EventLoopFuture, but I have an async function

Sometimes I decided to keep some function signatures as they were and I did not migrate them. For those cases I created a small helper function to create an EventLoopFuture from an async task.

extension EventLoop {
    func from<T>(task: @escaping () async throws -> T) -> EventLoopFuture<T> {
        let promise = makePromise(of: T.self)
        promise.completeWithTask { try await task() }
        return promise.futureResult
    }
}

For example executing multiple futures in parallel is easy with eventLoop.flatten, but it's much harder with async/await.

Migrate `.flatMap`

Migrate .flatMap({ messages in doSomething(messages) }) to let result = try await doSomething(messages).get().

Migrate `.flatMapThrowing`

Migrate .flatMapThrowing({ messages in doSomething(messages) }) to let result = try doSomething(messages)

Migrate `eventLoop.flatten`

Executing multiple futures in parallel is easy with eventLoop.flatten, but it's much harder with async/await.

I'd recommend to keep this part as is, and to keep this part as EventLoopFuture. See I need an EventLoopFuture, but I have async.

Migrate `.transform(to:)`

This is straight forward: use the value directly. Typically you'd return this.

Sometimes I used transform within a flatMap to keep the same return value. Now, just try await these side effects.

-   .flatMap({ user in
- user.update(on: req.db)
- .transform(to: user)
-   })
+   try await update(on: req.db)

Migrate `.always(_:)`

.always will be executed when an EventLoopFuture fails and when it succeeds. This is the same behaviour of defer with async/await!

-   return computeSomething()
- .always { _ in
- doSomething()
- }
+ defer {
+ doSomething()
+ }
+   return try await computeSomething()

_ Attention: you probably need to move your defer up. Using async/await will likely introduce more return and throw statements which will exit your functions early._

Returning constant futures

If you currently throw a failing future, just throw the error directly.

- return req.eventLoop.future(error: Abort(.notFound))
+ throw Abort(.notFound)

To replace a succeeding future, return the value directly.

- return req.eventLoop.future(success: value)
+ return value

If thee future(error:) was embedded within a do-catch to lift errors to an EventLoopFuture, you can probably remove the do-catch and mark the function as throws instead.

Test and Commit

Do not forget to regularly run your tests and to keep your project in a green state. From time to time, do some commits.

git commit -am "Use async/await for Vapor"

Real World Examples

In case you need guidance, here are typical examples for Vapor-endpoints. These examples should look familiar.

All code snippets are actual code from Puffery.

Example for a Fluent query

This function is part of the SubscriptionRepository. It is meant to be used from Controllers to consistently access, filter and sort the channel subscriptions of a user.

func all(of user: User) -> EventLoopFuture<[Subscription]> {
    do {
        return try Subscription.query(on: db)
            .filter(\Subscription.$user.$id == user.requireID())
            .sort(\.$createdAt, .descending)
            .all()
    } catch {
        return eventLoop.future(error: error)
    }
}

We start by changing the type signature to async throws.

To fix the type errors, we could drop do-catch as the new variant is throwing. Previously it wasn't throwing as there is no overload of EventLoopFuture.flatMap that accepts throwing EventLoopFutures. Therefore all(of:) was required to lift thrown errors to futures.

As there is no distinction between directly throwing and a query failure with async/await we can get rid of the do-catch. And as Fluent has overloads for both EventLoopFuture and async throws we're done here.

func all(of user: User) async throws -> [Subscription] {
    try await Subscription.query(on: db)
      .filter(\Subscription.$user.$id == user.requireID())
    .sort(\.$createdAt, .descending)
    .all()
 }

Example Migrations for simple read-only endpoints

My MessageController looked like this:

final class MessageController {
    func messagesForAllChannels(_ req: Request) throws -> EventLoopFuture<[MessageResponse]> {
        let user = try req.auth.require(User.self)

        return req.subscriptions.all(of: user)
        .flatMap(req.messages.latestSubscribed(for:))
      .flatMapThrowing { messages in
          try messages.map {
            try MessageResponse($0.message, subscription: $0.subscription)
                }
     }
    }

    // other endpoints ...
}

This code should be familiar to any Vapor developer. I started migration with the function signature, replaced flatMap and flatMapThrowing and inserted the .get().

func messagesForAllChannels(_ req: Request) async throws -> [MessageResponse] {
    let user = try req.auth.require(User.self)

  let subs = try await req.subscriptions.all(of: user).get()
  let messages = try await req.messages.latestSubscribed(for: subs).get()
  return try messages.map {
      try MessageResponse($0.message, subscription: $0.subscription)
    }
}

After I migrated my SubscriptionRepository, I could even get rid of the trailing .get().

Example Migration for simple write-endpoints

This function's migration path was more complex.

func confirmEmailIfNeeded(_ user: User) throws -> EventLoopFuture<Void> {
    guard let emailAddress = user.email else {
        return req.eventLoop.future()
    }

    let confirmation = try Confirmation(scope: "email", snapshot: emailAddress, user: user)
    return confirmation.create(on: req.db)
        .flatMapThrowing { _ in
            try Email(/*...*/)
        }
        .flatMap { email in
            self.req.queue.dispatch(SendEmailJob.self, email)
        }
}

Here we could completely remove the empty req.eventLoop.future(). A simple, blank return statement is enough. And creating models doesn't force us anymore to nest everything one level deeper. We await the result, but we discard it.

func confirmEmailIfNeeded(_ user: User) async throws {
    guard let emailAddress = user.email else {
        return
    }

    let confirmation = try Confirmation(scope: "email", snapshot: emailAddress, user: user)
    try await confirmation.create(on: req.db)
    let email = try Email(/*...*/)
    try await req.queue.dispatch(SendEmailJob.self, email)
}

Summary

Within this post we upgraded our Swift version, Package manifest, docker / CI Swift versions and our dependencies. Then we incrementally migrated portions of our codebase by following a set of rules. What was your migration like? Did you experience any problems?

If you wish, check out the open source repository of Puffery or check it out on the App Store. If you have any questions or feedback don't hesitate to ask me on twitter @vknabel or join the Puffery disussions.

DEV Community: Valentin Knabel

Switching From Let's Encrypt to Actalis

The Grand Redesign

How it started

The problem with Gatsby

Why the redesign?

What about the content?

Discontinuing of Projects

Reasoning

Blushlog: Going Virtual

The Tree Walker

The Bytecode Interpreter

Why that hassle?

Blushlog: A new Beginning

What will Blush be like?

Annotations

Control Flow

A few more things

What is the current state?

metalstack.cloud v0.2.1

The current state of Lithia after 2 years

The current state

The Developer Experience

Summary

24hrs format for html inputs in Firefox

Designing and scoping my programming language Lithia

My initial take on designing Lithia

What language is worth to implement?

It’s about the scope and milestones

Lithia is an experiment

Type System

Base Types

The type switch

Standard Library

What didn’t make it to Lithia

Summary

Starting the journey about creating a new programming language

What's in this series?

My motivations and background

Summary

Debugging Swift in VS Code in 2022

Adopting Swift Async Await in Vapor

Upgrading to Swift 5.5

Adopting Async Await

Migrate the function signature

Migrate Protocol Methods if directly affected

I need async, but I have an EventLoopFuture

I need an EventLoopFuture, but I have an async function

Migrate .flatMap

Migrate .flatMapThrowing

Migrate eventLoop.flatten

Migrate .transform(to:)

Migrate .always(_:)

Returning constant futures

Test and Commit

Real World Examples

Example for a Fluent query

Example Migrations for simple read-only endpoints

Example Migration for simple write-endpoints

Summary

Migrate `.flatMap`

Migrate `.flatMapThrowing`

Migrate `eventLoop.flatten`

Migrate `.transform(to:)`

Migrate `.always(_:)`