I genuinely chose the language for one of my projects based on this reasoning. I want to be in the nice UX gang.

This is exactly what Unison (https://www.unison-lang.org/) does. It’s kinda neat. Renaming identifiers is free. Uh… probably something else is neat (I haven’t used Unison irl)

Turns out that sum of PV($X in 1 year) + PV($X in 2 years) + … converges even though the series is infinite. Look up “perpetual bonds”.

The value of $10 paid annually forever is probably $200-500 depending on [things].

Source: I work in a bank but I’m also shit at finance so take this with a large grain of salt.

- it’s only kinda open source if it’s not on GitHub,

- it’s definitely not open source if it’s not in Git,

- but it can regain its open sourceness if it has an open Discord and the devs are hanging out there.

Here, all my heuristics exposed. (I’m not claiming they’re true or sensible, just saying what my brain thinks.)

(if anyone from SC is reading this -- search our wiki for "Jujutsu" and come say hi!)

Pretty much a strictly better experience than git so far — I’m not going back. `jj undo` is something that I expect in every program now and get vaguely annoyed it's not there.

Not having index/staging is great. Checking out another branch, switching to work on another thing, fixing a typo in an unrelated module, etc are all frictionless. "I'll insert a new commit five-commits-ago, do the refactoring there, and resolve conflicts" turns out to be much nicer than "I'll do the refactoring here and carefully stage it hunk-by-hunk". (I get distracted a lot -- maybe if you aren't tempted by shiny refactorings, this isn't a big deal for you.)

The merge story is also great. I have a commit with multiple parents. I can add more parents to it, change parents, rebase it somewhere, move it around. I have no idea how "rebasing a merge" works in git, but I'm afraid to try. In jj I don't care.

There are a few issues with jj that happen to not be a big deal for me, but I can imagine they could be a dealbreaker for someone else:

- No submodules support (yet)

- No LFS support (yet?)

- Doesn't track renames (yet?)

- When you do `git pull` with rebase, git skips duplicate commits -- this is great if something got rebased/amended on the remote. I was always suspicious that `git pull` just works even if I rebased the branch remotely, and now I know why it works. jj doesn't handle this yet. Not a big deal unless two people collaborate on a branch and want to do it the jj-way with rebases of everything.

Then I switched to Haskell. No (useful) debugger there.

Now I write TypeScript, and.. somehow I never figured out how to do debugging in JS properly. Always something broken. Breakpoints don’t break, VSCode can’t connect to Node, idk. Maybe I should try again.

For TypeScript, they list an example with `instanceof`:

https://counterexamples.org/polymorphic-union-refinement.htm...

In the playground:

https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABA...

I haven’t read volume 1, but apparently half of it is about data scraping, and I expect it to be similarly detailed. So if I were you, that’s where I’d start.

Another option is looking for “robots.txt” at Google Scholar and trying various keywords like “legality”, “scraping”, “case law”, etc.

NB: according to https://www.gtlaw.com/-/media/files/webinars/ian-ballon-may-..., page 4-470, it’s possible that failing to process a DMCA notice may only lead to losing safe harbor for the material identified in the notice, not for the entire service.

So GitHub might just choose to ignore the notice for React, get sued, and win, all without losing the safe harbor.

For less popular repos, I would not be surprised if you could take down any repo literally by submitting a completely bogus notice.

But honestly I still don’t know how much leeway - legally - service providers have in applying their own technical/legal expertise when evaluating DMCA notices. I’d appreciate any sources (court decisions, textbooks, whitepapers, descriptions of actual industry practices, etc) on the topic.

I’m more interested in “why doesn’t the same approach work against big sites”. But it looks like the comment about 512(a) vs 512(c) clarified that.