modersky

Here's the current state: https://github.com/lampepfl/dotty/pull/4229

It has to do with what kind of dependencies the incremental compiler wrapper (e.g. zinc) can extract from the baseline compiler (e.g nsc or dotc). The Scala 3 compiler dotc handles that itself, which has the potential to achieve better accuracy. But I am not sure how much it matters in practice. We'll find out.

We will check first whether they can be expressed as a macro (the macro roadmap for Scala 3 is still evolving).

It's currently about as fast as Scala 2.12, which means it compiles at roughly 3000 lines/sec. However, it supports more aggressive incremental compilation than Scala 2 so at least in my projects, which are typically 50K to 100K lines, most compiles are under a second, and I rarely see compile times over 5 seconds.

There's ongoing performance work to make both Scala 2 and Scala 3 faster than they are now. A lot of what people perceive as slow compile times are actually other factors (such as inefficient macros or slow build tools).

The shared library we are talking about is the upcoming 2.13 library, which has the new collections design. We currently link against the 2.12 library but will switch to 2.13 once that comes out.

There can be instances of Tree[Nothing], just like there can be instances of List[Nothing]. It just means that in a scenario like this:

    class Tree[T] { def elem: T }

I disagree. Value classes are a great tool in my arsenal, and not just for extension methods.

Different languages have different design tradeoffs. I had many profitable exchanges with Andrey Breslav and other Kotlin designers. We can have a technical discussion about the design choices without getting into a fight about who is more competent.

Have to step in here :-). In fact I bet that Scala has fewer features than Kotlin. In retrospect I now think Scala could have had fewer features, and hope we can get to a state where we can remove some of the redundant ones. But that's because (1) hindsight is always easy and (2) I am at heart a minimalist. Almost all programming languages have too many features to my taste.

Yes, Tree[Top] would have been another way to model this. I wanted Tree[Nothing] to make clear that getting the type of an untyped Tree gives a Nothing, i.e. a run-time error. Getting a Top is not quite the same, but it is almost as good, since only a view things can be done with type Any in Scala.

EDIT: There's one thing I did not stress in the talk and that makes Nothing a more attractive choice than Top: We want to do copy on write on these trees. I.e. if we transform an untyped tree to a typed one using "withType", we want to be able to reuse the untyped tree and just set the type (unless somebody else had already added another type). If the tree is of type Tree[Nothing], we can do that safely, even if there are still shared references to the same node as an untyped Tree. Getting the type of the shared untyped tree will give a Nothing, and nothing can be done with it. But if the type would be a Top, we would be able to apply some operations on it, so the copy on write would be unsafe.

It's much older than that. See

https://en.wikipedia.org/wiki/Futures_and_promises

The distinction between futures and promises in the wikipedia article matches Scala's terminology exactly.

You realize that the sender of this post (a) has been banned from all Scala mailing lists (b) has become one of the strongest Scala haters since?

People who actually use Scala love it. For instance, Scala is one of the most loved languages in the recent StackOverflow developer survey. The survey had more than 26'000 respondents, so this is pretty significant.

http://stackoverflow.com/research/developer-survey-2015#tech...

But you are completely right that there's also a lot of negative sentiment around it. Here are two possible reasons I can think of (I am sure there are others).

1. Scala does not form part of an established programming language tribe. It is neither a better Java nor a Haskell on the JVM. So people are challenged in their assumptions; they don't know what it is, and react negatively in order not to have to learn more.

2. Scala is pretty successful. So people in neighbouring language communities sometimes feel frustrated that a seemingly (to them) inferior language gets traction and their perfect language gets less. I saw some of that when Java eclipsed Smalltalk in the 90's. I never met a community as spiteful of Java as the Smalltalk one.

We have data to contradict this argument: Over 400'000 people have enrolled in an online Scala course with a success rate twice the industry average. "Almost vertical learning curve?" Please!

I think you got that wrong by a factor of 10. I get between 500 and 1000 lines / sec on my laptop. It depends on the code style. The more straightforward the code the faster the compile. Still with incremental compilation it means I wait rarely more than a couple of seconds.

The one line per minute was observed when trying to compile a query over an HList backed record with more than 300 columns. The problem was a polynomial increase of the size of the implicit search tree. This is due to the way implicits are used in shapeless HList library. Slick has a different approach which is much faster, but slightly less general.

The gist is that once you have [edit: recursive] typeclasses or implicits your search can become arbitrarily large and slow. There's nothing that can be done about it by the compiler except arbitrarily pruning the search tree. Or otherwise put, you should factor in implicit search complexity when designing your libraries.

I think the Twitter school is pretty up-to-date. Scala-by-Example is older. There are also a large number of good books teaching Scala. I believe it's worth investing in one or two. And, there's my Coursera course, if you want a more rigorous introduction not just to Scala but to functional programming in general.

Class types are generative. That's why p.V != q.V.

There is a lot of interest in research on the benefits of static vs dynamic typing. But unfortunately there is not a lot of hard data. There were some experiments, e.g.

    http://dl.acm.org/citation.cfm?id=2047861 

The Scala community is, and always has been, quite heterogenous. There's a vocal, and sometimes quite abrasive group of fundamentalists on HN and Twitter. But the Scala community is much more diverse than what you would hear from them.

I completely agree. We'll try to make the boundary between old and new versions as flexible as possible and both lint tools and language imports will be an important part of that.

Note also that the rewritings we consider are in their majority rather trivial. E.g. insert a ": Unit = " every time you used procedure syntax, or wrap every XML literal in xml"""...""".

The one thing that scares me a bit is experimental features. These will not port cleanly, and my advice right now would be: If you want your code to survive transitions without major rewrites, don't use experimental features. They might be tempting, but they can well be a trap down the line.

Well, then maybe the beginners do it right? You have not argued against my two points: It's much slower, and less clear.

I think that's a pretty extreme position. First, it will run a lot slower than the pattern matching alternative:

    optional match {
      case Some(x) => whatever(x)
      case None    => fallback
    }

What complicated things were aded 2.10 that do not require the -experimental flag to be set? Experimental means what the name implies. An experimental feature can disappear or change in the next release. It's there to experiment with but generally not to use in production code.

Just to avoid any misunderstandings: The linked page is a (very nicely done) joke. These are not Scala operators, but (by now retired) operators of a particular third party library for Http dispatch.

Just wanted to say that I think union and intersection types are very interesting and powerful. Also agreed on the fact that Tuple22 and friends are not ideal. We are looking for ways to avoid that in a future version of Scala. I am certainly very interested in what you and the Ceylon community do in terms of language design and hope we can learn from each other.

It is open source. I am sure the committers would be happy to get additional help.

Your timing could not have been better. There's a reactive programming course going on Coursera right now. Tomorrow we will start the part that introduces Akka. You can still enroll in the class.

https://www.coursera.org/course/reactive

Scala inherits essentially all its expression syntax from Java, including the string +. This was done because a lot of other things in Scala are new, so we did not want to rock the boat too much with changes that might seem arbitrary. That said, I believe string + is probably the most criticized feature in Scala's expression syntax. People are generally moving away from it, towards String interpolation, which is available from Scala 2.10.

Macros were not done at Typesafe, but by Eugene Burmako, who's a grad student at EPFL. Grad students do new stuff, and they publish about it, IDE improvements are typically not their piece of cake (Typesafe does have a very capable team working on IDEs).

As you imply, macros are labelled experimental, which means that you have to enable them explicitly. Having experimental features is Scala's way of reconciling a vibrant open source community with the stability needed for enterprise use. Needless to say, we do not recommend use of experimental features in enterprises. They are good for playing around with interesting new concepts and sometimes they do lead to something which is a win, such as the beautiful async/await library that will ship in 2.11.