Hacker News Reader

Comment by vim_wannabe | Hacker News Reader

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...

View on HN

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.

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.

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.

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.

Those criticisms are mostly of the way rustc outputs errors (it is definitely open to improvement, and notable improvements are made every few months) and how rustdoc shows generics (automatic generation of such things can’t really work well; there are ways that it could probably be improved, but they’re hard enough that no one has tried any of them that I know of).

Of course, the UI is a part of Rust, so these things do matter, but as far as the language implementation is concerned, it’s not as bleak as all that. Rust, being a comparatively complex language (unlike Go, for example, where linguistic simplicity is a feature) is taking a long time to mature, but it is steadily maturing.

To be clear, the paragraph you're quoting is criticizing one specific library (the naglebgra library) which overuses traits. In context, that quote is about the temptation of writing super-polymorphic code in Rust, and not strictly a complaint about Rust's specific implementation of polymorphism. I'm not at all convinced that the argument made by the video is somehow contradicted by the fact that Rust still lets you write unnecessarily polymorphic code.

Such heavy use of traits can allow you to do things that would otherwise have been impossible or less efficient—there are advantages to it. But they definitely come at a cost.

Reply on news.ycombinator.com