-
-
template-nix
The nix template, configured for Gitpod (www.gitpod.io) to give you pre-built, nix based ephemeral development environments in the cloud.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The needs of the Nix language differs from that of a general purpose programming language. Its sole purpose is to output a self-contained and deterministic package build script. As such, it doesn't need persistent state. Every external output, such as source tarballs has their hashes verified so it should wield the exact same result every time it's evaluated. If any external output doesn't match expectations, evaluation would be aborted immediately.
> And it would not be possible to keep track of anything. No counting, no transformation of data, nothing.
All of this is possible without state. Counting could be done with, say, 'builtins.length'. As for transforming data, that's what programming languages literally do. The Nix language isn't an exception here. In fact, the Nix language has everything to do with transforming data. It transforms high level package definitions to lower level build instructions.
> I see a lot of overhead coming from these mental gymnastics with no benefit
At least with the Nix language, there's no mental gymnastics going on. Defining a package is as simple as it gets, as can be seen here[1]. The benefits are reproducible package builds and composability. Since Nix functions don't contain state, it's really easy to combine abstractions and make modifications to packages compared to conventional package managers. See the Chrome example in the NixOS Wiki[2].
[1]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
[2]: https://nixos.wiki/wiki/Overlays
