We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
really good one. In software it always depends based on the constraints, having said that Rust is much more mature now than ever before. perfect for many domains except Android and ios
" In software it always depends based on the constraints, having said that Rust is much more mature now than ever before." Sorry but I don't see how the second part of the sentence is related to the first part. They seem like two totally disjoint statements about different things.
@@heater5979 my bad not expressing clearly. What I wanted to say is a few years before using rust means you are limited in a lot of ways like async, libraries, frameworks. So you have to choose the trade-off carefully. But now the constraints are less and making rust much more appealing (except hard learning curve :p).
Quite useful! Thanks. I like the graphic around 27:00 where you compare the parameters that compares languages! I have done some Scala / Java programming and based on that I am not sure if Haskell programmers will ever need to work in Rust. The areas of application are very different, IMO.
It's really great in some circumstances. It can be much easier to reason about and test. But for tasks that aren't functionally-oriented and/or when complexity increases, it can start to show cracks. A couple of examples where functional programming could cause issues: - Everything is immutable, meaning you may have to copy a large amount of data. - State isn't managed in the same straightforward way as an imperative approach. Use it for problems that lend themselves to the approach. Don't feel like you have to choose one over any other.
this was an example of a way you could implement a common functional programming higher order function. this is not what idiomatic rust looks like. In Haskell this same function is written as: (order of composition/parameters is reversed, f(g(x) in haskell rather than g(f(x)) in rust) (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) Rust still looks a bit more legible to me. The rest of the syntax above the parts that Haskell needs, are there to ensure that it's generic over all functions that take 1 parameter, and still have enough information to make it a 0 cost abstraction.
I will never understand why Functional Programming adherents will always take a simple function, like factorial, show the imperative version of it, which is clear to understand and follows the schoolboy definition of factorial, and then turn it into the functional version which is unfathomable at first glance. Throwing in unrelated concepts like "fold" and "lambda" and such like that one does not need.
Factorial is a math function. Functional languages use the math definition, which is the original definition. I saw this definition in grade school before knowing anything about any programming language.
@@mrwise2k You went to a superior school. We learned about factorial and fibonacci and whatever else after learning arithmetic but before we ever knew what a function was. Before age 10. The notion of functions came to us later after some time on algebra. After age 10. All of these things were therefor presented to us as operations on numbers done in loops. Of course these definitions can be cast in terms of recursive functions but you can't have functional recursion until you have functions in your mind, which we did not. I suspect that Euclid, Fibonacci etc did not think in terms of functions either. That is to say the original definitions were not functional. For example GCD is a loop, the guts of which are "continue subtracting the smaller length from the larger until they are both the same size." Which follows naturally from looking at line lengths, well geometry. The definitions of these things in terms of functions just obscures the meaning and hides how they were discovered.
It's hilarious how people keep bringing up this irrelevant most popular language vote. Look at number of projects, rust is nowhere near the top most popular languages, it's number 2 in PR and marketing tho.
It's like the 15th or 16th most used language, but those who use it love it. Once you get over the initial steep learning gradient it's supposedly capable of anything & everything, at C-like speeds. For the most part, my earlier comment notwithstanding, it seems pretty readable too.
We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
really good one. In software it always depends based on the constraints, having said that Rust is much more mature now than ever before. perfect for many domains except Android and ios
" In software it always depends based on the constraints, having said that Rust is much more mature now than ever before." Sorry but I don't see how the second part of the sentence is related to the first part. They seem like two totally disjoint statements about different things.
@@heater5979 my bad not expressing clearly. What I wanted to say is a few years before using rust means you are limited in a lot of ways like async, libraries, frameworks. So you have to choose the trade-off carefully. But now the constraints are less and making rust much more appealing (except hard learning curve :p).
Thanks, this talk made me learn Rust.
very insightful, thanks!
Quite useful! Thanks. I like the graphic around 27:00 where you compare the parameters that compares languages!
I have done some Scala / Java programming and based on that I am not sure if Haskell programmers will ever need to work in Rust. The areas of application are very different, IMO.
Great talk!! Rust is such a beautiful language!
Great talk, thank you!
At 21:33, I think the return type should be "impl Fn(X) -> Z" instead of "impl Fn(X) -> Y". The same typo occurred in the next slide.
I think i like functional programming but i cant tell if its better or OO hype all over again
It's really great in some circumstances. It can be much easier to reason about and test. But for tasks that aren't functionally-oriented and/or when complexity increases, it can start to show cracks. A couple of examples where functional programming could cause issues:
- Everything is immutable, meaning you may have to copy a large amount of data.
- State isn't managed in the same straightforward way as an imperative approach.
Use it for problems that lend themselves to the approach. Don't feel like you have to choose one over any other.
Nice
❤️
Completely lost me arund 22:00ish - do Rustaceans not believe in intelligible names for identifiers? It's like uglified/obfuscated code at that point.
this was an example of a way you could implement a common functional programming higher order function.
this is not what idiomatic rust looks like.
In Haskell this same function is written as: (order of composition/parameters is reversed, f(g(x) in haskell rather than g(f(x)) in rust)
(.) :: (b -> c) -> (a -> b) -> a -> c
(.) f g = \x -> f (g x)
Rust still looks a bit more legible to me.
The rest of the syntax above the parts that Haskell needs, are there to ensure that it's generic over all functions that take 1 parameter, and still have enough information to make it a 0 cost abstraction.
This says functional programming in Rust but it feels like OO programming. I don't like it, but I'll suffer through.
I will never understand why Functional Programming adherents will always take a simple function, like factorial, show the imperative version of it, which is clear to understand and follows the schoolboy definition of factorial, and then turn it into the functional version which is unfathomable at first glance. Throwing in unrelated concepts like "fold" and "lambda" and such like that one does not need.
Factorial is a math function. Functional languages use the math definition, which is the original definition. I saw this definition in grade school before knowing anything about any programming language.
@@mrwise2k You went to a superior school. We learned about factorial and fibonacci and whatever else after learning arithmetic but before we ever knew what a function was. Before age 10. The notion of functions came to us later after some time on algebra. After age 10.
All of these things were therefor presented to us as operations on numbers done in loops. Of course these definitions can be cast in terms of recursive functions but you can't have functional recursion until you have functions in your mind, which we did not.
I suspect that Euclid, Fibonacci etc did not think in terms of functions either. That is to say the original definitions were not functional. For example GCD is a loop, the guts of which are "continue subtracting the smaller length from the larger until they are both the same size." Which follows naturally from looking at line lengths, well geometry. The definitions of these things in terms of functions just obscures the meaning and hides how they were discovered.
It's hilarious how people keep bringing up this irrelevant most popular language vote. Look at number of projects, rust is nowhere near the top most popular languages, it's number 2 in PR and marketing tho.
It's like the 15th or 16th most used language, but those who use it love it. Once you get over the initial steep learning gradient it's supposedly capable of anything & everything, at C-like speeds. For the most part, my earlier comment notwithstanding, it seems pretty readable too.
It is not PR. Major companies use it already.