5 ms·

There's different things people mean by "systems language", but a common theme is extremely precise control over the machine code emitted by the compiler. If y

There's different things people mean by "systems language", but a common theme is extremely precise control over the machine code emitted by the compiler. If you take TypeScript and add pointers, you'd end up with something like Java, or maybe Go. This is not necessarily a bad outcome (Java and Go are both very popular), but those languages don't provide the sort of control you need when writing a kernel, video codec, embedded device firmware, or the runtime for a higher-level language. Some folks might disagree, but I wouldn't personally consider Go a "systems language" in the same way that C or Rust are. The complexity you see in languages like Rust reflects the programmer's desire/need for controlled compiler output, plus a healthy dose of innate complexity of the problem domain. TypeScript has one type of string, Rust has dozens, because String and OsString and CString each have different semantics that will cause bugs if they get mixed up. We know this because older systems languages did mix them up (C++'s std::string, C *char vs *void vs *uint_8), and there were bugs, and late nights crying into a GDB prompt looking for a missing NUL terminator. Also, I suspect from your focus on syntax that you're new to the field of programming. Once you've been writing non-web code professionally for 10 years or so, you'll pay a lot less attention to the notation. The most popular languages (C/C++/C#/Java/JavaScript/Rust/Swift/Go) all seem very similar syntactically compared to Haskell, Erlang, Lisp, or Forth.

deltasevennine 4y ago
>If you take TypeScript and add pointers, you'd end up with something like Java, or maybe Go. He's not just talking about pointers. He's implicitly talking about allocation and free. If you want facilities similar to just pure pointers without memory management then you have this already with all high level languages like JS or python. In fact the garbage collectors in these languages work by counting the references (aka pointers) pointing to a primitive. Thus from this reasoning he's talking about more than just pointers.
- jmillikin 4y ago
  You're talking about references. The OP and I are talking about pointers. TypeScript does not have pointers. Python technically does (`ctypes`), but 99.99% of Python code will never touch them. There are important differences between pointers and references, for example the ability to perform arithmetic on them.
  - deltasevennine 4y ago
    No he's talking about memory management and the notion of some shortcut pointing to it. Typescript with pointers (that do pointer arithmetic) and no extra memory management facilities doesn't make any sense. He's not referring to this.
    - jmillikin 4y ago
      > Typescript with pointers (that do pointer arithmetic) and no extra > memory management facilities doesn't make any sense. That's pretty close to what Go offers. It seems to be quite a popular choice for people who occasionally need manual memory management but are mostly willing to let the compiler handle things. It's pretty obvious that the OP is asking why a language like Rust needs to have a more complex syntax/semantics than TypeScript, and the answer has nothing to do with manually allocating buffers.
      - UncleEntity 4y ago
        I would argue that most of the complexity in low-level languages comes from herding references to memory locations (pointers and whatnot). There’s no reason TypeScript couldn’t be built on top of manual memory management and the concept of raw access to memory locations but I suspect it would start looking a lot like C with just a different syntax for type declarations.
grumblingdev 4y ago
> Also, I suspect from your focus on syntax that you're new to the field of programming 10+ years including low-level embedded stuff in C/C++ and everything in between. On the contrary, I would argue that someone working in non-web code for 10+ years could easily have an antiquated view of what the modern developer experience looks like. JS/TS is miles ahead in terms of developer productivity than many other languages. Talking about the long compile-refresh cycles, poor module systems, lack of good debugger support, real-time test runners, etc. Most JS devs have been using the same language for a very long time now, whereas non-web devs are jumping from Ruby to Scala to Go to Rust to Zig, and then the next thing. > TypeScript has one type of string, Rust has dozens, because String and OsString and CString each have different semantics The problem I see is that I'm sure there are a ton of Rust projects that don't want to do anything particularly low-level with a string. They want to operate on it in the same way a JS program would. But they are forced to grapple with all this complexity. I think the issue is probably that Rust was never designed for high-level kind of stuff. Like you wouldn't build a web app or web server in Rust. You might build a performant web server framework like nginx, but you wouldn't want to write the business logic in it. That's why I'd love to see a simple language that you could easily drop down into low-level stuff when necessary without a giant context switch and new compiler toolchain.
- jmillikin 4y ago
  > Most JS devs have been using the same language for a very long time > now, whereas non-web devs are jumping from Ruby to Scala to Go to > Rust to Zig, and then the next thing. Most non-web development has been in Java or C# for twenty years. All of the languages you list summed together have a market position smaller than Visual Basic[0]. > The problem I see is that I'm sure there are a ton of Rust projects > that don't want to do anything particularly low-level with a string. > They want to operate on it in the same way a JS program would. What does it matter? There's people who write web frameworks in assembly, or write firmware in (Micro)Python. You can't force the whole world to make decisions that make sense to you personally. > That's why I'd love to see a simple language that you could easily drop > down into low-level stuff when necessary without a giant context switch > and new compiler toolchain. The ability to drop down into low-level stuff is what adds complexity to a language. You can either have a simple language for high-level code with affordances for occasional low-level optimization (Java, C#, Go, Swift), or you can have a language that directly exposes things like struct memory layout or SIMD intrinsics at the cost of a larger reference manual. There's no meaningful in-between. [0] Per Tiobe at https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/

deltasevennine 4y ago

>If you take TypeScript and add pointers, you'd end up with something like Java, or maybe Go. He's not just talking about pointers. He's implicitly talking about allocation and free. If you want facilities similar to just pure pointers without memory management then you have this already with all high level languages like JS or python. In fact the garbage collectors in these languages work by counting the references (aka pointers) pointing to a primitive. Thus from this reasoning he's talking about more than just pointers.

jmillikin 4y ago
You're talking about references. The OP and I are talking about pointers. TypeScript does not have pointers. Python technically does (`ctypes`), but 99.99% of Python code will never touch them. There are important differences between pointers and references, for example the ability to perform arithmetic on them.
- deltasevennine 4y ago
  No he's talking about memory management and the notion of some shortcut pointing to it. Typescript with pointers (that do pointer arithmetic) and no extra memory management facilities doesn't make any sense. He's not referring to this.
  - jmillikin 4y ago
    > Typescript with pointers (that do pointer arithmetic) and no extra > memory management facilities doesn't make any sense. That's pretty close to what Go offers. It seems to be quite a popular choice for people who occasionally need manual memory management but are mostly willing to let the compiler handle things. It's pretty obvious that the OP is asking why a language like Rust needs to have a more complex syntax/semantics than TypeScript, and the answer has nothing to do with manually allocating buffers.
    - UncleEntity 4y ago
      I would argue that most of the complexity in low-level languages comes from herding references to memory locations (pointers and whatnot). There’s no reason TypeScript couldn’t be built on top of manual memory management and the concept of raw access to memory locations but I suspect it would start looking a lot like C with just a different syntax for type declarations.

grumblingdev 4y ago

> Also, I suspect from your focus on syntax that you're new to the field of programming 10+ years including low-level embedded stuff in C/C++ and everything in between. On the contrary, I would argue that someone working in non-web code for 10+ years could easily have an antiquated view of what the modern developer experience looks like. JS/TS is miles ahead in terms of developer productivity than many other languages. Talking about the long compile-refresh cycles, poor module systems, lack of good debugger support, real-time test runners, etc. Most JS devs have been using the same language for a very long time now, whereas non-web devs are jumping from Ruby to Scala to Go to Rust to Zig, and then the next thing. > TypeScript has one type of string, Rust has dozens, because String and OsString and CString each have different semantics The problem I see is that I'm sure there are a ton of Rust projects that don't want to do anything particularly low-level with a string. They want to operate on it in the same way a JS program would. But they are forced to grapple with all this complexity. I think the issue is probably that Rust was never designed for high-level kind of stuff. Like you wouldn't build a web app or web server in Rust. You might build a performant web server framework like nginx, but you wouldn't want to write the business logic in it. That's why I'd love to see a simple language that you could easily drop down into low-level stuff when necessary without a giant context switch and new compiler toolchain.

jmillikin 4y ago
> Most JS devs have been using the same language for a very long time > now, whereas non-web devs are jumping from Ruby to Scala to Go to > Rust to Zig, and then the next thing. Most non-web development has been in Java or C# for twenty years. All of the languages you list summed together have a market position smaller than Visual Basic[0]. > The problem I see is that I'm sure there are a ton of Rust projects > that don't want to do anything particularly low-level with a string. > They want to operate on it in the same way a JS program would. What does it matter? There's people who write web frameworks in assembly, or write firmware in (Micro)Python. You can't force the whole world to make decisions that make sense to you personally. > That's why I'd love to see a simple language that you could easily drop > down into low-level stuff when necessary without a giant context switch > and new compiler toolchain. The ability to drop down into low-level stuff is what adds complexity to a language. You can either have a simple language for high-level code with affordances for occasional low-level optimization (Java, C#, Go, Swift), or you can have a language that directly exposes things like struct memory layout or SIMD intrinsics at the cost of a larger reference manual. There's no meaningful in-between. [0] Per Tiobe at https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/