3 ms·

Systems languages (those usable in a "freestanding" environment with no OS or other runtime) are usually only about as complex as the underlying system. I'm thi

Systems languages (those usable in a "freestanding" environment with no OS or other runtime) are usually only about as complex as the underlying system. I'm thinking of languages like C (without the bits of libc that allocate), Rust (in `#![no_std]` mode), FORTH, and assembly. TypeScript is far more complex but that complexity is hidden from the user. A garbage collector is an extremely powerful abstraction, and makes a language much easier to use for tasks that don't need to deal with memory management in a precise manner. The problem is that systems languages (as opposed to applications languages like Java, Go, or Typescript) are used precisely where you need to deal with memory management in a precise manner.

grumblingdev 4y ago
> systems languages (as opposed to applications languages We shouldn't need such a wide separation between what is system vs application. The difference is essentially a few additional keywords and a compiler. But the simplicity comes from a high-level language, so you always need the high-level language. You only need the low-level language when you need to optimize something. So naturally, the high-level language should be the basis for a language that can do both. TypeScript is now well-established enough that its syntax should be used as this basis, and it natively targets the web which nothing else does.