It's still quite problematic IMO

Meh. You're not exactly wrong but I think it's pretty common for user-generated content sites to follow a logical delete strategy. It holds open the door to being able to restore data deleted by end-user error, and within the bounds of their data retention policy keeps data around that may be useful for internal analysis.

Actually come to think of it seems plausible that they only have ~3 years of logically deleted data, having purged deleted records older than that.

It's also plausible they had all the is-logically-deleted information in some redis datastore that wasn't being reliably persisted to disk and the process had to be restarted for the first time 3 years.

I'm actually leaving my restored comments untouched for now out of curiosity about what they'll do about it now that the issue is known. I think that will probably answer the question about whether this was accidental or intentional.

I wouldn't put it past Reddit to restore old comments given sufficient motivation, I just have a hard time imaging how the cost/benefit analysis would say that this is a good idea at this specific point in time.

It seems plausible that with all the other churn going on at Reddit - and as others have noted a large number of people deleting comments and accounts and maybe subs - that they accidentally restored some data-store to the wrong snapshot or something.

I just don't understand how the difference between "we HAVE N million comments" and "N million comments HAVE BEEN posted" in some investment deck could be worth the risk to reputation and good will, not to mention potential GDPR violations or bad press from doxing stalking victims or whatever.

Someone else mentioned SEO as a possible motivation. I might buy that. If Reddit is losing PV and DAU and restoring a bunch of old content would offset some of that with organic search traffic, that seems like something they might do.

Checking just now I see that comments up to 3 - 4 years old have been restored.

I'm not going to speculate as to why (beyond agreeing it's more likely to be incompetence than malice) but in my case at least there are definitely long deleted comments that have been restored.

Curiously, based on the DOL guide at [1], which to be fair isn't text of the actual law but it is an official government publication meant to explain it, _technically_ it is _not_ acceptable to give 60 days of severance in lieu of notice, but since the penalty for violating the act is a 60 days pay and benefits to all impacted employees, it works out the same either way.

> Can I pay my workers their salary and benefits for 60 days in lieu of notice? > > Neither the Act nor the regulations recognize the concept of pay in lieu of notice. WARN requires notice, making no provision for any alternative. Failure to give notice does a significant disservice to workers and under-mines other services that are part of the purpose of the WARN Act. However, since WARN provides that the maximum employer liability for damages, including back pay and benefits, is for the period of violation up to 60 days, providing your employees with full pay and benefits for the 60-day period effectively precludes any relief

[1] https://www.dol.gov/sites/dolgov/files/ETA/Layoff/pdfs/_Empl...

In other words, when the WARN act applies I don't think it's sufficient to give 90 days of severance. Those employees must remain on the payroll during the notice period.

I think it's common to tell these laid-off employees "you're on the payroll but not expected to report to work during the next 90 days", so it's kinda a distinction without a difference, but it does or at least could have an impact on things like benefits, bonus payouts and vesting.

But I stand by the statement that most able-bodied Americans could find some way to incorporate more human-powered transport into their routine if they really wanted to. And in many cases they could do it without any adding any superfluous travel. I.e., it may be slower or even less convenient in some way, but it was a trip you were going to make anyway. You're just changing the mode of transit.

(Incidentally if it's truly too dangerous or inconvenient to walk across the Costco parking lot with a loaded shopping cart I think we're well on our way to the people from Wall-E.)

Surely somewhere in that more-than-half-of-all-car-trips there are a few examples of car errands that could be easily replaced by bike, scooter or foot.

EDIT: incidentally even in the most car-centric dystopian suburb there are ways to incorporate more walking into your routine. The next time you go to a strip-mall or big box store you could park on the far side of the lot and walk to the door. A minor inconvenience in both time and effort, but you could probably add 1/2 mile or more of walking to your Saturday afternoon errands that way.

This is not a lot cheaper than what you quoted, but for ~$2k/mo you can rent a 1 BR apartment in one of those relatively new, relatively fancy condominium-style medium-rise buildings at Reston Town Center (essentially the "downtown" area, or at least one of them) which puts you in very short walking distance of a bunch of tech offices and even a good number of nightlife and entertainment options. You could easily live the "15-minute city" life there. It would be a little bit like living in a large outdoor mall, but it's a very walkable "neighborhood". (EDIT: the DC metro system is also within walking distance.)

There are a handful of other "tech hubs" like that scattered around the DMV.

It may not be feasible in all cases, but it's definitely feasible in some cases, and it absolutely works.

In particular, bike commuting is an excellent way to integrate exercise into your daily routine without going to the gym or the tedious exercise-for-it's-own-sake activity. It's not practical for everyone, but between power-assisted e-bikes and the observation that you don't need to do it _every_ day, it's a lot more achievable than many think.

Similarly, if you take public transport to work (or elsewhere) you could get off a stop or two early and walk the rest of the way to get some of the benefits even if lacking the time or stamina to do the whole trip on foot.

Integrating exercise into some task or activity you were going to do anyway (e.g., commuting or running nearby errands, if applicable) is much easier than trying to maintain discipline and motivation to exercise as a dedicated, stand-alone activity.

As a baseline, Electron performance _should_ be no worse than a regular SPA-style web UI running in the browser. Unless you find _everything_ on the web "irritatingly slow" it's surely _possible_ to create an Electron app with acceptable performance.

From my perspective anyway, I've both used and contributed to multiple Electron-based apps with performance that was not only "adequate" but not noticeably different from a typical native app. Basic Electron apps (done correctly) will look and feel more or less like a web app but perform more or less like a web app too.

FWIW there is a lightly-curated list of electron apps at https://www.electronjs.org/apps

I'm not sure offhand which of those is a good example of UI/UX and performance, but if you poke around with some of the medium-scope stuff (not too basic, not too ambitious) I'll bet you can find some examples.

UPDATE: I spot checked a few of those Electron apps for the fun of it. Here are a few examples you may find compelling:

* Deer - https://github.com/abahmed/Deer/releases/tag/v1.0.0 - A simple styled-text note-taking app that was last updated ~4 years ago. I don't _love_ all the UX choices personally but the performance seemed reasonable in my short test, especially considering the version of Electron they are using is 16 major releases out of date. There are probably more robust note-taking examples in that list (e.g. Inkdrop, Notable, Notion), this just happens to be the one I grabbed.

* Pencil - https://pencil.evolus.vn/ - A much more complex app for drawing fairly sophisticated Visio-like diagrams and UI mock-ups. Performance wise it seems about as responsive as a typical native app on my nearly 3 year old MacBook. But it may have large-ish baseline memory footprint so YMMV.

* I notice that some well known apps (or at least brands) are listed, like Trello, Asana, Notion, GitHub Desktop, Basecamp, WordPress, Twitch, Skype, Signal, Quickbooks, Light Table, Figma, WhatsApp, etc. For several of those I for one was not aware that they were Electron-based, and I'm guessing at least some (but probably not all) of those work pretty well. I think I've used both GitHub Desktop and Notion without anything to complain about but I'm not surprised that they are Electron apps. I've definitely used that Skype client and never noticed that it was an Electron app. I've never used it, but I'd bet Trello works well too.

IMO I think this demonstrates my original point in this thread: When an Electron app is well-engineered you don't even notice that it's Electron. It's survivor bias. People think Electron apps are bad because it's the bad apps that are noticeably Electron-based.

But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-able.

No joke, it is legitimately hard for a newbie to figure out how to close emacs, which is pretty ridiculous. (It's `C-x C-c` btw, but I honestly don't know how a first-time user could figure that out on their own without a menu. You need to be _told_. It's absolutely crazy that you need to consult the manual to know how it exit the program.)

EDIT: It looks like this thread is too deep for me to post a genuine reply, but just to respond to the "it's just plain emacs too" comment. Good point, and I was aware of that but I didn't know what to call the plain-vanilla Windowed/GUI-enabled emacs. I guess it's just "emacs". I actually hesitated on naming aquaemacs for exactly this reason, which is why I hedged with "or similiar".

FWIW you _can_ get emacs to launch as quickly as, say, vi, and to respond to input as quickly as just typing in the terminal (but in my experience the default GUI doesn't have noticeable input latency):

* `emacs -nw` will launch emacs in a terminal rather than a OS-native GUI window. This has surprisingly little impact on the interface or usability, but it does make cosmetic tweaks like font-rendering more difficult.

* `emacs --daemon` will start an "emacs server" process running in the background, and `emacsclient` will connect a UI instance to it (so you don't need to re-process all your .emacs stuff each time)

That said you can probably introduce a lot of input latency by hooking a slow method to the keypress event, but that applies to Atom and VSCode as well as emacs. But all three of them seem to do OK suggesting auto-completions of one kind or another, which must be handled on keydown or similar, so maybe that's not as critical as I assume.

I usually have a text editor open all the time anyway (recently Atom, lately VSCode) so the time-to-launch isn't that big of a deal in practice (and isn't _that_ large to begin with) but I am disproportionately, irrationally annoyed every time I need to wait for the editor to start.

Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.

If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).

If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.

That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.

Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.

I think `:packadd` or something may be the equivalent for vim.

But VSCode is also less responsive, more resource heavy and ultimately less flexible or extensible. Vim and emacs have more of a learning curve, and their configuration is more fiddly, but the biggest hurdle is probably that the interfaces they use for this predate modern GUI conventions. Notably the "search by keyword, click install, done" workflow for adding extensions is definitely standard behavior in emacs (and vim too, I assume).

Configuration fiddling aside - and that shouldn't be a daily activity - "Vim and Emacs cannot compare to VSCode when it comes to productivity" is a claim that does not hold up to scrutiny. In the hands of an expert user, emacs (and again, I assume vim too) is definitely more capable and productive than VSCode. I'm fairly confident this could be demonstrated objectively. They just _do more_ and can be made to do it _exactly the way you want_ them to. The learning curve for vi/vim and emacs represents an investment, but one that can pay off handsomely.

The topic of this thread is actually a perfect example of one of the major advantages of these "classic" editors. Atom - and countless editors that have come before - has been sunset. And it will eventually happen to VSCode too. Your Atom customization skills (and mine) are wasted. Now we need to pick up a new editor and climb a new learning curve. But vim or emacs mastery is a skill you'll literally be able to use for the rest of your career.

It's absolutely valid to decide that learning how to use these esoteric tools well is not worth the effort to you personally, but there _is_ a reason these tools have been around for nearly half a century.

But I agree with your core point. I use VS Code all the time, regularly switching between maybe a dozen different projects, and I personally don't run into performance issues or resource constraints very often. Certainly less often than with heavyweight IDEs like IntelliJ, Eclipse or XCode. But I felt the same way about Atom as well, so maybe my typical project/workflow/usage pattern is less resource intensive than others. (For one thing I hardly ever run apps from _within_ the IDE, I prefer to build/test/run from a terminal, so that might be a factor.)

VS Code isn't quite as responsive or quick to start as something like vim, or even emacs when run in a terminal, but its resource demands seem roughly on par with any other feature-rich IDE/editor in my experience.