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.
I've gotten the impression over the years that this compiler rewrite and simplification was a necessary step to ensure the long term success and viability of Scala. I think it's great that they've made so much progress with so little disruption to the Scala roadmap.
Why is Java 8 interop becoming an issue? Scala 2.12 does leverage the new bytecodes and some of the new stdlib, but in general Java 8 compat from https://github.com/scala/scala-java8-compat is usually enough from the programmer's perspective. Also, if it's lib support (as opposed to lambda support), you suffer the same things you would if you were using guava functors or something before, sometimes compat layers have to be written. If it's bytecode support, I suppose I don't understand the biggest pain points from the perspective of the programmer.
It's becoming easier for me to recommend it due to the slow moving roadmap. So are you going to tell people to stay away from the JVM for its ambiguous roadmap (openjdk projects being delayed, etc)?
Hi, Scala Team Lead at Lightbend here! We are working hard on getting 2.12 out. Almost ready!
While the theme for 2.12 is easily summarized (Java 8), I assure you the changes behind the scenes go all the way to the core. Compiling lambdas and traits to the best
Java 8 bytecode we can think of, unifying type checking of Single Abstract Method
types and Scala's built-in function types, as well as rewriting the whole optimizer
and byte code emitter was no small feat! It's been very satisfying to rework these
parts of the compiler, and I'm excited to see 2.12 going live soon!
We're cutting the last milestone (M5) this week, with RC1 scheduled for the
second half of July -- assuming M5 is well received. We're pretty confident,
as we build over 1MLoC of OSS Scala every night using dbuild (see scala/community-builds on github).
We at Lightbend care deeply about language stability and compiler robustness,
as we believe they are key for driving Scala adoption by the community and the enterprise alike.
Being PL researchers, we are also excited about simplifying and evolving Scala!
This is why we're working on a smooth & steady migration path towards the ideas
being incubated in Dotty.
Scala's process is a dialogue, which means coordinating with Martin Odersky
and his teams at EPFL and the Scala Center, as well as the whole Scala Community.
Ultimately, we at Lightbend set the Scala 2.x roadmap based on this consensus (since 2.10),
and take on OSS development and maintenance (as well as commercial support for our customers).
With the founding of the Scala Center, we're happy to share governance, while
remaining as committed to the day-to-day engineering and representation of the
pragmatic robustness and careful evolution voice :-)
This dialogue comes naturally to us, as half of our team are alumni from Martin's lab
(Lukas & I have been working on the Scala compiler for almost 10 years,
ranging from adding support for type constructor polymorphism in Scala 2.5,
rewriting the pattern matcher in 2.10, implementing named & default arguments,
while working on the theoretical foundation of an effect system for Scala
as well as the core of Dotty), while the other half are long-time contributors
to all aspects of Scala.
Sure, releases sometimes slip a bit -- we are a small team
(we're a small company -- our team size is no outlier), and while we get to
spend the vast majority of our time working on OSS, we also have some commercial
obligations inside the company (e.g., Scala support tickets are handled by us).
The other reason is that we have worked on 2.11 for 6 months longer than we
usually spend on a major release, because we wanted our Java 6 users to get
as many of the 2.12 features as possible on their platform (2.12 requires Java 8),
as well as providing a preview of the new ASM-based back-end and optimizer.
The Scala team at Lightbend takes care of half of all PRs, with the other half
being contributed by our awesome community (including EPFL, though they mostly
focus on their research and Dotty, which is how things are supposed to be).
We've worked hard on making it easier to contribute to Scala, and I'm very glad
to see the rate of community contributions trending up!
The Scala and Dotty teams talk regularly (we just had a Dotty & Scala summit before Scala Days),
to exchange tips on compiler performance as well as to work towards convergence
for Scala 2.x and Dotty. For example, the 2.12 trait and lambda encodings were
tried first in Dotty, with our real world adoption of these ideas feeding back
into the Dotty compiler. For 2.13, we're planning feature flags to implement the
first wave of Dotty features and restrictions (and vice versa for Dotty emulating Scala 2),
so that you can start migrating your code bases. For some more background, here
are our roadmap updates: http://www.scala-lang.org/news/2016-schedule/,
http://www.scala-lang.org/news/roadmap-next/, http://www.scala-lang.org/news/2.12-roadmap/.
I'd love to turn off write-access to JIRA and move to GitHub for new tickets. We'll get there, but first need to finish this release everyone's waiting for :-)
This doesn't concern me. If anything does, it is that Tyrpesafe, in becoming Lightbend, is not going to be as focused on the needs of the Scala community, despite reassurances to the contrary.
The they have added two additional people to the Scala team over the last few months. Everyone knows they suck at communicating, but I rather care about actions, and the actions I have seen are good.
Wrong, there's more Scala than Java in Lagom's implementation, as is easily verified on the link you provided yourself. See my comment above on some more info on the Scala team.
Different projects require different approaches. The introduction of the community process added 5 new maintainers and the merge of Slick and FreeSlick caused a lot of activity and contributions, so I'm pretty happy.
> Are you saying two new compiler engineers were hired by Lightbend?
I agree with the other commenters that there are plenty of people working on Scala (and arguably odersky is a much better researcher than he is a maintainer) that I wouldn't worry about people maintaining/upgrading Scala.
I do think 2.12 (and 2.11 before it) either had unrealistically optimistic deadlines or suffer from poor project management. 2.12 has slipped by well over a year at this point, which is sad for frameworks like Spark which are going to stick to 2.11 for their next MV cycle.
Expedia uses scala now? That's crazy. I worked there about 5 years ago and I'd never have thought of Expedia as the kind of company to play around with Scala. We were in the middle of a Java migration at the time.
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.
After learning sbt I've found it to be one of my favorite build tools out there. The fact that the build.sbt file is basically just a dialect of Scala allows for some very complex build jobs to be done easily.
Also the simplifications coming with sbt 1.0 like removing the Build.scala and dropping support for multiple build.sbt files makes it a bit cleaner in my mind at least. Before everything was spread around in multiple files (and possible 2 different build definition styles with the .sbt and .scala files) instead now everything is in pretty much one single file with a clean enough syntax for anyone to learn. (as someone said you only really need to know :=, += and +== of which the latter 2 function the same as they do in the standard lib for collections)
edit: Sorry was wrong about the multiple build.sbt support. Its still in but working with a single build.sbt has been made easier over the 0.13.x versions and we reverted all of our multi project builds into that and I just assumed it was being dropped (We also had a lot of Build.scala stuff so I guess i got mixed)
Do you have a link for dropping support for multiple build.sbt files? I can find a reference to it and I'll have to adjust my project if that is the case
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)
Hi there. I am that "someone". CBT is coming along very nicely. It is growing into a nice little community. We are working on getting the last bugs out and establishing the basic range of important plugins right now https://github.com/cvogt/cbt/
I recently wrote an sbt plugin. And I found that sbt became much easier after learning the core concepts.
The book 'Sbt in Action' explains it very well and also contains a great comparison of build tools; what they historically brought to the table.
I shouldn't have to read a book in order to understand a "simple" build tool. And I'm for damn sure not paying for it. Make something overly complex and sells a book for it. Great business model!!!
Like many things, there's a trade-off between up-front learning cost to gain expressiveness and usefulness later, and lower up-front cost at the expense of explicit verbosity later.
These days, you only need to use 3 of those operators: := for assignment, += for adding one item, and ++= for adding multiple. := is a bit weird since you can't override `=`, but the other two are exactly the same as you'd use with the standard collections library.
It's not only about the operators. The whole tools is not really straightforward. A great part of the time I just copy some magical strings into the build.sbt and sometimes it actually works. I tried learning it with understanding, believe me.
Just use Maven. It will be the lowest maintenance cost over time for your project. Nothing else matters, it's a frickin build system -- get it working and move on.
I disagree. I migrated a multi-project build from Maven to SBT. From thousands of lines of XML to 50 or less in SBT. So much redundancy was removed, and the project is much easier to maintain now because of it. SBT has a learning curve, yes, but once you get there I believe the maintenance cost is actually lower than with Maven, at least for more complicated projects.
I completely disagree that SBT or any non declarative build system is that much superior long term over Maven.
Maven is not a really like any of the other build systems. I would say most build systems are glorified Make. Maven is not.
SBT, Gradle, and even old school Ant seem far less verbose than Maven but Maven really shines when you have hundreds of projects in an organization. You can get extreme consistency.
You don't have to have everything checked in one gigantic source tree which makes open sourcing projects subsets of your code base easier. Yeah Gradle and SBT can sort of do this but not nearly as decoupled as Maven does it (generally with Gradle and SBT you have to do some path magic).
Just about every PL and editor can readily edit Maven pom files. That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent.
This is the complete opposite with build systems where basically the build system is turing complete scripting language. Projects have major drift and you loose lots of consistency.
> That means with out loosing comments or spaces you can have scripts go and rewrite hundreds of pom files or even just do a sanity check to make sure that they are consistent.
> build systems where basically the build system is turing complete scripting language
Not only that, but virtually no-one uses this Turing-Complete facility. In Gradle at least, I never see if- and for-statements. By using dynamically-typed Groovy in Gradle, you not only lose the ability for massive rewrites, but often also don't get any of the TC benefits. Perhaps it's different using statically-typed Scala in SBT, or Kotlin in Gradle 3.
Yeah, the hilarious part of scala hyperpartisans (and i like scala) insisting that SBT is great is when you point out that Maven is declarative and SBT is imperative.. in other words the exact opposite of scala dogma.
It's a good way to differentiate football-team partisanship from actual principles (not that any principle applies 100% of the time).
Maven is an archaic, verbose nightmare compared to SBT. SBT can be annoyingly esoteric at times, but even for the simplest thing like "add these JARs and compile," SBT wins over Maven, no question.
actually, the latter is far more readable without markup making my eyes bleed.
I generally prefer gradle's method of 'com.foocorp:foo:1.2' but that isn't acceptable statically. scala string interpolators could make it a thing, though.
To be fair you'd only be using one or the other, `%%` for jvm-only, and `%%%` for cross platform jvm/js builds.
Far and away the biggest blocker to learning sbt is the shaky IDE support for the build project. Apparently that's coming up next in 1.0; will be nice to click through to source from sbt build files and instantly grok what X symbol means. Have wasted a lot of time over the years slogging through documentation...
If you stick to defining dependencies maven works perfectly. If you encapsulate whatever other crap you want to do as proper maven plugins maven works perfectly. It's the people who decide they absolutely need to output to a different folder on Tuesdays but can't be bothered to write a proper tested plugin for doing that who get themselves in trouble.
If this is ever going to happen I feel like some level of SBT plugin compatibility may be a good call. I really dislike SBT, but a lot of the plugins are top-notch (sbt-android and sbt-android-protify are two great examples).
I agree. As a casual Scala developer I feel like SBT has always been a disaster. Does anyone know why Gradle isn't more popular for Scala development? I've had generally very positive experiences using it with Java.
IIRC you can replace SBT with more Java-like tools like Maven (if you prefer xml) or Gradle (if you prefer... Actually iirc gradle is ambiguous about language these days).
In my experience, to some degree. If you are using Play, for example, the Gradle plugin is currently held on Play 2.3. Play 2.4 is experimental, 2.5 is nowhere to be seen.
A subset of the Java standard library will be reimplemented, so most Scala code that only relies on that subset will just work. Java libraries and Scala code relying on Java dependencies will not work. This is similar to the current state of Scala.js.
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.
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/)? 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?
> Can someone convince me to still use Scala when Kotlin is around?
I probably can't, but several things about Kotlin have annoyed me. The main thing, coming from Scala, is lack of library-based Option as opposed to compiler null-checking enforcement. Sure Kotlin talks about the lack of overhead compared to an Option instance (or Optional in the Java 8 case) but the fact that I have to use imperative tools (if/else, etc) to do some of the functional things I might want to do (flatMap, treat as single-element collection, etc) drives me nuts.
Also, for the longest time I couldn't even have a sealed data class hierarchy (i.e. ADTs) but I think that is being remedied. I have also run into bugs where their insistence on limited operator overloads causes ambiguity with overload resolution [0]. I could go on and on having written both a lot (but less Kotlin lately) but not sure this is the best forum for comparing. I might not convince you that Kotlin's downsides compared to Scala outweigh its upsides, but we can't pretend downsides don't exist.
> apparently if things worked well, there would be at just one true - and well respected - answer for these.
Since when has that ever been true of any language where it wasn't dictated from above as a requirement, or people weren't funneled through norms and making alternate methods at a minimum hard (e.g. python)?
Expecting there to be one true and respected answer is to assume that you're either entering the ecosystem at a point where things are temporarily stable, or the ecosystem is stagnant, or someone has developed perfection and no advances can be made. CS and technologies and tooling hasn't stopped advancing, so I'm not sure why you would expect any particular language to have, or see that as a good thing.
I'm on one of the larger Scala teams in the U.S and have used it for quite a few years. In short, Scala is a much more powerful and expressive language (than Kotlin) that let's you write very functional code.
Most on our team would consider programming in Kotlin a huge regression, as it's not really geared for functional programming.
Here's a previous post where I talk about the pros and cons:
Kotlin spends a lot of time promising things and talking about things they plan to ship – and then never ship it.
Scala devs are honest, tell you exactly what's planned and then ship it. Tooling is great, the library system is amazing, and people get things done.
If you are happy with Java, keep using it (or try Kotlin – which is nothing more than a slightly less verbose Java). If you want a better language–use Scala.
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.
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]?
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.
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.
You will most likely get a chance of upgrading your macros into scala.meta before dotty comes out.
Also xml support as the scala-xml library will continue. Though as the xml literals are removed you have to use string interpolation (xml"<your><xml/>here</your>") which isn't as nice to use. (hopefully someone comes up with a nice DSL or something instead)
Unlike Scala, you can't figure out what Python code means correctly and statically — you have little idea what will be called by a function without running the code up to that point, so it's hard to do semantics-preserving refactorings.
But Python changed Strings to use Unicode, and that's something everybody uses and that is insanely hard to refactor automatically even with types.
For Dotty, instead, there are some hard-to-refactor-for changes, but they're in really advanced Scala things, so I expect they'll affect fewer users — mostly the kind of users who can write shapeless-like stuff.
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.
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.
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).
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.)
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.
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.
> 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, ...
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.
"Android Studio should currently not be used for development with sbt and Scala. Chances are, however, that it's a good fit for a Gradle + Scala setup."
Using InteliJ instead of Android Studio means not being able to use the latest tooling even from the stable version, as InteliJ is always some versions behind.
Using Gradle + Scala implies a few configuration steps that tend to break at each new Android Studio release, versus the out of the box experience from Kotlin.
I would do more things in Ceylon if it wasn't plagued by performance problems. So far the only way I've found is to avoid any of the few libraries written in Ceylon and just use Java libraries but if you're going to do that then Kotlin's interop is far more appealing.
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.
> 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.
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
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.
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.
Scala 2.12 would be taking a lot longer and delivering a lot less than Scala 2.11 even if it were on schedule (which it isn't, and there's been no official comment on what the new schedule is). I think the focus of 2.12 is entirely wrong (for my use cases it brings no new features to the table, and since it drops Android support, it's actually a regression compared to 2.11), and I think important features (better syntax for type lambdas, a way to express sum types without extraneous subtypes) are being delayed for too long if they're being delayed until Dotty.
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.
> 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.
If the language requires a single specific person to be involved so it can move forward, that they are choosing to spend their time on something you deem not the best way to advance the language, then that's actually the lesser of a few problems. Is the bus number of this project really one? If not, then it doesn't really matter what he chooses to spend his time on.
My english is obviously not as fluent as I thought it was. None of this was meant to be implied by my comments. I have no opinion on what the best way to advance Scala might be, nor am I even qualified to hold such an opinion. I have no idea whether Odersky's continued involvement with the language is needed or even desirable. I've no concept how much work is being done on Scala - none whatsoever? more than I could possibly imagine? probably somewhere in the middle.
What I said, and mean as my opinion and not an absolute truth, is that a non-insignificant chunk of the brains that used to work on Scala now seems to be busy on Dotty, and that the resulting work, amazing though it may be, might not make it back to Scala.
I have nothing to back this opinion up. Everybody involved with Dotty seems absolutely committed to it being the future Scala, and I've no reason to believe they're not in earnest. But I can't take the switch for granted until it's happened.
Thanks. I'll give this a thorough read - I think it deserves more than the cursory read I can afford to give it right now - and appreciate the time investment this no doubt represents.
The first is that the linked post answers a lot of points, but not the ones I made. It makes Dotty sounds really exciting, which it is. It makes it sound as if everybody working on Dotty believes it to be the future of Scala, and I believe that to be true, too. What it does not do (that I could see) is give reassurance that Dotty and Scala will not drift appart and become two similar but incompatible languages. I felt it'd be rude to point this out, since there really is no way to provide such guarantees (just like there really is no way for me to back up my worries with anything concrete).
The second part is, I'm not casting doubts, but expressing worries. I'm not saying it will happen, I fear it might. I'm sorry if this offends - I really am, my goal is not to insult anyone or demean anyone's work. I have no hidden agenda, and I'm not trying to be one of these anti-Scala trolls that sometime crop up. I love Scala. Look at my github profile, most of my public work is in Scala, and some of my libraries represent a lot of work (which obviously does not mean they're actually any good). I really, really hope everything works out the way people mean it to - as I said, Dotty sounds really exciting. I've seen too many "let's rewrite this from scratch and then make it backward compatible, it'll be amazing" projects to be able to believe it blindly, though.
We share your concern. As I said in my comment above -- the Scala and Dotty teams actively work together (we have our roots in the same research group at EPFL) to make sure Scala 2.x evolves towards Dotty and Dotty evolves towards Scala 2.x. Scala 2.12 and 2.13 will have language flags that unlock features being incubated in Dotty that we can already implement, and the Dotty compiler already has a Scala 2 compatibility mode.
We take continuity very seriously. No one wants a Python 3-style transition. In addition to the desire to avoid this, we also have a type system and a community build (think Google Blaze for Scala) that builds > 1MLoC OSS Scala code.
Thanks for taking the time to share this. I was aware of the community build - I believe it was discussed in some depths on Scalawags a while ago? - and find it to be an amazing initiative. Can't think of a better way to minimise the issues that Dotty might cause, and I'm in awe of the amount of work it must represent.
What I fear in that moment down the line where one feature goes over the arbitrary threshold you set yourself for community breakage, but is just too great to pass up on. Since the threshold is arbitrary anyway, it's fine to adjust it a bit... and a bit more later...
Not saying it will happen, and it would be dishonest of me not to say that I don't think you could possibly do more than you're already doing to prevent this kind of issue.
Scala 2.12, the next version that's currently at milestone 4, is going to be a huge release, having a new backend, optimizations, Java 8 interop, improvements for the type system, refactorings, basically the real deal.
But Scala needs to be production quality and stable enough for real work TM. Like when they were pushing experiments in Scala, people were complaining that Scala breaks too often.
Apparently now people are afraid that the experiments have moved to Dotty. You can't please everybody.
My fear is that the feature sets diverge enough that we get two very similar but distinct languages and a split community.
I'm not afraid that the experiments have moved to Dotty. That's an ideal scenario, if successful ones are indeed ported to Scala. I'm just not convinced they will be.
Absolutely. I'm saying I fear reality and theory might diverge and we find ourselves with a split language / community. I highly doubt anybody set out to write Python 3 thinking "it'll mess with the community for years to come, muhahaha".
Without getting too philosophical, I don't see what's so ominous about the present not being the future or vice versa. All we have is the present, really.
Myself, retronym & lrytz are on the Scala team at Lightbend. I'm proud of what we've accomplished with 2.10, 2.11 (8 minor releases!) and 2.12 (RC1 coming soon -- see my comment above), and excited about what the future holds for Scala! We work together closely with Martin's Dotty team, exchanging ideas about compiler performance and convergence of language features in Scala 2 and Dotty (the incubator for the future of Scala).
If you feel my comments were dismissive of your work, or your team's work, then I owe you an apology. You're right to be proud of what you've done, it's quite a list of achievements and I can only hope I ever produce work of that quality.
Aside from very much needed java 8 support in 2.12, Scala, IMO, has little need for more bells and whistles. Making a sound and coherent foundation instead would be much appreciated.
Which is what Dotty is attempting to do, but hopefully with minimal codebase breakage.
There's a tradeoff between breakage and improvement, but I'd like not to wait 10 years before I can use dotty (like python 2 to python 3). We can always have another dotty in 5 years time for another round of rationalisation/simplification.
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.
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.