4 ms·

Not quite sure what you mean by sublanguages - procedural and declarative macros perhaps? In any case I wonder about the simplicity/complexity dance. Simplific

Not quite sure what you mean by sublanguages - procedural and declarative macros perhaps? In any case I wonder about the simplicity/complexity dance. Simplification ends up with something like Lisp, in which you write DSLs that each has to be independently learned. Elixir does something similar. Some differentiation might just be a natural consequence of chasing ergonomics.

woodruffw 4y ago
If I had to guess: Safe Rust, Unsafe Rust, proc macros, declarative macros, the attribute language, and maybe async Rust (although I'd really just consider this sugar on Safe Rust). I love Rust, but I would love to see more syntactic unification between these components. Both macro languages, in particular.
- andrewstuart 4y ago
  There's something wrong if a language is so unsuited to programming itself that it needs another language - or five more languages - to get the job done. This is one of the great things about JavaScript - it's flexible enough to do everything in its ecosystem.
  - woodruffw 4y ago
    I don't think that's a good metric. Most of the most successful programming languages of all time have had at least one macro or attribute language attached to them.
- aussiesnack 4y ago
  Ah yes that'd be right. Haven't needed to write any unsafe Rust, so that's kind of under my radar. But agree about the macro langs.
- kibwen 4y ago
  Unsafe Rust is a minimal superset of Safe Rust, proc macros aren't their own language, there's no such distinction between Rust and "the attribute language", and async Rust isn't its own distinct thing, it's all just Rust.
  - woodruffw 4y ago
    Unsafe Rust is, in the Rust Language book's own words, a "second hidden language" within Safe Rust[1]. You're absolutely right that it's a superset; that's what makes it distinct and therefore a unique language with unique semantics (even if the syntax is nearly identical). Procedural macros can be used to define new languages within Rust, which means that grokking them requires the developer to understand their expressive capacity. For example, the paste[2] crate introduces a little bit of novel syntax for combining identifiers. Attributes are the counterpart to Unsafe Rust: their syntax is described separately from the rest of Rust[3]. Understanding how to use them involves components of Rust that aren't tied to the syntax of programs (e.g. doc and feature attributes, which connect to Rust's standard tooling instead). I agree that async Rust isn't its own distinct thing. I threw that one in as a possible interpretation, to make the count work. [1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html [2]: https://docs.rs/paste/latest/paste/ https://docs.rs/paste/latest/paste/ [3]: https://doc.rust-lang.org/reference/attributes.html https://doc.rust-lang.org/reference/attributes.html
    - kibwen 4y ago
      > that's what makes it distinct and therefore a unique language with unique semantics Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations. Which is to say, for any given expression that compiles with Safe Rust, if you wrap that expression in an unsafe block it will have precisely the same semantics. For the book to describe it as a "second, hidden language" is being a bit fanciful on its part; it later goes on to clarify that it just gives you a handful of extra powers. > Procedural macros can be used to define new languages within Rust Sure, but by that logic, Rust (and every other language that supports DSLs) has infinite languages inside of it, which does not amount to a particularly useful distinction; either a language supports crafting DSLs or it doesn't. To suggest that this means that the language itself has infinite sublanguages obscures its actual sublanguages, such as the built-in macro-rules DSL. > Attributes are the counterpart to Unsafe Rust: their syntax is described separately from the rest of Rust This is a misunderstanding of the reference manual (which is itself non-normative and fairly ad-hoc in structure); most pages contain their own grammar specification, e.g. the syntax for items is described at https://doc.rust-lang.org/reference/items.html https://doc.rust-lang.org/reference/items.html , but there is no user-facing item sublanguage in the same way that there is no user-facing attribute sublanguage. Attributes are attributes, they're just a part of Rust.
- p1necone 4y ago
  Unsafe Rust is just Rust, but there's a few extra things you can do inside unsafe blocks that you can't normally do outside them (because they're unsafe). I wouldn't call it a different language.
  - woodruffw 4y ago
    See my response to 'kibwen. We can nitpick all day about whether it's really a separate language; I think it satisfies at least one important definition of "language" by having its own separate syntax and semantics that aren't accessible to Safe Rust.
    - p1necone 4y ago
      But by that argument every feature in a language is it's own separate language. "This is the language that can only be written inside function definitions", "This is the language that can only be written inside ternary operators" and so on.
      - woodruffw 4y ago
        Sure: you can clearly drive this to absurdity. The list I gave was the ones I've heard people in the Rust community, including official Rust language documents, refer to as separate languages. Does that guarantee that we're carving the nature of "computer language" at its joints? No; it's merely a shorthand for expressing the range of syntaxes and semantics that you need to know to "fully" know Rust.
    - rascul 4y ago
      What syntax is different with unsafe?
      - woodruffw 4y ago
        Unsafe Rust's syntax is a superset of Safe Rust, meaning that there is syntax in Unsafe Rust that will not compile in Safe Rust[1]. [1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
- cesarb 4y ago
  > Safe Rust, Unsafe Rust These two are the exact same language. Some features (like calling unsafe functions, or dereferencing raw pointers) are "locked" outside unsafe blocks, but syntactically and semantically they are identical. It's easy to show this: put a unsafe block around a normal "safe" block, and all that happens is an extra "this does not need to be an unsafe block" warning from the compiler.
  - woodruffw 4y ago
    My other responses say this in more detail, but: they're not the exact same language if they have separate semantics and syntaxes, which they do. The fact that they can be composed together (much like C and the C preprocessor) does not make them the same language; it just makes them compatible.
- p1necone 4y ago
  As far as I'm concerned any programming language either has a good, builtin, type safe macro system, or people are going to use code generation (on large complex projects). And I never want to have to work on something with custom code generation. Typescript seems to have embraced the third option, which is having such a batshit insanely expressive dynamic type system that you don't need either 99% of the time while still having proper type safety.

woodruffw 4y ago

If I had to guess: Safe Rust, Unsafe Rust, proc macros, declarative macros, the attribute language, and maybe async Rust (although I'd really just consider this sugar on Safe Rust). I love Rust, but I would love to see more syntactic unification between these components. Both macro languages, in particular.

andrewstuart 4y ago
There's something wrong if a language is so unsuited to programming itself that it needs another language - or five more languages - to get the job done. This is one of the great things about JavaScript - it's flexible enough to do everything in its ecosystem.
- woodruffw 4y ago
  I don't think that's a good metric. Most of the most successful programming languages of all time have had at least one macro or attribute language attached to them.
aussiesnack 4y ago
Ah yes that'd be right. Haven't needed to write any unsafe Rust, so that's kind of under my radar. But agree about the macro langs.
kibwen 4y ago
Unsafe Rust is a minimal superset of Safe Rust, proc macros aren't their own language, there's no such distinction between Rust and "the attribute language", and async Rust isn't its own distinct thing, it's all just Rust.
- woodruffw 4y ago
  Unsafe Rust is, in the Rust Language book's own words, a "second hidden language" within Safe Rust[1]. You're absolutely right that it's a superset; that's what makes it distinct and therefore a unique language with unique semantics (even if the syntax is nearly identical). Procedural macros can be used to define new languages within Rust, which means that grokking them requires the developer to understand their expressive capacity. For example, the paste[2] crate introduces a little bit of novel syntax for combining identifiers. Attributes are the counterpart to Unsafe Rust: their syntax is described separately from the rest of Rust[3]. Understanding how to use them involves components of Rust that aren't tied to the syntax of programs (e.g. doc and feature attributes, which connect to Rust's standard tooling instead). I agree that async Rust isn't its own distinct thing. I threw that one in as a possible interpretation, to make the count work. [1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html [2]: https://docs.rs/paste/latest/paste/ https://docs.rs/paste/latest/paste/ [3]: https://doc.rust-lang.org/reference/attributes.html https://doc.rust-lang.org/reference/attributes.html
  - kibwen 4y ago
    > that's what makes it distinct and therefore a unique language with unique semantics Unsafe Rust doesn't have different semantics from Safe Rust, it's the exact same language but it allows more operations. Which is to say, for any given expression that compiles with Safe Rust, if you wrap that expression in an unsafe block it will have precisely the same semantics. For the book to describe it as a "second, hidden language" is being a bit fanciful on its part; it later goes on to clarify that it just gives you a handful of extra powers. > Procedural macros can be used to define new languages within Rust Sure, but by that logic, Rust (and every other language that supports DSLs) has infinite languages inside of it, which does not amount to a particularly useful distinction; either a language supports crafting DSLs or it doesn't. To suggest that this means that the language itself has infinite sublanguages obscures its actual sublanguages, such as the built-in macro-rules DSL. > Attributes are the counterpart to Unsafe Rust: their syntax is described separately from the rest of Rust This is a misunderstanding of the reference manual (which is itself non-normative and fairly ad-hoc in structure); most pages contain their own grammar specification, e.g. the syntax for items is described at https://doc.rust-lang.org/reference/items.html https://doc.rust-lang.org/reference/items.html , but there is no user-facing item sublanguage in the same way that there is no user-facing attribute sublanguage. Attributes are attributes, they're just a part of Rust.
p1necone 4y ago
Unsafe Rust is just Rust, but there's a few extra things you can do inside unsafe blocks that you can't normally do outside them (because they're unsafe). I wouldn't call it a different language.
- woodruffw 4y ago
  See my response to 'kibwen. We can nitpick all day about whether it's really a separate language; I think it satisfies at least one important definition of "language" by having its own separate syntax and semantics that aren't accessible to Safe Rust.
  - p1necone 4y ago
    But by that argument every feature in a language is it's own separate language. "This is the language that can only be written inside function definitions", "This is the language that can only be written inside ternary operators" and so on.
    - woodruffw 4y ago
      Sure: you can clearly drive this to absurdity. The list I gave was the ones I've heard people in the Rust community, including official Rust language documents, refer to as separate languages. Does that guarantee that we're carving the nature of "computer language" at its joints? No; it's merely a shorthand for expressing the range of syntaxes and semantics that you need to know to "fully" know Rust.
  - rascul 4y ago
    What syntax is different with unsafe?
    - woodruffw 4y ago
      Unsafe Rust's syntax is a superset of Safe Rust, meaning that there is syntax in Unsafe Rust that will not compile in Safe Rust[1]. [1]: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
cesarb 4y ago
> Safe Rust, Unsafe Rust These two are the exact same language. Some features (like calling unsafe functions, or dereferencing raw pointers) are "locked" outside unsafe blocks, but syntactically and semantically they are identical. It's easy to show this: put a unsafe block around a normal "safe" block, and all that happens is an extra "this does not need to be an unsafe block" warning from the compiler.
- woodruffw 4y ago
  My other responses say this in more detail, but: they're not the exact same language if they have separate semantics and syntaxes, which they do. The fact that they can be composed together (much like C and the C preprocessor) does not make them the same language; it just makes them compatible.
p1necone 4y ago
As far as I'm concerned any programming language either has a good, builtin, type safe macro system, or people are going to use code generation (on large complex projects). And I never want to have to work on something with custom code generation. Typescript seems to have embraced the third option, which is having such a batshit insanely expressive dynamic type system that you don't need either 99% of the time while still having proper type safety.