If you found out through gdb that your code compiled with -O0 was still somehow optimized by gcc, or if you found out that your gcc did not optimize your code aggressively enough although you gave it -Ofast, check out this issue [0].
Having debug symbols enabled should be the default in my opinion. Especially in a partially self-compiled distribution like NixOS. The threshold to submitting bugs should be low.
Unf I'm seeing a unicorn (GitHub fail whale) currently, so I cannot see the issue.
At work we use nix+cabal, not nix+stack. Not for any compelling reason other than we've been in business longer than stack has integrated with nix. We have a repo for our consolidated framework that implements our workflow and ops infrastructure parameterized on the project we're building, so we check this in as a submodule in a new project. One thing we do in particular is that we generate nix expressions from cabal files at build time, so we only need to maintain one without updating the other with cabal2nix with every change.
With all this in place in a project, building is as easy as nix-build. Development is as easy as nix-shell. For convenience we have scripts that wrap the workflow for activating a ghci or ghcid shell and some other functions. Deploying to AWS is easy, even though I've never done it myself.
One problem we have is build times with nix. In order to ameliorate this, we have a build server set up with the out of the box nix infrastructure. A developer only needs to build when they make their own changes; within a few minutes of a push the build server will compile the new project derivations and they'll be available to everyone else as binaries. It all Just Works.
As for specifics, the currently implemented Haskell infrastructure in Nix is pretty good. For my personal development I have a few auxiliary scripts a friend of mine cooked up to do very streamlined development. I'm still getting used to it so I can't say much on that front, but it's a very thin wrapper over the stuff in nix. The nix language is really gnarly, but if you can grok it then you can program your build environments in a purely functional way, and that's amazing! I would recommend to every developer that they set up their environment the way they want it. Nix is very flexible and robust. It will handle everything for you, you just need to tell it what you want.
You'll also notice that I put my nix configuration in a shared /home directory instead of /etc/nixos. I think I'm the only person to ever do this because I am neurotic and having to sudo to use version control on my OS config isn't my fave workflow.
Quick question, the url https://nixos.org/nixos/download.html lists the same url for both 32 and 64bits iso, I wonder if these are multiarch images or just an error.
Because of how Nix works, upgrading should leave your system in an identical state as if you had done a fresh install.
You can even downgrade if you want. I've switched to unstable and back to 16.03 (and now to 16.09) without a reinstall and everything still works perfectly.
The main issue I had while using NixOS is that it has a small and somewhat broken set of packages. This is compounded by the very incomplete Nix documentation - its way too hard to create new packages.
Perhaps it is hard to discover how to, but I was about to post here and say one of the best things about nix is how easy it is to hack and add packages. It does require a bit of learning about how it works, but once you do the whole system is quite understandable. It's also very easy to test out things locally, overriding and extending the nix package collection. It is fairly straightforward to set up, build and install your own local projects as nix packages. Even I -- a mere web developer, who mostly uses OS X -- got a package definition merged into the main repository, it was that simple.
I agree the documentation needs work. It can be a real exercise in institutional knowledge sometimes to piece things together. I'd love to help you package something new, or fix an existing package if you would like. The thing that kept me going is how easy it was to fix ... after learning the incantations.
I think the project as a whole would welcome suggestions on where to improve docs as well, and would _definitely_ appreciate some new docs being written. It is hard to do this once you're too familiar :(.
[0] https://github.com/NixOS/nixpkgs/issues/18995
Yeah. The devs believed it was okay to make gcc -O2 by default and impossible to override from the command line you gave to gcc.
If you encountered this issue I hope google could quickly bring you to that issue on github. Good luck and don't waste hours to figure out why.