My favourite Rust feature: the order of precedence of binary

>>60860576
It fixes something that Dennis Ritchie felt was one of the biggest mistakes of C: bitwise operators having higher precedence than comparisons, which was done because short-circuiting operations were only added later.

Java inherited that cancerous mistake from C. Rust didn't. Be careful when copypasting C code into Rust.

>>60860576
Rust is a /g/ meme, functional programming is inflexible and unlikely to come into general use for a long time.

Functional programming has no use outside of the academia.

>>60860657
It's pretty comfy. Rust supports both imperative and functional paradigm. I'd just use imperative when functional falls short.

But for data processing functional programming is just fucking awesome

>>60860684
Eh. Don't see why you'd use Rust and not Java/Scala.

>>60860763
Performance

>>60860683
Tho I don't know much information on the topic, according to one of my old CS profs, languages like Agda and Haskell have some degree of popularity among those who use ACSL specs to prove C code or anyone who wants to write code under "proven by construction" logic. He told us that in France, the airliners are currently seeking Agda programmers

File: 1489914396171.png (43KB, 645x364px) Image search: [Google]

43KB, 645x364px

>>60860763

>>60860657
Rust is multiparadigm. It's about as Functional as Swift or C#, though it has a better type system.

>>60860780
I know a fair amount about safety-critical real time programming, so I can say your professor is probably right. Also, Europe in general is much more into formally verified programming than the US or Asia.

>>60860576
Example of how the different operator precedence is useful: consider the expression

return x&1==1 

in a function that returns a bool.

In C and Rust, this will return true iff x is odd.

Now consider the following expression:

return x&1==0 

In Rust, this will return true iff x is even. In C, this will always return false.

>>60860818
That isn't so much a quirk of C's operator precedence, it is C lacking any pretense of type safety. Hence the weak typing WTF moments.

>>60860818
Rust doesn't need "return", it's an expression based language fyi.

>>60860860
That's kind of wrong, too. This particular case has nothing to do with automatic promotion or other top-tier issues, and more to so with the simple fact that C simply doesn't have Boolean types (historically).

>>60860860
x&1 could clearly be the same type as 0, regardless of your type system.

>>60860904
x&1 does have the same type as 0 in both languages. What is actually being returned in C is x&(1==0) . Comparison operators can not be overloaded into a non-bool in Rust because they are trait (typeclass) functions in the standard library.

>>60860818
So in the land of C, all numbers are odd, but only numbers that are odd are odd? I can't derive a contradiction from this, so I don't mind.

>>60861048
No, x & 1 == 0 is equal to x & (1 == 0) which is x & 0 which is always 0.
Its just == taker precedence so you need to put brackets. Though its no like you have to actively think and avoid it, it becomes natural once you just write in C.
Then again you'd never write something like "return x & 1 == 0", what you'd do is you'd "return !(x & 1)" or if you wanted just the second bit of x without inversion you'd do "x & 2" and just return an int or whatever.
Operator precedence doesn't really come into any language since its either close to C so its okay or its batshit crazy so its crap.

>>60860618
>copy/pasting code
>ever
You deserve whatever ills fall your way.