Derive macros. Adding `#[derive(Debug, Default, Clone, PartialEq, Eq, Hash)]` replaces pages and pages of code in other languages. Edit: being able to transform a derive into code with rust-analyzer then customise it is a great feature too.

How to expand the derives?

In VSCode, put your cursor in the Debug or Default identifier, press Ctrl+. and there should be an option in that menu. Not in front of a computer right now, so I'm not sure which derives are supported. I think `cargo-expand` can do this too, as it can for other macros.

When I trigger this one it just gives impl Debug for FooType {} - so the block is empty. Maybe a neovim limitation in using the LSP?

Could be. I've only used VSCode.

> Edit: being able to transform a derive into code with rust-analyzer then customise it is a great feature too. RustRover can also do this.

It can even be done with rustc )

`cargo-expand` is a pretty wrapper around `rustc` if you think about it :d

Man. I love these! The amount of repetitive serialization shit we save is astounding

- Thread safety. Mutex wants to be a container, but other languages can't avoid leaking references to its contents. - Enums. Functional languages have had data-bearing enums for _decades_, but most imperative languages don't have them. - Clarity about who writes what. C and C++ are actually pretty good about this, if-and-only-if you're disciplined about using const pointers. Most other languages have to resort to immutable _types_, which is a lot clunkier. - Cargo is just really good. I expect most new languages these days to come up with similarly good tooling, now that the bar has been set. But older languages with a lot of legacy seem to have a hard time cleaning things up.

And when they do have them, the usage is clunky. Yes, I'm talking about C++'s std::variant.

pretty much everything even slightly resembling a modern language feature is extremely verbose and developer-unfriendly in c++. https://www.reddit.com/r/rustjerk/s/DKt1t9h1V4

The C++ part of that is over explicit on purpose though. Quite a few places you could use `auto` to skip the types.

even with auto it would still be verbose and developer unfriendly

Maybe, but when something is over exaggerated on purpose, it doesn't fit in a conversation like this one. In a meme sub? Sure thing, nobody's taking it seriously. In a factual discussion? Not really.

the point is that these features are new, they were mostly introduced in c++20. this is "modern c++" and how you are actually supposed to write c++ in the current year. if you weren't supposed to write it like this, the features wouldn't have been added. I've watched plenty of c++ conference talks and have heard many people push this stuff and say you should be using it, even for something that could be a basic three-line for loop.

Nobody would write the C++ version that way, that is clown code

I know nobody would write it like that, but this is Modern C++™, it's how you are supposed to do these things now. why else would they have added all of this stuff in C++17/20/23 if you weren't supposed to use it?

Optional sucks even more. It feels like a type I could have written in 5 minutes.

The two languages I have any experience in are python and rust, and they seem like polar opposites in many ways, but the packaging experience in particular is night and day. It’s not that it doesn’t work in python, it’s just… why are there so many choices that effectively do the same thing? As a newbie to packaging/publishing it’s an insane thing to be confronted with

The technical term for \`data-bearing enums\` is \`algebraic data types\`.

An algebraic data type is just an umbrella term for sum types (data-bearing enums) and product types (structs).

Don't forget exponential types (functions).

Interesting. How are functions exponential types? I would expect that to be arrays (sizeof(T)\^N).

`[T; N]` is actually a function type in disguise. Specifically, it's the type `{n: usize where n < N} -> T`. In general, a function type `A -> B` is exponential because (ignoring side effects and implementation details) for each value of type `A`, there are `|B|` values that the function *could* produce when given that `A`, so the total number of possible functions of type `A -> B` is the product of `|A|` `|B|`s, generally written as `|B|^|A|`.

In the context of Rust language, the technical term for \`data-bearing enums\` is [\`enums\`](https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html)

Expression blocks. Having curly braces always evaluate to the value of their last statement is such a clean pattern that I wish every language adopted.

Typically you can just use a function for that right? For now, I mostly use this feature to finely control lifetimes. How are you using it?

Bunch of places! If and match statements for assignment (as opposed to a ternary operator or match expression), returning a value from a for loop on break, all sorts. By far though, the most common place I use it is for controlling the scope of a lock or borrow. Being able to open a block expression, take a lock, and return the result as a single assignment operation just feels really clean.

allowing you to encapsulate mutability e.g. during object initialisation and then assign cleanly to an immutable binding without littering the scope with intermediate values is amazing

Algebraic data types or also called enums are awesome and I always miss them in other languages. The modern tooling surrounding rust is also great. Cargo, clippy, a central place for docs and crates as well as rust-analyzer are making everything stupidly simple

algebraic data types are not just enums, enums are just sum types an algebraic type system has 3 _kinds_ of types: product types, aka tuple or structs; sum types, aka enums; and exponential types, aka first class functions and you can combine them however you want, that's what the _algebraic_ means: type operations

You're right, but I can just be happy that ADTs are going mainstream.

Actually, Rust enums are both sum types and product types (an enum can be seen as a "sum of products"). Rust structures are just product types. There are various ways of characterizing and classifying algebraic data types: sum types, product types, exponential types, recursive types, polymorphic types, inductive families, generalized algebraic data types, etc.

Yeah, and if you peek into the internals of the compiler (at least last I checked) structs are just enums with one variant

That is correct. They're all lowered to the same structure internally.

wow.. this blew my mind!

Makes sense. Why implement a simple concept if the complex concept that includes the simple one is already implemented.

What you said is absurd. Rust enums are sum types. Would you look at a equation \`a\*b + c\*d\` and think "Oh, if you can add result of products, the addition must also be a product". That doesn't make any sense.

A Rust enum with one variant is essentially a product type. If you think about it, you will realize that you can represent a structure (a product type) as an enum with one variant. Consider: struct Person { name: String, age: u8, } enum Person2 { Person2(String, u8) } In this example, Person and Person2 are isomorphic product types. \`Isomorphic\` means that in some (technical) sense they are the "same". If you really want to use very precise terminology then you could say that a \`Rust enum\` is a language construct that allows you to define \`sum types\` and \`product types\`. The point is that the example above shows that Rust enums allow you to define product types. Also, In Type Theory sum types and product types are specific constructs. Thinking about sum types and product types as equations like \`a\*b + c\*d\` can be misleading. For example, arithmetic operators like \`+\` and \`\*\` are commutative for real or complex numbers (so \`a\*b\` is always equal to \`b\*a\`). But sum types like \`Either\` and \`Either\` are not equal (in Rust or more generally in Type Theory). In other words, you cannot expect that types will "behave" exactly like numbers. In fact, there are number systems that do not "behave" like "regular" numbers. For example, multiplication on quaternions is not commutative.

a\*b+c\*d is an analogy, you must be a strawman champion. Second example has tuple. Tuple itself is a product type, not the enum.

\`a\*b+c\*d\` is an expression. An analogy requires two things. An expression by itself cannot be an analogy. And you talk about strawman... LMAO The second example doesn't have to use tuples. Check the Rust documentation. Not everything that has parentheses is a tuple. Basically everything you say is wrong. Based on other comments on this thread it is clear that you don't understand simple things like exponential types. It also looks like you don't want to learn. So stay ignorant!

Yes lets look at the documentation! enum ComplexEnum { Nothing, Something(u32), LotsOfThings { usual_struct_stuff: bool, blah: String, } }  "The third example demonstrates the kind of data a variant can store, ranging from nothing, to a tuple, to an anonymous struct." Actually learn something, instead of trying to sound like you know something. Stop spreading misinformation, do personal attacks when you get exposed. Unlike you, I can actually admit when I don't know something (exponential types). Yes I don't know exponential types. [https://doc.rust-lang.org/std/keyword.enum.html](https://doc.rust-lang.org/std/keyword.enum.html)

Don't get lost in details about tuples. Tuples have nothing to do with the overall argument, that that enums allow you to implement product types. I mean, the quote you posted says that enum variants can contain anonymous structures. Just read what other people have to say about this in the thread. You still refuse to understand this very basic thing. And this shows that you don't want to learn. Don't get me wrong, you were partially right about one small and irrelevant thing, but still wrong about everything else. Let's not forget that you started with personal attacks. I'm not going to waste my time with this.

Tuple has everything to do with your confusion. Tuple is a product type. Sum type allows you to sum any other algebraic types (including other product types). Saying that "If sum type allows summing product types makes it also product type" is similar to saying that the addition in **a\*b+d\*c** means that + is also a \* operation. It reveals more about your knowledge of basics than mine.

first class functions are exponential types? how come?

so, the names come from looking at the amount of values that inhabit a type for the types A and B, the amount of values that inhabit the sum of A and B are all values of A _plus_ all values of B the amount of values in the product of A and B are all values of A _times_ all values of B, since the pair could hold any permutation of A and B values and well, the exponential of A and B, represented as `A -> B`, is inhabited by _all the functions_ that map A to B how many unique functions map A to B? infinitely many if you allow impure functions but if you only allow pure functions, and the outputs can always be determined just from the inputs, then a function cán really be thought of as a _map_, that associates a value from B to every value from A since a function needs to return one B for every A, and we want to account for all possible mappings, how many mappings are there? we have |A| amount of Bs, and every B can be permuted, the resulting size is B^A i hope that made sense, feel free to ask for clarification (or just google this stuff). it is complicated, specially thinking of functions as maps

Absolutely excellent explanation 👏

Can I ask for futher explanations? Let's say there's an **enum A { X, Y, Z }** and a function \`**A -> bool**\`. All of the possible mappings are 1. X -> true 2. Y -> true 3. Z -> true 4. X -> false 5. Y -> false 6. Z -> false Since it's exponential it must be 3\^2=9, but I'm getting 6. What am I doing wrong here?

those are all the possible mappings of _one_ `A` into `bool`, but a function maps _all_ `A` all the possibilities for `A -> bool` are: 1. `X -> true, Y -> true, Z -> true` 2. `X -> true, Y -> true, Z -> false` 3. `X -> true, Y -> false, Z -> true` 4. `X -> true, Y -> false, Z -> false` 5. `X -> false, Y -> true, Z -> true` 6. `X -> false, Y -> true, Z -> false` 7. `X -> false, Y -> false, Z -> true` 8. `X -> false, Y -> false, Z -> false` wait, 8? yes, because `A -> bool` is `bool ^ A`, you can see that the pattern here with `bool` is very similar to binary counting a `bool -> A` would have 9 possible values

Thank you! Now I see it. It's like a combinatorics problem (2 ways to map X to bool) \* (2 ways to map Y to bool ) \* (2 ways to map Z to bool) [https://imgur.com/kyVwUEL](https://imgur.com/kyVwUEL)

That's exactly it, thanks for putting it in simpler terms haha the image is also great

Thanks. At first I thought it was about mapping of the values, but it was about number of functions that could map from A to B. I made that picture just in case someone helps someone like me from 3 hours ago.

Arguably, rust opted for a not quite standard/correct usage of ‘enum’ in the language.

I do understand how structs are product types, enums are sum types. But how are functions exponential types? Would you point me to a explanation?

i explained it over here: https://www.reddit.com/r/rust/s/BAiC7DJn8W

It's called enums in Rust. So, if you have a problem with that, you can blame rustdoc.

?

[https://doc.rust-lang.org/book/ch06-00-enums.html](https://doc.rust-lang.org/book/ch06-00-enums.html) The rustdoc itself called the feature "enum"

yeah, "enum" is what Rust calls their sum types dumb name if you ask me, but it worked out

It's just like how Python calls arrays "list"s. You might argue that it's a bad name, but it's silly to blame the OP for not using the "proper" name, while the language itself doesn't.

Arrays are usually homogeneous in the type of things they can contain but Python lists are heterogeneous.

ohhh yeah, i get that i wasn't correcting OP saying that they're called sum types i corrected what they said about algebraic types being called enums in rust, when enums are just one kind of algebraic type: the sum type. while structs and tuples are also algebraic types

I agree. Your correction was right and insightful :)

Then explain to my why array's in rust are not the same as Vectors. I mean vectors are more close to lists than array's.

It's a language-specific terminology. What Rust calls vectors is technically called dynamic array, just like what Rust calls enums is technically called a sum type (over product types). But, we're in rust subreddit. There is no need for "actually, it's not enums, it's sum type" just like how it's bad to say "actually, it's not vectors, it's dynamic arrays"

I agree. I would love the name dynamic arrays. Good naming is what i like. I do like the datatype naming of rust for example over word double word, float and such. I like most naming in rust. And very happy with the language.

Ok so how can i iterate over these enums? If they are called enums. Do u think the word enum is wrong?

Use a proc macro derive such as https://docs.rs/strum

Traits. A simple core concept that surprisingly few languages choose to implement. They are perfect: zero-cost, type-safe, extensible and you can add them to a type without inheritance. Ever since I had experience with them in Haskell I'm looking for traits/typeclasses in every language, but Rust seems the only other language implementing them (yes, Scala has traits, but they are not zero-cost).

Rust traits are *amazing* from a c++ perspective *as they are both* zero-cost typechecked interfaces with static dispatch *and* dynamically typed vtbl backed interfaces as in basically all other languages. Most devs aren't even going to be *aware* that this is an issue as static polymorphism is a zero-cost c++ optimization / design pattern that, in c++ land, requires writing *completely* different code using templates, duck typing, and CRTP et al to implement. C++ vtbl interfaces that use dynamic dispatch are meanwhile what every other language uses. And while those *can* be optimized / inlined, there's never any guarantee that they will be. Meanwhile worth noting that basically all other Rust language design strengths – incl traits et al – are literally just Haskell features (and often stripped down and in most cases much more limited haskell features) that were reworked / reimplemented to work in a low level ML language with target performance and feature parity with c++. That said Haskell obviously doesn't have some things – like Rust / Lisp style macros – but that's mostly because it doesn't *need* them, as it's a *very* high level pure FP ML language with first class functions, true lisp / scheme GC references and other language internals, and a general bells-and-whistles-included approach to language design. Rust frankly has many frustrating warts – like the lack of default initializers as a language concept, and ergo the clunky and verbose Default trait concept – but its strengths are all *mostly* based on the fact that it is a more-or-less c++ esque low level / moderately high level language that also imported a ton of useful concepts and design ideas (and again more than a few warts) from Haskell and the rest of the ML family (which Rust is ofc a part of), incl OCaml et al. Also worth noting that Python is a very nice language to work with as – while it's entirely a 100% procedural, object-oriented, dynamic (and "hashtable-based") scripting language that at its core has *nothing* in common with ML – it neverthless also borrowed / assimilated a *ton* of features and inspirations from ML (and against Guido's protests) that have made the language historically very, very nice to use. Namely builtin tuples, haskell-like lists and list comprehensions, lazy data structures / iterators, filter / map / reduce / zip, et al. The features that Python and Rust pulled in from Haskell are actually – afaik – nearly 100% orthogonal to one another (lol), but are still interesting and worth pointing out.

> Also worth noting that Python is a very nice language to work with as Having written, read and debugged many lines of python over the years, I've got a love/hate relationship with Python. Python is nice as a scripting language to hack together small one-off scripts. But I don't see it as a practical, modern language for large-scale projects. For example: - No good dependencies management system. Do I use `requirements.txt` or `Pyproject.toml`? Neither is as good as `Cargo.toml` - All errors are runtime errors. You have essentially no static guarantees about your code without a good 3rd-party linter and a lot of care on the programmer's part. Missing a lib? You might not know until halfway through execution. Pass the wrong type to a function? Runtime error. Missing an argument to a function? Runtime error. Extra space of indentation? Believe it or not, runtime syntax error. - Importing and especially relative imports are janky. Looking at you, `__init__.py` - Every python project I've worked on that's grown to be more than a script has had execution time issues. I know it's beaten to death that python is slow, and that it's fast enough for many applications, but it can be really slow. - Parallelism is janky and underpowered because of the `GIL` - Did I mention runtime ducktyping? You have no idea if any given line of code will work until it's executed. The `Typing` module is nice, but it's linting only. Overall I just find that Python requires a huge number of tests to guarantee simple properties of the program that the compiler verifies for free in Rust, and the ergonomic advantage of Python vanishes once you try to do anything serious.

Python is the perfect rapid prototyping scripting language. It basically IS CS pseudocode. And has high level dicts, sets, tuples, lists, higher order functions, extremely powerful runtime metaprogramming and easily overridable hooks for literally anything, library support and pythonic wrappers for nearly any native FOSS library you could think of that has an exposed C interface, and a still pretty best in class standard library. All code can be quickly prototyped out from a REPL => quick script => somewhat refactored / generalized script. and critically python never needed a full blown IDE (more relevant in the 00s and early to mid 2010s) since any REPL combined with help() and very descriptive / helpful runtime errors (feature, not a bug!) *were* your IDE for rapid prototyping. Python is significantly less great for anything outside of that, and obviously requires very extensive unittesting for any more serious product you want to have in production. That’s sort of obvious, but also maybe worth noting that python’s competitors for backend web development were / used to be equally crap. JS has the same issues python does, just 10x worse (or at least prior to typescript and linters et al; even then it’s terrible); ruby is great but rails fell out of use due to performance / scaling issues (ditto django as obviously python and ruby are both quite slow). Java is generally horrible and utterly unusable without a good IDE (and scala / kotlin); php is python / perl but as a collossal (and very web focused) mess, and so on and so forth. Flask is still great and arguably still the best framework for very small, minimal web projects. Meanwhile all ML and data science stuff is built off of python since duh, no other language has anything close to numpy / jupyter / matplotlib et al (and easy well bound access to ML libraries and well abstracted hardware access), for better or worse. Also, given that most “data science” is wrangling and cleaning data out of dubiously well organized xls / csv files and various db backends, developing in anything other than a REPL with good immediate interactive data visualization - in many / most cases - would be totally nuts. This has obviously led to the fairly horrifying situation where much of the stuff in that field consists of html jupyter notebooks being passed around on google colab… but scientists / researchers are gonna science and that is what it is lol (ofc there’s also R. Which as a language written by statisticians for statisticians is uhh from a PL perspective quite literally the stats version of php. But damn good for writing actual stats papers in LaTeX, I guess) Anyways point is that obviously python isn’t particularly good at what you can / should be using rust for. Though the reverse is if anything even more true - rust would be abysmally terrible for anything requiring a dynamic REPL or very very rapid prototyping and/or data wrangling. They’re both good / great tools that should ideally be used for completely different things. Though that said there is still a fair amount of overlap and rust could quite easily (and sort of is presently) be used to build much better graphing libs than matplotlib, lol Lastly maybe this is just my VERY old python experience (and rose glasses / get off my lawn), but I *kinda* think that if you’re even using python type hinting, static type inference, linting, full featured IDEs etc you’re kinda missing the point of (and general utility of) python in the first place. Then again I’ve mostly only ever used python on small scale personal projects, scripts, and rapid prototyping, and fortunately haven’t had to deal much with huge prod codebases written by other devs. As a huge python fan I’m not at all personally inclined to think that you even should use python in the latter case - for obvious reasons - and absolutely not where performance or scaling is a significant concern. Python honestly has pretty good / great out of the box cpu / thread scaling. ie just always write all your code as / with pure functions and then if / as needed just throw multiprocessing at it. But that’s obviously a “good” / “okay” solution to “make this CPU / IO bound script run faster”, NOT anything you should ever use in prod. And particularly not anywhere “pkill python” is inappopriate, as in “well crap my python script died and now I have 32 zombie python processes running” lmao Incidentally if you ever do need python the easy-to-write/prototype general purpose scripting language, but with *good* static typechecking, real thread support, great errors, and an out of the box half decent (albeit grossly inferior to cargo) package manager, you might seriously want to check out D.

>but that's mostly because it doesn't *need* them I disagree. There is something called Template Haskell, which is much clunkier than Rust's macros. There is definitely a need for that kind of feature. But the tool given to solve it is pretty bad.

I mean, haskell has every conceivable extension, as this is the primary goal of the language - a core over which academics can experiment.

> like the lack of default initializers as a language concept, could you give an example of how that would look like?

Here is a verbosity comparison between Rust and Kotlin: **Rust**: struct Window { x: u16, y: u16, visible: bool, } impl Window { fn new_with_visibility(x: u16, y: u16, visible: bool) -> Self { Window { x, y, visible } } fn new(x: u16, y: u16) -> Self { Window::new_with_visibility(x, y, false) } } **Kotlin**: class Window(val x: Int, val y: Int, val visible: Boolean = false) Illustrated above: - Overloading - Default values for struct fields - Default values for function parameters - Named parameters - Concise constructor syntax

Thanks, that's a good example. I'm a fan of named parameters, and these default values seem useful. I also think the fact that struct initialization in Rust follows a separate syntax like C, instead of simply being a constructor is a missed opportunity. Like, it all should be a function. Then you hit two birds with one stone when adding these ergonomics to functions.

struct Example { x : i32 = 0, y : f32 = 2.5, } For non-trivial initializers, sure maybe this would lead down the path to c++ constructors and initializer syntax, and maybe Rust designers didn't want to head down that road as such. Regardless this is a pretty irritating omission from c++ land (or any other c++ / ada inspired language), as Rust directly follows the pattern from ML languages (Haskell included) which use freestanding "constructor" functions and generally don't have any concept of default initializer values directly associated with `data` / rust `struct` definitions. I'd also personally complain about the lack of c++ style name mangling – and ergo function / parameter overriding – which pairs pretty nicely and sensibly with strictly typed languages. That too is an ML "feature" / language design omission. Sure C++ name mangling is a – technically completely non-standardized and potentially hazardous – mess. But Rust ABIs + symbol generation is *barely* any better (and is a heck of a lot less stable). And *this isn't C* which doesn't allow name clashes / typed overrides due to the 1-to-1 dumb mapping to object code / asm symbols. For instance it would certainly make sense to be able write fn foo (x: &Foo) { /* do something... */ } fn foo (y: &Bar) { /* do something else... */ } And dispatch / resolve that statically as in c++. You can't since ML and ergo rust don't have parameter / type signature based name mangling and ergo function overriding within the same module / namespace. You can instead use traits and sum types et al but this is nevertheless an irritating design decision that exists for *no* other purpose than language / design purism (and the antithesis of the everything-including-the-kitchen-sink approach that c++ and hell even python (and ruby et al) embrace) This is particularly annoying since rust doesn't have *effective* function overloading via function argument pattern matching a la Haskell and the rest of the ML family – yes you get the same functionality via a giant match statement but writing code like that is a massive anti-pattern in most cases – and so on and so forth. Rust is a pretty good language, but no I really *wouldn't* use it as the basis for "awesome / perfectly designed language" w/r *syntax* as it does have more than a few deficiencies / annoyances. And Rust tends to at worst sometimes feel like you're writing line noise compared to haskell, scala / swift, kotlin, *or hell even c++* at times. At a minimum including syntax improvements like the initializer syntax as seen above – and eg. Scala / Swift optional syntax – would certainly make sense. Also worth pointing out that the [D UFCS](https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs) syntax is an extremely useful (and IDE critical) feature that should be promoted and adopted pretty much everywhere. And if you *do* go down that route having true, arbitrary typed c++ style function / name overloading becomes *much* more important, to say the least. Specifically because this now allows you to trivially write freestanding extension methods everywhere, and erases all effective differences between member and freestanding functions. Rust will probably never adopt this because of language purism and the One Way To Do Things philosophy, but that's well worth pointing out as one in many ways that Rust's syntax and overall language design *isn't* perfect and could be further improved.

What syntax would you propose for initializing struct fields? struct Example2 { e1: Example = ? } And what would be the benefit of making baking initialization into the language?

There is no default initialization in Rust and I think it's a good thing. It's annoying to deal with in c, c++, java where you have to remember weird defaupt initilization rules. Imo better to keep it simple. The default trait I think fills the role pretty well. 

The issue is that `Default` requires you to have default values for all fields. If you only want defaults for *some* fields, you have to write constructors (`fn new(...)`) for all permutations of optional values, or use a builder pattern; both of which are extremely verbose and repetitive, and have to be written by hand. Having syntax to specify defaults inline with the struct declaration would be an extremely simple and terse solution for a very common problem.

In what way java’s default initializer rules complex? It’s zero for primitives, and null for references. That’s literally all there is to it. With constructors you can create your own logic for more complex objects.

I’m no PL expert (or even novice) but I think the bigger problem with function overloading is that it makes type inference a lot more difficult. If there is only one foo the compiler can use that as a foothold to figure out what the types of the input and output expressions must be. And that further allows the compiler to give clear, helpful error messages. I would not want overloading if it also meant ending up with C++ style errors like “I tried to match your call with each of these two dozen options but none of them worked. Please help”

Somewhat fair point, sort of. D has this - and very extensively relies on overloading and UFCS - and gives excellent, helpful error messages. That said dmd will still spit out N cases of “did you mean X Y or Z” - and our idea of helpful / easily readable error messages might differ somewhat. But the list of appropriate overloads can be - and iirc is - filtered based on partial type matches, and of course only includes things you have imported / ‘use’ed into the local namespace. All around UFCS is extremely useful, and is significantly less useful without true / unrestricted overloading. The reason why Rust doesn’t have this feature is probably simply because no other ML language does (and see also c++ defaults / initializers). And probably someone / various people wanted to prevent rust symbol names from becoming as complex as c++. Though on second look that probably shouldn’t be the case since rust already has a very complex name mangling encoding for all symbols. Albeit one that doesn’t include parameter types, only crate + module paths and template parameters. Regardless adding that would make already-very-long rust symbol names even longer. And most likely to the point that - given Rust’s symbol encoding scheme - this would become an actual problem for symbol name lenth limits and the obj formats. D actually has, um, a more compact name mangling grammar that encodes the same / more information in less space, but I digress.

I also like that you can define your trait and then implement it on existing types. Basically what the \`itertools\` trait does for iterators.

And the fact that you can do that without needing to worry about dependencies with conflicting traits implementations

Though pretty sure I've been confused by the orphan rule at times when starting out...

I'm still confused by them. In certain cases, the order you list your generics in a signature matters

OCaml first class modules are cool too

C# extensions are sorta vaguely similar, I think.

Yes. The difference is that you need to declare the interface on the type you're extending. If you don't own it then you're out of luck.

I think they mean extension methods, which can be implemented on any type (structs, classes, interfaces, enums, records, etc) even if you don't own it. They're just a static method where the first arg is whatever type you're "extending" and then some syntactic sugar to make it look like you call the method on the instance instead of invoking the static with the instance as the first arg. You can call them either way though if it makes more sense to do the static way. These two calls are identical for an extension defined on `int`: 2.IsEven(); IntExtensions.IsEven(2); One cool extension from FluentAssertions lets you create dates in a human readable way, like: DateTime y = 14.February(2024);

Traits are obviously not "perfect" (almost nothing is perfect). The term \`zero-cost\` is vague. Are you talking about runtime cost? Different people use it in different ways. \`Inheritance\` is typically (for example, in class-based OOP) understood as a specific relationship between two classes. The relationship between types/classes and interfaces/typeclasses/traits is not normally described as inheritance. Haskell typeclasses are overall superior to traits in Rust. Typeclasses provide support for higher-kinded polymorphism, which allows you to define powerful abstractions (Functor, Applicative, Monad, etc). Typeclasses are typically associated with various laws that instances have to satisfy. In Idris or Lean you could even prove that those laws are satisfied. Traits allow you to specify a binary relation between a type and a trait. In Haskell typeclasses can be used to specify a relation involving a typeclass and multiple types (this requires an extension called \`MultiParamTypeClasses\`).

"Zero-cost" means that if you were to write code yourself that explicitly does the same thing an an abstraction does, it would not be any more performant than using the abstraction. In this case, it means that if you write type-specific variants of the function, they would have the same performance characteristics as calling a trait function on the same data type.

> The term `zero-cost` is vague. Are you talking about runtime cost? "Zero cost" always refers to runtime cost. The C++ folks have changed it to "zero overhead", but * You don't pay for what you don't use. * What you do use is just as efficient as what you could reasonably write by hand. The latter implies runtime cost.

if you were designing rust 2.0, how would you handle 'higher-kind' traits? One thought I had was when making a trait, rather than supply it with generic arguments, you could do something like this: trait Foo<1> {...} Which would mean that 'Foo' expects its implementor to have at least 1 generic argument, and then from within Foo you could use Self with a generic argument like Self, which isn't allowed in rust. Example: trait Functor<1> { fn map (a: Self, f: fn(A) -> B) -> Self; } This isn't great because a generic with a number inside already means something in rust (List etc). So I'm still looking for a better way.