To have your Nix-based setup reproducible across different OS (Arch, Debian, Ubuntu, WSL2, MacOS, and NixOS), and have an extensible base config that can be customized to different situations, the go-to framework is home-manager (not NixOS, which only works on NixOS, or NixOS on WSL 2).
You might be interested in nickel (https://nickel-lang.org/), which is a modern take on configuration management based on the experience of Nix/NixOS configurations: purely functional configuration, built-in validation (types & contracts), reusable (functions, modules, defaults), and in addition exports to Yaml, Json, etc.
lix [1] might be less affected. Pierre Bourdon noticed that lix refactored surrounding code 4 months ago [2], and a comment claims that this Lix commit at least patched a different vulnerability GHSA-wf4c-57rh-9pjg [3].
To use lix instead of nix, set `nix.package = pkgs.lix` in your NixOS/home-manager configurations.
> In Hypothesis shrinking is based on the generation process. In Hypothesis generators act a bit like 'Functors' in Haskell, ie you can map over them. (You can also filter and `<>` and do monadic binds etc.)
You are right that the generators in Hypothesis correspond to `Functor`s, so you can map over it. Indeed, in QuickCheck, its `Gen` [1] (type of `arbitrary` [2], the generator in QuickCheck) is a `Functor`, and moreover a `Monad`, so you can do monadic binds on `Gen`.
> So in Hypothesis you can take a generator that produces integers, and create one that produces only even numbers by (in Haskell terms) mapping (2) over it. Now, the shrinker you get for free will also only produce even numbers.
> That's not possible (or at least not easily possible) in Haskell. You would have to define at least a newtype wrapper.
Since `Gen` in QuickCheck is a `Functor`, to multiply its output by 2 to generate only even numbers, you can do this in Haskell as:
fmap (\x -> x*2) (arbitrary @Int)
Or, for those preferring OOP-style chaining:
arbitrary @Int <&> (*2)
where `<&>` is `fmap` with arguments flipped, and `(*2) = \x -> x*2`, and `@Int` is type application to specialize `arbitrary` to generate `Int`.
I think what you are hinting at is that, QuickCheck separates generation and shrinking, while Hypothesis combines generation and shrinking. If you prefer combining generation and shrinking, you may want to check out hedgehog in Haskell, see [3] for a discussion of this trade-off.
I think by using the `MonadGen` in hedgehog [4], you should be able to map over and bind over generators, with automatic shrinking, much like Hypothesis.
Hypothesis was first released in 2013, while hedgehog in 2017, so it is possible that hedgehog was inspired by Hypothesis or similar property-based testing libraries.
But in general, I would be surprised if such ‘functional’ APIs (map, filter, reduce, bind, etc.) could not be ported to Haskell.
Do you have examples where Python’s Hypothesis (and its shrinking) works better than Haskell’s QuickCheck? This would let us improve Haskell’s QuickCheck.
My understanding is that Haskell’s QuickCheck can shrink functions, and with parametric polymorphism, can work with vector types and more [1], which would be difficult if not impossible in Python.
And in general, the base types covered by the shrinking in Python’s Hypothesis should have analogues by the shrinking in Haskell’s QuickCheck. And with deriving, Haskell’s QuickCheck should get shrinking ‘for free’ as in Python’s Hypothesis.
Also, Haskell’s QuickCheck extends to stateful and parallel checking, which is not supported in Python [2].
Reminds me of nix-output-monitor [1], for example see [2].
It makes it easy to understand how individual steps are progressing, and how individual steps relate to the overall plan. It enables me to locate expensive build steps, and possibly to avoid them if steps are failing.
1. their home environments: for packages (some reach for brew on MacOS) and configurations (dotfiles, and some reach for stow).
2. their development shells: for build dependencies (compilers, SDKs, libraries), tools (LSP, linters, formatters, debuggers), and services (runtime, database). Some reach for devcontainers here.
3. or even their operating systems: for development, for CI, for deployment, or for personal use.
Nix provision all of the above in the same language, with Nixpkgs, NixOS, home-manager, and devShells such as https://devenv.sh/. What's more, Nix is (https://nixos.org/):
- reproducible: what works on your dev machine also works in CI and in prod,
- declarative: you version control and review your configurations and infrastructure as code, at a reasonable level of abstraction, to specify what the system should be, not how to get there,
- reliable: all changes (switching generations or profiles) are atomic with easy roll back.
The Nix language is designed for conveniently creating and composing derivations – precise descriptions of how contents of existing files are used to derive new files. It is a domain-specific, purely functional, lazily evaluated, dynamically typed programming language.
So, its key features are:
1. domain-specific: designed for conveniently creating and composing derivations. This reason alone already justifies a new language, or an embedded domain-specific language (embedded in the Guile/Scheme for guix), or a mix of both (Starlark, the build language of Bazel embedded in a restricted Python-variant).
2. purely functional: this underlies the philosophy of the Nix package manager, which aims to be purely functional (also known as hermeticity in other build systems, such as Bazel). Being purely functional in turn underlies the congruence of the NixOS operating system, where you declare what the state the system should be in (as opposed to being convergent, so that you specify how to achieve the desired state).
3. lazily evaluated: similar to other build systems (including Bazel), so that you can build only what you need on demand.
4. dynamically typed: this one is controversial. Being dynamically typed—in other words, not developing a type system—gets Nix out of the door 20 years ago. But users often complain about the lack of proper types and modularity. There are experiments to add a type-and-contract system to Nix, such as Nickel (https://github.com/tweag/nickel).
Most of the above are also listed in the Overview of the One Pager.
Chris, how would you respond to the remark that the article is comparing a flawed Mojo implementation against a more correct Rust implementation? https://news.ycombinator.com/item?id=39296559
> > The TL;DR is that the Mojo implementation is fast because it essentially memchrs four times per read to find a newline, without any kind of validation or further checking. The memchr is manually implemented by loading a SIMD vector, and comparing it to 0x0a, and continuing if the result is all zeros. This is not a serious FASTQ parser. It cuts so many corners that it doesn't really make it comparable to other parsers (although I'm not crazy about Needletails somewhat similar approach either).
> > I implemented the same algorithm in < 100 lines of Julia and were >60% faster than the provided needletail benchmark, beating Mojo. I'm confident it could be done in Rust, too.
Some of these interactive simulations for learning are called “Explorable Explanations” [1], coined in 2011 by Bret Victor, the author of your second link (worrydream.com), which also talks about “Explorable Explanations”.
For more examples, see [2].
Very much agree that this is what explanations and presentations should be in the modern age. I think a documentation language (what Nota and Typst aim to be) is still needed in this age of Large Language Models, when the ideas are more complex than those expressible by natural languages.
https://github.com/nix-community/home-manager