The network isn't special. This applies locally too. But the article we are commenting on (at least, _I_ was commenting on) is about the network, and it uses the phrase "type safety over the network" in particular.

> You parse/validate unstructured binary blobs into structured data, and what’s left _is type safety_.

That is in fact exactly what I said. The point is that at some point you started with unstructured binary blobs. As soon as data leaves the application, it is no longer "safe", and it is unsafe until it is ingested and (re)validated. So my point can be freely generalised to "type safety beyond the application boundary is a fiction". And the application boundary will always exist, whether you are working with a strongly or weakly, statically or dynamically typed language.

When it comes down to it, what is being sent over the network is 1s and 0s. At some point, some layer (probably multiple layers) are going to have to interpret that sequence of 1s and 0s into a particular shape. There are two main ways of doing that:

- Know what format the data is in, but not the content (self-describing formats) - in which case the data you end up with might be of an arbitrary shape, and casting/interpreting the data is left to the application

- Know what format the data is in, AND know the content (non-self-describing formats) - in which case the runtime will parse out the data for you from the raw bits and you get to use it in its structured form.

The fact that this conversion happens doesn't depend on the language; JS is no more unsafe than any other language in this regard, and JSON is no better or worse of a data serialisation format for it. The boundary already exists, and someone has to handle what happens when the data is the wrong shape. Where that boundary ends up influences the shape of the application but what is preferable will depend on the application and developer.

Actually, it's even simpler than that: the $ operator is nothing but a function that applies its left argument to its right one! The full definition is

    f $ x = f x

The reason we moved away from it was that after a point, the amount of legwork to implement relatively simple behaviours became astronomical. Whether or not the current state of matters is "better", who's to say. But things are certainly much easier now.

Besides, you still can use those old modes if you want to :)

This is obviously false. The map type signature is significantly easier to understand than pointers, referencing and dereferencing.

I am an educator in computer science - the former takes about 30-60 seconds to grok (even in Haskell, though it translates to most languages, and even the fully generalised fmap), but it is a rare student that fully understands the latter within a full term of teaching.

I can't help but feel that this completely undermines your point - Vampire Survivors is bashed together using rudimentary knockoffs of sprites from games from the 1990s, in an engine which barely supports the idea of particles let alone proper visual effects.* It is the gameplay that carries Vampire Survivors, not the aesthetic.

Game feel is of course essential to producing a good game all-round, but a competent game designer can and will tell the difference between a good game design and a bad one, way before polish and juice are layered on top.

*I don't say this as a criticism - Vampire Survivors is fantastic - but the idea that it's propped up by its look is just daft.

Correction: function composition is not a monoid over unary functions, only over families of endofunctions (functions of type `a -> a` for some `a`). You can't compose a function of type `a -> b` with a function of type `a -> b` for example, when `a` /= `b`, because one gives back a value of type `b` which cannot be passed into a function expecting a value of type `a`.