I'm going to make a superficial comment and say that "cont" and "ret" are annoying and gratuitous differences. C/C++, Java, Python, JavaScript, and I think Perl/Ruby/Go all use "continue" and "break". It's just pointless to be different in this respect.
A different concept should use different syntax -- and it looks like Rust has several new concepts where they can invent whatever syntax they want. But the same concept should use the same syntax.
I agree. I was noticing that it really read "odd" to me, like someone was trying to be clever and terse. I don't think saving a few keystrokes is worth the decrease in cosmetic appearance/readability. Indeed, I inferred what those keywords meant, but, yuck.
This (my) comment is just noise, but I support the choice of short keywords - it helps in seeing them iconically. It's not the typing, though I think that helps too, but the reading - a long word, you have to /read/. A short sequence of chars is an instantly, right-brain recognized pattern. For that same reason I much prefer '0' to 'NULL' for ptrs in C/C++ to (I'm talking about visually, not type safety).
fwiw, I thought the same when I began work on Rust, but I have since gotten quite used to the shorter keywords. At this point, I can't believe the keywords in other languages are so pointlessly long.
But the truth is that whatever the surface syntax is, one quickly gets used to it. What's more important are the core concepts at work.
Calling next on an iterator and continue in a loop do very different things. C++ iterators use ++ too, but even though ++ and loops are often found together, I would not list ++ and continue as even remotely synonymous.
This looks like a bad design. It means either (a) the semantics of 'ret' inside a lambda function can change depending on the call site (whether it's used inside a for loop or not); (b) that a lambda function passed in from elsewhere can cause your function to return early; or (c) that lambda functions have different syntax rules depending on where they're being defined. All of which seem equally bad!
I hope there's something I've missed. I've been quite impressed by the rest of the language so far & it would be a shame if they got this wrong.
You're missing something. The semantics of `ret` are always consistent: it always returns from out the innermost `fn()` declaration (closures written using the sugared notation `{||...}` do not count as fn declarations, but closures written as `fn() { ... }` do). In cases where this is not possible, a static error is generated.
I feel continually obligated to remind people that if there's some aspect of the language that they don't like, they should speak up! :) The devs are always looking for feedback, either on the mailing list, the Github issue tracker, or in #rust on irc.mozilla.org.
That said, perhaps there is something you've missed. I've posted links to the Rust mailing list elsewhere in this thread, could you skim over those and let me know if they address your concerns? Honestly I'm not super-thrilled at this change myself, if only because it makes for loop invocations a bit busier to look at, but I can't say that I fully understand the semantic tradeoffs here.
> Why is there so much sugar?! Can't a keyword just be a keyword?
Statements based on keywords are syntactic sugar. What I'm seeing here in Rust is the complete opposite, building an iteration statement from language built-ins. It does include some sugar in it (and "for" is a special keyword) but the semantics of the construct is based on lambda calculus and other lower level constructs in Rust.
In general, it's better that a language has as little special syntax that cannot be constructed from elementary blocks. The gaps are then bridged by adding a little sugar coating to make programming convenient (for humans) but keeping the core language clear and concise (for interpreters and compilers).
For example, in C, you cannot define your own loop structures and you're stuck with for, do and while (C macros are so crappy that they don't count). Haskell, on the other hand, does not have any special iteration statements in the language core but there's a handful of iteration functions that are regular functions and you are free to define your own. Same thing with Scheme (and other Lisps).
What I do not understand of the late "scripting" languages (Dart, Rust) is why they don't just modify Ruby to have a stricter type system and call it done? That or just abandon the scripting mindset and go for more purely functional languages with non-C-like syntaxes like Haskell or OCaml.
Rust is emphatically not a scripting language. It is a systems language with many features drawn from functional languages (e.g. tagged unions for data types, pattern matching, a type class system, type inference) as well as a strong type system with the addition of type states, which are assertions tracked by the compiler. Yes, its syntax is C-like, but I'd assert that it has more in common with OCaml than Dart.
With that in mind, the suggestion that it'd be more worthwhile to strap static types onto Ruby is like looking at engineers designing an aerodynamic, fuel-efficient, high-speed dragster and suggesting they stick a bigger engine in a sedan and call it done. Yes, Rust has adopted a feature superficially similar to Ruby's; that does not mean it wishes to fill the same niche or that Ruby's goals align with Rust's in any significant way.
I didn't downvote you but I guess you are getting some hate for considering rust a scripting language, since it has none of the features traditionally associated with such languages (simple vm or interpreter, dynamic typing, no compile step).
I think you may be confusing it with something else.
A different concept should use different syntax -- and it looks like Rust has several new concepts where they can invent whatever syntax they want. But the same concept should use the same syntax.