My biggest gripe is that they left out readability.
I like the semantics of Rust, and appreciate the performance and the transparent memory model. I am extremely excited to try Rust on an embedded project.
Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance on my keyboard.
What exactly is terrible about it? The snake_case I got used to, I kind of like having braces, and that's not really a killer argument either, because most languages have them, apart from that I find Rust also much cleaner than Python syntax. I'm really not sure what you mean. Is it the lifetime annotations (because they're somewhat necessary).
fn accumulate<'a, T: Monoid>(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> T
where
T: From<&'a str> + From<String>,
yes, every single thing in there is necessary, it can be written in a more gruesome way, but the where clause clarifies it a bit
But let me cheat a little bit
( $(#[$attr:meta])* enum $enumer:ident { $($i:ident => $e:tt $( ( $($m:ident),* ) )* ; )* } ) => {
On the second one you got me though, I find the macro syntax a bit horrible. Sometimes I just want simple text substitution.
I guess the signature could be made more readable by using a few type aliases. The hardest part to read is the nested types.
I'm with you on the macro syntax, it is very hard to read. It is not easy to create a readable macro syntax though. All languages I know have hard-to-read macros, so this is not yet a solved problem.
for i in range(100000000):
...creates in memory a list with one-hundred million integers.
Expressive yes, but sometimes it can be double-edged for new comers (and not new comers).
fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t
where
t: Monoid + From &'a Str + From String,
It's also not realistically parseable- the Haskell/Ocaml-like removal of <>s and ()s relies on application being left-associative, and if you read this under that rule you've changed the meaning (e.g. `From &'a Str`).
Also, it makes autoindent in Emacs worse.
> If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window.
Clearly the correct answer is spaces. /s
Seriously though, I like python because not only is it pretty, it's also concise. While it's not perfect, a lot of time has been spent on language features to make them easily comprehendable.
The lesson for me from python is that UX is important, even in programming languages.
Here is the thing about indentation versus curly-braces-and-semi-colons: It boggles me that people find it acceptable to use one mechanism to communicate block structure to the compiler, and a completely different mechanism to communicate block structure to humans, and have no way to automatically check that they have the same semantics. This is a frequent source of bugs, and is entirely preventable. When it comes to the ergonomics of computer-convenient versus human-convenient, humans should win. Therefore, significant white space is clearly preferable simply from the standpoint of eliminating the source of an entire class of bugs.
But the main thing that makes Rust harder to read is all the punctuation noise and short, cryptic keywords. While one friend once said: "A good programmer can write FORTRAN in any language.", I don't feel compelled to help them.
Readability matters.
I still prefer whitespace to indicate blocks though.
Strongly agree. The solution that Rust, Go and other new languages have adopted is shipping a formatting tool to consistently make the semantics of indentation and braces match. I personally can't help but think that this is a worse-is-better solution when compared to significant whitespace, but at least it works. Every Rust CI I am setting up will fail the build if `rustfmt --write-mode=diff` feels like you didn't run rustfmt before committing.
> But the main thing that makes Rust harder to read is all the punctuation noise
Given the decision to favor explicit casts, references and dereferences over implicit ones, this cannot really be helped. In some ways, once you get used to it, it helps readability, because it always communicates what the things being worked on are.
> and short, cryptic keywords.
I agree that this was probably a mistake. Cannot really be helped now, though.
Overall, I think the readability argument against Rust is overstated. Sure, when you are starting out it looks like line noise, especially if compared to python. But it didn't take me more than a week or two before it basically became entirely clear and readable. The radical explicitness of the language helps readability in many ways that make it much better than C++.
Of course, much better than C++ is a low bar to pass.
I think it's funny how people still have issues with this in 2018.
Autoindent is a solution to a problem that doesn't exist in Python in the first place. Having two independent representations for blocks, one for human readers (indent) and one for compilers (braces), leads to nasty bugs when they get out of sync. Autoindent is a tool to keep them in sync. In Python there is a single representation, so nothing can get out of sync.
intmain()
{
r etu rn0;
} DO I = 1.100
DOI = 1.1
http://catless.ncl.ac.uk/Risks/9.54.html#subj1Python is ugly and inconsistent as hell due to lack of methods (no maps or reduce in collections for example), indentation, lack of expressions (nearly everything is a statement) and one statement lambdas.
Though rust is beyond good and evil indeed, I really don't get this obsession with brackets and C-like abominations like &*staff. Ada or SML are doing a much better job.
Languages like Java are more verbose which does make it a bit more frustrating to write but on the flip side I find them easier to read.