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.

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.

You can use JS from scala also.

Clojure(Script) can do the same.

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

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

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

It's also atrocious for comprehension.

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.

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.

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

It's not possible to actually build, because at the end of the day you are (presumably) using the implicit for something (e.g. JSON-serializing the value). You could explicitly pass ??? where the implicit is wanted to get a runtime failure where it's used. I guess it might be possible to have tooling do that "magically", but I'm not sure how useful that would be; if you're working on that particular area you can use ??? by hand, if you're not working on that area then you presumably won't be rebuilding it since you're presumably using incremental compilation anyway.

What is possible is to fail-fast when resolution fails, and not check for duplicates when resolution succeeds - one main reason for the blowup is that at every stage of recursive resolution you have to check whether the implicits were ambiguous. There's a proposed fix for that piece: https://github.com/scala/scala/pull/5649

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.

But if you do that you’re just writing JavaScript with pointless added verbosity and significant complexity pointlessly added to your toolchain.

The idea is to have fast compilation most of the time (local dev) and slower/full compilation during the "real" build.

Here's a testing analogy: My CI server runs all tests, every time. My local machine only runs the ones I tell it to run as if I change one small piece of an app then I'm not going to wait for the entire test suite to run.

And the incremental compilation isn't fast enough for you? Plus building Angular 2 (hundreds of thousands of LoC) takes only a few seconds.

Depends completely on how the implicits are being used. The older form of implicit conversions are pretty rough, but the more modern trend towards implicit enhancement IMO can improve readability.

that can be mitigated with IDEs showing marks on implicit uses, with mouse-over-to-peek-definition features (hope this lands on intelliJ... and hopefully a free license for me lol)