That is the case in Crystal. Doesn't feel weird - if anything it is consistent in that ()s always denote something to do with execution. Both ()s and {}s have multiple different other syntactic usages though, so it is not as if either is optimal.
Function calls can then be treated as functions from a single tuple argument, as is idiomatic in SML.
It's not inconsistent to hold the simultaneous beliefs that "trying to fix Rust's syntax would make it worse" AND "Rust's syntax is insane".
And given those beliefs, maybe adding a postfix operator to express what everyone else does with a function call was a poor call.
Nothing about the soundness of your design means that Rust isn't hard to learn, is all I'm saying. And per the freakshow all around us, it's getting harder, not easier.
Because tuples are considered good things to have in a modern language. Structs and enum variants are just named versions of tuples (denoted with parentheses) or records (denoted with braces—unnamed records don't exist in Rust). To follow languages like Python, they're written "(1, 2, 3)". (It would be weird if tuples were written "{1, 2, 3}", right?) Therefore, a tuple named Foo is written "Foo(1, 2, 3)".
Removing tuples from the language was actually considered at one point, but the community (including me) really wanted them to stay, so they stayed.
> Why is "127.0.0.1" not a String?
Because it's a str, and there is a difference between str and String. Not having a string-view type would be a big mistake in a systems language like Rust. Note that "127.0.0.1" is not a std::string in C++ either (though there is an implicit constructor that can make it one).
In fact, the reason why we have both "str" and "String" is precisely to address your criticism: if we named "str" "string_view" or something, then people would be really surprised that a literal like "127.0.0.1" isn't a string.
> Why do parametrized enumerants look in rvalues like C++ constructor arguments, which you promised earlier Rust didn't have?
Because saying Rust has C++ constructors would just make things more confusing, because then people would expect them to behave like C++ constructors. It's less confusing to say that Rust doesn't have constructors like C++ does.
> And... did they even need to be questions in the first place?
I don't see any alternatives to the above that would make the language better instead of worse.