Sound like a typical Rob Pike design. Idiosyncratic, not that user friendly, and mostly "works for me" affair (considering things like the Sam editor and parts of Golang).
It's actually from APL.
Not about character in general, much less about "rubbishing" it.
In light of this, "sounds like you have something personal against Rob Pike", is moot.
A flagrant example of
> idiosyncratic, not that user friendly, and mostly "works for me" affair
being date/time patterns in Go.
This approach to precedence comes straight from Iverson and APL itself. Iverson originally started out designing a more uniform mathematical notation. It developed into a programming language secondary to that. Note that J, K, and others in this family all duplicate this choice largely. And there's mainstream languages that have chosen the middle ground of allowing basic precedence for + - * / expressions but require explicit grouping otherwise.
It's not a particularly outlandish idea.
So attributing it to Rob Pike's personality traits is just off the mark. It's ok to be critical but it should be specific and informed, not just bashing someone character as a whole, and if you're gonna take it that far, you'd probably better at least know what you're actually talking about.
And note I've been critical of Rob's choices and behavior surrounding Go's date/time on a particular issue, so note this isn't empty hero worship on my part.
That's fine, since I didn't speak about Pike's "personality traits", but to his architecure/design tendencies.
And I didn't attribute this design to him. I know of APL, and even if I didn't the influence is right there in the TFA title. I compared it to his designs ("sounds like a typical Rob Pike design"), i.e. he adopted it because he does have these design tendencies, and so this was to his taste.
>not just bashing someone character as a whole
Where exactly are you getting that from? As if I've called him a "bad person" or something?
Even worse, you (GP) can't say this is typical without providing any examples when the most obviously relevant analogy (precendence in Go) does not support your statement.
It's probably good to not take the "typical" too literally and more as a "Rob Pike has done a few designs in the past that have this quality".
What's the point in creating something new if you simply repeat what already exists?
Refactoring?
Making a FOSS version?
Learning?
Doing it in Rust because it's fashionable?
Competition with an existing player in the same market?
And lots of other reasons besides...
Now, you might disagree with that, but at least disagree with what I tried to say, not what I didn't mean :)
For method capitalization, I'd say no, as this is the case in any other popular languages too (C# to name but one).
Not completely unique (e.g. variables v symbols in erlang, concrete type v generic placeholder in haskell) but really rare, and usually the capitalisation isn’t a switchable thing, it’s a very fixed meaning.