It probably takes a week to get used to ugly pants too. OP's point is a matter of aesthetic judgement. I don't mind it either, but = |&I: can| -> Agree { Rust::Syntax }; is.a(Bit(&mut chaotic);

I should probably have used something less ambivalent than "getting used to". There's certainly more elegance in Rust's semantics than syntax, but the latter doesn't really differ much from C, except for much better for loops, a sane declaration syntax (this is a BIG deal), and of course all the features that C just doesn't have, like closures^* Some of the syntax noise just has to be there in some way, to support the real deal which is the semantics.

^* I don't particularly enjoy the Ruby-borrowed || either, particularly because Alt-7 is a terrible key combination to type, but oh well.

Out of curiosity, what language specific keyboard requires alt-7 to enter the pipe symbol?

On the QWERTY keyboard, the pipe is near the enter key and easily typed.

Every time a language developer chooses to give their new language a novel, let alone chaotic, syntax, they sin against the very premise of software development being an engineering profession. Can you imagine the madness if mechanical engineers had the same laissez-faire mentality towards the conventions and learned best practices of their field? Randomly chosen bolts to use left hand threads just because it suits their arbitrary whim, every thread has a unique pitch never seen before just to make the machine stand out from the crowd. Parts of the machine use hot rivets, not because the design demands it but because it scratches a retro aesthetic itch the designer had that day. Every time a new machine is designed it has a whole class of new never before seen quirky ways of being put together and any mechanic who pleads for standardization on common sense ways of putting a thing together are just told to git gud because the creative expression of the 'engineers' is paramount.

(This is how we end up with German cars, isn't it?)

It's of course a matter of perspective, goals, and assumed knowledge. Is it choosing to not follow best practices, or leaving outdated practices with unfixable downsides behind? Is it inventing new things or instead actually just taking already-existing things that you just happened to not know about? Is it making arbitrary changes, or necessary ones for a useful goal? Is an extra bit of temporary pain for existing engineers worth making things better for all future engineers? (not to say that Rust has necessarily made all the right decisions; but alas basically nothing is perfect, and things certainly won't get better if noone tries)

> Every time a language developer chooses to give their new language a novel, let alone chaotic, syntax, they sin against the very premise of software development being an engineering profession.

Exactly which syntax should every language be using then? Everyone will give you a different answer.

> Randomly chosen bolts to use left hand threads just because it suits their arbitrary whim

Claiming the syntax was chosen randomly on a whim is very much not true: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

And there are times when it does make sense to use left-hand threads.

Just because someone looks at new syntax and doesn't immediately understand it doesn't mean that syntax doesn't exist for good reason.

Also, if your language's constructs and semantics don't exactly match those in other languages, then giving them the same syntax would be actively misleading, and therefore a design flaw.

Syntax is also only an issue for people who haven't taken the time to learn the language. If you haven't learned the language, then familiar syntax isn't going to help you anyway. You'll just think you understand something you don't.

It's like asking if the world should standardize on left handed or right handed screws as a default. There comes a point where the choice matters less than picking one at all.

Screw handedness is something that's basically always fine either way if planned for, and with largely no benefit for either option, so standardizing that is easy enough.

But, like, even then, there's screw drive (JIS vs phillips vs pozidriv vs a ton more) to worry about with screws. (never mind the obvious aspects of diameter & length)

The significant thing I think is that such trivial impactless questions just do not exist for programming languages. Even like comment starting characters is a messy question - "//" nicely aligns with "/* */" using the slash char, but "#" is a char shorter and interpreted languages need to handle "#!" as a comment for shebangs anyways. And things only get more complicated from there.

And, unlike with physical things, it's trivial to work with non-standardized things in software. Not like you're gonna copy-paste arbitrary code from one language into another and just expect it's gonna work anyway (else we wouldn't have more than one language).

Bit that is more like standardizing on a language, not a syntax across languages.

I also don't think syntax is even a problem worth worrying about. It takes very little time to become accustomed to a new syntax. It's the semantics that are hard to learn. Difficulty syntax can often be helpful when learning a new language, as it serves as a reminder that the semantics are different.

Laughs in lisp

I've written Clojure professionally. It's exactly the language I had in mind when I said that it takes a week to get accustomed to. I find it a very clean and elegant language. Shame that it's dynamically typed.

Check out Common Lisp, it's gradually typed, so if you want you can just write your code like this:

  (defun fib (n)
    (declare (type (Integer 0 100) n))
    (the (Integer 0 *)
         (if (< n 2)
             n
             (+ (fib (- n 1))
                (fib (- n 2).)