6 ms·

Rust’s choice of sigils is aesthetically displeasing. Double colons (::) and angle bracket generics are ugly. Unmatched apostrophes is jarring to those used to

Rust’s choice of sigils is aesthetically displeasing. Double colons (::) and angle bracket generics are ugly. Unmatched apostrophes is jarring to those used to them being used for strings or character literals. It was an unforced error to imitate C++, which was forced to use those characters due to backwards compatibility with C and the C preprocessor. A new language doesn’t have to use those characters. For example, the D language uses the dot as a path separator for modules, namespaces, templates, etc. as do other languages like Python.

HideousKojima 4y ago
I like angled brackets for generics but hate double colons. I assume it's because I'm coming to Rust from C# though? I wonder how C++ devs learning Rust feel.
kibwen 4y ago
> It was an unforced error to imitate C++ Rust spent enough of its weirdness budget on new semantics. I may not be a fan of C++-style syntax, but if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain.
- arthurcolle 4y ago
  This is almost overly permissive... Yeah sure it looks the same but the semantics are so different that the statement seems... wrong
  - vlovich123 4y ago
    As someone with a long history of c++ experience I found rust syntax fairly familiar even if some details are meaningfully different. For example, most code you read is very very similar. I found an easier time coming to Rust from c++ in terms of syntax familiarity than swift. I found swift much faster to write code once I actually got my head around it (I also had substantial experience with Objective-C/C++ prior to picking up swift). I think the strong counter is that you only really learn a language once, but Swift is a bridge from those coming from Objective-C not C++ and tries to hit other language goals so it’s hard to compare. Certainly this is the first real language giving c++ a run for its money in a way that nothing else has before, that’s not nothing, and it’s hard to argue whether the syntax chosen is part of that success or in spite of.
  - ssokolow 4y ago
    Because Rust is, in effect, a GC-less Ocaml derivative with a coat of cherry-picked C++ syntax as paint. That's why the semantics are so different. It's more of the lineage that began with ML in 1973 than of the ALGOL 68 lineage like C is. The Rust compiler was even originally written in Ocaml before it became self-hosting. That's also where syntax elements like these come from: - let for variable declaration and postfix type annotations separated with colons - 'a (Ocaml's equivalent to <T> for generics, because, on an abstract/theoretical level, Rust's lifetimes are a special type of generic parameter, right down to "a" apparently being the habitual default type variable name, just like "T" is in C++) - Option (option in Ocaml), Some, and None - match - fn (fun or function in Ocaml) - -> and => (just -> in Ocaml) for function returns and match arms - ()
- lmm 4y ago
  > if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain. I wonder how well that's worked out for them. My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++.
  - Yoric 4y ago
    Recall that the initial target was browser developers. I've seen what feels like considerable adoption from among Firefox developers. Chromium developers feel very tempted, too. Feels like success!
  - sho 4y ago
    > My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++ Is there any reason in particular you think a lot of high-level language people are moving to Rust? That is not my impression or experience at all and I struggle to think of any reason to do so besides a large, individual change in career focus. As a higher-level language user myself, I can't think of a single reason I would ever use Rust for anything. Sure, I think it's cool, and it's always good to learn new languages, but in practise it's just not suited to my domain - and I think that goes for the vast majority of us. I would say golang has scooped off more of the dynamic language types myself, although I also consider it a productivity downgrade and/or cargo cult to mostly be ignored without compelling reason. Which is even more the case with Rust!
    - j-pb 4y ago
      Fullstack & Wasm. There comes a point in your career where you're dissatisfied with the capabilities of the warm and friendly upper layers of your stack, and you descend into the cold dark waters where things are hard but fast. I used to write primarily in highlevel languages, but if you want to write realy interesting high performance stuff in javascript, WASM+Rust is a really neat tech to use. Similarly, with WebGL/WebGPU you need some familiarity with bare metal programming. I still write a lot of JS, but I regularly drop down to Rust.
lanza 4y ago
[flagged]
jb1991 4y ago
Angle brackets aren't that uncommon, are they? Swift is a modern, elegant language that uses angle brackets for generics. Fortunately it uses the period instead of the double colon (thank goodness for that!) but I don't see anything ugly about brackets.
- ssokolow 4y ago
  It's directly responsible for Rust needing the "turbofish" syntax to pin down generic return types as in let foo.iter().map(|x| x*2).collect::<Vec<_>>() If they'd used something like [T] for generics, then there'd be no collision with the < and > operators needing disambiguation in some contexts. They even have a Book of Mozilla-esque entry in their test suite named "Bastion of the Turbofish" to pin down an example of the problem case, complete with https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba913137585219ba0a691f/src/test/ui/parser/bastion-of-the-turbofish.rs https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba9...
  - mvolfik 4y ago
    I don't think that's true - .collect[Vec[u8]]() - here you might be accessing property collect and taking the value at index denoted by the item of Vec at position denoted by the variable u8. And at the end calling the resulting thing? (That's not actually valid in rust afaik, you'd have to wrap it in parentheses like this `(...collect[])()`)
    - Measter 4y ago
      That is actually valid Rust, and it works exactly as you said: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dd960239ede4419f4beeaadd35cec434 https://play.rust-lang.org/?version=stable&mode=debug&editio...
    - ssokolow 4y ago
      The argument that generics should have used [] generally goes hand in hand with the argument that [] for panicking indexing is a wart on Rust's "pit of success" design philosophy and that panicking indexing should have been more verbose to type than the .get() for Result-returning indexing... but probably less verbose to type than the `unsafe`, potentially UB-inducing `.get_unchecked()`.
WalterBright 4y ago
It would have worked in C++ to use the . for them, too.
kazinator 4y ago
> Unmatched apostrophes is jarring Welcome to Lisp! 'x means (quote x) '(+ 1 2) evaluates to (+ 1 2)
davidkunz 4y ago
I don't know if it's just me, but find angle brackets really hard to read. Many times I just miss the ending one, because they have the same height as normal characters, so they don't stand out.
- zozbot234 4y ago
  That's a font issue. In proper type setting, angle brackets are different from normal less/greater than characters. An IDE with good in-built parsing could use variant forms for <> characters as used in generics, as opposed to relational operators.
  - davidkunz 4y ago
    Yes, but syntax decisions of programming languages shouldn't rely on such things. I would've preferred square brackets for generics (and something else for indexing).
    - arp242 4y ago
      «..» Always seemed like a good solution to me, from a readability perspective. But I think many will object on account of being too hard to type (which is not unreasonable; on my Linux machine it's "Compose <<" and fairly easy; I'm not sure how hard/easy it is on Windows or macOS, but even if it's easy I think most people don't know it's easy and will still make the language harder to learn).
puffoflogic 4y ago
<> are the worst characters for generics, except for all the others that have been tried. () leads to the type syntax being difficult to distinguish from value syntax, which is great in dependently-typed languages but bad elsewhere. [] is already used for slices, albeit in a different way; and C should be objection enough if you want to make types look like values. {} is a nonstarter because it leads to ambiguity between return type and function body, and in an everything-is-an-expression language, once again we are back at types-look-like-values. There are no more matched pairs left on an ANSI keyboard. Personally, while I hear you that :: is ugly, I do really like being able to distinguish module paths from value paths at a glance. And when looking for an alternative, we once again run into other characters already having far more familiar conflicting uses, or just being too weird. (E.g., # or @ could have been used, but that's probably worse than ::.)
- zozbot234 4y ago
  To be fair, arrays and slices are probably uncommon enough in current code that they shouldn't get exclusive use of the [] brackets. They could just be a generic type like any other.
  - cutemonster 4y ago
    Scala uses [ ] for generics, works well. I think you're right that array access is a rare case, definitely doesn't deserve its own reserved characters. And [ ] tends to mean "crash if out of bounds", crazy to have gotten its own reserved characters :-)
- nneonneo 4y ago
  And that's why we have Unicode! Vec⟪u8⟫ Vec｢u8｣ Vec⟦u8⟧ Vec༼u8༽ I'm sure this could open up a whole new frontier of exciting, untypeable language designs. If it works for APL, it should work for any language!
  - lifthrasiir 4y ago
    Or that's why we have digraphs. `Vec[\u8\]` or `Vec[.u8.]` may have worked (these examples are from Fortress [1] and Nim [2]). [1] https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page=104 https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page... [2] https://nim-lang.org/docs/manual.html#lexical-analysis-other-tokens https://nim-lang.org/docs/manual.html#lexical-analysis-other...
rhaway84773 4y ago
The exclamation mark choice seems poor as well. It’s something one would associate with something extraordinary, like an exception. Seeing it in code all over (as a beginner…I’m sure after a while you get used to it), it screams danger to me every time I encounter it in code.
- ssokolow 4y ago
  It means "DANGER: This may hide an early return or other things which violate the expectations for how control flow works."
jeremychone 4y ago
I had the same initial opinion about the '.' Vs. ':' for module separation. Why add weight to make this distinction? However, after over a year of coding Rust every day, I now really appreciate the distinction. It's an effective way to give a meaningful context point at a very low cost. I was wrong again! Which has been a consistent pattern with my initial Rust appreciations.

HideousKojima 4y ago

I like angled brackets for generics but hate double colons. I assume it's because I'm coming to Rust from C# though? I wonder how C++ devs learning Rust feel.

kibwen 4y ago

> It was an unforced error to imitate C++ Rust spent enough of its weirdness budget on new semantics. I may not be a fan of C++-style syntax, but if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain.

arthurcolle 4y ago
This is almost overly permissive... Yeah sure it looks the same but the semantics are so different that the statement seems... wrong
- vlovich123 4y ago
  As someone with a long history of c++ experience I found rust syntax fairly familiar even if some details are meaningfully different. For example, most code you read is very very similar. I found an easier time coming to Rust from c++ in terms of syntax familiarity than swift. I found swift much faster to write code once I actually got my head around it (I also had substantial experience with Objective-C/C++ prior to picking up swift). I think the strong counter is that you only really learn a language once, but Swift is a bridge from those coming from Objective-C not C++ and tries to hit other language goals so it’s hard to compare. Certainly this is the first real language giving c++ a run for its money in a way that nothing else has before, that’s not nothing, and it’s hard to argue whether the syntax chosen is part of that success or in spite of.
- ssokolow 4y ago
  Because Rust is, in effect, a GC-less Ocaml derivative with a coat of cherry-picked C++ syntax as paint. That's why the semantics are so different. It's more of the lineage that began with ML in 1973 than of the ALGOL 68 lineage like C is. The Rust compiler was even originally written in Ocaml before it became self-hosting. That's also where syntax elements like these come from: - let for variable declaration and postfix type annotations separated with colons - 'a (Ocaml's equivalent to <T> for generics, because, on an abstract/theoretical level, Rust's lifetimes are a special type of generic parameter, right down to "a" apparently being the habitual default type variable name, just like "T" is in C++) - Option (option in Ocaml), Some, and None - match - fn (fun or function in Ocaml) - -> and => (just -> in Ocaml) for function returns and match arms - ()
lmm 4y ago
> if your goal is to specifically tempt C++ developers with the promise of safer/saner language semantics, then making syntactic concessions towards familiarity with C++ is the right call. Rust isn't trying to be The One Language To Rule Them All, it's trying to target a very specific domain. I wonder how well that's worked out for them. My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++.
- Yoric 4y ago
  Recall that the initial target was browser developers. I've seen what feels like considerable adoption from among Firefox developers. Chromium developers feel very tempted, too. Feels like success!
- sho 4y ago
  > My impression is that there's been a lot more people moving to Rust from Python/Ruby/Javascript than from C++ Is there any reason in particular you think a lot of high-level language people are moving to Rust? That is not my impression or experience at all and I struggle to think of any reason to do so besides a large, individual change in career focus. As a higher-level language user myself, I can't think of a single reason I would ever use Rust for anything. Sure, I think it's cool, and it's always good to learn new languages, but in practise it's just not suited to my domain - and I think that goes for the vast majority of us. I would say golang has scooped off more of the dynamic language types myself, although I also consider it a productivity downgrade and/or cargo cult to mostly be ignored without compelling reason. Which is even more the case with Rust!
  - j-pb 4y ago
    Fullstack & Wasm. There comes a point in your career where you're dissatisfied with the capabilities of the warm and friendly upper layers of your stack, and you descend into the cold dark waters where things are hard but fast. I used to write primarily in highlevel languages, but if you want to write realy interesting high performance stuff in javascript, WASM+Rust is a really neat tech to use. Similarly, with WebGL/WebGPU you need some familiarity with bare metal programming. I still write a lot of JS, but I regularly drop down to Rust.

lanza 4y ago

[flagged]

jb1991 4y ago

Angle brackets aren't that uncommon, are they? Swift is a modern, elegant language that uses angle brackets for generics. Fortunately it uses the period instead of the double colon (thank goodness for that!) but I don't see anything ugly about brackets.

ssokolow 4y ago
It's directly responsible for Rust needing the "turbofish" syntax to pin down generic return types as in let foo.iter().map(|x| x*2).collect::<Vec<_>>() If they'd used something like [T] for generics, then there'd be no collision with the < and > operators needing disambiguation in some contexts. They even have a Book of Mozilla-esque entry in their test suite named "Bastion of the Turbofish" to pin down an example of the problem case, complete with https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba913137585219ba0a691f/src/test/ui/parser/bastion-of-the-turbofish.rs https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba9...
- mvolfik 4y ago
  I don't think that's true - .collect[Vec[u8]]() - here you might be accessing property collect and taking the value at index denoted by the item of Vec at position denoted by the variable u8. And at the end calling the resulting thing? (That's not actually valid in rust afaik, you'd have to wrap it in parentheses like this `(...collect[])()`)
  - Measter 4y ago
    That is actually valid Rust, and it works exactly as you said: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dd960239ede4419f4beeaadd35cec434 https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - ssokolow 4y ago
    The argument that generics should have used [] generally goes hand in hand with the argument that [] for panicking indexing is a wart on Rust's "pit of success" design philosophy and that panicking indexing should have been more verbose to type than the .get() for Result-returning indexing... but probably less verbose to type than the `unsafe`, potentially UB-inducing `.get_unchecked()`.

WalterBright 4y ago

It would have worked in C++ to use the . for them, too.

kazinator 4y ago

> Unmatched apostrophes is jarring Welcome to Lisp! 'x means (quote x) '(+ 1 2) evaluates to (+ 1 2)

davidkunz 4y ago

I don't know if it's just me, but find angle brackets really hard to read. Many times I just miss the ending one, because they have the same height as normal characters, so they don't stand out.

zozbot234 4y ago
That's a font issue. In proper type setting, angle brackets are different from normal less/greater than characters. An IDE with good in-built parsing could use variant forms for <> characters as used in generics, as opposed to relational operators.
- davidkunz 4y ago
  Yes, but syntax decisions of programming languages shouldn't rely on such things. I would've preferred square brackets for generics (and something else for indexing).
  - arp242 4y ago
    «..» Always seemed like a good solution to me, from a readability perspective. But I think many will object on account of being too hard to type (which is not unreasonable; on my Linux machine it's "Compose <<" and fairly easy; I'm not sure how hard/easy it is on Windows or macOS, but even if it's easy I think most people don't know it's easy and will still make the language harder to learn).

puffoflogic 4y ago

<> are the worst characters for generics, except for all the others that have been tried. () leads to the type syntax being difficult to distinguish from value syntax, which is great in dependently-typed languages but bad elsewhere. [] is already used for slices, albeit in a different way; and C should be objection enough if you want to make types look like values. {} is a nonstarter because it leads to ambiguity between return type and function body, and in an everything-is-an-expression language, once again we are back at types-look-like-values. There are no more matched pairs left on an ANSI keyboard. Personally, while I hear you that :: is ugly, I do really like being able to distinguish module paths from value paths at a glance. And when looking for an alternative, we once again run into other characters already having far more familiar conflicting uses, or just being too weird. (E.g., # or @ could have been used, but that's probably worse than ::.)

zozbot234 4y ago
To be fair, arrays and slices are probably uncommon enough in current code that they shouldn't get exclusive use of the [] brackets. They could just be a generic type like any other.
- cutemonster 4y ago
  Scala uses [ ] for generics, works well. I think you're right that array access is a rare case, definitely doesn't deserve its own reserved characters. And [ ] tends to mean "crash if out of bounds", crazy to have gotten its own reserved characters :-)
nneonneo 4y ago
And that's why we have Unicode! Vec⟪u8⟫ Vec｢u8｣ Vec⟦u8⟧ Vec༼u8༽ I'm sure this could open up a whole new frontier of exciting, untypeable language designs. If it works for APL, it should work for any language!
- lifthrasiir 4y ago
  Or that's why we have digraphs. `Vec[\u8\]` or `Vec[.u8.]` may have worked (these examples are from Fortress [1] and Nim [2]). [1] https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page=104 https://homes.luddy.indiana.edu/samth/fortress-spec.pdf#page... [2] https://nim-lang.org/docs/manual.html#lexical-analysis-other-tokens https://nim-lang.org/docs/manual.html#lexical-analysis-other...

rhaway84773 4y ago

The exclamation mark choice seems poor as well. It’s something one would associate with something extraordinary, like an exception. Seeing it in code all over (as a beginner…I’m sure after a while you get used to it), it screams danger to me every time I encounter it in code.

ssokolow 4y ago
It means "DANGER: This may hide an early return or other things which violate the expectations for how control flow works."

jeremychone 4y ago

I had the same initial opinion about the '.' Vs. ':' for module separation. Why add weight to make this distinction? However, after over a year of coding Rust every day, I now really appreciate the distinction. It's an effective way to give a meaningful context point at a very low cost. I was wrong again! Which has been a consistent pattern with my initial Rust appreciations.