6 ms·

It will be interesting to see what the subset is. I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall,

It will be interesting to see what the subset is. I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall, the language is just not the most approachable. Some of the features are super valuable every once in a while, but I might gladly give some of them up for a streamlined language that is easier to get people started on (while not just writing imperative style Java with Scala syntax) My other curiosity is compatibly. If I can compile a subset of my project much faster that doesn't need all of Scala, that seems like an okay place to be in.

adamnemecek 9y ago
Check out Kotlin. I picked it up in like half a day. It wasn't idiomatic Kotlin but w/e. It can compile to JS and you can use just about any JS lib from Kotlin (which is insanity). You'll be able to write ios apps with it soon enough. Scala can be too hard sometimes.
- brianwawok 9y ago
  You can use JS from scala also.
- alextheparrot 9y ago
  He's using Spark and Flink... Given that I'm also in that big data space, I'm certain the tooling provided by Kotlin is strictly worse than Scala for those applications.
- afghanPower 9y ago
  Clojure(Script) can do the same.
MrBuddyCasino 9y ago
> It will be interesting to see what the subset is. Totally. Its interesting that they approach this from a compile speed angle, I wonder how much they are also considering the mental load of certain features. This might become an interesting project for companies already doing Scala. New ones at this point will probably prefer Kotlin.
sulam 9y ago
Historically anything with heavy use of implicits is embarrassingly bad for compilation.
- koolba 9y ago
  It's also atrocious for comprehension.
  - lmm 9y ago
    Not the same thing. The thing that slows down compilation is recursively derived implicit parameters for typeclasses, which don't tend to be a problem for reading - you just write "myObject.toJson" (and behind the scenes it recurses through the structure of myObject at compile time, ensuring that all of the nested types bottom out in values that can actually be serialized to JSON, and compiles to something of similar efficiency to manually naming all the fields). The thing that causes readability issues tend to be overuse of implicit conversions, and the community has largely moved away from that, thankfully.
    - harveywi 9y ago
      This is interesting. Would it be helpful, and possible, to add a "YOLO mode" to the Scala compiler so that it just make-believes that recursively derived implicit parameters bottom out properly? Maybe force the caller to give an explicit type (even if the type is wrong). I'd do that to reacquire some semblance of quick compile times. Then, when the developer has finished they can switch off "YOLO mode" and start playing whack a mole with the types, as needed, punctuated by longer compilation times.
      - koolba 9y ago
        Typescript is kind of like that. You can run the compiler with the type validations disabled. That can lead to potentially broken code but it can also be significantly faster than waiting for all type checks to complete.
lmm 9y ago
> I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall, the language is just not the most approachable. Some of the features are super valuable every once in a while, but I might gladly give some of them up for a streamlined language that is easier to get people started on (while not just writing imperative style Java with Scala syntax) Any concrete ideas? In my experience the parts people find intimidating often aren't actually language features, they're things some library or other implements. I mean there are things I would remove from Scala if I were in charge - structural types (provided there was still a way to express partially applied types i.e. standardize kind-projector in the core language), Dynamic - but they don't tend to be the parts that trip people up.

adamnemecek 9y ago

Check out Kotlin. I picked it up in like half a day. It wasn't idiomatic Kotlin but w/e. It can compile to JS and you can use just about any JS lib from Kotlin (which is insanity). You'll be able to write ios apps with it soon enough. Scala can be too hard sometimes.

brianwawok 9y ago
You can use JS from scala also.
alextheparrot 9y ago
He's using Spark and Flink... Given that I'm also in that big data space, I'm certain the tooling provided by Kotlin is strictly worse than Scala for those applications.
afghanPower 9y ago
Clojure(Script) can do the same.

MrBuddyCasino 9y ago

> It will be interesting to see what the subset is. Totally. Its interesting that they approach this from a compile speed angle, I wonder how much they are also considering the mental load of certain features. This might become an interesting project for companies already doing Scala. New ones at this point will probably prefer Kotlin.

sulam 9y ago

Historically anything with heavy use of implicits is embarrassingly bad for compilation.

koolba 9y ago
It's also atrocious for comprehension.
- lmm 9y ago
  Not the same thing. The thing that slows down compilation is recursively derived implicit parameters for typeclasses, which don't tend to be a problem for reading - you just write "myObject.toJson" (and behind the scenes it recurses through the structure of myObject at compile time, ensuring that all of the nested types bottom out in values that can actually be serialized to JSON, and compiles to something of similar efficiency to manually naming all the fields). The thing that causes readability issues tend to be overuse of implicit conversions, and the community has largely moved away from that, thankfully.
  - harveywi 9y ago
    This is interesting. Would it be helpful, and possible, to add a "YOLO mode" to the Scala compiler so that it just make-believes that recursively derived implicit parameters bottom out properly? Maybe force the caller to give an explicit type (even if the type is wrong). I'd do that to reacquire some semblance of quick compile times. Then, when the developer has finished they can switch off "YOLO mode" and start playing whack a mole with the types, as needed, punctuated by longer compilation times.
    - koolba 9y ago
      Typescript is kind of like that. You can run the compiler with the type validations disabled. That can lead to potentially broken code but it can also be significantly faster than waiting for all type checks to complete.

lmm 9y ago

> I have been writing scala for 2 years, mostly in spark and flink and as much as I love parts of it, overall, the language is just not the most approachable. Some of the features are super valuable every once in a while, but I might gladly give some of them up for a streamlined language that is easier to get people started on (while not just writing imperative style Java with Scala syntax) Any concrete ideas? In my experience the parts people find intimidating often aren't actually language features, they're things some library or other implements. I mean there are things I would remove from Scala if I were in charge - structural types (provided there was still a way to express partially applied types i.e. standardize kind-projector in the core language), Dynamic - but they don't tend to be the parts that trip people up.