The state of the Scala website and documentation | Hacker News Reader

The state of the Scala website and documentation

groups.google.com

133 points0xmohit98 comments

This pull request showed me just how much the Scala community values good documentation: https://github.com/playframework/playframework/pull/6545 – tldr: not much.

I work a lot with Django, and the documentation is amazing. It's up to date, cross-referenced, everything is linked to everything else, code is executable, etc.

Here, rather than a 2 line fix to make the code in the examples executable and explain how some data is being used, the maintainers opt to keep the code examples non-executable, and obfuscate the code, expanding explanations in text to make up for it.

Documentation is important. If someone doesn't understand it, the project should make a sincere attempt to understand why, take on feedback, instead of shutting down discussion and dismissing someones lack of understanding.

> This pull request showed me just how much the Scala community values good documentation: https://github.com/playframework/playframework/pull/6545 – tldr: not much.

Erm... But the change was shitty. How would that make good documentation? The phrase just before said "Here's example JSON", and the JSON got changed to Scala code. How is that indication of appreciation or not of good documentation?

Not to mention the same doc page already showed how to convert JSON into a Scala value earlier.

well if you work a lot with Django than you have the same stuff like that aswell:

> https://docs.djangoproject.com/en/1.10/howto/initial-data/ > https://docs.djangoproject.com/en/1.10/topics/serialization/...

of course you can't just use it directly in Python.

Documentation is about reading, 90% of the stuff is just reading. And there is clearly everything said about the snippet above the snippet: "In the code samples below, we’ll use the following JSON:". Since you already visited the last page, you should've probably already understood how to parse the Json.

I see a lot of issue's on a daily basis and I even give some examples if needed, even if a discussion should take place on a mailing list, however I think before ANY issue should be made, people should carefully read and check if there is even an issue.

But Playframework's documentation is already really good. There are some cases which aren't described so good, but they aren't even well described in Django I guess, what I mean is testing, a lot of this topic is not easy and you probably learn on your way of getting a better developer to get better in it.

I started to contribute to Play! In the middle/start of the year and a lot of people are just helpful (and busy). And I've seen plenty of one character spelling mistakes merged. If something is not strictly understandable we even give a advice to discuss it on the mailing list.

I can't comment about the specific pull request, but the number of contributors is probably a reasonable indicator.

Look at the number of contributors for Scala [0], Go [1], and Rust [2].

[0] https://github.com/scala/scala/

[1] https://github.com/golang/go/

[2] https://github.com/rust-lang/rust/

  >> number of contributors is probably a reasonable indicator

In case you don't want to click on the links:

    Scala: 287
    Go:    704
    Rust: 1599

Scala was my first serious use of a JVM language and I kept hitting little rough patches that people were assumed to understand from a prior Java background. One example: a month or so into my use I started getting a puzzling failure when sbt was trying to download a dependency. Everybody already knows about Java's security certificate handling, Ivy, and Maven, right? I didn't. I kept on Googling the wrong terms because I was searching for Scala and sbt. The problem turned out (IIRC) to be a dependency download attempt that started from a URL whose certificate was trusted and then got 302 redirected to a mirror whose certificate was not yet trusted by Java. The error messages that actually showed up in my console were not at all helpful and I ended up using tcpflow and a Java-savvy colleague to figure out what was actually happening. Would it be so hard for (e.g.) sbt to provide an interactive security prompt for if you want to trust a remote source's security cert, rather than expecting you to figure out the error message and solve it the Java way with plain Java tools? (Maybe it would be hard. Maybe that's why it doesn't do that. I don't know because I didn't use Java before Scala.)

I don't have concrete examples to hand for the other rough spots but I recall hitting other areas of knowledge that are explained via Java instead of standing on their own. "The Scala Bar is like Java's Foo, but with these improvements..." I never learned the Java Foo and I don't really want to have to acquire a working Java developer's knowledge to use Scala. I'm using Scala and not Java. If you're writing docs for Scala and the reader needs to know something important about either Java-the-ecosystem or Java-the-language, please inline that knowledge.

I wouldn't recommend SBT, especially for beginners (Maven is much better documented), but no, it can't give you a prompt because programs don't have access to modify the keystore by design. The JVM is one of the few platforms that actually has a decent go at security, which sometimes means usability suffers.

To use scala effectively, you must use SBT. Almost every scala library and framework is built using it. There are tons of productivity enhancing tools wrapped in plug-ins for it. It is java, scala and scalajs aware, and incrementally compiles large projects if you use it. The documentation for it is good from version 0.12 on. You can learn 90% of what you need to do scala builds in SBT in 4 hours by reading the documentation and the walk-through tutorial. Eventually you may need to write your own tasks, but 90% of those tasks are covered by the existing plug-ins available, and you can easily modify or create a new task by writing some simple scala function on your first day using the tool without having to publish a plug-in to some repo for it to work.

I absolutely would reccommend SBT for beginner scala users. It's a must to use and understand it, as much a part of understanding scala as understanding for comprehensions, case classes, and if/else expressions.

Using SBT with Scala is certainly encouraged, but you can use other build tools. At work we're successfully using gradle without too many problems. The only things that are slightly weird are the not-so-perfect plugins for gradle, but that is understandable considering they are mostly community driven (sometimes only a one person even).

> the not-so-perfect plugins for gradle

Could be because Gradle up to version 2.x provided only Groovy for writing plugins and build scripts. Gradle 3.0 was released a few months ago, and provides both Kotlin and Groovy for plugins and builds, and even prefers Kotlin for writing plugins. Perhaps the "not-so-perfect" situation will change as plugin providers switch over.

I recently looked into Groovy's apparent popularity at #17 on the TIOBE ranking and found Baidu was giving a result 12 times too high and Yahoo a result 20 times too high, both of which would skew the ranking. Groovy's real ranking is somewhere below that of #50 ranked Clojure. These results are being used to promote Groovy as successful to the Apache Software Foundation directorship. I can understand Gradleware wanting to switch to a language with a seemingly more honest approach to promotion.

Libraries and frameworks use SBT because they need to cross-build for multiple scala versions - that isn't something you normally need to do as a "regular" developer. Even post-0.12 the documentation is a lot lot worse than maven's. You can absolutely use Scala effectively without it.

I was hired to work on an existing codebase that used sbt. I had domain knowledge and plenty of general development experience but I hadn't used Java, the JVM, or Scala for production code before. My previous background was C, Fortran, Python, and JavaScript (scientific computing and web dev).

I hope you don't try Clojure then, is much worse there ;)

Joking aside, in Clojure this a feature, one of Clojure's theme is "embrace the host"(leverage java apis).

I don't know Scala but in Clojure you definitely need to become familiar(if you aren't) with Java if you are serious about writing productions apps in it.

Also, abstractions leak.

I've been using Clojure happily for years without needing to dip into Java for anything other than something like parseInt(). Leiningen is a joy to use compared with anything Scala has to offer and Clojure also has its own library repository. When I asked on IRC where to find Scala libraries I was advised to go scavening on Maven Central. Jeez.

> I've been using Clojure happily for years without needing to dip into Java for anything other than something like parseInt()

You needed to dive into Java to figure out something as basic as parseInt?

I said "dip into", not "dive into" and by dip into I meant discovering I needed Java rather than a Clojure function.

I didn't mean to offend you. I don't know Clojure or Java, and was just wondering why you need to look into the internals of Clojure for something as basic as parseInt.

Clojure.core doesn't have a parse integer function. You use Java interop to get one. It's as simple as '(Integer/parseInt "42")'

You can use the built-in read-string too to generically read a string as Clojure data: `(read-string "42")`

The function is simple enough that clojure doesn't make its own wrapper for it, so you wind up doing this:

(.parseInt Integer x)

That may be what he means by dive into Java.

To be fair, package managers and SSL certificate issues are a PITA in pretty much all ecosystems.

On the JVM, even if you stick to pure Java, you still need to figure out where and how the dependency resolver is launched before you can override its settings, which can depend on things like your build tool and IDE. But at least, adding your own certificates to the keystore/truststore is fairly straight-forward.

  We are basically filtering our audience down to people who can
  either invest plenty of time (to wade through the
  documentation/ask for help on the mailing lists and gitter),
  money (to pay for training or attend conferences) or both.

  ..

  I think it wouldn't be charitable to think that the state of
  documentation is a result of the involved parties' massive
  conflict of interest, as Lightbend (has partners that sell
  training), EPFL and ScalaCenter (receive money from commercial
  Coursera courses) all profit from the current situation
  financially.

This hits the nail on the head.

Linus said once that if the only benefit of using C for Linux was excluding C++ programmers, that was enough of a benefit.

Sounds really negative, but to be honest, sometimes if the only benefit of Scala is excluding people that are not comfortable with advanced programming, for a project that requires it, then great. You saved your recruiters the job of looking over a lot of resumes that you didn't want anyways.

Scala is not incredibly hard. I am not gifted and I managed to learn it to an extent in which I could solve practical problems.

That being said, I think learning Scala comes out more naturally when you have some exposure to Java. Since many Scala constructs are really shorthands for longer Java code.

I have to accept though that some people go really hardcore on the functional side (like the typelevel/scalaz folks) and that can be really intimidating.

You're also saving your recruiters the job of looking over a lot of resumes from people who have productive full-time jobs in another language and have limited time to pick up a new language because they're busy delivering business value in their existing language. It's a very high-false-positive strategy.

Very true, geofft. Sometimes you can formulate your job posting like: Scala or Java, with preferred Scala experience. I had issues when trying to recruit for a Scala position, and we expanded the search a little bit to include senior Java programmers too.

> I think learning Scala comes out more naturally when you have some exposure to Java.

My experience at the office is different. I come from Java, but I've seen people who literally never programmed in Java or any other Java-like language succeed with Scala (and then they get horrified when they find out what Java looks like). They have none of the bad habits that come from years of writing Java code. It's enlightening, really. A few years ago this experiment wasn't possible -- of course everyone doing Scala was a Java expat. Not anymore, though!

I couldn't disagree more with you about excluding people. Excluding newcomers is always bad, but also, don't people "comfortable with advanced programming" deserve good documentation? Of course they can and will succeed in the absence of it, but only after wasting valuable time.

Linus' statement is controversial and shouldn't be quoted as gospel. In any case, he argued against C++ programmers because he thinks they -- and their chosen language -- suck, not because of advanced programming or whatever (note: not my opinion!).

(That's why I started saying "I think", to emphasize it's an opinion rather than a fact.)

My personal experience has been that it is easier to explain people Scala when you can explain it in Java construct terms... But I can see how someone coming from, let's say, Swift, can have an easier time writing idiomatic Scala.

I am against excluding people for the sake of excluding people but you need to consider that communities have some core values, and the core values behind the Scala community are different to that of, let's say, PHP. You know what I mean.

I fully agree about the community values, but how is having no good documentation helpful for building said community?

Also, it'd be VERY disappointing if the reason for this lack of documentation was the explanation from the root comment in this thread.

As the Scala team lead at Lightbend, I'm truly saddened to see posts like this. It couldn't be farther from our intentions and interests! We absolutely want outstanding Scala documentation, and would never stand in the way of improving them in any way.

My whole team has worked extremely hard this year to bring you the best 2.12 compiler we can. We also spend as much time as possible helping out with polishing documentation, but we feel a coordinated push for better documentation belongs under the umbrella of the Scala Center (whose mission is to "Independently guide and support the Scala community" and to "Provide deep, and quality, educational materials for Scala"). We'll be thrilled to collaborate, but we (as veteran Scala users) are not the best placed to write getting started guides.

EDIT: It was brought to my attention that my comment about the Scala Center could be misinterpreted. I meant to say I would support a proposal to the Scala Center advisory board about improving Scala's documentation, with a focus on the getting started experience.

Let me give you a 'fer instance' (this may be the only one that exists, but it's one that had me WTFing until I found the correct documentation to read via stack overflow)

Calling grouped on a Seq.

I've been playing around with some API requests, and needed to batch a long Seq to make reasonable sized GET requests.

So I called grouped on a Seq, then to sanity check I called .length on the grouping.

Then suddenly I had an empty iterator.

Maybe I should have known better, yeah, but the documentation I was reading http://www.scala-lang.org/docu/files/collections-api/collect... doesn't mention this fact about iterators. Again, maybe I'm the only person in the world who didn't realise the problem with calling .length on what I thought of as a regular old batched set.

It wasn't until I hit on the right google combination that I found http://www.scala-lang.org/api/current/#scala.collection.Iter... from a stack overflow reference, and the lightbulb finally went on.

Thanks for the example. We agree that this is a tricky part in the collections. For Scala 2.13, our headline feature will be simplifying/refining the collections API. One of the areas we'd like to improve is to make the transitions from eager to lazy more clear. Also, we'd like to keep immutable (more) separate from mutable collections. Once we switch gears from 2.12.0 to 2.13 milestones, we'll be sure to provide a convenient way to share gotchas like this, so we can see how to prevent them.

I think there is some good Scala documentation.

By core values of the Scala community I refer to trying to create idiomatic ways of solving problems, and trying to get the most out of the language. One evidence of this is the amount of domain specific languages created in Scala.

Twitter's Scala school was a good resource for me, the official tutorial by Odersky in Coursera is a good starting point too. You can also watch Scala talks in YouTube, to supplement documentation reading.

Those resources are good. Twitter's Scala school is more relevant as a reference than Odersky's progfun course (if that's what you mean by "official tutorial"), because progfun is more about FP and less about Scala-the-language (this made it even more interesting for me, but also makes it less useful as a reference). Note, however, those resources are external.

I understand what you mean by core values. I don't understand how they are improved by a lack of documentation.

The tour of Scala lost me initially. I used "Another tour of Scala", I found that one to be easier to digest.

I'm not sure that's such a good filter in this case. There are a lot of cool new languages out there, and most people would rather spend their time learning rather than fighting with poor docs. Anybody "comfortable with advanced programming" will also be aware that there are many other languages with better documentation.

Also, I think it attributes the bad documentation complaint to the wrong thing.

Look at the tutorial, for example: http://docs.scala-lang.org/tutorials/tour/tour-of-scala

The intro page just lists a few selling points: OO, functional, static typing and extensible. The second page has no continuity and is about "Unified Types," with a big complicated diagram and a blob of code. No explanation what to do with the code to compile it, run it, load it in a REPL or anything. I need a tutorial just to be familiar enough with Scala to use the tutorial. The entire "tutorial" is like that with no continuity and no connection with anything coming before it.

A person can go to haskell.org, navigate to the documentation, start with the tutorials, and eventually learn the language. That would be nearly impossible using the scala-lang.org page, without a huge amount of pre-existing Java and functional coding experience.

I think the two examples are different because you are suggesting that Java knowledge become a sort of pre-requisite for learning Scala, whereas the Linus' quote mentions C which, AFAIK, doesn't have a pre-requisite-other-language-that-you-have-to-learn-first (if anything, I would suggest new programmers to learn C before moving to higher level languages!).

> (like the typelevel/scalaz folks)

well I was scared about that as well, but than I bought https://www.amazon.de/Learn-You-Haskell-Great-Good/dp/159327... and used cats (XorT,OptionT) and now I don't want to miss those two.

P.S. I am not gifted also and I guess I managed to learn it to an extend, too. Basically I'm always afraid when writing mutable/imperative code now.

Yes. Haskell's Maybe / Scala's Option was a fantastic finding for me. I quickly incorporated that in all of my code, I think it filters out a lot of problems, especially the "billion dollar mistake" (null reference exception).

Interesting to note that the most natural translation of Linus's statement is:

"if the only benefit of using Java was excluding Scala programmers, that was enough of a benefit."

Scala adds multi-paradigm heavily complexified syntax on top of Java.

Scala : Java :: C++ : C

None of this makes any sense to me (except that these unfounded claims are not charitable). Lightbend (my employer) builds our whole platform in Scala, and we are proud to say you'll have the best experience using it from Scala (though Java 8 will do too, if that's more your jam). Sure, we make some money from training, but we are far more interested in having as many people use Scala so that they'll be even more productive using our platform.

My team at Lightbend is responsible the majority of the Scala 2.x compiler and standard library work. That's our focus. We do try to help out on the documentation front over at https://github.com/scala/scala-lang. You can easily see for yourself that 90% of the PRs there get merged.

Don't boo -- submit a PR!

I think the author hit upon some pretty good points. Several years ago when I started poking around Scala I really had to push myself to work with it and especially with respect to simple thigns like do I download SBT or Scala. One of the more personally frustrating things I found as a newbie is that the bulk of the documentation seemed to be written as a reference. Compounding that was the un-googlable nature of some of the operators like ":<" which really made things more difficult than I felt that they needed to be.

Regardless, although it was not what I would describe as a pleasant experience, after working with Scala for a few months I definitely found languages like Haskell a lot easier to comprehend. So, I obviously managed to internalize something. :-D

> Compounding that was the un-googlable nature of some of the operators like ":<"

Ah! souvenirs

"- [..] Oh, but you have to use the epaulette function!

- The what?

- The epaulette! (>>>) it's like the zigouigoui, but you don't have to lift anything. Just flatMap that shit and you're good."

My biggest technical complaint about Scalaz. You can't effectively communicate concepts that involve nameless symbolic constructs, and slang as a replacement is inherently exclusionary.

I see how people might look at how close java & javax are, and think scala & scalaz are equally close. They are not. Scalaz is a completely separate project from the core Scala project.

Scalaz has (or should have) ascii names for every method I believe. If you can find examples otherwise we can fix it.

This reminds me of that short time I've been working with scala... I honestly think Scala is Perl on the JVM. I mean, the write-only unreadable-code part of Perl, but on the JVM.

Can you provide examples? There's a lot to criticize in Scala, but I can't find many examples of symbol soup, especially in user-written code. There is some, sure (most languages suffer from this to a degree), but so many you consider the language write-only? I just don't see it.

Keep in mind Scalaz is not Scala.

Interesting discussion. Thanks for posting.

As I've gotten to learn many different languages (PHP, Ruby, Go, Java, Python, etc) over the last 10 years, it has been really interesting to see how different languages and communities can vary so wildly in their quality of documentation.

As it relates to programming languages, Go's "Tour of Go" (https://tour.golang.org/welcome/1) is an excellent introduction to the language. I wish every language had an intro guide as good.

In terms of frameworks, I absolutely love the Ruby on Rails guides. They strike the right balance between staying high level enough for me to build a mental model of how the framework is working under the hood, while getting deep enough to be useful to solve individual problems I have.

Overall, I think the Ruby community has done a great job of documenting their libraries and frameworks. Whether it's Rails or Sinatra, or it's a library like Devise, Ruby OSS projects seem to tend towards thorough documentation.

On the flip side, Spring's documentation (and most Java library documentation) is absolutely atrocious. Spring in particular only seems to give you 2 flavors of documentation: a 10-minute tutorial, or a 1000-page deep dive in all of the corners of the framework. And Java libraries in general seem to have miserable, out-of-date, incomplete documentation.

> On the flip side, Spring's documentation (and most Java library documentation) is absolutely atrocious. Spring in particular only seems to give you 2 flavors of documentation: a 10-minute tutorial, or a 1000-page deep dive in all of the corners of the framework. And Java libraries in general seem to have miserable, out-of-date, incomplete documentation.

I actually find the opposite with Java libraries. They are generally over documented but are complete. The issue is that many have issues with publishing doc/Javadoc (with github it is slightly non trivial) and thus are outdated. Java projects have also been around a lot longer so some of them use archaic doc formats like docbook (spring).

However the biggest problem with Java documentation is the accessibility of the standard language + javax stuff (ie jdk + jee). IMO Oracle does a piss poor job of this. You have to register and it is either in some messed up help tree format or some PDF that is impossible to download.

On the other hand Apache and Spring I think are far far far more detailed in documentation than your standard PHP, Ruby, Python projects. The documentation may not be as pretty but it is there. I stress that because many languages and libraries lack specifications or review processes (even still) and Java was doing it fairly early (albeit with various corporate agendas).

Since this is all about docs, having gone from Java/Scala to Rust, I cannot emphasize enough how much better Rust is at this. With `cargo doc` I get a local set of static files for the exact version of the libraries I'm using. Why can't everything be this easy?

It is that easy with Java/Scala... if... you are using an IDE.

Eclipse through the maven plugin (m2e) will auto download the source code and will show doc as you code (along with drilling into the code. Intellij does something comparable as well. Racer can do this as well (and I admit far nicer in that it is editor agnostic).

The problem is the tools for Java/Scala are all over the place so developers have different experience with the language that probably have very little to do with the language itself (syntax and libraries) but rather the tools.

I would agree Rust is not the norm and IMO perhaps even the gold standard of what modern language organization and tooling should be.

Java/Scala should probably have better builtin tools (or atleast mutually agreed on tools like auto formatting, editor agnostic completion /refactoring (ala racer), package management (Java is actually decent on this as maven is the standard), etc).

I'm not sure if you are serious? Spring's documentation is some of the best I've ever seen.

I write Scala code professionally, and the language documentation is the worst I've encountered. Luckily, I've leveled-up to the point where I don't need it anymore and can just lookup prototypes and comments directly in the source code when I need it (thing almost everyone is doing after a certain time, btw). I understand the frustration of beginners, and I've even began to host talks/presentations, inside my company, for a few coworkers. I hope to get them past, at least, past the few interesting concepts and the shitload of symbols/operators/random-combinations-of-chars-on-my-keyboard that you encounter on a day-to-day basis.

This is not an excuse for poor documentation, but I've found that not relying on documentation in general vastly improves my productivity. It requires being comfortable digging into the innards of the libraries and frameworks I use, which helps me understand performance characteristics, extension points, understand stack traces, understand failures when they happen, find bugs, learn language idioms, etc.

The website of Scala.js is devoid of some of the problems mentioned. It has an in-browser playground, a getting started guide that uses sbt and follows development conventions, and a useful list of libraries. Maybe Scala can learn a bit from Scala.js?

EDIT: small grammar error

It could be the case that Scala language and docs are really done from perspective of maintainers. When I look at commits this year on github [1], there are about half dozen people making significant contribution and most of them seems to be associated with Lightbend. Other popular languages e.g Java/Rust/Swift/Go have very vibrant commit activity from lots of contributors

https://github.com/scala/scala/graphs/contributors?from=2016...

I am completely unsurprised. I've been pretty negative on Scala in the past, and this is one of those reasons. The community does not feel inclusive and, my perception is that as a beginner you're simply expected to deal with the lack of documentation, the odd behavior of the tools, etc. And that (frankly) makes me fairly uninterested in contributing back to it.

I wonder if it's because many people who stay with Scala are more interested in the many advanced language features it offers, as opposed to building libraries to be used by day-to-day practitioners (who have very different metrics for deciding if a library is worthwhile or not).

I'm not sure what you mean by building libraries to be used 'day-to-day'. If you mean that the Scala community is in general more interested in building libraries/tools used by professionals than hobbyists I'd agree, but I can't think of any popular libraries that aren't used day to day by all of the developers on our very very large scala team.

Out of curiosity, which libraries does your team use?

Scalaz, Scalaz-Stream and http4s constantly. Doobie, Spray, Shapeless, Monocle, and others less often but still definitely more than rarely.

Scala's poor documentation stems from a much more fundamental problem - the absence of a Clojars/Rubygems/PyPI for Scala libraries. It's in the process of being fixed now, I believe, but why did it take so long? The Clojure community has a much lower profile in industry than Scala yet right from the beginning they really valued their community and produced an excellent repository for Clojure libraries and an easy-to-use build tool - Leiningen. The Scala community, by contrast, comes across to outsiders as just not that interested in community. Maybe it's the Java legacy.

Personally this is interesting to see after I just recently tried to learn a little Scala to see if I could realize the promise of a fluid front-end to to back-end experience between Scala and Scala.js. I eventually gave up in defeat because the documentation and tools just didn't make for a smooth enough jumpstart for me. Maybe people coming from Java just already have enough prerequisite knowledge to get past that but for me I just wasn't progressing very fast. I had a much easier time progressing in Elixir/Phoenix and Elm recently and to a lesser extent F#. Just my two cents...

Elixir shines by how easy it makes it to write good documentation.

The Markdown-renderd docstrings for modules and functions can be converted into nice websites[1] or are available in the command line[2].

[1] http://elixir-lang.org/docs/stable/elixir/Enum.html#map/2

[2] https://i.imgur.com/RhS283f.png

Yeah, there is quite a bit of project management and juggling needed to set up a ScalaJVM/Scala.js shared project. Maybe this would help you? https://www.scala-js.org/libraries/skeletons.html

Excellent. I can now point to this for a good objective reason to not use Scala.

Actually, I'm really sad. I used Scala back in 2005 (Edit: Corrected from 2001?) (God, I'm old) for it's Actors model to do peer-to-peer networking protocols. It was SOOOOOO much better than C/C++ and I could deploy stuff without installation across multiple architectures.

I'm especially sad because it seems like Scala always needed just a little more sustained effort on the community front to move into the big time and it never really got it.

Scala came out in early 2004, Scala 2.0 in 2006 and I'm not sure about actors but probably not before 2007.

In 2001 Martin's lab was probably working on Pizza / Java generics :)

You are quite correct, I just looked at one of the domains I registered for that and the date was 2005.

As for actors, I was definitely using alpha level stuff. So, your dates jibe with that.

Apparently I'm getting old enough that my memory is getting faulty. :)

Now, if I could only figure out how to do strikethrough for edits...

I wouldn't be that sad. Bad docs may be a good objective reason not to use Scala, but there may well be even better objective reasons to use it, like doing data science with Spark, or even building resilient fault-tolerant systems with Akka. The final calculation will, as always, rest with each potential user.

I remembered another thing that Java users already know but surprised me in Scala in a bad way: null. I read a lot about Scala's type system in the week between I was hired to write Scala and when I actually started writing code. Most of it was about how great Scala's type system was and how much safety it provided; the company even called itself Typesafe then. I read many paeans to the virtues of Scala's type system that would turn runtime errors into compile time errors, but they didn't highlight that it can't prevent that most common and annoying of Java runtime errors, the NullPointerException. Due to a lack of prominent mentions in the Scala docs and tutorials I read, I thought that Scala authors either didn't have to think about Java's Billion Dollar Mistake or that the compiler would guide them to safety before the code could blow up at runtime.

Maybe manually dealing with nulls is supposed to just be assumed by anyone using the JVM... But I'd used Jython a little in the past and I didn't have to explicitly deal with null-checking then. Jython converts null to None. In the absence of prominent warnings to the contrary I had thought that Scala would provide at least as much automatic safety as Python-on-JVM does.

The correct way to handle this in Scala is to wrap the possibly-null reference (which I assume you're getting as a return value from some Java library) in Option(), not manually checking for null.

By "manually checking" I mean that I have to use my own brainpower to notice places where null can leak in to code I'm writing; the compiler doesn't actually enforce the type safety I thought I had. I do use Option to handle sometimes-nulls after I notice them.

EDIT: since Jython doesn't allow raw nulls to leak in from Java libraries, and Kotlin prevents accidental use of nullable values at compile time, it naively seems like Scala could prevent accidental null introduction despite living on the JVM. Or as a distant second-best, prominently warn about the perils of null whenever introducing its type system to beginners.

Aren't Jython `None` values essentially `null`s? But, Kotlin, Swift, and others are starting to get it right. Scala will follow suit--the plan is for 'Dotty', the next major version of the Scala compiler, to represent nullable types explicitly as `A | Null` (`A` or `Null`). Without that explicit type there will be no way for a type to hold `null`.

Until that happens, in Scala we continue to work through in the presence of potential nulls by wrapping stuff that comes from Java APIs in `Option`s and never explicitly returning `null` from any Scala APIs.

I really wanted to pursue Scala. It looked promising: runs on the JVM, is far saner than Java, has features that keep the "Java 1.4 was the last real Java" crowd away, has a mixed-paradigm OO/FP approach, lots of features... things like all the FUD over compile times and performance didn't really bother me (if I cared about resource usage/performance, I wouldn't use the JVM, duh).

I found two classes of problems.

The first was the lack of practical guides. How do I access a database? Should I use a Java lib for that? What about a rudimentary CRUD app? What if i need something Java-EE-ish, like a message queue/IPC? I kept finding myself in scenarios where I had to reach out to Java, which I was deliberately trying to migrate away from.

Second, there's the fact that Scala has full OO along with the ML-style FP, which makes it hard to figure out if I was doing things the "right" way. Do i use traits and composition and case classes? Should methods go on classes? What's up with the Object pattern? Do I store state on classes or should I prefer case class/record types? When is it a judgment call... and if it is a judgment call... how do I make it without much experience in the language or having any experienced Scala users to guide me?

I'm not averse to spending $100 on books and working through them. I tried that with Scala, but somewhere around page 200 of Programming Scala, gave up.

Then there's the scare factor, there are so many "we're switching from Scala to Java 8" or "we already use Grails" that it was looking like it was turning into a dead end professionally very quickly, especially outside of DC/NY/SF/Chicago. One job I was looking at told me they were moving all their Scala work into Java because of client pressure.

The bigger irony being that I started using OCaml instead, a language where the documentation is usually just an interface file and type signatures.

Scala documentation is a bit hard to understand, some articles do not have a good balance in their level of detail... e.g: documentation for Futures and Promises. I use text-to-speech to read it since it can be a bit dense.

Scala.js is great, but it is different (numeric primitives, threads, to start with).

I dove deep into Scala a short while back and I can concur with those that thought the documentation was sub-par almost all around, from Scala-Lang site itself, to big things like Play Framework to across small userland libraries. The saddest thing was that I wanted to improve those docs, but I didn't know how. When I finally got to the point through tedious trial and error, I couldn't even remember where to start. It doesn't help that there's 10 ways in Scala to do everything, but no way to find out which is the best one, or the worst, or one that even just works with your current version. Surely this the tone of this post is quite whiny, but it really did make Scala hard as hell to approach.

I find this incredibly sad. Plenty great products/languages have died because of poor documentation, poor respect for beginners.

Yet... here the Scala community is... repeating the past and justifying with the same reasons.

I personally only spend time learning a new language when:

1. I can get employed because I know it. (example: python)

2. It is easy to pick up and learn. (example: arduino )

3. It solves a problem I must solve ( perl/bash scripting )

Scala doesn't meet any of the above criteria.

There are a lot of Scala jobs. And they usually pay much better than Python jobs. Not discussing your 2 other points since they are pretty subjective.

If you can program Java you can program Scala. You can't write good Scala code, but that (hopefully) comes with time. Scala solves the same problems Java does, just better. And there are lots of jobs for Scala. Not as many as there are for Java or Python, but maybe as many as for Ruby? I'm not sure exactly.

> If you can program Java you can program Scala.

Clojure would probably be my choice nowadays rather than Scala.

Clojure has a great community and is a good counter example to the Lisper's whining that the syntax is what keeps people away.

If I truly needed Actor stuff for performance, I'm probably going leave the JVM and reach for Erlang anyway.

Clojure is great, but the more natural progression is from Java to Scala, not to Clojure, if only because you can program in Scala as if it were Java++. You won't write the best Scala, but it will work and you can look at it as "Java with weird syntax".

Going from Java to Clojure requires a major mental shift :)

That depends a lot on the background of each developer.

My introduction to FP was via Caml Light, SML and Lisp, so either Scala or Clojure are approachable to me.

I don't use any professionally, as our customers only do standard Java and C# projects, but among the programming languages I dabble when travelling, I tend to play more with Clojure than Scala.

Sure, but it goes without saying that Caml/SML/Lisp -> Clojure is more straightforward. This is Java to Scala, which is relatively painless and doesn't require a major mental shift early on (though of course you'll need it eventually). Any Lisp variant does require a mental shift, unless of course you already knew a Lisp! Which, in my experience, is not the case with most Java programmers.

Depends where people learned Java I guess.

Since I have always worked in companies where you don't get through HR without a degree in computing related areas, I always ended up working with Java developers that do know multiple programming languages.

But I guess it is indeed a problem for those that are self taught.

> Clojure is great, but the more natural progression is from Java to Scala, not to Clojure, if only because you can program in Scala as if it were Java++.

The problem is that I can program Java as Java++.

Java 1.8 still has its warts, but are they worth the shift to Scala? Maybe? But it would really have to be a compelling reason.

For example, people still often don't know about java.util.concurrent. 99% of their concurrency problems could be solved simply by grabbing the correct data structure out of there.

If they can't be bother to know something as easy as that, what real hope do I have of them really using Scala well?

> Java 1.8 still has its warts, but are they worth the shift to Scala?

Oh, yes. Few who've had to deal with both a Java 8 and a Scala codebase are going to tell you otherwise. Java 8 is like Scala through blurred glass.

Another thing is that Java 8 is Java++ only now, after many of us have already adopted Scala. In other words, "too little, too late" :)

Regardless, are we discussing whether it's good idea to adopt Scala coming from Java (I think it is!) or whether the transition from Java to Scala is easy? I thought it was the latter, and if so, it's unarguably easier than the transition from Java to Clojure. Scala "looks like" Java in a way Clojure doesn't.

> Regardless, are we discussing whether it's good idea to adopt Scala coming from Java (I think it is!) or whether the transition from Java to Scala is easy? I thought it was the latter, and if so, it's unarguably easier than the transition from Java to Clojure. Scala "looks like" Java in a way Clojure doesn't.

A bit of both. How's that for a hedge? :)

Admittedly, I'm coming back into Java with 1.8+ and don't have a legacy codebase to deal with. So, my calculation as to whether Scala is worth the cost is quite skewed from someone who has been doing it since Java 1.4.

Is it easier to transition from Java to Scala than to Clojure? Maybe. But the people who can make the Scala transition also seem to be the same people who can make the Clojure transition.

And, I think that's the core problem for Scala. The features that make Scala compelling aren't a nice, slow, logical evolution from Java.

>If I truly needed Actor stuff for performance, I'm probably going leave the JVM and reach for Erlang anyway.

Erlang has a kind of narrow use case though. It's pretty much only useful if you really need the low-latency high-availability actor model. It's amazing for that but not for much else. Elixir fixes some of the warts, though. Scala is a truly versatile language, being able to replace Python, Java and Erlang, and inheriting most of the strengths of those.

Btw, Scala has all of the major concurrency primitives (STM, futures, actors, mutex etc.) and doesn't dictate you use any of those.

... except that Scala devs have made the learning curve steep.

Lots of jobs for Scala? I'm not sure about that. Scala is a bit like Rails, at least here in the UK, where about 80% of the available jobs are in London. Step outside the capital and it's almost non-existent. Search Indeed.co.uk by job title and you'll find Java:Scala is 5:1 in London and 24:1 in the rest of the UK.

Java:Scala job ratios in other countries are even worse:

USA 29:1, Netherlands 19:1, Canada 33:1, Germany 46:1, France: 93:1, India 113:1, China 1639:1,

So I think it's fair to say that, with the exception of the London financial sector, Scala hasn't really made a difference to the dominance of Java in industry.

I think those jobs are concentrated in the financial sector and in big-data processing (almost completely due to Spark).

How about the speed of the compiler? Last I used Scala, that was the deal breaker for me.

That's interesting. Just a few days ago with great regret I decided to drop the (free) Scala course on Coursera after almost finishing week #3 (of 5 I think). I'm actually already pretty familiar at least with the essentials of functional programming but would like to go even deeper.

However, I found the step too steep between the easy to understand lectures and the exercises, and the latter not as useful as they could be. It felt like I was suddenly dropped off and left to my own devices with no guidance. "Now implement this!" Uhm... what? Sure, that's easy, I've been implementing much more complicated things for decades. The problem is I have no idea how to approach it "the right way" as far as Scala is concerned, that's why I'm taking the course!

Looking at the forum - extremely sparsely populated even after over 4 months - showed that I could also expect no guidance from there. That meant that even when I finished a task I was unable to find out if what I had done was the right (functional) way. For one and most importantly, there is hardly anyone to respond, but also since the only exercises are the homework assignments you can't just post your code, that's an "honor code violation". There also is no "solution", i.e. you can't see how the course author(s) would have implemented it.

Another example, people in the forum complained about extreme differences in performance for very minor differences in the way you wrote something, and you had to find all of this out completely for yourself, again no guidance at all.

Another point is that I found the problems too academic. Sure, I can walk a list of head.tail or a tree of left.element.right tuples. But overall the problems were all from what I did a long time ago at university and it felt very, very far from what I deal with now - and I don't just do CRUD or other boring stuff and actually do have interesting algorithms to implement. The course feels like being made for university students - in a negative way.

Overall I found the course more frustration than it was worth. I could have solved the programming challenges easily enough in a way I already knew, but what's the point? I wanted to learn the new (Scala) way, but felt all alone in trying to do that.

The course was like a good violin player demonstrating a piece and then giving me some sheet music and shoving me out the door "come back when you can play that". It's hard to complain about "free", but if course forum participation is a guide, both total numbers as well as the steep drop-off after week 1 and 2, it isn't very successful.

The course: https://www.coursera.org/learn/progfun1

Note: Enrolling in the courses individually is possible for free, going through the "specialization" page at https://www.coursera.org/specializations/scala only shows the for-pay option.

I actually liked the progfun1 course, which I took a few years ago. It's one of the cleanest courses I've taken on Coursera. It's true that it's slightly "academic", but that's what many introductions to functional programming often feel like.

However, the follow-up courses, Reactive Programming (retired) and Functional Program Design, are a total let down. They are a rip-off, especially if you paid for them: a complete mess, no relation between lectures and assignments, no introduction of new concepts in relation to a greater context, the slides are not proof-read, constant mentions to non-existent slides and lectures, repeat material from previous courses (a side-effect of the courses being mash-ups of previous material), and example code that doesn't type-check or compile. It's not any single mistake, but the aggregation of them all, and the feeling that the authors just don't care enough. Thankfully I didn't pay for this.

In my opinion, the gold standard for Coursera is Dan Grossman's excellent Programming Languages, which I fully recommend.

I share the exact same story. Progfun is a really smooth introdu tion to FP in my opinion, no crazy syntax and only the core concepts. For any deeper concepts and if you don't understand what FP really means you should check out a purely functional language.

Just to clarify my opinion on progfun: The lectures are good.

The coding tasks could have been okay - if there was any guidance. I don't even get to see any sample solutions. So even if I make it work, I don't know if that is a good way to do it, the "functional", the "Scala way". And the performance issue I mentioned, it was a major one, the difference between the code even being usable for more than a thousand elements in the list or getting a stack overflow, and the difference was extremely minor, in one case the order in which you called "union" on sets. All of that had to be found out by the students, and even after they found out nobody really had a good idea or explanation for why it was so.

Also, there only was one (small!) opportunity to actually practice what you just learned per week - and that came without any feedback apart from "works/doesn't". Since the course was about a particular programming style that really wasn't enough.

Have to say, I loved Dan Grossman's work teaching SML. Quite a few of those lecture videos had lightbulb moments for me.

A production is only as good as it's training and docs.

I would go a step further: 'Training and Docs ARE the Product'.

Having bad docs is like selling a car without wheels -> It's not a car :), rather, not a thing that 'solves the problem of getting people from point A to point B'.

My experience with Scala has generally led me to concur with the overall assessment that Scala information and communication is pretty weak.

Hope they can improve it, it's a pretty cool language.

Reply on news.ycombinator.com