7 ms·

> You can't compare it to a scripting language because it has type information. What do you mean by this?

by mrkeen 7y ago

echelon 7y ago
Rust requires types, pointer types, lifetime bounds, trait classes, etc. for struct and function declarations. They're also used to disambiguate in other places when type inference isn't possible, such as during method chaining.
- arcticbull 7y ago
  You could have that in a scripting language, and you could not have that in a compiled language. The difference between the two is the back-end not the front-end.
  - echelon 7y ago
    What are you talking about? A statically typed language would be hard to reason about without types and it would dramatically impact compilation times. Why would you include lifetime annotations in a GC'd scripting language? These are features for the compiler and the human to reason about. The language and compiler are intertwined. While you could divorce the language from the compiler, it would be misguided to do so for many languages and problem domains. You can hold up TypeScript as an example of a scripting language with types that upholds your philosophy, but its advantage is primarily for humans. I'm unaware of any performance benefits or optimizations it provides. It wasn't carefully spec'd out with a compiler in mind. It's a well thought out cross-compiled superset language. This isn't the case with languages designed for bare metal. edit: I can't reply with a comment thread this nested. Compilers absolutely inform language design and vice-versa. Bad language design leads to horrible compilers (C++). A good language design process works in lockstep with its compiler design, with careful attention to the AST, the number of passes, analysis, etc. If we didn't think about compilers, we couldn't design languages that could be compiled.
    - arcticbull 7y ago
      Whether a language is compiled or interpreted has nothing to do with its design. For instance, you can interpret C++ with Cling or compile it with Clang. You can compile Python or interpret it. Same with Rust. Otherwise, you've conflated a bunch of things. Interepreted languages don't need to have a GC, or lifetime annotations, or anything else, really. Static typing doesn't require explicit type annotations, although it tends to have them, and neither is the domain of exclusively interpreted or compiled languages. And so on. I also argue there's no meaningful distinction between "designed for bare metal" and "designed for application programming" other than a language that is designed to allow deployment on bare metal has a way for you to poke memory locations and at minimum turn off a GC. Everything above and beyond that is language features or libraries and by no means limits your ability to operate quickly and efficiently in either domain.

> You can't compare it to a scripting language because it has type information. What do you mean by this?

by mrkeen 7y ago

> You can't compare it to a scripting language because it has type information. What do you mean by this?

Rust requires types, pointer types, lifetime bounds, trait classes, etc. for struct and function declarations. They're also used to disambiguate in other places when type inference isn't possible, such as during method chaining.

arcticbull 7y ago
You could have that in a scripting language, and you could not have that in a compiled language. The difference between the two is the back-end not the front-end.
- echelon 7y ago
  What are you talking about? A statically typed language would be hard to reason about without types and it would dramatically impact compilation times. Why would you include lifetime annotations in a GC'd scripting language? These are features for the compiler and the human to reason about. The language and compiler are intertwined. While you could divorce the language from the compiler, it would be misguided to do so for many languages and problem domains. You can hold up TypeScript as an example of a scripting language with types that upholds your philosophy, but its advantage is primarily for humans. I'm unaware of any performance benefits or optimizations it provides. It wasn't carefully spec'd out with a compiler in mind. It's a well thought out cross-compiled superset language. This isn't the case with languages designed for bare metal. edit: I can't reply with a comment thread this nested. Compilers absolutely inform language design and vice-versa. Bad language design leads to horrible compilers (C++). A good language design process works in lockstep with its compiler design, with careful attention to the AST, the number of passes, analysis, etc. If we didn't think about compilers, we couldn't design languages that could be compiled.
  - arcticbull 7y ago
    Whether a language is compiled or interpreted has nothing to do with its design. For instance, you can interpret C++ with Cling or compile it with Clang. You can compile Python or interpret it. Same with Rust. Otherwise, you've conflated a bunch of things. Interepreted languages don't need to have a GC, or lifetime annotations, or anything else, really. Static typing doesn't require explicit type annotations, although it tends to have them, and neither is the domain of exclusively interpreted or compiled languages. And so on. I also argue there's no meaningful distinction between "designed for bare metal" and "designed for application programming" other than a language that is designed to allow deployment on bare metal has a way for you to poke memory locations and at minimum turn off a GC. Everything above and beyond that is language features or libraries and by no means limits your ability to operate quickly and efficiently in either domain.