Its not a huge issue in Haskel and they are making it less. Its also worth noting that a lot of the systems programming code uses very little in the way of traits.. maybe for the system program niche it will work... C# , PHP , JS and Java pretty much have GP programing covered anyway.
I should elaborate on this ... What i mean is the guys who write systems programing now rarely use C++ and higher abstractions they pretty much use C .. im currently fighting for printf not to be default string formatting ! . So moving to rust is a natural fit .. I do agree that it may result in some problems in user land but only if it becomes a very successful language and they will have less issues than Haskel. And it would still be far superior to C / C++ ... +1 on the crappy reference the tutorial and blogs are more usefull . Ben On Mon, Jul 15, 2013 at 10:37 AM, Jonathan S. Shapiro <[email protected]>wrote: > On Sun, Jul 14, 2013 at 5:31 PM, Alex Rozenshteyn <[email protected]>wrote: > >> It's my understanding that Rust traits suffer fewer coherency issues than >> Haskell type classes because Rust disallows orphan impls, so that in order >> to implement a trait, either the trait or the data needed to be defined in >> the same crate. >> > > This is conceptually equivalent to the haskell rule that a type class > instance must either be provided in the unit of compilation that introduces > the type class or in the unit of compilation that introduces the type. > > That allows a check for non-overlapping instances, but it doesn't address > the problem of instance resolution, e.g. for List<'a> vs List<char>. > > General aside: the Rust "reference" is exceptionally poor on describing > behavior, rules, and restrictions. > > > Jonathan > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
