bmcgee84

4 ms·

1. 1.▲
   Nix and NixOS: a retrospective(bmcgee.ie)

   3 points by bmcgee84 4y ago|2 comments
2. 2.▲
   by bmcgee84 4y ago

   Nothing wrong with the workflow you described, done much the same in the past myself.
3. 3.▲
   by bmcgee84 4y ago

   Yup
4. 4.▲
   Show HN: A reproducible Nix package set for Ethereum clients and utilities(github.com)

   1 points by bmcgee84 4y ago|0 comments
5. 5.▲
   by bmcgee84 4y ago

   Thanks. It's a pattern I saw in https://github.com/LMAX-Exchange/disruptor .
6. 6.▲
   by bmcgee84 4y ago

   I'm new to Go, still finding my way with the idioms. Since there's nothing internal and this is just a small library I can see how it's simpler to flatten the directory structure, which also seems to be how other libraries do
7. 7.▲
   Show HN: Playing with Generics and atomics in Go 1.19(github.com)

   6 points by bmcgee84 4y ago|4 comments
8. 8.▲
   by bmcgee84 11y ago

   Certainly there will be overhead, and I can see how it can quickly mount up. Each person will have a different idea of where the tipping point is in terms of that overhead. For me personally, what was described is not that onerous.
9. 9.▲
   by bmcgee84 11y ago

   30 is a bit of an exaggeration don't you think? I counted 13 tools, 9 of which share (or can share) a common login (Google). This is far from as onerous as you're making it out to be.
10. 10.▲
    by bmcgee84 11y ago

    I've been using Google paid services for almost 4 years now, I've yet to experience any issues. That being said I'm not saying I never will experience such problems, but on balance I would argue the risk/benefit for a sm