Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The worst decision regarding Rust syntax was following C++ syntax. Due to this, we write, in type syntax

Things<Like<This, That>, That> -- as in C++

Instead of a more legible (and very familiar to Rust authors)

Things (Like This That) That -- as in Haskell

Inherited from C++, we had also :: for namespacing (while a dot . could be perfectly be used for that), and tons of other stuff like <> for scoping generics.

Without some of that we could have:

    pub fn read<P: AsRef Path>(path: P) -> io.Result (Vec u8) {
      fn inner(path: &Path) -> io.Result (Vec u8) {
        let mut file = File.open(path)?;
        let mut bytes = Vec.new();
        file.read_to_end(&mut bytes)?;
        Ok(bytes)
      }
      inner(path.as_ref())
    }
Perhaps it looks a little better? It looks for me, at least.

For doing better than that we could drop C-like syntax perhaps?

The trouble is that languages have a weirdness budget - there's a finite amount of novel stuff a language can have until it becomes too weird for mainstream programmers. So language designers have to pick their weird features carefully. Spending it all in novel syntax is unwise.

I think that at the time the Rust pull was safety for low level code and, as Rust was targeted to replace some C++ components, following C++ syntax was seen as a good idea.



What’s the worst decision for you is my favorite feature of the language syntax for me. I find it easy to read and very easy to navigate in the text editor because types are enclosed by balanced operators that editors can easily highlight and jump between.


> Rust was targeted to replace some C++ components, following C++ syntax was seen as a good idea.

And that was a good decision. If it were too far from the C++ syntax, I would not have learned it, because as a mostly C++ guy at the time, some similarities with C++ helped me keep interest in Rust. Also, I was unable to parse Haskell's "type parameters as function applications" syntax, which was purely confusing. The Rust syntax is an abomination, that's true, but it is a necessary evil.


The parenthesis aren't to be parsed like usual functions f(x), I think that's was the major source of confusion

It's more like this,

Thing<A> becomes Thing A

Thing<A, B> becomes Thing A B

Thing<A, B, C> becomes Thing A B C

The parens only appears when you want to further nest types

And.. okay, I reckon that the Haskell syntax for types would be unfamiliar. But, at least, it's not as cluttered


By comparison, near-source-compatibility with C is arguably the "worst" design decision that C++ made, a constant source of complexity and frustration, and yet the #1 reason behind C++'s early growth and continued success. There are a lot of different factors at play here.


Dot syntax is used when accessing a function/property on a value, :: is used when accessing a function/property on a module or type. I think it's great having this visual distinction, especially given that you can call the same function in either style:

  let x = Foo::new();

  x.bar();
  Foo::bar(x);


I thought the distinction was meaningful until I worked in a language that used dot pervasively, and saw that it was totally fine.


Function application and type annotation both using parens is pretty jarring for a lot of people. I much preferred the proposal that would have used [] like typescript or scala.


I like how the namespace and the function chaining have different characters. I think it makes it easier to read.


Surely mixing usage of space and parentheses for function application is a bad idea?


But I'm not talking about function application - I'm talking about type application.

The syntax of type application and function application is already different in rust: F<A, B> vs f(a, b).

Type application even has default and named parameters! F<X = A, Y = B> and F<A> if B has a default.

I just think this particular type-level syntax is very noisy, specially because types in Rust tend to be very nested.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: