[Ygg2]

    > Nobody claims that <> isn't "familiar". People are claiming
    > that <> isn't very good, and they are correct with that.
    > Those languages which made <> "familiar" picked <> because
    > they added templates/generics/... after the fact and tried
    > to bolt them onto an existing language without breaking all
    > existing code.   

What people are claiming this? Is there some argument

     <Type, <Type<Type>>> 

is much better than

     [Type, [Type[Type]]]

in monospaced fonts? I agree I prefer it, but I know it comes down to subjectivity and familiarity. Not the most compelling reasons.

  >      impl Index<usize> for MyFunnyArray {
               type Output = u32;
               fn index<'a>(&self, _index: usize) -> &u32 {
                   &self.arr[random::<usize>() % 3]
               }
           }

           impl IndexMut<usize> for MyFunnyArray {
               fn index_mut<'a>(&'a mut self, _index: usize) -> &'a mut u32 {
                   self.arr[random::<usize>() % 3] = random();
                   &mut self.arr[random::<usize>() % 3]
               }
           }

Sure, you can write that, but you can also write:

      fn getIndex(&self, index: usize) {
           self.arr[random::<usize>()%self.arr.length]
      }

Rust won't protect you from stupid mistakes. The only question is whether it will allow you to override index syntax.

      myArray[3]
      myArray.getIndex(3) 

I actually prefer this small token of power, as opposed to having to write:

     date1.compareTo(date2) < 0
     date1.equalsTo(date2)
     date1.index(at)

That gets tedious fast.

     > As you might see, they are called i32 and u32, not i32 and UnsignedInt4Bytes.

Correct, because they are both built in literals. String isn't a built in literal. You can't have:

      u32::new()



     >Not sure what you suddenly try so say with "you can't
     >modify this", "you can't mutate that".

     >As shown in 1) [] can do whatever the developer implements.
     >Sure, the usual language rules apply, I think nobody 
     >disagreed on that.

No matter how many time you call Index on your array it stays the same. What kind of trippy Index you want to implement is still there, only with uglier syntax.

      > Yes, that's exactly the concern I'm raising here, because that's what Rust is encouraging.

It's not. All macro invocations are fenced in by macro calls. All syntax extensions are followed by extension calls. Could macros/syntax extensions do horrible things? Sure. So can regular code.