[frowaway001]

It says a lot about Rust's culture. If they are not only _not_ interested, but actively hostile towards input, why should I bother?

Just look at the replies. Sure, it's possible to hand-wave issues away by setting the standards low enough with "Java did that mistake, too", "we just copied that from Python", "this looked more familiar" ... I think no one disagreed with that.

It's 2015, and having marketing along the lines of "we only made half of C++' mistakes" just doesn't cut it for me anymore.

For other people it might be good enough, but I'm worried that Rust won't get enough traction if the language is not drastically better on average than its incumbents, but just messy in different ways.

[Ygg2]

First off, Rust != Hacker News. You might have been downvoted by someone unaffiliated by Rust on HN. For example I'm affiliated with Rust community but didn't down-vote you.

Second, let's review your post:

You never supplied examples to your comment of using some abbreviation only half of the time.

Your point about Rust using [], () and {} for functions is wrong, because it only ever uses () for function calls, others can appear in macro.

Your example of using <> vs [] is a subjective choice, that doesn't have any scientific or even majority consensus. To make matters worse, one of Rust's side goal is to somewhat ease migration of C++ programmers to Rust. I actually agree with you on this point, but I realize most people would find this syntax confusing due to habit of writing array literals using brackets.

On the other hand underscore python style that is proven by a study[1] to be a better choice for readability you consider the less usable one.

[1] http://www.researchgate.net/profile/Bonita_Sharif/publicatio...

Could you improve your post with examples and scientific studies demonstrating your points and post it to http://internals.rust-lang.org/ or http://users.rust-lang.org/ ?

[frowaway001]

It is perfectly fine that many design choices in Rust evolved from "let's copy what $random_language did", but mentioning the drawbacks of that kind of approach to language design suddenly requires "scientific studies demonstrating your points"?

Are you kidding me? That's exactly what I meant with "Rust people are actively hostile toward input".

It is even more "I don't want to hear what you say" than it appears on the first look, because we both know that counting all "scientific studies" about language design probably wouldn't require more fingers than a human usually has.

So all we have is some empirical knowledge. You even got some findings for free! Things no one ever said:

  - "Having two different ways to call/invoke/execute stuff
     made it much simpler to learn the language."
  - "Making the casing of types inconsistent really helps 
     when reading code."
  - "Dropping random characters in functions and types made 
     me feel at home coming from C! I would be terribly 
     confused if ptr was called pointer, vec vector, fmt 
     format, iter iterator or rt runtime. The only thing I 
     don't like is FromStr, it should really by FrmStr 
     instead! .. I love str's rsplitn btw!"
  - "Calling Strings Strings and String views str ... that 
     makes a lot of sense!"
  - "Having used both <> and [] extensively, <> is much 
     more readable."
  - "It was a really great idea to have special syntax for 
     arrays, so the language designers could overload [] 
     with two completely different meanings."
  - "Having both () and [] available is great because you 
     can write code where foo(x) and foo[x] do different 
     things!"¹
  - "Not having varargs really worked out! Nevermind that 
     most popular macros exist solely to emulate varargs!"
  - "Despite most macros not needing the do-whatever-
     you-want syntax, let's require ! for all of them. This 
     way, macro writers don't have any reason left to try 
     making their macros behave predictably! Isn't it great 
     that they can just claim 'you knew that all bets where 
     off when you wrote that !, so stop complaining!' 
     instead of fixing their macro?"
  - "Fucking up Generics so badly that it requires 
     different ways of writing them depending on the 
     context really paid off. It's certainly not an issue 
     which is hit by every person writing something Generic 
     for the first time."
  - "Inventing unnecessary differences between modules and 
     objects is great, because it forces you to think 
     whether you need to use . or :: and breaks use-sites 
     of that code when migrating from one to the other."
  - "Given all the lessons of terribly broken dependency 
     management systems out there – let's just ignore them 
     all and put every package in a global namespace ... 
     what could ever go wrong?"

The language could have been much better if Rust devs wouldn't have been so insecure and defensive, but now it's too late anyway.

So why bother evoking any more excuses in different places? Rust-the-bad-parts is basically unchangeable now.

So what's left? I think it's only honest if Rust devs would be more open about the mistakes they made, and wouldn't require outside expertise to point out the issues.

¹ WAIT ... that's actually what Rust devs said when they defended having both () and [].

[kibwen]

Not only are all your points about Rust incorrect, but numerous people in both this thread and past threads have repeatedly told you why they your points are incorrect and yet you persist in believing that they have been unaddressed. At this point it's safe to say that observers have caught on to your campaign of indefatigable misinformation and find it easier to downvote your comments than to waste any more of their time making arguments that you will proceed to blithely ignore.

In fact, it says a lot about Rust's culture that people were willing to engage you constructively in the first place despite your acerbic and technically-naive ramblings.