Sesterl is a language for the BEAM with syntax from the ML family of languages (Standard ML, OCaml, F#, Elm) created by Takashi Suwa (github, twitter jp, twitter en). I hope they don’t mind me sharing it here!
Sesterl has static type checking and in the future will support session types (hence the name).
The readme has more information and a few of first libraries and projects linked, go check it out!
I don’t mind, there’s only a few things to configure per project, and the format is widely known. I don’t need to touch that file too often. What would be your personal go-to alternative?
Hello, I am the original creator of Sesterl. Thank you for the suggestion. As pointed out here, I also suspect that YAML would be somewhat unwieldy for configuration formats.
On the other hand, however, I have some concerns about adopting TOML. TOML seems slightly less expressive than YAML or JSON when it comes to handling deeply nested structures (like objects that contain an array of objects each of which contains an array). This tendency appears to be acknowledged to some extent by a core developer of TOML (See the comment). Since I wanted to handle nested data for the configuration of Sesterl projects, I came to think that it would be better to adopt YAML instead of TOML for the time being.
Both YAML files and TOML ones may be accepted as configuration files in the future, though.
Absolutely. But I’d argue that those deeply nested structures might be an anti-pattern for configuring a library – in an ideal reality at least, one we often don’t have.
My main issue with YAML is mostly about its super inconsistent handling of data types and different ways of expressing maps (IIRC, might have been another structure).
Hence if complex nested structures are required I’d likely opt for JSON.
But in any case, I can just talk and talk and was mostly giving a quick opinion based on having to manually manipulate YAML, XML, TOML, JSON and various language-specific configurations (like lists of dependencies in Elixir’s mix.exs project file). That opinion wasn’t intended as a complete and super serious criticism. I am aware that in reality we have to gauge tradeoffs.
(And I’ve also trained myself to mostly use tools to manipulate those types of files anyway. Or a full-blown linter/LSP mode for each of them so it can warn me of a dumb mistake early on.)
Dhall, JSON5 and JSONNet are all very nice but are very niche still and I’ve met resistance from people to adopt them – and honestly they were right to resist, it would take way too much effort to rework your pipelines after all.
To be fair, at this point I think everybody should just embrace Lua for configuration (like it’s done in NeoVim) and let’s all stop fighting, join hands and make the world a better place.
(EDIT: And I have worked with Rust quite a bit so maybe that made me a bit positively biased towards TOML.)
Since this is something built on top of erlang, why not just use printed erlang terms, as in all the config files for erlang. It is just a simple call of file:consult/1 to load.
I created a #sesterl channel on Elixir Slack, I’ll be there from time to time if someone wants to chat.
In other news, I figured out we can use action-download-artifact to install sesterl on Github Actions (at least until build artifacts expire) - example workflow
Hoping to work on generating HTML documentation for stdlib soon (maybe using ex_doc)
Here’s a little bit of code I ported from fsharp to sesterl as an exercise (“complete and easy” bidirectional typechecking, impl I ported - I omitted booleans and ifs)
I just translated the code and not tested well, the original implementation is not well tested either so may contain errors, but anyway my observations are:
equality check in F# is polymorphic and works on any two values of the same type - I just added an erlang helper
andalso, orelse (&&, ||) operators would be nice (issue to add them)
match guards in fsharp can be any function calls??? That’s wild. In that case I had to add only a tiny bit of repetition. I could also just write helper functions for the conditions and chain ifs with if ... then ... else if. But at least the guards that are allowed in Erlang would be good to add some day, destructuring with pattern matching with some additional conditions makes the code a bit more concise.
