Hacker News Reader

Comment by lmm | Hacker News Reader

As a huge Scala fan, I fear that Dotty will suck the oxygen away. In particular, freezing the syntax for as long as the proposed timeframe for Dotty to be delivered would kill any language.

I would urge typesa^H^Hlightbend to bring forward the introduction of vital syntactic features from dotty (e.g. existentials as HKTs, if they really think that's the best way to express type lambdas). Even if that involves making large changes to scalac that will have to be thrown away, the Scala community cannot survive with the syntax the way it is for much longer.

View on HN

Of all the things holding Scala back, frozen syntax is the least of its worries.

My two biggest day-to-day peeves are:

  1) The poor quality of the entire tool chain
  2) Immature libraries and ecosystem

Tool chain: from the slow-as-molasses compiler, to the fact that every so often IDEA gives up and refuses to parse parts of our project, to the horror that is SBT, working with Scala just feels* painful. Heck! - my Macbook Pro sounds like it's taking off whenever I start a Scala compile, and if I'm building from scratch? https://xkcd.com/303/

Libraries and ecosystem: many opensource Scala libraries feel more like experiments in language wrangling or narrow (exposing only a tiny subset of the underlying features) wrappers for existing Java libraries than well-tested code. Documentation? Almost always spotty. Library community? Spotty. Source? Good luck reading it. Depending on the author's bent it can range from vaguely understandable to downright inscrutable. (On this last point: I've often poked around various Java/Python/Go/C libraries and been able to figure out fairly quickly what's going on. Much less so with Scala.)

Besides those two points - Scala is complex. To a newcomer the language is unfriendly and has a lot of rough edges. You have to build a lot of context to interpret existing Scala code - and much of this context is incidental to the problem at hand. This makes it very tough to incrementally learn about Scala features/syntax and slowly explore an existing Scala code base (especially an opensource one, where authors are more likely flexing their advanced Scala knowledge). And all that syntactic sugar? Terse. Elegant. Unintelligible to a newcomer.

Sorry. /rant over.

There are better options on the tooling. Eclipse rather than IDEA, Maven rather than SBT. Not perfect by any means, and the compiler is slow, but good enough to work with day-to-day.

The library ecosystem is growing every day, and the community is starting to recognize the importance of good documentation. See e.g. the Cats project, with a big emphasis on that.

Code readability in general, rough edges, and things that are difficult for newcomers to read incrementally are precisely why I'm so worried about the syntax being frozen.

Is Eclipse (Scala IDE) better than IntelliJ now? About a year ago people convinced me to switch to IntelliJ because Scala IDE was totally unusable, full of spurious compilation errors and useless refactor that introduced random symbols instead of doing its job.

So has the situation been reversed now?

Eclipse still has problems, its refactoring doesn't really work, and the UI locks up every so often, but its compiler is substantially more reliable than IntelliJ's. It's a case of picking your poison really.

Maven is a hug step backwards. SBT has its issues, but maven is god awful. Going forward though on new project, I plan on using Gradle. I find it a lot easier to work with than SBT.

At least you can find documentation on Maven :/ The biggest problem with operator-heavy syntax? Google searches.

What operator syntax?

e.g. :+= and :++= (which are both commonly used in build.sbt files). If you don't know the difference between those it's rather hard to search for.

Nono! Typesafe, I mean Lightbend, declared that random strings of symbols are just method names, so no need to worry about that operator overloading thing! Except methods with ":" in the name tend to work differently wrt. precedence.

(Look, I'm not on a crusade against Typesafe/Lightbend, but they've been hugely disingenous on a lot of things like this. I could have accepted it if they'd just said "yes, it's operator overloading, but better". Instead they chose this ridiculous disingenuous "nono, it's just method names!" approach. In my book, the only people who can get away get arbitrary method/function naming are the LISP/Scheme people. Because in LISP/Scheme there is no precedence to worry about.)

I have never seen them. Do they actually exist?

Most of the time, there is := (set something), += (add something) and ++= (add multiple things). I think that's pretty straight-forward.

Yes, they're very common in build.sbt files. How else would you add library dependencies?

I know exactly what they do; the underlying reasoning is very consistent, maybe even elegant. But if you don't know and need to understand/modify a build.sbt file, it's very tricky to find out.

> How else would you add library dependencies?

Like this?

  libraryDependencies ++= Seq(...)

Ok, so what's the difference between that and

    libraryDependencies :++= Seq(...)

? Because I've definitely seen that in some build.sbt files.

This doesn't exist:

    error: value :++= is not a member of sbt.TaskKey[Seq[sbt.ModuleID]]

I can't disagree more about immature ecosystem. Cats, Scala.js, Shapeless, Akka, reactive streams (Akka Streams, Monix, etc.), Play, Slick and other awesome libs [1] are one of the main reasons why I am using Scala at all. IntelliJ Scala plugin is not perfect, but it understands code much better than, for example, Clion or QtCreator without clang code model, and C++ ecosystem is hardly immature, and of course it's lightyears better than any dynamic language IDE support.

Code complexity though, yeah, it's hard (for me, at least) to grasp ordinary for Scala abstraction-heavy, typeclass-heavy code. I would love to see better code exploration tools for Scala.

[1] https://github.com/lauris/awesome-scala

I learned incrementally. At first I used Scala just for properties. It's 2016, Java8 and we still don't have properties? W--T--F! (unless you count JavaFX).

Over time, I learned slowly to use vals or var, that I don't need to initialize a return value and ship it at the end, and how to build up mapping.

The syntax; I agree with you totally. I just got hired by a company doing Scala and OMG that codebase. I'm seeing all kinds of constructs I haven't used yet.

I still prefer Scala over Java, but there is a high cost to entry.

Cannot survive? That seems really hyperbolic to me. I think the language is in a really good state for the vast majority of users right now.

For me, the language still hits a sweet spot miles ahead of the dynamic languages in its soundness, the old school typed OOP languages in its "functionalness", and the typed functional languages in its approachability and modernity (compared to, say, Haskell). Scala's killer innovation was to find a way to apply sound typing to Ruby-like syntax, and in that, it succeeded quite nicely.

That's not to say the stagnation isn't frustrating or that there aren't great improvements to be made. I think Scala would be greatly improved if Shapeless were expressible with much less hackery. It's a testament to Scala that Shapeless is even possible, but it's still pretty unsatisfactory when it comes to regular people being able to understand such code, let alone debug it when it goes wrong.

But look at Scala through the lens of other languages. It took monumental effort to get to Java 8, Python 3, and ES6. It's unfair to paint the current Scala plateau as some kind of albatross. Especially given that just a few years back, people were complaining about language churn.

The language is in a great state in terms of what's possible, and in terms of the underlying abstractions (partly why Dotty doesn't seem like an urgent requirement to me). It's in a much less state in terms of what those things look like in code. Shapeless is great in terms of what you can do with it, but much less great in terms of what the compiler errors look like when you make a mistake. Contrast with Ceylon where similar functionality was built in from the start.

Python 3 was very much at the front of my mind as I wrote that - I think their "plateau" has killed the language (I hope I'm wrong). People were complaining about language churn, but I wasn't one of them. With Dotty an unknown number of years away and no committed schedule, I simply don't think Scala can afford to freeze for that long.

I think we have very different conceptions of "survive" and "killed". Python certainly seems alive and well to me, if not exactly the hottest thing out there.

I think Python is a dead language walking at this point. It was big enough that momentum will keep it going for a while, but that's more a case of dying slowly than living long.

>In particular, freezing the syntax for as long as the proposed timeframe for Dotty to be delivered would kill any language.

Because Scala doesn't have enough syntax already?

Honestly no. A lot of the complex Scala you see is because Scala doesn't have syntax for something and so you have to put it together out of other things. Type lambdas and Miles Sabin's unboxed union types trick are prime examples of cases where adding some syntax would make a lot of real-world Scala a lot more readable. Likewise ADT case classes where you don't really want the class to be its own type - a little syntax would save a lot of repetitive "smart constructors".

Also there are cases where it's not more syntax that's needed, but different syntax. E.g. the way irrefutable unpacks in for/yields desugar to a (with)filter call is just dumb.

Reply on news.ycombinator.com