Rust is exceptionally noisy and terse. Easily worse than C++, in my opinion, which is known for being noisy.
Two things bug me in particular. Rust eschews readability by erring on the side of terseness — fn instead of something like func, for example, might save some typing, but does contribute to making visually denser.
The choice of snake_case instead of camelCase also adds to the noisiness, because there's no programmer font that aligns the underscore with the text baseline, so it's disruptive. Snake case is pretty aptly named; typographically, there's a lot more visual cohesiveness to camelcase. (As an aside, I never understood the lack of consistency here: the capitalized version of foo_bar should surely be Foo_Bar, not FooBar.) Python admittedly uses snakecase, but avoids looking too ramshackle by having otherwise very little noise.
func typeList(dex *DexFile,
off uint32, parseClassDesc bool) []BStr {
I'm not the world's biggest fan of Go, but they did nail the readability aspect. Nim is another good example which does it even better.
Of course, Go doesn't have lifetime annotations, but I can't understand who thought using ' was a great idea.
I wish more time was spent on the visual aspect of a language. I'm really liking Reason, Facebook's new syntax for OCaml, which shows that a language can be made fresh and friendlier through aesthetics alone. Elixir is cleaner than Erlang, but I think it went too far in emulating Ruby; instead of very simply aligning "def" and "end", for example, you now have "do ... end" everywhere).
Your criticism comes down to wanting a different abbreviation for "function" and wanting camel case instead of snake case. I would suggest that it's not that we didn't spend time on the "visual aspect" of a language: rather it's that we made choices that were not your preference. We had to pick something and disappoint somebody; I apologize that that person was you.
> Compare something in Rust (from OP's repo):
As with so many of these comparisons, you're effectively comparing a language with GC to a language with safe manual memory management, and misinterpreting this as evidence of bad syntactic choices. (Same with Nim: Nim has GC.)
Look at the function signature when you remove the lifetime annotations:
No, those were only the two most obvious, easiest-to-solve examples that came to mind.
With all due respect to you and your Rust colleagues (who have done a lot of impressive work), "we made choices that were not your preference" sounds a little condescending. These are my personal opinions, just as your counterarguments are opinions. We should all able to make technical arguments without resorting to that kind of rhetoric. Of course you made choices. Everyone here is entitled to disagree with them and explain why.
There's a false dichotomy between "hard-to-read syntax" and "no syntax at all" being implied here. It's reasonable to imagine that Rust could have had less terse, but still readable, syntax, even for things like lifetimes.
> We should all able to make technical arguments without resorting to that kind of rhetoric.
The subtext here is that these decisions aren't technical. They're pretty arbitrary: "func" vs. "fn" or camel case vs. snake case. There's no science here: there are lots of very successful languages with camel case and lots of very successful languages with snake case.
I certainly appreciate that you have specific reasons for your preferences, but I take issue with the idea that we didn't spend time on the visual aspect of the language.
> It's reasonable to imagine that Rust could have had less terse, but still readable, syntax, even for things like lifetimes.
Do you have a proposal?
There were long threads with different proposals back when this stuff was being designed, but none of them were particularly palatable. The verbosity with anything that wasn't as lightweight as possible turned out to be too much.
you're effectively comparing a language with GC to a language with safe manual memory management, and misinterpreting this as evidence of bad syntactic choices.
So a better comparison would be to Swift. I don't think Rust compares favorably with Swift either.
Swift isn't garbage collected. ARC is not GC. It's actually a form of manual memory management, with lots of help from the compiler. The way you structure your program does give particular objects a particular lifetime.
Reference counting is a form of garbage collection [1] [2], as I've explained numerous times before. It has been considered a form of GC since the original papers in the 1960s and I see no reason to revisit that definition now.
To track the lifetimes of objects, Swift programs perform operations (reference count manipulation) at runtime. That's because the Swift compiler does not know the static lifetimes of objects, unlike Rust. It can optimize away some reference count traffic, but this doesn't change the basic system: semantically, all objects are reference counted.
Patrick already got into the subjectivity aspect here, so I'll leave that subthread there.
> Rust eschews readability by erring on the side of terseness
We actually used to be more terse, then slowly expanded things until it felt right. At one point in time, "return" was "ret".
> I can't understand who thought using ' was a great idea.
We had a lot of discussion about this before 1.0, and nobody was able to come up with a proposal that was clearly better.
> I wish more time was spent on the visual aspect of a language.
We did spend a lot of time on this, and are continuing to. For example, the rustfmt team is just getting going, to nail down the last bit of style guidelines. Rust has had many different syntaxes over the years, and this is what we arrived at. See that other thread on subjectivity; I actually really like the "C with a bit of ML sprinkled in" that we arrived at. The only thing I don't like at all is the turbofish, ::<>, but I understand why it exists, it's almost never required, and it at least has a fun name to take some of the edge off. That said, I've also gotten less and less opinionated about syntax over time; semantics is far more interesting. As long as everything is consistent, I don't care as much about the specific details.
"C with a bit of ML sprinkled in" is IMO quite an understatement. ML is all over the place.
Personally i would have been happier if Rust had become "C with only the borrow checker and nothing else".But the community decided differently, and that's OK too.
I'm a low level guy (embedded and systems stuff) and what i would hate in our codebase is if look at line of code and find x numbers of concepts in it.
Nevertheless i applaud what you and the Rust community achieved, but my impression is that you'll be going the C++ way. Why? I follow the discussions of the Rust community about the future of the language, and there's always this "if we only add this one more feature" (for example see discussion about GC).
P.S.:
For everyone saying "just use the features you need", no, this won't work. If they are available, people will (a)use them (see C++).
In fact, the only reason you need to write 'a anywhere there is to tell the compiler that the & reference and the lifetime parameter to DexFile are the same. If either of those two lifetimes didn't exist (e.g. if DexFile didn't take a lifetime) you could drop them entirely:
The difference with that go code is *DexFile is like Arc<DexFile>, and not like &'a DexFile<'a>. Yes, the go code is more readable, but it comes with additional overhead and data ordering constraints that the Rust code avoids.
Two things bug me in particular. Rust eschews readability by erring on the side of terseness — fn instead of something like func, for example, might save some typing, but does contribute to making visually denser.
The choice of snake_case instead of camelCase also adds to the noisiness, because there's no programmer font that aligns the underscore with the text baseline, so it's disruptive. Snake case is pretty aptly named; typographically, there's a lot more visual cohesiveness to camelcase. (As an aside, I never understood the lack of consistency here: the capitalized version of foo_bar should surely be Foo_Bar, not FooBar.) Python admittedly uses snakecase, but avoids looking too ramshackle by having otherwise very little noise.
Compare something in Rust (from OP's repo):
to Go: I'm not the world's biggest fan of Go, but they did nail the readability aspect. Nim is another good example which does it even better.Of course, Go doesn't have lifetime annotations, but I can't understand who thought using ' was a great idea.
I wish more time was spent on the visual aspect of a language. I'm really liking Reason, Facebook's new syntax for OCaml, which shows that a language can be made fresh and friendlier through aesthetics alone. Elixir is cleaner than Erlang, but I think it went too far in emulating Ruby; instead of very simply aligning "def" and "end", for example, you now have "do ... end" everywhere).
Edit: Typo.