slikts

Recursion is a powerful, relatively low-level approach, and the price for expressive power is readability, but it has legit use cases. What you said has a grain of truth in that usually you should prefer combinators like map or filter (if you're doing FP), but just throwing away recursion is silly. Having a strong opinion on it and not seeming to know about TCO is also not a good look.

Without modules there can be dependency hell: conflicting subdependency versions, unless all your dependencies update their subdependencies in lockstep.

You mean statically, not strongly typed. Strong typing roughly means avoiding implicit type coercion.

This is a common straw man; PHP 5 and 7 made large strides, but that's because there was so much to fix, and there still is and will continue to be, like lack of first class functions, actual modules, etc. PHP is also unsuitable for persistent processes like serving WebSocket.

Never, since PHP is fundamentally flawed, and trying to redesign it would make the split between Python 2 and 3 pale in comparison. PHP's main selling point is backwards compatibility and the existing ecosystem; a fundamental redesign would remove that. PHP's name is also mud when it comes to programming language design, and its community is notorious for poor practices, so no one's really clamoring for a more modern PHP.

The bitter truth for PHP stans is that it is what it is, you can get things done, and you can have valid reasons for using it (like legacy reasons, job market, etc.), but it's rightfully trending down and will continue to.

I'll rework that section; thanks for the feedback.

"Very slightly" means that I shared that I'd submitted it here; realistically a couple of upvotes could have come from that, but I don't know. The talk about botnets and whatnot is just hyperbole. You inferring alternative accounts and pulling numbers out of thin air is ridiculous.

The wording is indeed pretentious, hopefully improved in future iterations.

It's a major recurring theme; for example, anything that refers to implicit or explicit is part of it. The list you quoted is a placeholder to be elaborated.

Asynchronicity is just how sequential models are extended to support concurrency. Parallelism and concurrency are orthogonal, so a concurrent model can be executed in parallel.

That looks nice, but Python is an odd choice for studying synchronization primitives considering it has the GIL.

You're right, I qualified it with "classic JVM threads", but a less ancient example would be better; it's just not immediately clear which green thread implementations are also relatively heavyweight like JVM green threads used to be.

That's some fevered imagination.

The trade-offs of locks are accidental locking like deadlocks; message passing removes this trade-off but is less flexible, and dataflow further constrains the use of explicit synchronization. It's part of the larger argument for declarative approaches enabling equational reasoning.

Task/data parallelism bear to be mentioned because they're common terms; thanks for pointing it out.

Thanks, and yeah, the part about lightweight threads stands to be expanded. Other missing parts are reactive vs interactive, linearizable vs serializable and push vs pull.

The relations could definitely be made more clear, but if you could point out what specific terms you find unrelated, I could explain how they fit together. The basic organization is working up the ladder of abstraction; for example, scheduling is a fundamental concept, so it comes before other concepts that rely on it (which is all of them).

For what it's worth, the feedback I've had so far elsewhere suggests that there aren't particular inaccuracies. A somewhat contentious part is defining concurrency in terms of order independence, but the main source for that is Peter Van Roy (https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf section 4.3), so it's of good provenance.

The implicit coercion rules don't matter if you make sure to convert the types explicitly, but then you're just relying on your discipline. You might be able to pull it off individually, but it starts mattering more when working with other people.

Also, from a brief glance at your code example, you don't seem to have caught up with other current best practices like linting or modules.

You can't remove JavaScript features without breaking websites. The one exception was when the strict mode pragma was added, but that was a one-off, and there's too much resistance now to add more pragmas (they tried that with "strong mode").

The best solution currently is to have linter rules enforcing ===.

The issue there is that TS allows dropping out of the type system with `any`, so it might not actually be checking the types you're comparing, so I'd still use ===.

It's idiomatic to use == to check for both null and undefined at least.

A lot of people seem to have a perception of languages as being handed down by some language gods, and apparent problems with the language get explained away by "mere users" lacking knowledge, perspective, discipline, etc.

Odd to post something you haven't made as "Show HN".