Hacker News Reader

Comment by JodieBenitez | Hacker News Reader

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.

View on HN

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

Oh ? Thanks, fine... so that applies to zig has well...

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.

> 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.

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.

Variable names in most languages are pascalCase, not CamelCase, which is typically used for type names.

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.

    use foo::bar::baz;

    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.

    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 :-)

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.

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.

> // invisible error here because someone used tabs by mistake

would not parse, so no invisible mistake.

Implying every site you post code to will have correct syntax highlighter.

Rust's philosophy is "explicit over implicit" - braces fall inline with that. One extra line for a struct is really not a lot.

That whitespace sensitivity also leads to having to escape newlines, with `\` trailing lines all over the place in Python. I find that far uglier than "4 times the dots" for import statements.

> Of course, I don't agree :-)

For sure, I think that's kind of my point. Like, this all feels very unimportant to me and extremely subjective. I think that rust's syntax fits into its philosophy, however. I would not mind unifying path syntax such that `:` became `.` however.

oh the irony...

    "Explicit is better than implicit."

;-)

It's a fantastic example of how witty sayings don't necessarily lead to agreement, even among people who would agree in the truth of the saying.

Indeed... "philosophy" is often a poor justification for technical choices.

I don't actually see the irony?

> "double colons bad" is just an extremely subjective take that I don't really buy at all.

It is objectively worse to type shift+; two times than a single non-shifted period.

That's a very simple selling point, what's there not to get?

What I find worse than the typing issue (which I agree with) is that it is an uncommon choice for something a very common choice exists.

Even worse is that its use is so similar to the situations where the dot is used that it's just confusing. The Internet is full of questions when to use which. This is in my eyes unnecessary complexity and does not mesh well with the aspiration of Rust wanting to be beginner friendly.

FWIW I am "pro-dot". I just don't think it matters much at all.

> 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.

> and do away with snake_case.

That's seem counterproductive - according to: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUn....

I.e. you would do with most readable part of syntax.

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.

> 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.

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| ()

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.

It requires less learning than Haskell. A tad more than C. Less than C++.

> 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.

Reply on news.ycombinator.com