1) You basically have both () and [], wasting one of the scarcest
resources in syntax (brackets).
Some people might argue that getting a value from an array is totally
different from getting the same value from a function or a map, and
deserves special syntax. If we look at languages which did away with
this made-up difference we see that pretty much no person is missing
it.
Even if you disagree with this reasoning and consider arrays to be
something very special, deserving its own syntax – guess what? Rust
developers introduced the traits Index and IndexMut, so all the great
ideas about some type being special and knowing what happens when you
read [] went straight out of the window.
If we dig deeper and try to understand why they did something so
astoundingly mis-designed, we basically hit an interesting issue:
They overloaded their [] operator to do two completely different
things, depending on whether there is an & in front.
Thing A: return the value at the given index
Thing B: return an address pointing into the indexed data
This of course doesn't translate well into the () syntax, given that
Rust devs are proud that they don't support overloading.
(I guess []'s overloading doesn't count for some reason ... and doing
the little dance with traits doesn't count either.)
Taking a step back, if it would have been considered acceptable to
pick two different names for doing two different things, the whole
issue wouldn't exist, e. g.:
Thing A: values(1)
Thing B: values.at(1)
2) Yes, we agree. Having different sets of rules for a) language
designers and b) language users has shown consistent results:
It never worked out.
3) Yes. I have nothing against terse syntax, it should just be
consistent. (I favor not abbreviating things though, because it's
difficult to be both terse and consistent, considering that things
can be abbreviated in more than one way.)
4) Yes, I know what they do. I just thought it was a nice example of two
related constructs having different casing style and abbreviation
style.
6/7) See 1). The sad thing is that [] can do whatever the developer
wants. All guarantees went out of the window with Index/IndexMut.
9) What I meant was that not every macro wants to define some weird
language DSL. There are plenty of things which only exist as macros
because the language lacks varargs. (vec! for instance.)
If the language ever adds varargs, vec! can't just stop being a macro,
because that would break source compatibility: They would need to keep
the macro version of vec and introduce a new non-macro version of vec,
and hope people migrate from vec! to the "new" vec.
It's a design which makes the common 90% suffer for the benefit of the
most complex 10%. Sometimes it is worth it, but in this case I think it is
not.
10) I had the combination of picking a symbol which is both hard to read and
hard to parse in mind.
Every language that chose <> has weird cruft and therefore it shouldn't
haven been too surprising that Rust is also suffering issues, but in
Rust's case the problems have been shokingly severe. There are loooong
discussions about it if you want to read them. (So it's not just me.)
11) Sorry, I meant structs.
12) URLs are an option. There are also alternatives. I think the essence is
that it's possible to deal with these issues without entering Java's
tld.mycompany.mycontinent.mygroup.myproject.mydogsmiddlename madness.
I hope this cleared some things up. :-)
