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

[CommunityMember]

It can be made defined behavior, so it will always increment before assignment, can't it?

Rust has a strong governance model for proposing, reviewing, and determining whether to accept, or reject, language proposals. You should avail yourself of those processes if you want to make a difference.

[Volta]

Will you let it go already? Try to focus on something that has an actual impact. Like, why does Rust, in 2022, still require a semicolon at the end of the line? Sheesh...

I will let it go, because there are two explanations that make sense.

[Volta]

Sure, so in "i = i++ + i-- + i++ + i-- + i++", can you figure out the result for i = 1? The C standard doesn't care and just says "undefined behavior" because it depends on evaluation order.

The question is basically why does Rust have to carry all this C garbage from 50 years ago.

In 'proper Rust' it would be: i = ((++i) + (--i) + (++i));

From left to right, but you made another point that makes sense.

[cb88]

Cool, I'm interested to see what new types and abstractions can be built around the kernel interfaces to make Rust productive for driver writing. A lot of people are cynics here, but what I see is an opportunity to have less experienced driver writers publish less-broken drivers than they would with C.

Drivers are usually broken because they do something "wrong" to the hardware... so it will catch many human errors but probably won't reduce broken drivers much. It may even increase them as people say "compiles for me" and move on instead of testing.

Note I am actually in favor of Rust drivers... just pointing out that we live in reality not a rust fixes all utopia.

[Chugworth]

No, that does not solve the problem, sure it makes it less confusing, but it still leads to undefined compiler behavior.

Example:

var i = 10;
i = i++;
// Is the variable i now 10 or 11?
// Increment before assign or assign before increment? 

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.

I made one reply, but looking back I think I'm confused at what the issue is there. First you set "i" as 10. In the second line you're going to set "i" as something else - the current value of "i", with "++" indicating an increment. What's the issue?

I've got to say though, these days I deal mostly with Python, PHP, and C#, and I much prefer the way that C# handles its variables. Python and PHP just strike me as sloppy in comparison.

[RahulSundaram]

So, there's 'auto' keyword already used in those languages or what? If no, then there's no explanation why it cannot be used instead.

I will try one last time. Languages tend to adopt conventions that are already well known and have a clear meaning. a keyword like 'let' or 'var' is far more popular and therefore tend to be adopted quickly. 'auto' is a confusing keyword depending on which language and version of the language you are familiar with and evidently no other language wants that baggage.

[bug77]

Drivers are usually broken because they do something "wrong" to the hardware... so it will catch many human errors but probably won't reduce broken drivers much. It may even increase them as people say "compiles for me" and move on instead of testing.

Note I am actually in favor of Rust drivers... just pointing out that we live in reality not a rust fixes all utopia.

A fair point, but still, Rust makes multithreading easier for drivers.
At the end of the day, you are right: Rust is just a smarter tool, it won't do the coding for you. Hopefully with Rust you can pay more attention to what you're doing with the hardware and less attention to memory management/safety

[mdedetrich]

Tbh I entirely disagree with calling a language that is simply immutable by default and has lambdas/closures and map/filter/reduce a "functional language" when the definition of functional programming is purely about rather autisticly trying to make programmatic functions into mathematic ones. It's a very traditional imperative language which happens to have the same set of useful features derived from functional languages that work well in an imperative context that every other modern programming language has. It may be in part inspired by, but neither it, Scala, or any similar language is truly a functional programming language on any sort of philosophical grounds because that's not an invariant they're trying to enforce.

While I understand what you are getting at, defining a functional programming language in such a way is not very useful because you can easily claim that Haskell is not purely functional due to unsafePerformIO or asynchronous exceptions which breaks the mathematical laws of functional programming.

Realistically speaking you have a spectrum, and people have argued that its the languages increasing ability to implement functional programming in an organic/natural way that allows it to be a "functional programming language". In this regard Scala and Haskell are more functional than Rust, since with Rust its difficult to implement functional programming constructs due to it missing certain features (such as HKT's - higher kinded types). Scala for example has a large amount of purely functional programming libraries such as cats/ZIO ecosystems which rival those of Haskell. These kinds of libraries however don't really exist in Java/Rust etc etc, its possible to program in such a way its not ergonomic/idiomatic.

Also notably while a lot of computer scientists/mathematicians, in terms of modern lexicon functional programming is not really the mathematical definition of function but rather the ability to treat functions (or more correctly subroutines) as values hence why lisp and its dialects is regarded as a functional language (as well as languages like javascript). This is why the definition of a purely functional programming language exists which is referring to the mathematical notion of functions and all if its implications (i.e. treating side effects explicitly as well being able to represent functions as values).

I think these criticisms are more readily explained by law of triviality principle. Superficial syntax criticisms are very common in programming (Python and spacing for example is a super common critique even hardly a major problem - Python has plenty of *other* substantial issues however). It requires much more in-depth knowledge of the language to point out say async design warts than complain about silly things like a keyword used even though it is very common. I wouldn't view this as anything particular to Rust.

While I see your sentiment in this case the people in the thread arguing in such a way are not being intellectually honest, i.e. they are not doing it from a position of actually improving the language or genuine criticism but rather just complaining for the sakes of complaining. I can guarantee you that even if there was an alternate syntax, the same people would still complain.

This is also ignoring the fact that since Rust favors immutability as well as having features such as pattern matching, ,let is the best syntax to use. C/C++ does not have those and blindly syntax from other languages while disregarding the design of the host language is frankly dumb.

[Volta]

I can guarantee you that even if there was an alternate syntax, the same people would still complain.

I can guarantee you're mistaken and your believes like the one above don't represent reality.

[Volta]

Rust has a strong governance model for proposing, reviewing, and determining whether to accept, or reject, language proposals. You should avail yourself of those processes if you want to make a difference.

It's too late for such changes and I'm not going to vote for something that won't affect current Rust developers in any positive way. Furthermore, there are logical explanations behind this. I'm certain it will be very successful language and its adoption in Linux is irrefutable proof. Even if some C developers may don't like its syntax too much.