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!
Top comments (0)