5 ms·

> except the problem of too many features Scala is a pretty simple, concise and coherent language though. Never understood why people deem it has too many feat

> except the problem of too many features Scala is a pretty simple, concise and coherent language though. Never understood why people deem it has too many features, I write it professionally and never felt so. At least comparing it to C, C++, Python. Java may be more simple, but you have tons of features added with metaprogramming via dozens of annotations generating lots and lots of boilerplate, Lombok and Spring are examples of that.

kerblang 5y ago
> Never understood why people deem it has too many features I'll start with one (key)word: `implicit` I agree with your distaste for metaprogramming though.
- ernst_klim 5y ago
  > I'll start with one (key)word: `implicit` I don't think implicit counts as "too many features" or as something complex. Basically all it does is finding a canonical value in scope for a hole of certain type.
  - kjeetgill 5y ago
    I only worked in Scala briefly so maybe it's coming from Java habits, but implicits were huge pain. When first reading through code you don't really know if that function call you eyed over really has the params you think it does. It makes it WAY harder to track what's derived from what. Either way, the local Scala guru there said the Scala community was starting to get over implicits.
    - valenterry 5y ago
      I think that's were it comes from: people that briefly worked with Scala in the past. At some point it was true, but nowadays the problem is solved because IDEs will show you were an implicit is used and where it comes from. Without that, it was indeed more difficult - but also not more difficult than Java's reflection or DI (where you had and have even less help).
    - ernst_klim 5y ago
      > When first reading through code you don't really know if that function call you eyed over really has the params you think it does. Yeah, but don't you feel the same pain when using Spring's autowiring? Or python's (or C++ template) default arguments? Or dynamic method dispatching in any OO language, where you don't know what method you actually call? Or late bindings? I don't see how implicits' implicitness is significantly worse than any other kind of implicitness common in other language.
      - kjeetgill 5y ago
        I mean me personally? I'm very boilerplate tolerant. I'm not a fan of Dependency Injection/Auto Wiring for similar reasons and I've never found wiring boilerplate to be too painful. In fact I'd love even more explicitness and manual wiring for almost everything like disk, network, or even clock access aka passing capabilities! Default params are generally fine since they're hidden on the implementation side but explicit if they vary at the caller site. And even dynamic dispatch I try to use carefully and sparingly. I just like really explicit programs.
        ernst_klim 5y ago
        > I'm not a fan of Dependency Injection/Auto Wiring for similar reasons I see. My point was that such things are pretty common in most contemporary languages and I don't see how Scala is special in this regard. Yes, unlike Go or Java, implicits are part of the language spec and not some metaprogramming magic on top of it, but I'm not sure it's a bad thing.
- halfmatthalfcat 5y ago
  You can use Scala without introducing implicits and even if you have to interopt with a library that does require them, it's quite easy to learn how to use them. It's also easy to abuse them but then that's not really Scala's problem. They are changing implicits in Scala 3 though with the "given" keyword which is more ergonomic.
  - cutler 5y ago
    Scala can't let go of implicits as they're a fundamental part of the language. I just don't believe this Scala 3 fudge to give the impression implicits are not alive and well beneath the surface.
    - esarbe 5y ago
      Scala 3 takes the most common use cases for implicits and makes them more ergonomic. Implicits are still in the language, but not exposed as concept. Odersky called the approach for Scala 3 "intent over mechanism."
- asimpletune 5y ago
  You don’t have to use implicits though, but you’d be super happy they’re there should you ever be in a situation where they’re helpful
  - diroussel 5y ago
    Doesn’t a monad or for comprehension use implicits to find the right CanBuildFrom? Are you suggesting to use scala without using for comprehensions? Or do you mean you don’t need to write your own? It’s been a long time since I wrote scala, so may be getting it wrong.
    - joshlemer 5y ago
      CanBuildFrom is gone in the 2.13 collections rewrite
    - valenterry 5y ago
      No it does not. A for-comprehension just requires that map/flatMap methods are available. No implicits or CanBuildFrom needed.
- lmm 5y ago
  Implicits are one feature that replace many features in other languages (Kotlin has probably 5 or 6 special features that each do limited subsets of what implicits can do, and still misses important parts of their functionality). There is some legitimate criticism to be made of Scala implicits (though I have yet to see a better alternative), but "too many features" isn't it.
  - lolinder 5y ago
    What Kotlin features do implicits serve to replace? I'm new to Scala and am having trouble imagining when I'd want to use an implicit, so I'm genuinely curious.
    - lmm 5y ago
      Off the top of my head: Extension methods. "with" contexts. Scope functions (by letting you write your own). Many of the things done with kapt (e.g. typeclasses, not that there's a good way to do them in Kotlin). Spring-style autowiring (not part of Kotlin proper, but seemingly the idiomatic way to use it). The magic last parameter lambda syntax thing (by letting you implement the magnet pattern).
    - beerbajay 5y ago
      Scala implicits are used in a few different places, predominantly in library code where they can for example be used to derive instances of type classes. e.g. in circe: import io.circe.syntax._ List(1, 2, 3).asJson Where `asJson` requires an instance of an `Encoder`[1] and this Encoder can be derived with the help of implicits. For you as a normal user, the two common places where you might use implicits are (1) for implicit classes providing syntactic sugar: // original def doSomething(a: A): B = ??? val a: A = ??? val b = doSomething(a) // with implicits implicit class AImplicits(a: A) { def doSomething: B = ??? } val a: A = ??? val b = a.doSomething and for (2) implicit conversions. These are a foot-gun, so should be used in limited circumstances. At work, we use case classes in data pipelines then convert these to avro classes on save; there's lots of ways to do this, but as an example if you have an `Optional[Int]` and your avro constructor requires a nullable java `Integer` then `JavaConverters` won't save you and you'll need something like: implicit def optIntToInteger(optI: Option[Int]): java.lang.Integer = optI.map(Int.box).orNull [1] https://circe.github.io/circe/api/io/circe/syntax/package$$EncoderOps.html#asJson(implicitencoder:io.circe.Encoder[A]):io.circe.Json https://circe.github.io/circe/api/io/circe/syntax/package$$E...
ragnese 5y ago
Exactly this. Java-the-language is so simple that Java-in-practice is disgustingly littered with verbose patterns to accomplish really basic abstraction concepts, annotations that may or may not work at runtime, and runtime reflection with unsafe casting because of type-erased generics. Java codebases are way scarier than Scala.

kerblang 5y ago

> Never understood why people deem it has too many features I'll start with one (key)word: `implicit` I agree with your distaste for metaprogramming though.

ernst_klim 5y ago
> I'll start with one (key)word: `implicit` I don't think implicit counts as "too many features" or as something complex. Basically all it does is finding a canonical value in scope for a hole of certain type.
- kjeetgill 5y ago
  I only worked in Scala briefly so maybe it's coming from Java habits, but implicits were huge pain. When first reading through code you don't really know if that function call you eyed over really has the params you think it does. It makes it WAY harder to track what's derived from what. Either way, the local Scala guru there said the Scala community was starting to get over implicits.
  - valenterry 5y ago
    I think that's were it comes from: people that briefly worked with Scala in the past. At some point it was true, but nowadays the problem is solved because IDEs will show you were an implicit is used and where it comes from. Without that, it was indeed more difficult - but also not more difficult than Java's reflection or DI (where you had and have even less help).
  - ernst_klim 5y ago
    > When first reading through code you don't really know if that function call you eyed over really has the params you think it does. Yeah, but don't you feel the same pain when using Spring's autowiring? Or python's (or C++ template) default arguments? Or dynamic method dispatching in any OO language, where you don't know what method you actually call? Or late bindings? I don't see how implicits' implicitness is significantly worse than any other kind of implicitness common in other language.
    - kjeetgill 5y ago
      I mean me personally? I'm very boilerplate tolerant. I'm not a fan of Dependency Injection/Auto Wiring for similar reasons and I've never found wiring boilerplate to be too painful. In fact I'd love even more explicitness and manual wiring for almost everything like disk, network, or even clock access aka passing capabilities! Default params are generally fine since they're hidden on the implementation side but explicit if they vary at the caller site. And even dynamic dispatch I try to use carefully and sparingly. I just like really explicit programs.
      - ernst_klim 5y ago
        > I'm not a fan of Dependency Injection/Auto Wiring for similar reasons I see. My point was that such things are pretty common in most contemporary languages and I don't see how Scala is special in this regard. Yes, unlike Go or Java, implicits are part of the language spec and not some metaprogramming magic on top of it, but I'm not sure it's a bad thing.
halfmatthalfcat 5y ago
You can use Scala without introducing implicits and even if you have to interopt with a library that does require them, it's quite easy to learn how to use them. It's also easy to abuse them but then that's not really Scala's problem. They are changing implicits in Scala 3 though with the "given" keyword which is more ergonomic.
- cutler 5y ago
  Scala can't let go of implicits as they're a fundamental part of the language. I just don't believe this Scala 3 fudge to give the impression implicits are not alive and well beneath the surface.
  - esarbe 5y ago
    Scala 3 takes the most common use cases for implicits and makes them more ergonomic. Implicits are still in the language, but not exposed as concept. Odersky called the approach for Scala 3 "intent over mechanism."
asimpletune 5y ago
You don’t have to use implicits though, but you’d be super happy they’re there should you ever be in a situation where they’re helpful
- diroussel 5y ago
  Doesn’t a monad or for comprehension use implicits to find the right CanBuildFrom? Are you suggesting to use scala without using for comprehensions? Or do you mean you don’t need to write your own? It’s been a long time since I wrote scala, so may be getting it wrong.
  - joshlemer 5y ago
    CanBuildFrom is gone in the 2.13 collections rewrite
  - valenterry 5y ago
    No it does not. A for-comprehension just requires that map/flatMap methods are available. No implicits or CanBuildFrom needed.
lmm 5y ago
Implicits are one feature that replace many features in other languages (Kotlin has probably 5 or 6 special features that each do limited subsets of what implicits can do, and still misses important parts of their functionality). There is some legitimate criticism to be made of Scala implicits (though I have yet to see a better alternative), but "too many features" isn't it.
- lolinder 5y ago
  What Kotlin features do implicits serve to replace? I'm new to Scala and am having trouble imagining when I'd want to use an implicit, so I'm genuinely curious.
  - lmm 5y ago
    Off the top of my head: Extension methods. "with" contexts. Scope functions (by letting you write your own). Many of the things done with kapt (e.g. typeclasses, not that there's a good way to do them in Kotlin). Spring-style autowiring (not part of Kotlin proper, but seemingly the idiomatic way to use it). The magic last parameter lambda syntax thing (by letting you implement the magnet pattern).
  - beerbajay 5y ago
    Scala implicits are used in a few different places, predominantly in library code where they can for example be used to derive instances of type classes. e.g. in circe: import io.circe.syntax._ List(1, 2, 3).asJson Where `asJson` requires an instance of an `Encoder`[1] and this Encoder can be derived with the help of implicits. For you as a normal user, the two common places where you might use implicits are (1) for implicit classes providing syntactic sugar: // original def doSomething(a: A): B = ??? val a: A = ??? val b = doSomething(a) // with implicits implicit class AImplicits(a: A) { def doSomething: B = ??? } val a: A = ??? val b = a.doSomething and for (2) implicit conversions. These are a foot-gun, so should be used in limited circumstances. At work, we use case classes in data pipelines then convert these to avro classes on save; there's lots of ways to do this, but as an example if you have an `Optional[Int]` and your avro constructor requires a nullable java `Integer` then `JavaConverters` won't save you and you'll need something like: implicit def optIntToInteger(optI: Option[Int]): java.lang.Integer = optI.map(Int.box).orNull [1] https://circe.github.io/circe/api/io/circe/syntax/package$$EncoderOps.html#asJson(implicitencoder:io.circe.Encoder[A]):io.circe.Json https://circe.github.io/circe/api/io/circe/syntax/package$$E...

ragnese 5y ago

Exactly this. Java-the-language is so simple that Java-in-practice is disgustingly littered with verbose patterns to accomplish really basic abstraction concepts, annotations that may or may not work at runtime, and runtime reflection with unsafe casting because of type-erased generics. Java codebases are way scarier than Scala.