Comment by allengeorge | Hacker News Reader

Comment by allengeorge | Hacker News Reader

Parent Full thread

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.

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.

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

Reply on news.ycombinator.com