They have wide discretion because most of the INA is subject to "may" clauses instead of "shall" clauses right now.
And this guy has been told, repeatedly, that the very specific law he claims has "may" clauses had "shall" clauses, already; that there was a massive court case over it, and it didn't do jack or shit.
Most of the common complaints are about minimum memory and CPU footprint; VSCode takes comparable resources to run as far more fully-featured IDEs. But if you've got the specs these are unlikely to actually feel bad, it's just kinda goofy.
The biggest problems are pretty hardware-specific, but they've been pretty bad when they pop up. I've had VSCode pull 16+GB memory (especially bad on an 8GB-RAM system) or peg multiple threads at 100% core utilization just idling, all with the default configuration, no extensions. A lot of it seems very dependent on renderer, especially since it started defaulting to a hardware renderer even on Intel integrated GPUs, but sometimes 'normal' developer workstations with multimonitor configurations have gone really wonky. While a less common use case, I've seen bigger problems with massive files in VSCode than in VisualStudio, Intellij, Android Studio (which isn't great itself!), or NotePad++, sometimes to the point where I had to shutdown the computer because VSCode was capping out CPU utilization so high that I couldn't use the mouse or keyboard.
((I've also had problems with deployments of VSCode, rather than VSCode itself. Which, tbf, usually aren't even the Electron developers faults, but since it includes things like a 40+ GB electron update, it's still worth keeping in mind before committing to VSCode as a day-to-day dev environment.))
VSCode defends itself in many cases by pointing to issues with extensions, and to some extent that's fair: just as it's not the Electron devs fault that a distro screwed up once, it's not VSCoders fault that a random html/css extension can peg a cpu. You can't build a framework that can contain every sufficiently dedicated forkbomb without making it useless. But you're almost certainly going to need some extensions just handle basic compiling and debug functionality. And some of them are pretty bad! My worst experience have been with the Java variants, with high idle CPU utilization across the board, but that's mostly because VSCode is the 'officially supported' tool for FIRST FRC so I see it on a lot of different non-optimized hardware. I don't do much webdev, but the few times I've run into ESLint, even with a minimal ruleset and properly configured (why is apply-rules-on-typing even an option?!) it's been pretty painful.
- Prev
- Next
Ar'kendrythist handles power scaling better in the first few books, where there's not merely charged conflict but the protagonist being a pretty severe underdog. Even well after that, there's always a bigger fish until (arguably) the back half of the last book, and that's the point where the protagonist dying stops mattering and what the villain could do to everybody else becomes more important.
While it's still a little obnoxiously progressive-in-the-inevitability sense even by my standards, that works out pretty well for keeping the tension high; what fixing a wasteland of slavery and infighting even looks like is a more interesting question than who's power is more maximum and can blow up a city (though that happens a lot too). The author's also willing to kick out legs under the protagonist often enough that even some situations where it seems like they should be certain to win, a problem will show up and whatever the heroes built collapse. Never quite to the point of being unfair, though it gets a little close at times.
More options
Context Copy link