3 ms·

And the syntax could be backwards compatible TypeScript is what I am saying, instead of an entirely new syntax, package manager, etc.

pornel 4y ago
TypeScript's syntax as it exists today wouldn't be usable. TS's type system isn't sound — a valid TS program may still have type errors. This is not a big deal for a dynamic JS VM, but in natively-compiled code it can cause crashes and security vulnerabilities. TS doesn't have syntax for value vs reference types or memory ownership/lifetimes. It relies on a garbage collector to "guess" the information missing from the syntax, but systems programming languages almost by definition do not want to do depend on this. TS's syntax for immutability is almost non-existent. There's no syntax for compile-time vs run-time evaluation distinction. You may be severely overestimating how much it would help you to know syntax of a system's programming language without knowing systems programming (very little, because syntax is the easy part). At best TS's syntax could used as a starting point for a new syntax of a new language, not compatible with TypeScript in any useful sense, with changes and extensions for all the features that low-level programming needs. But if you kept the syntax similar to TS, then new features may end up looking bolted on and forced to use less convenient syntax, since all the most convenient syntax is already taken by TS. This is why Objective-C looks so bizarre — it tried to be a superset of C, but C features already took all the nice syntax. C++ also suffered a lot by trying to be a syntax superset of C and older versions of itself. Building on a wrong syntax as a base leads to poor defaults, confusing recycling of old keywords, and traps caused by having convenient syntax for features you're not supposed to be using any more.
- grumblingdev 4y ago
  > This is why Objective-C looks so bizarre Interesting point, hadn't thought about this before. > TS doesn't have syntax for value vs reference types or memory ownership/lifetimes...if you kept the syntax similar to TS, then new features may end up looking bolted on and forced I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. It's all abstracted away into libraries. It just comes down to a different syntax, but they are all doing the same thing. As seen here: https://rosetta.fiatjaf.com/compare/TypeScript/Rust/ https://rosetta.fiatjaf.com/compare/TypeScript/Rust/. Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then.
  - nyberg 4y ago
    > I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. > Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then. This depends on what the language is being used for. If it's to write high level glue code then passing references/pointers around is likely the norm. However the majority of cases you will care about how things are passed, how they're allocated, where they're allocated, and so on. If you don't care you're often using the wrong tool for the job or you're writing inefficient messy code. Writing allocators (arena/bump, heap, gc, rc, memory pools, etc) requires control more often than not and applications which desire performance often need to write their own tailored to their usage patterns (e.g you don't want it to free things at the wrong time). Data layout and alignment of said data play a key role in keeping the application performant along with the ability to reinterpret memory without copying values which is something TS lacks. Access to inline assembly for the cases where the compiler generates undesirable code or where what you want to do can't be expressed in the language itself. The above applies to quite a few domains and especially to embedded where you often have limited resources (time, memory, code size, etc). It may seem like a rare case but if you look around your at your everyday appliances around your home, sensors in your car, your headphones, and so on, you'll see that it's a rather common case. It would be good for you to try such languages for a while so you can see why the features presented to you exist and try to develop something which touches the different areas where it's used. Embedded is a nice start with especially dealing with MMIO.

pornel 4y ago

TypeScript's syntax as it exists today wouldn't be usable. TS's type system isn't sound — a valid TS program may still have type errors. This is not a big deal for a dynamic JS VM, but in natively-compiled code it can cause crashes and security vulnerabilities. TS doesn't have syntax for value vs reference types or memory ownership/lifetimes. It relies on a garbage collector to "guess" the information missing from the syntax, but systems programming languages almost by definition do not want to do depend on this. TS's syntax for immutability is almost non-existent. There's no syntax for compile-time vs run-time evaluation distinction. You may be severely overestimating how much it would help you to know syntax of a system's programming language without knowing systems programming (very little, because syntax is the easy part). At best TS's syntax could used as a starting point for a new syntax of a new language, not compatible with TypeScript in any useful sense, with changes and extensions for all the features that low-level programming needs. But if you kept the syntax similar to TS, then new features may end up looking bolted on and forced to use less convenient syntax, since all the most convenient syntax is already taken by TS. This is why Objective-C looks so bizarre — it tried to be a superset of C, but C features already took all the nice syntax. C++ also suffered a lot by trying to be a syntax superset of C and older versions of itself. Building on a wrong syntax as a base leads to poor defaults, confusing recycling of old keywords, and traps caused by having convenient syntax for features you're not supposed to be using any more.

grumblingdev 4y ago
> This is why Objective-C looks so bizarre Interesting point, hadn't thought about this before. > TS doesn't have syntax for value vs reference types or memory ownership/lifetimes...if you kept the syntax similar to TS, then new features may end up looking bolted on and forced I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. It's all abstracted away into libraries. It just comes down to a different syntax, but they are all doing the same thing. As seen here: https://rosetta.fiatjaf.com/compare/TypeScript/Rust/ https://rosetta.fiatjaf.com/compare/TypeScript/Rust/. Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then.
- nyberg 4y ago
  > I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. > Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then. This depends on what the language is being used for. If it's to write high level glue code then passing references/pointers around is likely the norm. However the majority of cases you will care about how things are passed, how they're allocated, where they're allocated, and so on. If you don't care you're often using the wrong tool for the job or you're writing inefficient messy code. Writing allocators (arena/bump, heap, gc, rc, memory pools, etc) requires control more often than not and applications which desire performance often need to write their own tailored to their usage patterns (e.g you don't want it to free things at the wrong time). Data layout and alignment of said data play a key role in keeping the application performant along with the ability to reinterpret memory without copying values which is something TS lacks. Access to inline assembly for the cases where the compiler generates undesirable code or where what you want to do can't be expressed in the language itself. The above applies to quite a few domains and especially to embedded where you often have limited resources (time, memory, code size, etc). It may seem like a rare case but if you look around your at your everyday appliances around your home, sensors in your car, your headphones, and so on, you'll see that it's a rather common case. It would be good for you to try such languages for a while so you can see why the features presented to you exist and try to develop something which touches the different areas where it's used. Embedded is a nice start with especially dealing with MMIO.