The too good to be true alarm bells in my head are ringing. There's almost no way it delivers on all of the features listed here. Gonna need a lot of proof to back all of this up.
I'd say there's also a big difference in the sort of correctness that static types guarantee vs the correctness that tests give you. Tests, to borrow some phrasing from Donald Rumsfeld, are only really effective against "known unknowns" not "unknown unknowns." Tests are only as thorough as the test writer and the "known unknown" cases they can come up with to test against. But as software developers we've all been in the situation where some case that you didn't think to test for is what winds up causing a bug (an "unknown unknown").
Static type systems on the other hand, can give you much greater guarantees of correctness (if they're sound). Due to the Curry-Howard isomorphism we know that programs in sound static type systems are the same as mathematical proofs. That's a much stronger guarantee than what you're given by testing alone. The problem of missing a case in your testing goes away if you have a mathematical proof that that case cannot occur. You've taken away some of the burden of thoroughness from the programmer and given it to the compiler instead.
In a perfect programming utopia we would all encode the desired properties of our programs in static types and have no need for testing because we'd have proofs of correctness. The problem of course is that writing those kinds of proofs into types is very time consuming and tedious and isn't realistic for most software development. So we still need tests to cover what is too expensive or complicated to type.
Oh, for sure I still love monads. I miss Haskell's do syntax in every other language. I think it's a great design pattern that starts popping up constantly once you know where to look. My objection is being forced to use monads due to the language's lazy by default semantics. You get this problem with haskell where the IO monad eventually just pollutes a huge chunk of your code because you can't safely sequence side effects without it. Sometimes I just wanted an escape hatch that would let me do side effects that I knew to be safe/harmless. Haskell has unsafePerformIO but it truly is unsafe because you can't guarantee the execution order of your side effects, which makes it useless as an escape hatch for a lot of purposes.
I used to be a big Haskell programmer. While I still love the language, I've really come around to the idea that strictly evaluated functional languages like F# or OCaml are the best for programming in. You get the nice functional features but don't have the straightjacket of laziness forcing you into certain design decisions. It's really nice sometimes to be able to mix in impure, side effectful code without having to thread it through a monad. The OCaml family feels like a nice blend of good sound functional features with enough escape hatches to be productive in real world programs that might occasionally need arrays or mutable state or IO. Laziness by default also makes things like debugging or reasoning about performance frustratingly difficult. I do miss Haskell's typeclasses in these languages, though. My ideal language is basically Ocaml/F# but with Haskell's syntax and typeclasses.
Almost all creative works make the majority of their money in the first few years from their release, if not the first year itself. Movies, TV, etc. will still be extremely profitable businesses under a shorter copyright. Shorter copyrights also serve to help encourage creators and artists to continue to produce new works for the public to enjoy.
How else did we get our current extreme copyright lengths? Were regular people advocating for this? Or was it for wealthy corporations and their shareholders? Did anyone responsible for the Great Recession face any legal consequences for destroying our economy and putting people out of their homes? Did people go to jail?
Call it hyperbole if you want, but it's the reality we're living in.
Revert copyright back to the original 28 years and Disney's increasing domination of the media market becomes less of a concern. Of course this probably won't happen because the US and other world governments exist to serve Disney and their shareholders, but it's the easiest way to fix this that doesn't involve a long and complicated antitrust case that the government might lose in the courts.
If you want to be even more daring and spend a little bit of public money, you could have a publicly financed streaming service with most major public domain works. You could make it available through the Library of Congress.
To me Dart is pretty disappointing. Modern languages like Swift and Rust have shown the power of incorporating functional features like sum types and pattern matching. Dart just feels like the same sort of OO language we've been getting since Java became popular.
Edit: Also the continued existence of null in new programming languages is a baffling choice to me.
The US is the wealthiest country in the history of the world. If we want to make providing disabled people with fulfilling jobs that pay a good wage a priority, we are entirely capable of accomplishing that.
It's more likely that they use it to depress the wages of abled workers. This sort of unskilled labor isn't exactly scarce enough to cause meaningful competitive pressure like you describe.
Very skeptical that this is due to Amazon's generosity and not just because they can tap into an underpaid and underemployed workforce. They don't seem to be giving these people access to the jobs that actually make money at Amazon. I'm very wary of feel good stories about employing people with disabilities in low paying jobs with lots of repetitive manual labor. Often it's a way to get cheaper and more easily exploited labor that you can get your PR team to spin as charity.
Typically with crypto you want to stick with one major industry standard implementation that is strenuously verified. It's probably more concerning if everyone's using their own.
TLDR; linked lists' theoretical performance advantages are often negated by years of hardware optimization for dealing with arrays.