
Dotty: a next generation compiler for Scala - tycondryus
http://dotty.epfl.ch/
======
walkingolof
Looking forward to this, its a bold step to start from "scratch", but in
return the Scala community will get a compiler that have solid theoretical
foundation, better performance and more utility for development tools.

Scala's Road Ahead - by Martin Odersky
[https://www.youtube.com/watch?v=_2oGY8l67jk](https://www.youtube.com/watch?v=_2oGY8l67jk)

------
joneholland
We are a big scala shop at Expedia and it's concerning that Martin is more
interested in Dotty.

Scala 2.12 is late, and not having easy java8 interoperability is becoming
more and more of an issue.

I love the language but it is becoming harder to recommend it for new things
due to the ambiguous roadmap.

~~~
hocuspocus
I fail to see how this is concerning. Scala isn't a one-man project. Martin is
a university professor, i.e. someone supposed to work on education and
academic research. It's already pretty remarkable that so many students and
researchers at LAMP/EPFL (funded by Swiss taxpayers) are working on real-world
projects, that you can use in production at your commercial company.

~~~
oelang
One small correction, they're funded by the Swiss taxpayers and the European
union.

~~~
douchey
well no, this is not the case. ( I have a Ms in CS at EPFL)

~~~
oelang
[http://www.scala-lang.org/old/node/8579](http://www.scala-
lang.org/old/node/8579)

------
salex89
Not directly related, but: do the world a favor and build a new SBT! This <<=
one += is a bit -> """strange""" .

~~~
evacchi
Strongly agree. SBT really is puzzling and (IMO) overcomplicated. Someone is
working on an experimental alternative called CBT which is pure Scala (as in:
less DSL like syntax)

~~~
imtringued
I'm not even sure why the acronym stands for simple build tool.

~~~
evacchi
I think they refitted the acronym into "Scala Build Tool" a few years ago

~~~
agumonkey
What was the original meaning then ? sluggish bloat transducer ?

~~~
choward
Sucks big time

------
youjiuzhifeng
There are many evolutions for Scala. Here is a compiler to compile scala code
to native: [https://github.com/scala-native/scala-
native](https://github.com/scala-native/scala-native)

~~~
johncolanduoni
Wow, this looks like exactly what I've been looking for. What is the interop
story as far as Java/existing Scala code?

~~~
hepta
Interop with Java seems unlikely unless they keep a JVM tucked away somewhere.

~~~
johncolanduoni
Now that I look at it, they essentially do, it's just that they implement it
from a more Scala-centric point of view (e.g. implementing traits directly
instead of being layered on top of a Java variant). It seems like it shouldn't
be too hard to compile JVM bytecode to run on the same runtime.

------
jondot
When I read this, I can't think of anything else but Scala fatigue. As a CTO
migrating a company from .NET to the JVM, I found there's already a mess of
conforming to a subset of Scala within real (and more importantly - ordinary)
teams.

What subset of Scala? what libraries? what build system? apparently if things
worked well, there would be at just one true - and well respected - answer for
these.

So now I ask, honestly, why not go with Kotlin
([https://kotlinlang.org/](https://kotlinlang.org/))? a language that IMHO
didn't try to rule the world from day one (a Good Thing), but scores high on
aesthetics, abstraction, power, IDE, compilation speed, and Java integration.

I have been following (and playing with) Scala since a bit before the Yammer
thing exploded, I've been following Odersky as a student listening to the
OOPSLA podcasts, and I never got to convince myself Scala is worth it. Can
someone convince me to still use Scala when Kotlin is around?

~~~
polskibus
Can you share the reasons for migration?

~~~
jondot
We bought a company, and that company had a technology that was based on the
JVM. We were on .NET.

The domain dictated that we needed a 'heavy lifting' framework like .NET or
the JVM.

We did also work with Ruby, nodejs, and Go for certain microservices.

So now, decision making time:

\- Do you reimplement in .NET ? \- Do you live with both .NET and JVM bases?
\- Do you migrate existing systems from .NET to Java?

The .NET system was aging in any case, people needed a fresh breath of air,
and it was nice to get rid of all of the Microsoft licensing and closed
garden. It is then when I decided the new-gen stack would be Java8 and Kotlin,
side-by-side. Kotlin was (and still is) amazing.

~~~
romanovcode
>all of the Microsoft licensing and closed garden

You mean the horrors of MIT[0] license?

[0] -
[https://github.com/Microsoft/dotnet/blob/master/LICENSE](https://github.com/Microsoft/dotnet/blob/master/LICENSE)

------
dschiptsov
Simplification instead of piling up, clarifying and redoing right, as
understanding grows, instead of adding extensions (like crippled lambdas to
Java) and reduction to closest approximation to the [unattainable] optimum
(smallest possible, well balanced set of mutually complementing each other
features, like in R5RS) in general - is the right way.

I hope Swift will eventually stop piling up features and will try to get back
to the right fundamentals too.)

~~~
jpliska
Have you all seen Kotlin?

~~~
premium-concern
Yes, it's like they reinvent all the things that were considered but discarded
in Scala and believe they found something nobody ever thought about before.

~~~
partisan
I am not sure that Kotlin competes with Scala in any way. They are trying to
remove the pain from Java by providing a concise and safe language (see the
quotes from their website below). What are "all the things" they reinvented
that were discard in Scala?

> Kotlin is a pragmatic programming language for JVM and Android that combines
> OO and functional features and is focused on interoperability, safety,
> clarity and tooling support.

> Being a general-purpose language, Kotlin works everywhere where Java works:
> server-side applications, mobile applications (Android), desktop
> applications.

~~~
premium-concern
> What are "all the things" they reinvented that were discard in Scala?

Extension methods, properties, special syntax for everything, final by
default, short constructor syntax, trying to put band-aid around Java's broken
collection types, ...

~~~
didip
I'd love to learn more about Java's broken collection types. What's broken
about them?

~~~
premium-concern
The pattern of throwing exceptions for operations deemed "unsupported", an API
that requires massive workarounds to keep alive in Java 10, no support for
immutable collections, unmodifiable views are a complete clusterfuck, no
persistent collections etc.

------
smegel
> Is it the future Scala? Yes, it will be - eventually.

I thought, that's a big claim -- then saw who is working on it.

~~~
nrinaudo
It also means that the main designer of the Scala language is not working on
Scala but on a language that will "eventually" become the future of Scala,
which means that, right now, dotty is _not_ the future of Scala.

A lot of very smart people seem to be very excited about that, I can't help
but find it ominous.

~~~
sandisk5
> It also means that the main designer of the Scala language is not working on
> Scala

No, it means that person is not working _only_ on Scala, or rather the current
implementation of Scala. People can work on multiple projects over the course
of a year/years.

> on a language that will "eventually" become the future of Scala

You changed "Is it the future Scala? Yes, it will be - eventually" (I think
can best be reworded "eventually be the future Scala") to "eventually become
the future of Scala." To me, those have different connotations. The former
means that it's not finished yet, but when it is it will be the base of Scala
at that time. The latter implies, to me, that at some time in the future this
will be the base of Scala at some time further in the future.

> which means that, right now, dotty is not the future of Scala

And here's where that different meaning leads you wrong. dotty is the future
_of_ Scala right now, but it's not that future Scala yet.

> A lot of very smart people seem to be very excited about that, I can't help
> but find it ominous.

People are generally happy to have to the creator of something they like
working on its future.

Scala is being maintained. Improvements and releases are being made in the
meantime. More than one person can work on Scala, and a single person can work
on multiple aspects of Scala. Big changes like dotty are being carefully
planned and executed at the same time other changes are made. People are
excited that Scala is continuing to evolve and becoming a better language, and
that a beloved innovator/creator is playing a significant role in that.

~~~
nrinaudo
Right, yes, I read "the future of Scala" but that isn't what it said at all.
My mistake entirely, you're absolutely correct.

On the other hand, I stand by my "not working on Scala" comment. This is based
on commit history, which I admit might not give the whole picture but is
certainly a fairly strong indication:
[https://github.com/scala/scala/graphs/contributors](https://github.com/scala/scala/graphs/contributors)
Odersky's activity has drastically diminished towards the end of 2012, with
his last Scala commit in July, 2014.

I've no issue with him doing exactly what he wishes, he owes the community (or
at least, _me_ ) absolutely nothing and if he's more excited to work on Dotty
than on Scala, then there is no doubt that's what he should be doing. My
concern is that the more I look at Dotty, the more it looks like a very
promising language that looks a _lot_ like Scala, but that adds and removes
some features to it - that is to say, not actually Scala. I've no trouble
imagining a future where the differences grow enough that they stay / become
entirely distinct, and seeing a large chunk of the brains behind Scala busy on
Dotty doesn't feel me with confidence in the former's future.

~~~
edko
I really do not see the problem with this. Odersky oversees a team of very
capable people he trusts to work on the current Scala version, while he works
on the future. He is the father of Scala, but please do not underestimate the
brilliant people that are actively working on Scala now, allowing him to
develop the bleeding edge.

~~~
nrinaudo
You're misreading my comment. What bothers me is not that the "father of
Scala" is working on the future of Scala, but that he's working on something
that I fear might become another language altogether.

I'm not saying Scala is in bad hands or a dead language. But when a project's
creator looses interest and moves to different things, well, it's usually not
the best sign for that project. And again, I'm not saying that this is
happening right now, or even that it necessarily will, just that Dotty
definitely has the potential of leading to that situation.

~~~
premium-concern
> I'm not saying Scala is in bad hands or a dead language. But when a
> project's creator looses interest and moves to different things, well, it's
> usually not the best sign for that project.

"looses interest" ... "moves to different things" ... WTF? How can people come
up with this FUD?

Scala2 and Dotty are two dialects of the same language, just as ScalaJS and
Scala Native are dialects of the language.

Keep calm and carry on.

------
phischu
The linked page links to a set of slides:
[http://www.slideshare.net/Odersky/compilers-are-
databases](http://www.slideshare.net/Odersky/compilers-are-databases)

I have a question regarding slides 29 to 31.

The author says an untyped tree is represented as Tree[Nothing]. This leads to
undesired variance behavior which is in turn overriden.

But there cannot be any instances of type Tree[Nothing] because there are no
instances of type Nothing. Wouldn't an untyped tree be better represented as
Tree[Unit]?

~~~
modersky
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 }
    

if t is a Tree[Nothing] then t.elem will not return normally (it might throw
an exception instead).

~~~
wereHamster
Ok, so there are instances, which throw exceptions, fine, we're in Java land
after all, where anything can happen. But why is Tree[Nothing] more useful
than Tree[Unit]? Both contain the same amount of information (both Nothing and
Unit convey zero bits of information), but one throws an exception while the
other is safe at runtime.

~~~
duhace
Tree[Nothing] is a subtype of all Tree[_] types. This is similar to Nil in
scala, which is really a singleton implementation of List[Nothing] or None,
which is a singleton implementation of Option[Nothing]. Unit does not have
this property, it is just a subtype of AnyVal/Any.

Basically, Tree[Nothing] allows you to indicate that a Tree is empty via the
type system while still allowing you to use that same type to build an actual
tree from. If Nil was List[Unit] instead of List[Nothing], 1 :: Nil would be a
compile time error instead of a List[Int].

Oh, and Unit does have an implementation in scala called "()", so if you had a
Tree[Unit] you would not be able to tell if it was actually empty or not. You
can see this in scala with () :: Nil. It produces a non-empty List[Unit].
Nothing has no such implementation. As for the exceptions, there's not much
you can do wrt that. What should happen if you call head on an empty List?
That's a straight-out error. headOption or a match block is the safe way to
deal with lists if you don't want to have exceptions ever.

------
insulanian
What's the chance for this to become a new Python 3 story?

~~~
premium-concern
Zero. People are actively aware of what happened in Python 2/3.

The good thing is that Scala is a typed language, so they can

a) provide tooling for migrating code

b) compile things and get clear information about how much differences there
are

I think somebody said that necessary lines of change from Scala 2 -> Scala 3
should be below 0.1% to be acceptable.

~~~
enlait
Oh you. Our codebase uses scala xml and macros; migration will be a major
PITA.

~~~
eugene_burmako
Author of Scala macros here. Here's a recent discussion on the future of
macros in the brave new world of Dotty:
[https://www.reddit.com/r/scala/comments/4our5m/keynote_scala...](https://www.reddit.com/r/scala/comments/4our5m/keynote_scalas_road_ahead_by_martin_odersky/d4gd439).

------
troels
That's going to cause some confusion ...
[http://www.graphviz.org/](http://www.graphviz.org/)

~~~
cranium
DOT is just the name of the calculus used to prove the core of the language
(and Dotty the name of the new compiler). It won't appear often in the
literature meant for the general public so I don't think there will be much
confusion.

------
HypeInference
"@adriaanm our plan for Scala is to declare JIRA bankruptcy and run for the
githubs. Maybe take the top half of the open issues with us."

[https://twitter.com/adriaanm/status/571073842434547712](https://twitter.com/adriaanm/status/571073842434547712)

------
jakozaur
Previous discussion:
[https://news.ycombinator.com/item?id=10482585](https://news.ycombinator.com/item?id=10482585)

------
cryptos
Can't help, but I don't like these click a button to scroll down to relevant
content presentations. That is the new style of the doomed splash screens.

------
malcolmgreaves
Does anyone know if structural typing is not coming to dotty without the need
for runtime reflection?

------
oconnor0
What is the relationship between Dotty and Scala Native?

------
codecamper
looking forward to seeing (reading about) how fast it is.

~~~
jinst8gmi
According to Odersky's recent talk [1, 2] it's about twice as fast as the
current Scala compiler and should still improve significantly.

[1]
[https://www.youtube.com/watch?v=_2oGY8l67jk](https://www.youtube.com/watch?v=_2oGY8l67jk)

[2] [http://www.slideshare.net/Odersky/scala-days-
nyc-2016](http://www.slideshare.net/Odersky/scala-days-nyc-2016) (slide 21)

~~~
wereHamster
> I think we can do better than Monads to achieve this.

(slide 52)

Looking forward to their solution.

~~~
Blaisorblade0
For anybody curious, I think he's hinting at modern effect systems, on which
there's lots of research these days. He advised for instance Lukas Rytz PhD
thesis at EPFL (and Lukas Rytz is still working on Scala, now at Lightbend).

------
monocasa
Is this enough to run chisel?

------
agounaris
I build a tool, for the tool, which is a better tool of the tool to create
bytecode. Seriously adding up stack in order to solve complexity, actually
creates more complexity.

~~~
bad_user
I don't really understand your point. Is that a truism? Is it related to the
freaking article? Also, have you built a tool or was that sarcasm?

~~~
Blaisorblade0
Assuming I get him correctly, that's bad sarcasm. I'd recommend instead this
joke on JavaScript toolchain: [http://cube-drone.com/comics/c/relentless-
persistence](http://cube-drone.com/comics/c/relentless-persistence)

Compilers are huge beasts, but good ones are worthwhile, and Dotty is a better
Scala compiler, so this criticism seems misdirected.

