4 ms·

Despite the invalid example, the point still stands. Put arbitrary Rust against Python or Typescript and you'll see it immediately. I love Rust and very much l

Despite the invalid example, the point still stands. Put arbitrary Rust against Python or Typescript and you'll see it immediately. I love Rust and very much like OP it comes very close to my ideal language. I also think it had very good start when it comes to syntax but did a wrong turn when it copied things from C/C++, which in my opinion have horrible syntax for mostly historical and obsolete reasons. But not all is lost. With the editions mechanism we could do a syntax overhaul. I really, really hope that will happen. Meanwhile it's the small things everyone can do. One thing I advocate for is to adopt the most common style for identifiers in Java, Javascript, Typescript, Python, and even some parts of the C/C++ world and do away with snake_case. If we could do away with underscores and double colons we could have a much nicer language already.

JodieBenitez 3y ago
> Meanwhile it's the small things everyone can do. One thing I advocate for is to adopt the most common style for identifiers in Java, Javascript, Typescript, Python, and even some parts of the C/C++ world and do away with snake_case. snake_case is used a lot in Python: module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name. (not mandatory, it's just from the style guide) But I don't even think snake_case or CamelCase matter as much as plain keywords vs. symbols or "commonly used" symbols and ones that are not too noisy. I know compared to Rust strong points this all seems to be petty criticism, but we all read lots of code, probably more so than writing.
- weinzierl 3y ago
  I'm OK with SCREAMING_SNAKE_CASE for constants, because that is an ubiquitous convention. Same for globals, they should be rare anyways (and constant most of the times). For crates dashes are already widely used and that is how it should be. +1 for plain keywords. Common separators when necessary (e.g. constants or everything that ends up in the filesystem, bc upper/lowercase is a pain there). Regular struct, enum, trait variable names: CamelCase hands down, like almost everyone does it.
  - insanitybit 3y ago
    Variable names in most languages are pascalCase, not CamelCase, which is typically used for type names.
insanitybit 3y ago
What is better about Rust vs Python's syntax? struct Foo<T> { t: T } vs (assuming we get the pep for inline typevars) class Foo[T]: t: T I don't see how Python is meaningfully better at all. Or use foo::bar::baz; vs import foo.bar.baz I just don't get the problem here. "double colons bad" is just an extremely subjective take that I don't really buy at all. I much, much prefer snake case and would hate to see pascalcase in Rust, but also at the end of the day these are such minor things that barely barely impact readability.
- JodieBenitez 3y ago
  struct Foo<T> { t: T } Braces... one extra sign (and line) for nothing while indentation works fine. import foo::bar::baz; import foo.bar.baz 4 times the dots, also useless comma. Objectively less visual noise in Python. Of course the importance of it is subjective, I agree with that. But still, less cruft is good. > minor things that barely barely impact readability Of course, I don't agree :-)
  - Ygg2 3y ago
    These are subjective things. I don't consider Rust syntax perfect, but I don't these suggestions as way to improve it substationally. If you want to get rid of `::` and `;` and braces you have to look at the fallout of those decisions. Braces are imo much better at being robust than whitespace. def Foo[T]: t: T size: u32 // invisible error here because someone used tabs by mistake `;` disambiguate expression vs statement. If you remove it you need way to differentiate between them. Another problem with `import foo.bar.baz` is how will you distinguish between a method call or a type declaration? E.g. `std.option.Option.Some` what is this? Type? Method? Module? What is `std::f64::consts`??? Not to mention you kinda have to have compiler in mind, if syntax is ambigous you're going to have a very bad time.
    - weinzierl 3y ago
      I agree with that and would not want to see braces and semicolons go because they are pretty conventional. In this case Python and Javascript/Typescript are the outliers. It's the opposite for the double colon syntax which, apart from Rust, to the best of my knowledge only exists in C++ (for good reasons) and some functional languages for a completely different purpose. Honestly curious question: What fallout would you see from replacing it with a dot in Rust. I immediately see no disambiguation issues, but I'm not a compiler writer.
Ygg2 3y ago
> Despite the invalid example, the point still stands. Put arbitrary Rust against Python or Typescript and you'll see it immediately. Eh, I don't think that is fair, Rust even at best of times will have concepts like lifetime/references that Python and TS can just ignore and are thus "simpler". A much better comparison would be something like https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html. > and do away with snake_case. That's seem counterproductive - according to: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn.... I.e. you would do with most readable part of syntax.
- weinzierl 3y ago
  Before Rust everybody[1] seemed to believe we cannot have a safe and natively compiled language. Rust proved the opposite. I don't see why we can't have clean, low noise, high signal syntax in a language like Rust. My criticism is not the syntax that makes the language more expressive - that's essential complexity. I would want the accidental complexity removed, like the somewhat redundant distinction between dot and double colon. And I wish the cognitive load reduced by making the syntax as familiar as possible to as many people as possible. That's the reason I mentioned Javascript and Python - not only is their syntax more concise but also familiar to more people. When it comes to the snake case study, I'm not surprised at all. They did not control for the size each identifier took on the screen. That a bigger signal enables a faster response is common sense. Longer identifiers are easier to recognize but the downside is that they take away space we could use for other important things. That's why most languages keep the most frequent ones (like variable names) short and free from unnecessary noise like underscores. Also the sample size in the study was extremely small. [1] Except the Haskell/ML folks, naturally.
  - Ygg2 3y ago
    > I don't see why we can't have clean, low noise, high signal syntax in a language like Rust. My criticism is not the syntax that makes the language more expressive - that's essential complexity. As I pointed in Matklad's post you need to add those concepts in or devise a way to infer them, side by side comparisson of Rust/JS is meaningless if one has no concept of lifetime or one abstracts details via GC. > Before Rust everybody[1] seemed to believe we cannot have a safe and natively compiled language. I do agree, but you can't avoid all trade-offs. Rust got safe, natively compiled language by increasing type complexity (adding lifetimes and ownership), and adding more sigil noise. If Rust had GC it would be way simpler and way less usefull. > like the somewhat redundant distinction between dot and double colon I don't think it's redundant. But I'm not a Rust compiler guy.

JodieBenitez 3y ago

> Meanwhile it's the small things everyone can do. One thing I advocate for is to adopt the most common style for identifiers in Java, Javascript, Typescript, Python, and even some parts of the C/C++ world and do away with snake_case. snake_case is used a lot in Python: module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name. (not mandatory, it's just from the style guide) But I don't even think snake_case or CamelCase matter as much as plain keywords vs. symbols or "commonly used" symbols and ones that are not too noisy. I know compared to Rust strong points this all seems to be petty criticism, but we all read lots of code, probably more so than writing.

weinzierl 3y ago
I'm OK with SCREAMING_SNAKE_CASE for constants, because that is an ubiquitous convention. Same for globals, they should be rare anyways (and constant most of the times). For crates dashes are already widely used and that is how it should be. +1 for plain keywords. Common separators when necessary (e.g. constants or everything that ends up in the filesystem, bc upper/lowercase is a pain there). Regular struct, enum, trait variable names: CamelCase hands down, like almost everyone does it.
- insanitybit 3y ago
  Variable names in most languages are pascalCase, not CamelCase, which is typically used for type names.

insanitybit 3y ago

What is better about Rust vs Python's syntax? struct Foo<T> { t: T } vs (assuming we get the pep for inline typevars) class Foo[T]: t: T I don't see how Python is meaningfully better at all. Or use foo::bar::baz; vs import foo.bar.baz I just don't get the problem here. "double colons bad" is just an extremely subjective take that I don't really buy at all. I much, much prefer snake case and would hate to see pascalcase in Rust, but also at the end of the day these are such minor things that barely barely impact readability.

JodieBenitez 3y ago
struct Foo<T> { t: T } Braces... one extra sign (and line) for nothing while indentation works fine. import foo::bar::baz; import foo.bar.baz 4 times the dots, also useless comma. Objectively less visual noise in Python. Of course the importance of it is subjective, I agree with that. But still, less cruft is good. > minor things that barely barely impact readability Of course, I don't agree :-)
- Ygg2 3y ago
  These are subjective things. I don't consider Rust syntax perfect, but I don't these suggestions as way to improve it substationally. If you want to get rid of `::` and `;` and braces you have to look at the fallout of those decisions. Braces are imo much better at being robust than whitespace. def Foo[T]: t: T size: u32 // invisible error here because someone used tabs by mistake `;` disambiguate expression vs statement. If you remove it you need way to differentiate between them. Another problem with `import foo.bar.baz` is how will you distinguish between a method call or a type declaration? E.g. `std.option.Option.Some` what is this? Type? Method? Module? What is `std::f64::consts`??? Not to mention you kinda have to have compiler in mind, if syntax is ambigous you're going to have a very bad time.
  - weinzierl 3y ago
    I agree with that and would not want to see braces and semicolons go because they are pretty conventional. In this case Python and Javascript/Typescript are the outliers. It's the opposite for the double colon syntax which, apart from Rust, to the best of my knowledge only exists in C++ (for good reasons) and some functional languages for a completely different purpose. Honestly curious question: What fallout would you see from replacing it with a dot in Rust. I immediately see no disambiguation issues, but I'm not a compiler writer.

Ygg2 3y ago

> Despite the invalid example, the point still stands. Put arbitrary Rust against Python or Typescript and you'll see it immediately. Eh, I don't think that is fair, Rust even at best of times will have concepts like lifetime/references that Python and TS can just ignore and are thus "simpler". A much better comparison would be something like https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html. > and do away with snake_case. That's seem counterproductive - according to: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn.... I.e. you would do with most readable part of syntax.

weinzierl 3y ago
Before Rust everybody[1] seemed to believe we cannot have a safe and natively compiled language. Rust proved the opposite. I don't see why we can't have clean, low noise, high signal syntax in a language like Rust. My criticism is not the syntax that makes the language more expressive - that's essential complexity. I would want the accidental complexity removed, like the somewhat redundant distinction between dot and double colon. And I wish the cognitive load reduced by making the syntax as familiar as possible to as many people as possible. That's the reason I mentioned Javascript and Python - not only is their syntax more concise but also familiar to more people. When it comes to the snake case study, I'm not surprised at all. They did not control for the size each identifier took on the screen. That a bigger signal enables a faster response is common sense. Longer identifiers are easier to recognize but the downside is that they take away space we could use for other important things. That's why most languages keep the most frequent ones (like variable names) short and free from unnecessary noise like underscores. Also the sample size in the study was extremely small. [1] Except the Haskell/ML folks, naturally.
- Ygg2 3y ago
  > I don't see why we can't have clean, low noise, high signal syntax in a language like Rust. My criticism is not the syntax that makes the language more expressive - that's essential complexity. As I pointed in Matklad's post you need to add those concepts in or devise a way to infer them, side by side comparisson of Rust/JS is meaningless if one has no concept of lifetime or one abstracts details via GC. > Before Rust everybody[1] seemed to believe we cannot have a safe and natively compiled language. I do agree, but you can't avoid all trade-offs. Rust got safe, natively compiled language by increasing type complexity (adding lifetimes and ownership), and adding more sigil noise. If Rust had GC it would be way simpler and way less usefull. > like the somewhat redundant distinction between dot and double colon I don't think it's redundant. But I'm not a Rust compiler guy.