5 ms·

I agree 100%. The Rust syntax is so different from C, C++, Go and Java that it's very difficult for me to use. I love the idea of Rust, but I wish the syntax wa

by w8rbt 9y ago

I agree 100%. The Rust syntax is so different from C, C++, Go and Java that it's very difficult for me to use. I love the idea of Rust, but I wish the syntax was more similar to traditional languages. If it were, I think it would be a very easy transition for many of us.

sanderjd 9y ago
I'm curious: what is so different about the syntax? It seems very similar to me.
- majewsky 9y ago
  I think the thing that puts me off the most is the lifetime specifiers: let foo:'static str = "foo"; Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. Just like for parentheses; imagine how confusing it would be if ' would have been ( instead. let foo:(static str = "foo";
  - kbenson 9y ago
    > Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. In fairness, you should never be searching for matching apostrophe. Single quote, maybe. The fact that it's an apostrophe should also trigger that it might have something to do with possession... (or that something was omitted).
  - int_19h 9y ago
    This particular convention is inherited from the ML family, where it has been very popular for a very long time. For what it's worth, there are many cases even in the natural language where ' is not supposed to have a "closing" counterpart - indeed, the "it's" in this very sentence is one such example. Then you have the use of ' to denote feet and minutes of arc. Now, technically these are all actually different symbols, with their own Unicode codepoints etc - but in practice, people use ' for all of them, and it doesn't seem to be confusing anyone. You could treat the ' in Rust as something along these lines.
  - sanderjd 9y ago
    Granted, lifetime syntax has no analogue in the languages the comment I was replying to mentioned. That doesn't seem to be enough to qualify as "so different" though. But maybe it is?
zanny 9y ago
A lot of the compromises made in Rust syntax were to make it much, much easier for the compiler to reduce passes to compile into a syntax tree. There are certainly some things that should just be obvious now, though. Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol, using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.) And the syntax for lifetimes is horrible, with the 'a and the fact that in practice its about as significant as naming parameters in a C++ function definition in a header (ie, pointless - the words are discarded by the compiler every time). And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam. Given all that, Rust is still, IMO, the best programming language we have right now for native performance, period. We can criticize what we don't like but we should at least agree its the best we have.
- kbenson 9y ago
  > Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol Obtuse? It's sort of common. Multiple languages use it. Personally I like the namespace separator being distinct from the object/struct element accessor. At least they didn't copy PHP in using backspace... > using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.) Please, let's not have more cases where things look like functions but aren't. Functions should look like functions. Operators should look like operators. You might have to learn a small set of operators for a new language. This is front-loading some confusion and learning pain for ease of use later. It may make the language harder to read for people that don't know the language, but anyone reading the source code with the aim to make some changes should probably know the operators at least. I'm not sure giving it a slightly more expressive name but making it look like something else actually makes life easier for those people. > And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam. Optional whitespace significance? That sounds like a recipe for disaster, IMO. I can see a case for one or the other, but mixing of modes like that when it deals with something that is by nature somewhat invisible (or meta), seems prone to problems. Also, examining why Python has had problems with functional style workhorses like map might shed some light on the negative aspects of whitespace dependent syntax.
allengeorge 9y ago
That...seems very surprising to me. I've used almost exactly the same set of languages, and I found the Rust syntax incredibly familiar. There are times when (especially if you use a lot of boxing and ref-counting) that you can get a touch of operator soup, but that's not that often. Anyways, the languages feel very similar to me.
deleted 9y ago
[deleted]
bpicolo 9y ago
The syntax is really on the same as C-Style languages, minus the extra lifetimes bits.

by w8rbt 9y ago

sanderjd 9y ago

I'm curious: what is so different about the syntax? It seems very similar to me.

majewsky 9y ago
I think the thing that puts me off the most is the lifetime specifiers: let foo:'static str = "foo"; Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. Just like for parentheses; imagine how confusing it would be if ' would have been ( instead. let foo:(static str = "foo";
- kbenson 9y ago
  > Whenever I see an apostrophe, my mind defaults to frantically searching for its counterpart at the end of the string they're enclosing. In fairness, you should never be searching for matching apostrophe. Single quote, maybe. The fact that it's an apostrophe should also trigger that it might have something to do with possession... (or that something was omitted).
- int_19h 9y ago
  This particular convention is inherited from the ML family, where it has been very popular for a very long time. For what it's worth, there are many cases even in the natural language where ' is not supposed to have a "closing" counterpart - indeed, the "it's" in this very sentence is one such example. Then you have the use of ' to denote feet and minutes of arc. Now, technically these are all actually different symbols, with their own Unicode codepoints etc - but in practice, people use ' for all of them, and it doesn't seem to be confusing anyone. You could treat the ' in Rust as something along these lines.
- sanderjd 9y ago
  Granted, lifetime syntax has no analogue in the languages the comment I was replying to mentioned. That doesn't seem to be enough to qualify as "so different" though. But maybe it is?

zanny 9y ago

A lot of the compromises made in Rust syntax were to make it much, much easier for the compiler to reduce passes to compile into a syntax tree. There are certainly some things that should just be obvious now, though. Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol, using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.) And the syntax for lifetimes is horrible, with the 'a and the fact that in practice its about as significant as naming parameters in a C++ function definition in a header (ie, pointless - the words are discarded by the compiler every time). And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam. Given all that, Rust is still, IMO, the best programming language we have right now for native performance, period. We can criticize what we don't like but we should at least agree its the best we have.

kbenson 9y ago
> Using the C++ namespace separator of :: is just ludicrously obtuse for an extremely common symbol Obtuse? It's sort of common. Multiple languages use it. Personally I like the namespace separator being distinct from the object/struct element accessor. At least they didn't copy PHP in using backspace... > using the & for refs is archaic (I mean... you could have just called it a ref. ref T instead of &T. And then just ref(foo) or foo.ref to get a ref to foo.) Please, let's not have more cases where things look like functions but aren't. Functions should look like functions. Operators should look like operators. You might have to learn a small set of operators for a new language. This is front-loading some confusion and learning pain for ease of use later. It may make the language harder to read for people that don't know the language, but anyone reading the source code with the aim to make some changes should probably know the operators at least. I'm not sure giving it a slightly more expressive name but making it look like something else actually makes life easier for those people. > And I certainly would have argued for whitespace significance, at least as an option, instead of classic semicolon spam. Optional whitespace significance? That sounds like a recipe for disaster, IMO. I can see a case for one or the other, but mixing of modes like that when it deals with something that is by nature somewhat invisible (or meta), seems prone to problems. Also, examining why Python has had problems with functional style workhorses like map might shed some light on the negative aspects of whitespace dependent syntax.

allengeorge 9y ago

That...seems very surprising to me. I've used almost exactly the same set of languages, and I found the Rust syntax incredibly familiar. There are times when (especially if you use a lot of boxing and ref-counting) that you can get a touch of operator soup, but that's not that often. Anyways, the languages feel very similar to me.

deleted 9y ago

[deleted]

bpicolo 9y ago

The syntax is really on the same as C-Style languages, minus the extra lifetimes bits.