4 ms·
As someone interested in Scala but barely having used it, how do Scala's generics differ from C#'s reified generics? I've always found it difficult using gener
by edgyswingset 11y ago
As someone interested in Scala but barely having used it, how do Scala's generics differ from C#'s reified generics? I've always found it difficult using generics on the JVM in comparison to the CLR because of boxing. I did a preliminary search but couldn't really find a good comparison between C# and Scala generics that was up to date.
- kailuowang 11y agoThe traditional concept of generics you see in C# wouldn't be a selling point for Scala. There are more powerful "generic" programming tool in the scala world. See this article for an example. https://meta.plasm.us/posts/2015/11/08/type-classes-and-generic-derivation/ https://meta.plasm.us/posts/2015/11/08/type-classes-and-gene...
- edgyswingset 11y agoThat doesn't seem to have anything to do with generics; it looks to me like a great showcase of Traits and having an Optional type. Although I agree that those are more powerful constructs than what you can use in C#, that doesn't quite answer my question about how Scala generics themselves are such a great feature. Perhaps the OP was referring to the type system instead?
- whateveracct 11y agoimplicit parameters of generic traits (aka the typeclass pattern) have everything to do with how Scala's generics can be used in more powerful ways than C#'s. And they are 100% tied to Scala's generics. Generic types in Scala can be used in implicit search kick off inductive generation of type-safe code. If you literally just mean generics at runtime, they are no different than Java's, outside of support for specialization for primitive types. > Perhaps the OP was referring to the type system instead? Generics and the type system are pretty much the same thing? They only matter and have true power at compile time regardless of your language. So the fact that Scala's generics have absurd power at compile-time (way more than anything in C#) is 100% relevant.
- runT1ME 11y agoScala has higher kinded types (or, generics over generics). This is amazing (but can take a while to see why/get confortable with). .NET doesn't have this feature.
- edgyswingset 11y agoThanks, this is what I was hoping someone would write! I searched around a bit about HKT's and although I can't say I understand them, I can see how the ability to do something like provide a constructor over a type could be useful. It feels like it has a lot of use in writing very general-purpose libraries, or perhaps a DSL that can map to a wide variety of different types. Interesting!
- joslin01 11y agoGenerics in C# and generics in Scala have the same basic features (generic classes/interfaces/methods). When I say "powerful", the first thing that comes to mind is its ongoing reflection evolution. TypeTags give us access to class information in a functional manner (by passing in an implicit type info object) that we can take advantage of using Scala's (also powerful) matching mechanism. The second thing that comes to mind is the ability to support variance. To quote Twitter Scala School: "A central question that comes up when mixing OO with polymorphism is: if T’ is a subclass of T, is Container[T’] considered a subclass of Container[T]?" Scala allows us to express this information using +/- as in `Container[+D]` allows for subclasses of `D`. Finally, though not so much related, an interesting development in the type space is type macros (http://docs.scala-lang.org/overviews/macros/typemacros.html http://docs.scala-lang.org/overviews/macros/typemacros.html). This will give us a stronger "generic" approach to programming that allows us to write code to construct type hierarchies. In general, Scala is moving fast and always evolving. You'd have to be more specific as to what your problems are concerning boxing & jvm. Lists are properly specialized such that a = List(1) == List<Int> and a(0) == Int. Of course, if you use a diverse set of types in the list, you'll have a `List<Any>` which then you would use `match` like so... match item { case i:Int => println("int " + i) case s:String => println("string " + s) }