4 ms·

I love the semicolon rule, I think that distinction is extremely important and too often gets muddled (though in Rust's case I think it's more accurate to say

I love the semicolon rule, I think that distinction is extremely important and too often gets muddled (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions")

still_grokking 4y ago
> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness. Usually nobody reads semicolons! They are usually just line noise coming form a time as parsing code was actually still some kind of science and people made syntax with the explicit intent to be easy readable by archaic computers (and not humans in the first place). I think `return`s are superfluous but given the choice between some more line noise in the form of a `return` statement and this semicolon brain-fart I would clearly prefer the `return`… > (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions") Since when? Did I miss something? (This could be, I'm looking only occasionally into Rust). AFAIK leaving out the semicolon is only an option on the last expression of a procedure, turning that "procedure" into a function. Leaving out (the completely unnecessary!) semicolons elsewhere is a syntax error to my best knowledge. fn main() { let baz = if false {"bar"} else {"foo"} println!("Hello, {baz}!", baz = baz); } The above code would not compile, afaik, because the semicolon is missing on the first line of the procedure. The completely unnecessary semicolons are just one of the examples that make the Rust syntax heavyweight and needless noisy for no good reason. I don't get how a modern language can fall back to such antique syntax. The very rare use-case where you really want to write some comprehensive one-liner could have been easy supported by optional semicolons. But in the general case one just doesn't need that line noise. Rust is a great language, really! But they obviously didn't put any effort into the syntax. The result is that the language reads partly like C++, and I guess almost everybody could agree that C++ has one of the most terrible syntax out there. Rust is "modern" language with a stone age look & feel. That's a big missed opportunity, imho.
- Quekid5 4y ago
  > But they obviously didn't put any effort into the syntax. Ackshually moment here, but they did put a lot of effort into chosing syntax which would require very little look-ahead on the part of the parser (given current or even decade+ old parser tech). I don't understand their reasons for doing so at all, but that's what they did. The result is... not very human-friendly IMO.
  - still_grokking 4y ago
    Exactly my point. This syntax was made for machines, not for humans. That's just not reasonable given how fast our computers are, and where the actual work for a modern compiler lies. But I don't get that either: Parsing is today the least problem. The time you spend parsing is negligible (if you didn't mess up the language completely, of course) compared to the time for type-checking and optimizations. Avoiding look-ahead (or especially the need to re-parse parts recursively) is a very good rule of thumb, sure. But when you need to decide whether you make the language simpler to read for the machine or more heavyweight for the human the answer should be absolute clear. A modern compiler spends anyway most of its time in the semantic analysis (and depending on language, later optimizing the output). Optimizing the lexical part for the win of a few milliseconds on tens of thousands of lines just makes no sense. Today's computers are even fast enough to parse spoken human language fast enough. Again it's the analysis that takes time there. The thing with Rust's syntax is especially annoying as almost everything else in that language makes a lot of sense. The concepts are neatly put together. It's explicit about the right things. It's considerably small and simple. It's almost a kind of sweet spot in language design, imho. And than it was hit hard with the ugly stick. That's a really sad point. And so needless. I still hope they will come to their mind some day, and will start to offer a kind of "light" syntax at some point. I really wish Rust could be more like Scala 3 on the outside, with a clean, minimal pythonic look & feel, and not like how someone put it before in a comment in this thread "When I look at Rust, all I see is `{};`". The later is also exactly my impression, sadly.
    - brundolf 4y ago
      It’s not just about parser throughput, it also helps with giving better error messages (because the compiler can make better sense of partially-broken syntax), which is something the Rust team cares a whole lot about.

still_grokking 4y ago

> I love the semicolon rule, I think that distinction is extremely important and too often gets muddled Yes, the distinction is important. That's why it's extremely annoying that this distinction is almost invisible if you don't look very close on the code using magnifying glasses. Like I said: Marking such an important distinction through something almost invisible like a (missing) semicolon is pure craziness. Usually nobody reads semicolons! They are usually just line noise coming form a time as parsing code was actually still some kind of science and people made syntax with the explicit intent to be easy readable by archaic computers (and not humans in the first place). I think `return`s are superfluous but given the choice between some more line noise in the form of a `return` statement and this semicolon brain-fart I would clearly prefer the `return`… > (though in Rust's case I think it's more accurate to say it distinguishes between "statements and expressions" than "procedures and functions") Since when? Did I miss something? (This could be, I'm looking only occasionally into Rust). AFAIK leaving out the semicolon is only an option on the last expression of a procedure, turning that "procedure" into a function. Leaving out (the completely unnecessary!) semicolons elsewhere is a syntax error to my best knowledge. fn main() { let baz = if false {"bar"} else {"foo"} println!("Hello, {baz}!", baz = baz); } The above code would not compile, afaik, because the semicolon is missing on the first line of the procedure. The completely unnecessary semicolons are just one of the examples that make the Rust syntax heavyweight and needless noisy for no good reason. I don't get how a modern language can fall back to such antique syntax. The very rare use-case where you really want to write some comprehensive one-liner could have been easy supported by optional semicolons. But in the general case one just doesn't need that line noise. Rust is a great language, really! But they obviously didn't put any effort into the syntax. The result is that the language reads partly like C++, and I guess almost everybody could agree that C++ has one of the most terrible syntax out there. Rust is "modern" language with a stone age look & feel. That's a big missed opportunity, imho.

Quekid5 4y ago
> But they obviously didn't put any effort into the syntax. Ackshually moment here, but they did put a lot of effort into chosing syntax which would require very little look-ahead on the part of the parser (given current or even decade+ old parser tech). I don't understand their reasons for doing so at all, but that's what they did. The result is... not very human-friendly IMO.
- still_grokking 4y ago
  Exactly my point. This syntax was made for machines, not for humans. That's just not reasonable given how fast our computers are, and where the actual work for a modern compiler lies. But I don't get that either: Parsing is today the least problem. The time you spend parsing is negligible (if you didn't mess up the language completely, of course) compared to the time for type-checking and optimizations. Avoiding look-ahead (or especially the need to re-parse parts recursively) is a very good rule of thumb, sure. But when you need to decide whether you make the language simpler to read for the machine or more heavyweight for the human the answer should be absolute clear. A modern compiler spends anyway most of its time in the semantic analysis (and depending on language, later optimizing the output). Optimizing the lexical part for the win of a few milliseconds on tens of thousands of lines just makes no sense. Today's computers are even fast enough to parse spoken human language fast enough. Again it's the analysis that takes time there. The thing with Rust's syntax is especially annoying as almost everything else in that language makes a lot of sense. The concepts are neatly put together. It's explicit about the right things. It's considerably small and simple. It's almost a kind of sweet spot in language design, imho. And than it was hit hard with the ugly stick. That's a really sad point. And so needless. I still hope they will come to their mind some day, and will start to offer a kind of "light" syntax at some point. I really wish Rust could be more like Scala 3 on the outside, with a clean, minimal pythonic look & feel, and not like how someone put it before in a comment in this thread "When I look at Rust, all I see is `{};`". The later is also exactly my impression, sadly.
  - brundolf 4y ago
    It’s not just about parser throughput, it also helps with giving better error messages (because the compiler can make better sense of partially-broken syntax), which is something the Rust team cares a whole lot about.