Skip to content

Commit

Permalink
improve motivation
Browse files Browse the repository at this point in the history
  • Loading branch information
PgBiel committed Apr 26, 2024
1 parent 7358eb6 commit c2c583e
Showing 1 changed file with 5 additions and 5 deletions.
10 changes: 5 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -78,19 +78,19 @@ You can install Glistix in one of the following ways.
## Motivation
Glistix aims to tackle **several problems that arise when working with slightly more complex Nix code.** Whereas basic Nix is fairly straightforward to use (including declaring attribute sets, perhaps adding a few conditionals), it is evident that leaving that happy path and writing more involved code **can take considerable time and/or effort** due to the **lack of type-safety in Nix,** which leads to **limitations in Nix LSPs** and often **hard to understand errors** which could have been avoided with static type-checking - that is, checking the correctness of your Nix code before you even try to evaluate it.
Glistix aims to **improve the development experience of working with more complex Nix code.** Whereas Nix can be fairly straightforward to use at its core (the language itself is tiny in terms of syntax), it can be observed in reality that writing more involved Nix code **can take considerable time and/or effort to get right** due to the **lack of type-safety in Nix,** which leads to **limitations in Nix LSPs** and often **hard to understand errors** which could have been avoided with static type-checking - that is, checking the correctness of your Nix code before you even try to evaluate it.
Personally, I (author of Glistix) have faced this kind of problem while **writing my own NixOS and Home Manager modules** - oftentimes the logic can get a bit involved, in which case it'd be nice to have static type-checking and other kinds of validation, not only for better autocomplete and LSP experience in general, but also to avoid unnecessarily long debugging sessions induced by what could be reduced to a simple type mismatch.
Personally, I (author of Glistix) have faced this kind of problem while **writing my own NixOS and Home Manager modules** - oftentimes the logic can get a bit involved and become particularly hard to debug and/or expand on without some form of static type-checking (and thus proper autocomplete and so on).
While there have been **several attempts to add some form of static type-checking** to Nix, very few have had great amounts of success so far. It always seemed like Nix needed some quite large (and thus unfeasible) changes to make it possible.
**That's where Gleam comes in**. Gleam is a **functional and statically-typed language** with **friendly syntax** and **great tooling** (including the compiler and its **helpful errors,** great support for **unit testing**, good **LSPs** in editors, and so on). What's more, **Gleam was designed for transpilation to other dynamically-typed languages** (namely Erlang and JavaScript). So, it was **the perfect match:** we could leverage the Gleam compiler and its tooling to **write any slightly more complicated logic with Gleam,** transpile that to Nix, and **keep complexity of actual Nix source code at a minimum** - the Nix code would just **call the transpiled Gleam code as much as possible.**
**That's where Gleam comes in**. Gleam is a **functional and statically-typed language** with **friendly syntax** and **great tooling** (including the compiler and its **helpful errors,** great support for **unit testing**, good **LSP support** across editors, and so on). What's more, **Gleam was designed for transpilation to other dynamically-typed languages** (namely Erlang and JavaScript). So, **it was the perfect match:** we could leverage the Gleam compiler and its tooling to **write more complicated logic with Gleam,** transpile that to Nix, and **attempt to keep complexity of actual Nix source code at a minimum** - the Nix code would then **focus on calling the transpiled Gleam code as much as possible**.
Thus **Glistix was born:** it adds a **Nix backend to the Gleam compiler**, alongside **auxiliary features and tooling to make Gleam easier to use within the Nix ecosystem.** The main goal is precisely to **integrate Gleam and Nix together as much as possible,** so that you may **write Gleam code and use it within Nix**, and **vice-versa** (Gleam code can invoke Nix functions through FFI).
Importantly, this is very much **inspired by [PureNix's approach](https://github.com/purenix-org/purenix)**. That project, which allows compiling PureScript to Nix, was one of the options considered before settling on Glistix's design, and has similar goals regarding type-checking and tooling. The **main difference** in our approach is **the usage of Gleam,** whose **simplicity in syntax, concepts and usage makes it stand out** among other languages. Still, make sure to check out PureNix as well if you're interested in learning more about alternatives!
Importantly, this is very much **inspired by [PureNix's approach](https://github.com/purenix-org/purenix)**. That project, which allows compiling PureScript to Nix, was one of the options considered before settling on Glistix's design, and has similar goals regarding type-checking and tooling. The **main difference** in our approach is **the usage of Gleam,** whose **simplicity in syntax, concepts and usage makes it stand out** among other languages. Nevertheless, make sure to check out PureNix as well if you're interested in learning more about alternatives - it is an awesome project as well!

We hope you will enjoy using Glistix for your Nix projects!
**We hope you will enjoy using Glistix for your Nix and NixOS projects!**

## Features

Expand Down

0 comments on commit c2c583e

Please sign in to comment.