To convince more companies to use Haskell and grow its user base basic things like locking should just work for reproducibility; at least for the part that the programming ecosystem has under control, i.e. Haskell packages. You won’t convince many companies to adopt Nix (yet), especially not at the same time with adopting Haskell. They’re sold to Docker for now to manage everything else like c libs…
cabal freeze seems like an attempt at lock files before the programming community found a good structure as used in Javascript or Rust. Workarounds like downloading/pinning some Hackage index or manually post-processing the freeze file feel just like, well, workarounds. If a freeze file looks like a lock file, it should behave conveniently, predictably like lock file or clearly state what it’s for (and either way we should improve locking with hashes etc, ideally with some widespread parseable format like json).
Regarding Nix: The lack of a modern locking mechanism clearly shows in the cumbersome Haskell Nix support: the official Nixpkgs tools don’'t even look at your Cabal versions or freeze files, because they don’t contain enough information for reproducibility. You need a large separate out-of-tree project like haskell.nix that requires import-from-derivation to work around the lock shortcomings, and oftentimes it doesn’t work out-of-the-box. In Rust for example, with its easily parseable json lock file Nix packaging is so much easier, because Nix can build upon it.
Another important but expected tool that has to work around locking shortcomings is the widespread version-bumping tool Renovate. It seems to use workarounds like “git trailers” where it would just bump the lock file in other languages.
So freeze files definitely need some improvements.