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

[Volta]

I think these criticisms are more readily explained by law of triviality principle.

No, blah, blah, blah. it's what I wrote before. Rust is becoming a 'proper' C equivalent, but it's using toy languages syntax. Don't expect a left wheel driver to feel comfortably in right wheel one. Especially when one has to use both. However, maybe Rust is aimed at js, Kotlin, Python developers? Personally, I doubt.

[uid313]

So limit them to pre-incrementation. Problem solved.

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.

[Luke_Wolf]

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.

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.

[Volta]

Every other language has other keywords like var or let instead since they don't have the legacy baggage where the same keyword can mean different things.

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.

[microcode]

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.

[microcode]

No, blah, blah, blah. it's what I wrote before. Rust is becoming a 'proper' C equivalent, but it's using toy languages syntax.

What? Toy languages like ML? Whatchu smokin' buddy.

[bachchain]

I've just check and incrementation and decrementation in C like way is not possible in Rust. WTF?

The increment and decrement operators are relics of the PDP 11 days. They made sense for the PDP 11, but nowadays it's just an ugly hack that creates ambiguity and ub for the sake of saving someone from having to type a single character

[Volta]

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

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

[bug77]

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.

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...

[dremon_nl]

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

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.