Rust Support Is Being Worked On For The Linux Kernel's V4L2/Media Subsystem

[ryao]

There were actually studies done on computer programming languages syntax specifically and they do have an impact, and iirc C++ (which is where Rust borrowed its syntax from) was one of the worst when it came to visually parsing and reading the code.

I have read enough papers to know that a substantial proportion of them are garbage. :/

There is plenty of room for the same code to be both highly readable and highly unreadable just from differences in spacing, variable naming choices, etcetera. Obfuscated C is probably the most extreme version of this, although I consider the GNU project’s coding convention to make C code extremely difficult to read. Meanwhile, C code in Bill Joy normal form is a joy to read. Given such huge variations in readability within a single free form language, I am highly skeptical of any claim to be able to determine one language is more readable than another. Maybe you could normalize by comparing fixed form languages and fixed form versions of free form languages, but that ignores that familiarity is also a big part of what makes one language more readable than another. It also potentially ignores that some style conventions for free form languages are simply better than others.

I recall when I learned programming that I found imperative syntaxes to be more natural than functional syntaxes. While highly powerful and not hard to learn, things like map and fold operations were unlike anything I experienced in my life until that point, so I had little interest in using them outside of situations where I was forced to use them. I suspect that I was not alone in feeling that way, which would be consistent with the adoption of functional languages within only niche areas. I also recall that I found free form syntax to be more natural than fixed form syntax. My opinions have not changed much since my initial impressions. The only real difference is that I do not find fold and map operations as alien as I once did.

That being said, it would be nice if studies explained why their results are actually meaningful and not just data that was easy to collect, was submitted to a “peer reviewed” journal to give the impression that grant money was not wasted and was accepted by that journal solely because there was nothing more interesting submitted to them, they are paid fees for accepted papers and they needed to accept a number of fees to meet a quota. Do not just take my word for it though:

https://bigthink.com/surprising-science/believe-it-or-not-most-published-research-findings-are-probably-false/

[jacob]

Yeah I agree, I can't stand the type after the variable name. It make it unreadable.
I wish Rust was more a like safer & modernized & purified best of C/C++ to be a true C/C++ 2.0.

Such a language exists: D. It has its own problems, but that's what it's aiming for. Rust was not designed to be the same as C or C++, only better. If that's what you are looking for, then Rust is not the right language for you. Carbon, Swift or Zig might be worth a look instead.

[ssokolow]

Citation needed.
That would be more than JavaScript, C, C++ and Java combined. I very much doubt that somehow.

I meant by number of members, not by historical accident of "C got popular because the compiler came free with your UNIX license. C++ literally began as 'C with Classes', Sun poured gigantic amounts of money into promoting Java as the C++ killer, and JavaScript was a "written in a weekend" language with a captive market."

[ssokolow]

While I do love Rust, I have to say that its syntax is pretty terrible and the Rust dev's admitted that the reason Rust has its syntax (largely derived from C++) is they wanted to make it more familiar to C/C++ devs to try and win them over, not because its better.

Rust's syntax is, in large part, Ocaml with C++ mixed in for popularity. The parts people complain about and the parts which are superior on technical grounds usually come straight from Ocaml.

For example:

• Ocaml uses let for variable declaration and postfix type annotations separated with colons
• 'a (Rust's syntax for lifetime parameters) is Ocaml's equivalent to <T> for generics, because, on an abstract/theoretical level, Rust's lifetimes are a special type of generic parameter, right down to "a" apparently being the habitual default type variable name, just like "T" is in C++.
• Aside from Option being all-lowercase in Ocaml, it, Some, and None come straight from it
• match is an Ocaml construct
• Rust's fn isn't a perfect match for Ocaml's fun, but it's close.
• Ocaml uses -> for function return declarations and match arms. Rust uses -> for the former and => for the latter.
• Ocaml uses () for void returns

The original Rust compiler was also written in Ocaml.

As for other influences, Rust's traits are a borrowing of Haskell's typeclasses and they list others in the reference. (According to that, they didn't actually get the use of semicolons to separate statements from C++, but from the ML family (eg. Ocaml), which also use them.)

It's not that far off to say that Rust is a GC-less Ocaml derivative with curly braces, ::, and <T> syntax added.

[lowflyer]

Rust was not designed to be the same as C or C++, only better.

You got that almost correct. Rust was deliberately designed to be *different* than C++ to attract all the C++ haters out there.

[jacob]

You got that almost correct. Rust was deliberately designed to be *different* than C++ to attract all the C++ haters out there.

Get your tinfoil hat and your medication, it will be all right.

[ryao]

I meant by number of members, not by historical accident of "C got popular because the compiler came free with your UNIX license. C++ literally began as 'C with Classes', Sun poured gigantic amounts of money into promoting Java as the C++ killer, and JavaScript was a "written in a weekend" language with a captive market."

Given that FORTRAN compilers came free with all systems for decades and FORTRAN never became popular outside of scientific circles, C’s popularity came from more than the compiler coming for free and really was not an accident. There were also plenty of attempts to force ALGOL on everyone prior to C. C gained popularity due to it being a simple way of writing portable performant code. That is a combination that neither FORTRAN nor ALGOL can claim to do.

FORTRAN’s IO facilities are a pain to use without for example having extra white space added and you cannot do unsigned integer arithmetic in FORTRAN, despite how useful it is, which makes it non-performant for a number of algorithms used in computers. It also had a lovely “the variable is real or integer based on the first letter of its name” hack. ALGOL originally had no IO facilities, which made anything written in it that did IO non-portable, and its call by name is a huge pain. ALGOL 68 added IO facilities, but it was really only a language that people used when it was forced upon them by the ACM, rather than by choice.

C on the other hand came with UNIX’s IO facilities, gave easy access to hardware features, avoided committee invented headaches like call by name and was not just portable, but was performant in areas where the only choice had previously been assembly. It is little wonder that it became popular given the other choices at the time. The combination is good enough that it continues to be popular on its own merit today, despite its detractors.

To be fair to FORTRAN, a dialect of FORTRAN from Sun Microsystems did support unsigned integer arithmetic. However, it never became part of the standard since those in charge of the standard are heavily opposed to the introduction of unsigned integer arithmetic into the language. To be fair to the standards committee(s), of which FORTRAN has two, mixing unsigned and signed integer arithmetic is a known source of bugs that not allowing integers to be unsigned avoids, so their position is understandable. They instead added some hacks to handle common cases where unsigned integer arithmetic is useful without actually introducing unsigned operations.

I had the displeasure of learning that from an attempt to use FORTRAN as a portable way to write a high performance portable vectorized fletcher4 implementation for ZFS last year. That attempt did not progress beyond the “look up how to do unsigned integer arithmetic” phase. I ended up using GNU C, and finishing the PR is in my backlog. Interestingly, the WIP code has been observed to outperform in-line assembly, in part because it enabled the compiler to do loop optimizations that the in-line assembly did not allow. Our original in-line assembly code was contributed by Intel for the sake of improving performance on x86_64 and all subsequent additions for other architectures / ISA extensions were based on it. Seeing my GNU C vector version of it outperform the original on Zen 3 was a surprise, since I did not expect Intel to have left room for improvement.

[Weasel]

1. The syntax you're complaining about is common in the world of functional languages, which is at at least as large as the world of languages with C-inspired syntax and, if you include the elements that were present in LISP, predates C by a mile.
   
   You're essentially complaining that Polish isn't a Romance language when, if they'd chosen to use Cyrillic like other Slavic languages, rather than using the Latin alphabet, you would have taken for granted that it would be different.

2. Many of those syntactic decisions have solid reasons. For example...
   • Using fn at the beginning and the return type at the end and putting types after parameter names is to simplify parsing by avoiding the need for the lexer hack. It's also very common in functional languages, either as fn, or fun, or func or function (which JavaScript borrowed), or defun (define function). (Types after parameter names, separated by a colon, is also how Wirth languages like Pascal do it.)
   • Syntactic collisions aside, |args| syntax for lambdas will be familiar to anyone who uses Ruby.
   • The postfix ! for macros is to denote that, unlike a function call, the macro call may contain control flow constructs like return which apply to the function that's calling it.