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

[RahulSundaram]

i += 1;

Really? Also 'let this, let that'. This is some js syntax bullshit. Couldn't they keep it more C like?

+= is a common pattern including in C and Python.

''let" is a common keyword as well across many languages including Kotlin, Swift, Haskell etc and hardly limited to Javascript or Typescript. Declaring the type manually all the time is a limitation of the C language. If the variable has an assignment, most other programming languages (including recent versions of C++ via auto keyword) allow you to skip declaring the type manually since the compiler knows what the type is. You could do manually declare it in Rust if you wanted to (ex: let thing1: i32 = 100). It is just not necessary typically.

[skeevy420]

Cool!

What driver or subsystem of Linux would you like to see ported to Rust?

OpenZFS

Could care less about the technical reasons, just imagine how fun that thread will be

[milkylainen]

Mmm..

No.

[Weasel]

Also 'let this, let that'. This is some js syntax bullshit. Couldn't they keep it more C like?

Amen.

[Volta]

+= is a common pattern including in C and Python.

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?

''let" is a common keyword as well across many languages including Kotlin, Swift, Haskell etc and hardly limited to Javascript or Typescript. Declaring the type manually all the time is a limitation of the C language. If the variable has an assignment, most other programming languages (including recent versions of C++ via auto keyword) allow you to skip declaring the type manually since the compiler knows what the type is. You could do manually declare it in Rust if you wanted to (ex: let thing1: i32 = 100). It is just not necessary typically.

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.

[skeevy420]

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.

Your post just made me think

let there = light;
print!("And it was good.");​

[roughl]

Also 'let this, let that'. This is some js syntax bullshit. Couldn't they keep it more C like?

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 no unintuitive. Thanks for explanation btw.

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.

[Weasel]

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.

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.

[mdedetrich]

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?

[kpedersen]

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.

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.