Part of the problem is choosing from those options (when you have a choice). Open-ended questions like that nuke my productivity when starting a project because I spend more time researching and weighing options than actually programming.
As time has gone on, I’ve increasingly become a fan of restricting how many ways devs can do something.
you just pick one and go with it.
Might be my ADHD, but I can never just do that. But I posit that excess choice hurts feature development pace by wasting effort on reinventing the wheel.
A good example is the Nix ecosystem:
Nix expression language provides almost no constraints, leaving users to do the same things in a bunch of ways, and preventing a clear notion of which way is generally best from arising…which makes upstream super conservative with implementing new features the community wants, because any decision might break one those things. Leaving us with a 5+ year old “experimental” feature + CLI used by 80% of users, but no consensus on an official implementation. So many simple upstream changes become a series of 3 competing community projects providing a solution for that feature, further preventing consensus.
It’s true that you can easily fall into analysis paralysis when you start learning JS, but honestly things have somewhat stabilized in recent years. 10 years ago everybody was switching frameworks every 6 months, but these days we’re going on 8+ years of absolute React dominance. So I guess that’s it for the view layer.
The data layer has seen some movement in more recent years with Flux then GraphQL / Relay, but I think most people have settled on either Apollo or react-query now (depending on your backend).
On the backend there was basically only express.js, and I think it’s still the king if you only want to write a backend.
Static websites came back in fashion with Jekyll and Github Pages so Gatsby solved that problem in js-land for a while, but nowadays Next also fulfills that niche, along with the more fullstack-oriented apps.
Svelte, Vue, Aurelia and Mithril are mostly niche frameworks. They have a dedicated, vocal fanbase (see the Svelte guy as sibling to your comment) but most of the industry has settled along the lines I’ve mentioned.
I want to add that, like you, I’ve become a big fan of restricting the numbers of ways to do something.
IMO, It’s more time wasted choosing, more time wasted reviewing, and makes it easier to overlook errors. I want more opinionated languages and frameworks.
I reallt like the approach taken in Rust’s borrow checker, where good, safe, and sometimes overbearing design choices are enforced by default, but you can explicitly declare exemptions. Makes identifying potential problem code blocks easy too.
This is exactly why I always tell myself it’ll be super fun and easy to replace a Linux distro on one of my machines, and I do the fun part of balancing release style, desktop environment, all the shiny stuff…know what stops me dead in my tracks upon install?
Deciding a file system. Because it feels like such a weighty decision with far-reaching effects.
According to internet research, they’re all the right one, they’re all the wrong one, they’re all just fine, and don’t use any of them because they’ll wipe all your data. Lol
Your documentation on file system choice is either anecdotal or engineering-masters-thesis, seemingly no in-between.
I’ve just decided BTRFS with snapshots is great, and keep good enough backups that I shouldn’t have to fiddle with the fanciest deep-knowledge features to save my system.
Your documentation on file system choice is either anecdotal or engineering-masters-thesis, seemingly no in-between
God, I feel this so much. All the benchmarks are such ass too.
I have also struggled with picking a disk layout + FS, and landed on using a single BTRFS partition with FDE.
For now, I’m happy. Unless there’s a new FS that definitively beats BTRFS on NVMe perf and supports copy-on-write and something that makes FDE as easy as subvolumes that definitively beats BTRFS on NVMe drives, I won’t even bother looking into it again.
I’ve considered moving to a RAID setup, but it seems like more trouble than it’s worth, since I do regular /home backups & NixOS keeps my entire system config in version control.
If I ever consider a different disk setup, I’m just going to fire up a clean distro install on a spare NVMe and benchmark my most common tasks myself.
NixOS has killed my decision paralysis for choosing distros and desktop env stuff since I can just enable whatever in my config, try it out, then revert if I don’t like it enough to switch.
Only thing I can’t trivially test is disk layouts, but with disko, it might be easy enough to create a custom NixOS installer that:
auto-installs a disk layout & your config
reboots
runs your benchmarks
writes the results to disk
reboots into the live image, repeating this for a list of disk layouts.
I feel the same way. Designing good, opinionated APIs is HARD, but it also provides the best experience for both the author and the consumer.
Prettier is the undisputed king of JS formatters because it has no options by design. You set and forget.
One of the reasons iOS is so successful is because they lock down their APIs and put strict standards on apps, making it hard to write something that doesn’t at least look good and slot into the OS well.
Part of the problem is choosing from those options (when you have a choice). Open-ended questions like that nuke my productivity when starting a project because I spend more time researching and weighing options than actually programming.
As time has gone on, I’ve increasingly become a fan of restricting how many ways devs can do something.
Might be my ADHD, but I can never just do that. But I posit that excess choice hurts feature development pace by wasting effort on reinventing the wheel.
A good example is the Nix ecosystem:
Nix expression language provides almost no constraints, leaving users to do the same things in a bunch of ways, and preventing a clear notion of which way is generally best from arising…which makes upstream super conservative with implementing new features the community wants, because any decision might break one those things. Leaving us with a 5+ year old “experimental” feature + CLI used by 80% of users, but no consensus on an official implementation. So many simple upstream changes become a series of 3 competing community projects providing a solution for that feature, further preventing consensus.
It’s called Analysis Paralysis caused by Overchoice. Basically, the more similar options there are, the harder it is to pick.
It’s true that you can easily fall into analysis paralysis when you start learning JS, but honestly things have somewhat stabilized in recent years. 10 years ago everybody was switching frameworks every 6 months, but these days we’re going on 8+ years of absolute React dominance. So I guess that’s it for the view layer.
The data layer has seen some movement in more recent years with Flux then GraphQL / Relay, but I think most people have settled on either Apollo or react-query now (depending on your backend).
On the backend there was basically only express.js, and I think it’s still the king if you only want to write a backend.
Static websites came back in fashion with Jekyll and Github Pages so Gatsby solved that problem in js-land for a while, but nowadays Next also fulfills that niche, along with the more fullstack-oriented apps.
Svelte, Vue, Aurelia and Mithril are mostly niche frameworks. They have a dedicated, vocal fanbase (see the Svelte guy as sibling to your comment) but most of the industry has settled along the lines I’ve mentioned.
I want to add that, like you, I’ve become a big fan of restricting the numbers of ways to do something.
IMO, It’s more time wasted choosing, more time wasted reviewing, and makes it easier to overlook errors. I want more opinionated languages and frameworks.
I reallt like the approach taken in Rust’s borrow checker, where good, safe, and sometimes overbearing design choices are enforced by default, but you can explicitly declare exemptions. Makes identifying potential problem code blocks easy too.
This is exactly why I always tell myself it’ll be super fun and easy to replace a Linux distro on one of my machines, and I do the fun part of balancing release style, desktop environment, all the shiny stuff…know what stops me dead in my tracks upon install?
Deciding a file system. Because it feels like such a weighty decision with far-reaching effects.
According to internet research, they’re all the right one, they’re all the wrong one, they’re all just fine, and don’t use any of them because they’ll wipe all your data. Lol
Your documentation on file system choice is either anecdotal or engineering-masters-thesis, seemingly no in-between.
I’ve just decided BTRFS with snapshots is great, and keep good enough backups that I shouldn’t have to fiddle with the fanciest deep-knowledge features to save my system.
Might be my ADHD as well. XD
God, I feel this so much. All the benchmarks are such ass too.
I have also struggled with picking a disk layout + FS, and landed on using a single BTRFS partition with FDE.
For now, I’m happy. Unless there’s a new FS that definitively beats BTRFS on NVMe perf and supports copy-on-write and something that makes FDE as easy as subvolumes that definitively beats BTRFS on NVMe drives, I won’t even bother looking into it again.
I’ve considered moving to a RAID setup, but it seems like more trouble than it’s worth, since I do regular /home backups & NixOS keeps my entire system config in version control.
If I ever consider a different disk setup, I’m just going to fire up a clean distro install on a spare NVMe and benchmark my most common tasks myself.
NixOS has killed my decision paralysis for choosing distros and desktop env stuff since I can just enable whatever in my config, try it out, then revert if I don’t like it enough to switch.
Only thing I can’t trivially test is disk layouts, but with disko, it might be easy enough to create a custom NixOS installer that:
I feel the same way. Designing good, opinionated APIs is HARD, but it also provides the best experience for both the author and the consumer.
Among other examples.