
How Rust Gets Polymorphism Right [video] - adamnemecek
https://www.youtube.com/watch?v=VSlBhAOLtFA
======
vim_wannabe
There is a rumor[1] even Rust has yet to get polymorphism right:

>I'm using nalgebra for math. I'll write a bit about it here, because I think
it's relevant to Rust as whole. I'm not sure if I actually like it. It's so
heavily templated that most of the error messages are impossible to
understand, so I usually just double-check what I wrote and try to guess
what's wrong. It's also where rust's documentation generator gets in trouble.
Signal to noise ratio there is <10%. Not sure how to fix that. Anyway, my
point is that maybe it's not always the best idea to write code as generic as
possible.

[1]:
[https://www.reddit.com/r/rust/comments/795dg4/i_spent_the_la...](https://www.reddit.com/r/rust/comments/795dg4/i_spent_the_last_year_writing_a_plant/)

~~~
bjz_
Much of nalgebra's woes come from it trying to be n-dimensional without
support for constants-in generics yet (this is in the works). To do this it
does crazy wizardy using traits to model numbers at compile time. It's
impressive for sure, but the compile errors are equally impressive. Which is
why work is being done to add support for constants in generic parameters.

But this is the case of one library. Another library to suffer from poor
errors is the futures lib, but that will be solved with the `impl Trait`
syntax that is in the works.

Definitely agree it's a good idea to have a balance when it comes to generics,
but likewise I'm glad folks are pushing the boundaries and finding room where
things could be improved. It does take time for the language to catch up
though, but they're working on it. Lots of good stuff is coming out of the
current impl period.

~~~
seanmcdirmid
Using classes or traits to model dimension numbers is something I did in C#
when working on Bling 10 or so years ago. If you only have a few dimensions
you need to handle anyways, it works out, and you can embed predecessor and
successor dimensions in the types. Good days, though I guess I’m not that
reckless anymore.

~~~
bjz_
Yeah, same in the C++ world with templates. They're just so handy, especially
when you want performance! Thankfully C++'s `constexpr` has made this kind of
thing much more tenable from a library consumer's perspective, and Rust will
again be following in its footsteps, albeit with a less adhoc version based on
dependent types.

For what its worth, my cgmath library just has a bunch of hardcoded
`Vector{2,3,4}`, `Point{2,3}`, and `Matrix{2,3,4}` types.

~~~
seanmcdirmid
Ya, that like is familiar. In C#, you can declare class D4 : Dim<D3,D4,D5>
...., and then use extension methods to access the D3 and D5 type parameters
as previous and next dimensions. It all was nice and f-bounded as well. C# is
an under appreciated language for these kinds of things.

------
myst
I’d love to see comparison between Rust and Haskell/ML WRT polymorphism. I
wonder if “gets right” would appear there and on what side.

~~~
jmcomets
Apples & Oranges.

Although Rust heavily borrows from the ML family, the fact it has mutability
and imperative reasoning makes it hard to compare them.

But if you want a short one:

\- Sum Types EDIT: AND Product Types (silly me)

\- function-objects & closures

\- typeclasses (as far as I can tell), but no higher kinded types

\- no monads, functors nor monoids built-in

\- trait objects (eg. runtime polymorphism, think "abstract classes")

~~~
ketralnis
> \- Sum Types but no Product Types

Maybe I'm missing something, but aren't tuples and structs/records examples of
product types? Which both rust and haskell have?

~~~
mathw
Yes I always thought tuples were the archetypal product type, which is why in
some ML dialects they're notated as "Type1 * Type2".

Rust most certainly has them, as does Haskell. Records/structs of course are
just the same thing with names for the components.

Thus, even Java has product types.

~~~
masklinn
> Thus, even Java has product types.

Even _C_ has product types. Which is why I'm always bothered when people claim
language X lacks algebraic data types.

They probably lack sum types, but are very unlikely to lack product types.

~~~
kod
Product types without sum types and pattern matching are basically useless for
expressing ADTs. That's what people mean.

~~~
masklinn
> Product types without sum types and pattern matching are basically useless
> for expressing ADTs.

That makes no sense. Algebraic data types are not _expressed_ , they're a
concrete thing, a classification of composite types (by multiplication (hence
product types) or addition (hence sum types)).

~~~
kod
Sure it does, languages allow you to express things.

Some shitty languages don't have a concise way for you to express particular
things (like sum types), so you have to rely on idioms or "patterns".

------
leshow
It makes me smile that this type of programming is starting to influence so
many things. You see it even in Swift with 'protocols' and 'extensions'.
Typeclasses are a fantastic method of abstraction. I remember watching a video
on Rust's history and they said that some time during Rusts development a
bunch of haskellers joined and the current traits and ownership system was
born (I'm sure I'm oversimplifying here)

~~~
lmm
I'm glad that it's happening, but at the same time I'm frustrated that it's
taken 20+ years to adopt a limited subset of what Haskell had.

------
hmottestad
Watching this recording I really wished they would invest more in audio
equipment and in people who know how to record it. Reminds me of a lecturer at
uni who had a bunch of recorded quest lectures that he would show every year.
Audio on those was terrible, constantly clipped sound, but when we complained
he said he couldn't hear anything wrong.

~~~
MHordecki
This is why text articles are superior to videos - or at least an accompanying
transcript. Text is very hard to mess up.

~~~
chrismorgan
U+1F928 FACE WITH ONE EYEBROW RAISED

(Interpretation of that raised eyebrow: text isn’t hard to mess up. It is
nonetheless more accessible in general, I just couldn’t leave the “text is
very hard to mess up” unremarked on.)

~~~
scrumper
Your counterpoint example to the proposition that text is hard to mess up
is... a picture?

Edit: or have I completely missed the point of what you're saying!

~~~
kbenson
It's a picture as much as any particular character in a font is, which is to
say, _it is_. We're just very used to recognizing particular variations and
combinations. There's one problem here that can be expressed in two ways, one
is a proliferation of many new characters which people may not know the
idiomatic usage of until they've encountered it in more context, the other is
new combinations of known characters and words into a _new_ idiomatic usage
that has the same problem.

Consider that there was a time not so long ago where the vast majority of
people didn't know what LOL meant and would be confused when encountering it.
On the other end you could probably copy some heavy British slang in here
right now and I would be very confused.

