Deriving Traits in Rust with Procedural Macros
1–10 of 31 posts
Re: Deriving Traits in Rust with Procedural Macros
#2Rust is morphing into a complexity beast that rivals C++. When the cognitive load require to read and write Rust code far exceeds that required of other, more popular languages, the future does not look rosy.
Re: Deriving Traits in Rust with Procedural Macros
#3Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope.
Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption.
There seems to be a need for training classes in Rust that explain the development philosophy, because it's not readily apparent from the online resources to anecdotal me who's able to code in Haskell, Elxir, Erlang, Clojure, C, C++17, Ruby, Python, Go, assembly and LLVM IR.
Re: Deriving Traits in Rust with Procedural Macros
#4Rust is morphing into a complexity beast that rivals C++. When the cognitive load require to read and write Rust code far exceeds that required of other, more popular languages, the future does not look rosy.
Maybe. It has a lot of practical innovations and constraints but some inconsistencies and rough edges that will likely be addressed. Perhaps programming languages need the freedom to try things, make mistakes and then use feedback with an RFC process, which Rust has, to make improvements. Feel free to submit RFCs if you notice anything specific.
Re: Deriving Traits in Rust with Procedural Macros
#5Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…
I found that I actually needed to buy the "Programming Rust" book, read it cover to cover, and then go back and start programming.
When I just tried to jump in, things didn't quite click.
Re: Deriving Traits in Rust with Procedural Macros
#6Rust is morphing into a complexity beast that rivals C++. When the cognitive load require to read and write Rust code far exceeds that required of other, more popular languages, the future does not look rosy.
Procedural macros are something you more or less never need to write in application code, but they add tremendous power to libraries
Re: Deriving Traits in Rust with Procedural Macros
#7Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…
> I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again.
By default the value is moved in Rust, just like with std::move in C++17, which you say you know. This is to avoid performance issues when you pass complex structures, such as vectors, around. If you want to copy your value, you have to call .copy() explicitly.
Re: Deriving Traits in Rust with Procedural Macros
#8Lifetimes - implicit/explicit semantics for how long a name is considered alive, whereas in C++ there would be a delete or falling out of scope. Borrowing - I still don't understand how or why a non-reference is implicitly consumed by passing it (read-only intention) by value(?) to another function and then can't be used again. Pony does explicit consumption. There seems to be a need for training classes in Rust that…
> Borrowing
The way I think about this (which isn't quite how rust seems to) is that every value (including references) is always destroyed by passing it to a function, but gets implicitly copied if (arg is copyable && arg is referenced below). Eg:
T a = mkT() # create value
foo(&a) # create and immediately destroy/pass reference
bar(a) # => bar(copy(&a)) # create-and-pass copy
baz(a) # last use, so dont bother copying
Re: Deriving Traits in Rust with Procedural Macros
#9Great article, there aren't many resources for writing proc macros right now.
However, I think this could be done with a generic impl of WritableTemplate for all T where T: Template.
Re: Deriving Traits in Rust with Procedural Macros
#10Rust is morphing into a complexity beast that rivals C++. When the cognitive load require to read and write Rust code far exceeds that required of other, more popular languages, the future does not look rosy.
Procedural macros are something you more or less never need to write in application code, but they add tremendous power to libraries
Which doesn't make it easier, since you might want to structure part of you application code as a reusable library.