Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ssokolow
    replied
    ryao, Good point. Pascal was also hamstrung by taking so long to outgrow being designed so tightly to be only a teaching language.

    (Sorry I can't quote-reply properly. Broken site template until the page rolls over.)

    Leave a comment:


  • ssokolow
    replied
    rclark, by that logic, C should have just used JE, JNE, JNZ, etc. from assembly and not had weird things like if/for/while/do.

    Powerful pattern matching is a time-tested aspect of functional languages and, as someone who switched to Rust from languages like Python and Javascript (and yes, I do use C in my retro-hobby programming for lack of Rust), I wouldn't give it up for the world.

    Again, Rust isn't "a better C++"... it's a GC-less ML derivative with syntax made more C++-like to make it look less alien to mainstream programmers. Based on the "my favourite language is God's gift to programming and everything should be like it" in your logic, I could argue that we should throw out your favourite language because it's not enough like the language I think is best.

    You can't blame the people who designed Rust to meet their own niche (Just as Go was designed to serve the roles that Google was using C++ for, Rust was designed to serve the roles Mozilla was using C++ for) because it was a self-itch-scratch. The most justifiable position you can take is to fault all the people switching to it because "stop liking what I don't like!"

    (Sorry. Can't quote-reply properly. Broken site template until we tick over to a new page.)

    Leave a comment:


  • rclark
    replied
    They 'could' have made it more like c/c++ and supported the standard control constructs that most everyone is familiar with... Like instead of 'match', use 'switch' and make it very close to 'c' ... but no ... have to use => instead of ':', same with for loops (c and c++ are so 'intuitive' to use). but no.... At least 'while' works as it should and can mimic a for loop...
    Code:
    let mut x = 0;
    while (x < 10)
       {
       // do something
       x = x + 1;
       }
    Of course the 'forced' style warnings are another headache that should NOT be in a compiler (although you case set flags at beginning of each module so ignored). If syntactically wrong -- call it out... But not style. Strange thinking went into Rust to make it that much harder to use. As much as I'd like to like it, it just seems cumbersome. The perfect language is one that gets out of the way and lets us get the problem solved with the least amount of fuss . <sigh> Not there yet .
    Last edited by rclark; 08 April 2023, 01:47 PM.

    Leave a comment:


  • ssokolow
    replied
    Looks like Weasel managed to be so condescending that he broke the site template.

    Leave a comment:


  • Weasel
    replied
    Originally posted by ssokolow View Post
    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.
    1. Originally posted by ssokolow View Post
    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.
  • Originally posted by ssokolow View Post

    But who gives a shit about functional languages? They're unreadable hieroglyphs for the most part. Same with Lisp. Only used by math dorks.

Leave a comment:


  • ryao
    replied
    Originally posted by ssokolow View Post

    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.
    Last edited by ryao; 08 April 2023, 09:15 AM.

    Leave a comment:


  • jacob
    replied
    Originally posted by lowflyer View Post

    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.

    Leave a comment:


  • lowflyer
    replied
    Originally posted by jacob View Post
    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by mdedetrich View Post
    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.
    Last edited by ssokolow; 07 April 2023, 10:16 PM.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by fallingcats View Post

    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."
    Last edited by ssokolow; 07 April 2023, 10:15 PM.

    Leave a comment:

  • Working...
    X