Announcement

Collapse
No announcement yet.

Rust Porting Begins For Intel's "e1000" Linux Network Driver

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

  • Anux
    replied
    Originally posted by Weasel View Post
    That's exactly the problem. Let should only be used for functional languages, which Rust is not. There's a reason they're so cryptic for programmers instead of math nerds. Keep that shit away from structured languages.
    Rust is also a functional language.

    I honestly don't understand how you guys where ever able to learn any programming language, if you already hang up on such a simple thing like let. I'm just a hobby programmer and needed nothing else than one code example to get how this works.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by RahulSundaram View Post

    Let has been used in many many non functional languages starting with BASIC (like 50 years ago) and more recently Swift and Kotlin. You are just unaware of it.
    Its hilarious seeing these people pick minor syntax grievances from a language even though such syntax has been quite common place for decades (as you pointed out).

    Lets call it out as it is, these complaints are really just distraction/venting mechanism for people that don't like Rust for largely irrational reasons. I am also not a fan of Rust's syntax (they admitted they copied C++ syntax to make it easier for C++ people to migrate over even though arguably there are much nicer syntax's, i.e. Ruby/Scala) however in the grand scheme of things its a really minor gripe.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Weasel View Post
    That's exactly the problem. Let should only be used for functional languages, which Rust is not. There's a reason they're so cryptic for programmers instead of math nerds. Keep that shit away from structured languages.
    Let has been used in many many non functional languages starting with BASIC (like 50 years ago) and more recently Swift and Kotlin. You are just unaware of it.

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by Volta View Post

    I think (and hope) it's not such common when value equals 1. I've just check and incrementation and decrementation in C like way is not possible in Rust. WTF? .
    It is uncommon because collections in languages like Python and Rust allow you to loop through them without manually incrementing them.

    https://github.com/dtolnay/rust-faq#...ment-operators


    Originally posted by Volta
    I'm not used to beg someone to 'let' me something. The one who chose this word must be some kind of beta. I'd prefer something like: auto name_of_var. 'Let' is completely unintuitive. Thanks for explanation btw.
    Programming is not English and even in English let is many contexts is used to say "make this happen" or even as a warning: "let him try"

    https://www.merriam-webster.com/dictionary/let

    Let has a completely different context in programming, mostly originating from math: https://en.wikipedia.org/wiki/Let_expression

    Leave a comment:


  • kpedersen
    replied
    Originally posted by mdedetrich View Post

    For a completely trivial driver I would agree. However most modern drivers aren't written for OS's built in the 90's where drivers were largely just memory mapped IO. From what I can tell they deliberately picked a trivial driver just to see if there were roadblocks, the real payoff is in more typical modern day drivers.
    That's fair. I am excited to see how this one plays out either way.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by kpedersen View Post

    Exactly. So my point is that perhaps Rust's strengths are not ideal here. It will all just be bindings and unsafe {} sections.
    For a completely trivial driver I would agree. However most modern drivers aren't written for OS's built in the 90's where drivers were largely just memory mapped IO. From what I can tell they deliberately picked a trivial driver just to see if there were roadblocks, the real payoff is in more typical modern day drivers.

    Leave a comment:


  • uid313
    replied
    Originally posted by Volta View Post

    i += 1;​

    Really? Also 'let this, let that'. This is some js syntax bullshit. Couldn't they keep it more C like?
    It is not syntax bullshit. The i++, ++i, etc are confusing and can lead to undefined behaviors and differences among compilers.
    Example:
    PHP Code:
    var 10;
    i++;
    // Is i now 10 or 11? 
    New programing language often do away with i++ and ++i in favor of i += 1. Some languages such as Swift which previously supported i++ have removed that syntax.

    Leave a comment:


  • Volta
    replied
    Originally posted by roughl View Post

    Let is also very common when talking about variables in math, like: "Let x equal 10". See https://en.wikipedia.org/wiki/Let_expression for example.
    Yes, but it makes more sense imo. It implies there's some logic involved. When I want to reserve some memory for variable I shouldn't care if there's some hidden compiler's logic behind this. It should just reserve memory.

    Leave a comment:


  • kpedersen
    replied
    Originally posted by mdedetrich View Post

    Uh most of that unsafe dealing directly with hardware which by definition is unsafe because a compiler cannot prove such a thing. What exactly is your point here?
    Exactly. So my point is that perhaps Rust's strengths are not ideal here. It will all just be bindings and unsafe {} sections.

    Originally posted by piotrj3 View Post

    Rust unsafe is still safer then C/C++
    In practice they are 100% equally as safe. Which is completely "unsafe" because all bets are off. Arguably the extra code needed for the Rust bindings "abstractions" open up a potential for more complex data marshalling issues and reduction of type safety.

    Last edited by kpedersen; 19 September 2022, 09:32 AM.

    Leave a comment:


  • mdedetrich
    replied
    Originally posted by kpedersen View Post
    In this source unit: https://github.com/fujita/rust-e1000.../rust_e1000.rs

    48 unsafe keywords in 1224 lines. And that is generous because many unsafe sections span many lines. An example of a longer one is this:
    https://github.com/fujita/rust-e1000..._e1000.rs#L219

    Is that really worth it? Perhaps in future there will be more infrastructure to access the raw parts in a safer manner.

    That said, it is very fun to see drivers written in higher level languages. A cool project!
    Uh most of that unsafe dealing directly with hardware which by definition is unsafe because a compiler cannot prove such a thing. What exactly is your point here?

    Leave a comment:

Working...
X