An Optimization That Is Impossible In Rust

Primogen: I do not comment on politics Also Primogen: German strings!

Hey Prime. A PhantomData is simply a type marker for the compiler. Let's say we have a trait that has functions that work with a certain generic type D. We want to apply that trait to a new Struct we created. But that struct doesn't have the type D. Like this: pub struct Something<D: SomeTraitYouNeed>{ ... } The struct has the generic marker D, but it doesn't have any of its attributes that follow the requirements of D. This will confuse the compiler because it will not be sure of how to apply the trait rules. In that case we create a PhantomData that implements those rules: pub struct Something<D: SomeTraitYouNeed> { PhantomData<D>, .... } PhantomData is just to fulfill the rules of the compiler, it will not exist in the compiled source code. Edit: Here is an example of a use for this. I once created a Worker struct for running custom functions in multi-threaded environments. It requires a trait for the parameter of the function, and another for the function it is going to run. It stores the parameters of the function, so that is okay. It doesn't store any attribute that implement the trait of the function it is going to execute. Due to that, I needed to implement a PhantomData for the function it is going to execute. Edit: For those unfamiliar with Rust. Traits are interfaces. Or, in simpler terms, a "class" with only functions. A generic is a "type that implement ("inherit") a certain trait ("Interface").

The whole article is just kind of wrestling with the semantics of the language lol

Would be nice to see the asm generated by this , compared to a C implementation of the same...

In this case PhantomData is there mostly because of variance, the struct is now covariant to T because it is naturally covariant to PhantomData<T>. To explain variance: There exist three types if variance. Covariant<T>: 'a if T: 'a // a restriction in T leads to a restriction in Covariant<T> Invariant<T> if T: 'a // a restriction in T does nothing to Invariant<T> 'a: Contravariant<T> if T: 'a // a restriction in T loosens restrictions in Contravariant<T> Examples on how to make those types: struct Covariant<T>(T); struct Invariant<T>(*T); struct Contravariant<T>(fn()->T);

What? Polars the python library is written Rust. They are not two separate things.

I thought German strings are like: "Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz"

34:30 Lifetimes work well in Rust. The trick is just not to use them at all if possible. Or only in structs. And when you use a lifetime in a struct, there has to be a good reason for it. The best reason I came across is when you want to create some temporary type T, which has mutable access to some other type O, forbidding the user to access the value of type O as long as a value of type T exists. In my case it was some edit struct T, which enables editing O safely. Because after editing, the states have to be updated. So the safe way to edit is using a value of type T. And the drop method of T updates the states of O. And only after T has been dropped, the user can access O directly again, which will be in a safe state again.

I really like those type of videos.

the same polars is the rust and python one. written in rust, can be used in both.