It would be, if the code wasn't so horrifically bitrotted at this point. GHC has changed a lot since Elm last got any meaningful update, and they decided to use unsafe GHC primitives everywhere that have no support guarantee. You have to fix a bunch of issues with the compiler source before it will even compile on a relatively new version of GHC.
Nix's raison d'etre is building packages in as much isolation as possible. When building packages, HOME is set to /homeless.
However, for setting up stuff in $HOME, there's a popular tool which uses the Nix expression language as its configuration language: home-manager. Even then, home-manager is more about using nix to configure programs. (I use it to symlink dotfiles). Nix's default is "the stuff it symlinks is read-only".
For "ensure this directory exists", I'd have `mkdir -p <dir you want>` in your shell's init / rc file.
Nix (or NixOS, really), on the surface, looks like a configuration management system and a packaging specification had a functional programming baby.
Now, I'm a systems engineer who generally writes in easy-to-use languages. I've used Arch the past decade and have used a variety of tools to automate my personal systems. My team is composed of systems administrators and network engineers who transitioned into devops-esque roles. Part of the purview of our jobs is to use configuration management systems to codify OS state. This could either result in an immutable image or mutable state on a long-running piece of field hardware.
Nix looks like a potential replacement for something like Ansible/Packer and there are a variety of projects hitting the front page of Hacker News that semi-presents it as a replacement (stuff like nix-ops or image to cloud pipelines).
So as someone who codifies system state as part of their day-to-day job, I'm looking at NixOS as a potential alternative. And there seems to be ABSOLUTELY no community support or documentation for learning Nix from a systems administrator point of view. Which is absolutely maddening because I'm an individual contributor that decides how packaging is done within a organization. Everybody in my team looked at Nix and said "this is absolutely impossible to use - we are literally never going to use this to support our organization."
And that's mostly because there is no guiding principle for how to adapt your mental model to think about the new paradigm if you're coming from something like Ansible... and there is no structured documentation for how to produce an OS state when what you know is YAML blocks or a Ruby based DSL.
I mean, it feels like the bones are there: you use Nix to install packages, start services, configure network interfaces, manage the kernel, etc.
But it also feels like Nix was built by functional programmers for functional programmers - with no UX for the people who would actually manage operating systems within a technical organization. Your syseng team isn't going to be functional programming whizzes. They're going to know Go or Python and be able to do medium-difficulty leetcode problems.
Honestly, there needs to be a "NixOS for Ansible Programmers." And if it's absolutely apples to oranges, then that needs to be communicated upfront somewhere.
Yeah that's super helpful for NixOS configuration options. What trips me up more is configuring particular packages. Usually it's where I want to configure a particular version or github commit of a package for some reason (usually I want a bug fix).
However, a bunch of packages are defined in some bespoke way with various custom config inputs that generate other bits of config and generally are hard to understand. Thinking it through, I'm not sure it's possible for the OP's tool to solve this particular problem.
Yes, FydeOS is a ChromiumOS fork with their own login server and Android support. They recently open-sourced their base build (including Pi image overlay) on OpenFyde.io
There's cadmium there, yeah.
But cadmium is not addictive, and is not a reason for cigarettes being addictive.
Removing the cadmium will not make cigarettes less addictive.
Tobacco plants pull metals in from the soil, which includes cadmium, and radioisotopes of polonium and lead.
So while I was off cigarettes I would vape, then still craved cigarettes. But I was getting all this nicotine, right? Then I smoked one, as planned, one per season while quitting, which changes the self-talk from "I can never smoke again" to "I gotta hold out for Autumn." Then I smoke it, it's so metallic. Incredible. I personally craved the metal, and in particular I did find a study rats preferred some dosage of something with cadmium in it.
For simple languages, it can be a bit of a pain to write and maintain a lexer and a parser. For example, if I'm gonna parse JSON and nothing more, I think it's a bit silly to use a two external DSLs when I could use a simple eDSL. I think Happy and Alex both have their places, absolutely. For parsing full on programming languages I can imagine using parser combinators to be a bit painful. But parser combinators work great for a lot of cases.
I don't really think many people are calling it a panacea. From my experience in the community most people I know who write Haskell write it for productivity reasons (including me, I'd rather be using Idris 2 with algebraic effects though.)
I'm not saying it's somehow magically more productive than other languages, because it's useless to throw around stuff you can't really prove like that, just some people find it to be the case.
I've never found "everyone writing their own DSL" to be problematic, because it's all exposed through the Monad/Applicative/Functor classes, so the way you use them are all very similar. Honestly, the usage of such eDSLs is one of my favourite parts of writing Haskell.
And about interesting applications in Haskell, I'd consider https://hasura.io/ pretty interesting!
EDIT: And about language extensions, yeah, they can be a problem. What we do is settle on a base set of extensions, and if you want to use another one, you need to provide sufficient justification for it.
