> When a language team abandons self-hosting (TS in TS) for raw performance (Go), it signals we've hit fundamental limits in JS/TS for systems programming.
I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant.
I don't know why one would choose JS or TS for "systems programming", but I'm assuming you're talking about user-space programs.
But really, those who know the difference between a compiled language and a VM-based language know the obvious fundamental performance limitations of developer tools written in VM-based languages like JS or TS and would avoid them as they are not designed for this use case.
Yeah, the term has changed meaning several times. Early on, "systems programmer" meant basically what we call a "developer" now (by opposition to a programmer or a researcher).
If my memory serves, the "programmer" was essentially a mathematician, working on a single algorithm, while a "system developer" was building an entire system around it.
I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant.
I don't know why one would choose JS or TS for "systems programming", but I'm assuming you're talking about user-space programs.
But really, those who know the difference between a compiled language and a VM-based language know the obvious fundamental performance limitations of developer tools written in VM-based languages like JS or TS and would avoid them as they are not designed for this use case.