I don't think that's really humour - that's an important piece of information.
Curious why you'd recommend that. It seems to me that it costs you something (convenience of standard VC practice on code) and gains you little. I'd recommend checking out the linked presentation above - for things like…
I think this post only gives half of the story. The thing is you need to manage not just your schema (and reference data) but also your DB code - i.e. stored proc etc. For schema, the approach recommended by the OP…
Nix (and NixOS, NixOps etc) is totally, totally awesome (only downside is that it's not a statically typed language itself). Just be warned that it does have a non-trivial learning curve of its own though.
Ah, right, that makes sense - thanks.
I take it you mean OS-level threads then?
"we added a tracker for the number of suspended Haskell threads" - would you mind sharing how you did that? I couldn't see any obvious GHC APIs for it.
I don't think that's really humour - that's an important piece of information.
Curious why you'd recommend that. It seems to me that it costs you something (convenience of standard VC practice on code) and gains you little. I'd recommend checking out the linked presentation above - for things like…
I think this post only gives half of the story. The thing is you need to manage not just your schema (and reference data) but also your DB code - i.e. stored proc etc. For schema, the approach recommended by the OP…
Nix (and NixOS, NixOps etc) is totally, totally awesome (only downside is that it's not a statically typed language itself). Just be warned that it does have a non-trivial learning curve of its own though.
Ah, right, that makes sense - thanks.
I take it you mean OS-level threads then?
"we added a tracker for the number of suspended Haskell threads" - would you mind sharing how you did that? I couldn't see any obvious GHC APIs for it.