4 ms·

Not a Rust user, so not some intelligent criticism... but boy how Rust source codes hurt my eyes ! Things like this: <'_> #[] stuff::thing::blah

Not a Rust user, so not some intelligent criticism... but boy how Rust source codes hurt my eyes ! Things like this: <'_> #[] stuff::thing::blah @gloop(gloop) if(fizz) |buzz| .Meh => |wtf| I know, I know... you probably get used to it once you understand the semantics and it's subjective anyway and and and... but still, not all languages I know repel me visually.

wizzwizz4 3y ago
Your last three examples are syntactically invalid Rust. It should be more like: <'_> #[foo] stuff::thing::blah match gloop(gloop) { x @ _ => x } if fizz { |buzz| Some(buzz) } else { |_| None } Meh => |wtf| ()
- JodieBenitez 3y ago
  You're certainly right, I just copy/pasted stuff from the article and changed identifiers, probably adding errors in the process, but the point was never to give accurate examples, just point that even reading Rust code requires significantly more learning than other languages. YMMV of course. Thanks for correcting me. Still not a joy to read though.
  - wizzwizz4 3y ago
    It requires less learning than Haskell. A tad more than C. Less than C++.
    - maleldil 3y ago
      > Less than C++ That depends. Rust requires less learning than C++ for writing safe code. There are plenty of C++ developers that feel like they know the language but produce unsafe code. Rust won't let you do that, so these developers complain.
hucker 3y ago
The last three are taken from the OPs Zig example, and is not valid Rust at all.
- JodieBenitez 3y ago
  Oh ? Thanks, fine... so that applies to zig has well...
weinzierl 3y ago
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.

wizzwizz4 3y ago

Your last three examples are syntactically invalid Rust. It should be more like: <'_> #[foo] stuff::thing::blah match gloop(gloop) { x @ _ => x } if fizz { |buzz| Some(buzz) } else { |_| None } Meh => |wtf| ()

JodieBenitez 3y ago
You're certainly right, I just copy/pasted stuff from the article and changed identifiers, probably adding errors in the process, but the point was never to give accurate examples, just point that even reading Rust code requires significantly more learning than other languages. YMMV of course. Thanks for correcting me. Still not a joy to read though.
- wizzwizz4 3y ago
  It requires less learning than Haskell. A tad more than C. Less than C++.
  - maleldil 3y ago
    > Less than C++ That depends. Rust requires less learning than C++ for writing safe code. There are plenty of C++ developers that feel like they know the language but produce unsafe code. Rust won't let you do that, so these developers complain.

hucker 3y ago

The last three are taken from the OPs Zig example, and is not valid Rust at all.

JodieBenitez 3y ago
Oh ? Thanks, fine... so that applies to zig has well...

weinzierl 3y ago

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.