"Lightbend" as a name is I think the least interesting part of this announcement.
So, Typesafe pivots away from being the company behind Scala to being the company behind the "Reactive Platform (tm)".
I didn't understand the motivation at first--they announced they were going to do this a while ago--but this sentence sums it up:
> ... with more than half of our customers representing traditional Java enterprises. We continue to evolve, becoming more language agnostic ...
I can understand this. While I always liked the Typesafe brand because of it tech connotation and implicit relation to Scala, if you want to diversify outside of the Scala box, you'll have to change the name.
As a Scala fan, however, it's hard to not see this as a blow to the community. Having Typesafe behind Scala was one of the major advantages of choosing Scala, and IMHO the primary reason Scala adoption spread wider and faster that Clojure, Haskell et. al.
I was hoping the JVM community would coalesce around one post-java language and I was hoping it was Scala. But now add Kotlin to the mix of Groovy and Clojure, and the future gets murkier. Especially with the mind-share and great communities around Rust and Go.
This is probably a good thing for Typesafe/Lightbend, however. The Scala ecosystem had been tough to monetize. Putting their full weight behind commercial offerings on top of FOSS foundations seems like a better business strategy.
> I was hoping the JVM community would coalesce around one post-java language and I was hoping it was Scala. But now add Kotlin to the mix of Groovy and Clojure, and the future gets murkier
Those languages you mention each have vastly different use cases:
Scala = statically-typed replacement for Java, backed by Typesafe/Lightbend, an FP/OO hybrid by adding functional programming to the JVM
Kotlin = statically-typed replacement for Java, backed by Jetbrains, delivered via its popular IntelliJ product
Groovy = dynamically-typed addition to Java 7 and before, failed attempt to shift into static typing, no longer backed by any business, and no IDE plugin being maintained. Only used like bash for the JVM, and Gradle build files
Clojure = dynamically-typed addition to Java (all versions), backed by Cognitect, expanded to other platforms (e.g. ClojureScript, ClojureCLR)
Rust could be the future, but I just don't see it for Kotlin. Scala's not perfect, but moving to Kotlin leaves a lot on the table. It reminds me of Swift in the way that it left out a lot of Scala at the outset, but appears to be slowly growing Scala-like functionality. At some point, I'm like, maybe life would be better if people just used Scala or languages that attempt to build on its techniques, rather than scale them back.
Hmm, Rust and Kotlin are targeting very different markets. I can't forsee Rust ever taking over much (if any) of the market that Java/Kotlin/Scala are going after, the cost/benefit tradeoffs are just too different.
JetBrains' strategy with Kotlin is pretty simple - take the best bits of Scala whilst not allowing anything to compromise toolchain quality or seamless Java interop. The goal being commercial success rather than research papers. It's basically a spin on the same recipe that made Java itself a success in the early days. Which is why I anticipate they'll be quite successful with it.
From what I understand, Kotlin will be gaining more features slowly but steadily, similar to what you describe for Swift. I think that Kotlin's ability to integrate seamlessly into any Java codebase (at least in theory) is one of the strongest things it has going for it. Plus being backed up by Jetbrains, with very strong focus on providing a top notch IDE experience.
How would you distinguish Kotlin's and Scala's Java integration? I only use Scala, but don't use it within a larger Java codebase, but my understanding is that this is pretty straightforward.
You should be able to drop in a Kotlin file into any Java project, and mix and match as you choose, without having to restructure the entire project, and move to a different build system.
You still need to build it with a Kotlin compiler though, right? Assuming you install the Scala compiler directly, rather than relying on SBT, you can do the same.
I tested it out a bit, it seems that first, the Kotlin files get compiled with the Kotlin compiler jars; after that the Java files get compiled with javac.
Given how long it took relative to the original announcement that a name change would take place (more than a year ago IIRC), I thought the idea had been shelved, apparently not.
Guess it doesn't really matter what the name of the company is, so Lightbend, Streamy, Scalewhale, etc. all make sense. The logo though, really? Looks like a 3rd place winner from the local kindergarten arts and crafts contest.
Anyway, wrt to Scala, Lightbend's focus seems to have shifted at least in part to enterprise Java, which by necessity means less resources for Scala development. Probably explains the delay in the Scala 2.12 release: the core developers are too busy serving 2 masters (Lightbend clients and the compiler).
Well, moving forward Scala's surthrival depends on the community and continued popularity of libraries, not so much the company behind the language. Fortunately EPFL provides an ongoing stream of R & D to help bridge the gap created by Lightbend's semi-pivot.
Firstly, as the letter notes, the majority of people using TypeSafe/LightBend's services are in fact "traditional" Java shops. This suggests that - in the enterprise at least - there's limited Scala penetration.
Secondly, the move to a more generic name (LightBend) is one more step away from their core competency. The name TypeSafe was chosen to highlight a particular aspect of the platform they felt was important. Although they likely still do, their customers don't appear to appreciate it (or at least in the same way it was meant, as an advert for Scala).
Finally the bifurcation of technical resources between ongoing Scala development and Dotty as a research project are likely to come up short in both regards. We are on the cusp of Java 9 being released within the year and Scala's big backwards incompatible step forwards with Java 8 still hasn't happened.
At the least you'd have to be a gambling person with a penchant for long odds to continue with Scala at this point.
I'm a python fan, but for something mission critical where there was the slightest chance I had to refactor, there's no way I'd use an untyped language when I could use a strongly typed one.
> At the least you'd have to be a gambling person with a penchant for long odds to continue with Scala at this point.
I attended a (non-scala) meetup recently and got talking to a guy who does consulting in the Scala world. He'd been to a major conference in the past few weeks and reported that the vibe there was exceedingly bleak, with lots of negativity over the future of the Scala project.
I don't remember which conference exactly, but I do remember the gist of the complaints. In no particular order:
- tooling (such as sbt) is still poor, even after years of complaints and calls to fix it.
- no real roadmap for improvements to scala itself in the near future
- Dotty being a diversion for the core team, detracting from scala
Now, I only dabble in Scala, so I couldn't really comment on any of these, but I did get the impression that there's a lot of un-happiness amongst core users of Scala. (See also allengeorge's comments elsewhere in this thread)
The crazy thing is that all of those points are blatantly false.
- There has never been more activity in tooling as in the last half year. There are whole tooling conferences with almost 200 people attending. Tooling has been improved steadily, and people made huge progress on all fronts (ScalaIDE, IntelliJ, Ensime, SBT). Things have improved vastly.
- Dotty is not developed by the core team. The people working on Dotty are additional resources put into Scala, and they are helping scalac development because they share design approaches and bug fixes with the Scala team.
On one side, I support Odersky's decision to focus on Scala's simple and modular next version, Dotty (the present one became a Flying Spaghetti Monster, without the flying part). But as for now, Scala is effectively dead.
As a huge Scala fan, I fear that Dotty will suck the oxygen away. In particular, freezing the syntax for as long as the proposed timeframe for Dotty to be delivered would kill any language.
I would urge typesa^H^Hlightbend to bring forward the introduction of vital syntactic features from dotty (e.g. existentials as HKTs, if they really think that's the best way to express type lambdas). Even if that involves making large changes to scalac that will have to be thrown away, the Scala community cannot survive with the syntax the way it is for much longer.
Of all the things holding Scala back, frozen syntax is the least of its worries.
My two biggest day-to-day peeves are:
1) The poor quality of the entire tool chain
2) Immature libraries and ecosystem
Tool chain: from the slow-as-molasses compiler, to the fact that every so often IDEA gives up and refuses to parse parts of our project, to the horror that is SBT, working with Scala just feels* painful. Heck! - my Macbook Pro sounds like it's taking off whenever I start a Scala compile, and if I'm building from scratch? https://xkcd.com/303/
Libraries and ecosystem: many opensource Scala libraries feel more like experiments in language wrangling or narrow (exposing only a tiny subset of the underlying features) wrappers for existing Java libraries than well-tested code. Documentation? Almost always spotty. Library community? Spotty. Source? Good luck reading it. Depending on the author's bent it can range from vaguely understandable to downright inscrutable. (On this last point: I've often poked around various Java/Python/Go/C libraries and been able to figure out fairly quickly what's going on. Much less so with Scala.)
Besides those two points - Scala is complex. To a newcomer the language is unfriendly and has a lot of rough edges. You have to build a lot of context to interpret existing Scala code - and much of this context is incidental to the problem at hand. This makes it very tough to incrementally learn about Scala features/syntax and slowly explore an existing Scala code base (especially an opensource one, where authors are more likely flexing their advanced Scala knowledge). And all that syntactic sugar? Terse. Elegant. Unintelligible to a newcomer.
I can't disagree more about immature ecosystem. Cats, Scala.js, Shapeless, Akka, reactive streams (Akka Streams, Monix, etc.), Play, Slick and other awesome libs [1] are one of the main reasons why I am using Scala at all. IntelliJ Scala plugin is not perfect, but it understands code much better than, for example, Clion or QtCreator without clang code model, and C++ ecosystem is hardly immature, and of course it's lightyears better than any dynamic language IDE support.
Code complexity though, yeah, it's hard (for me, at least) to grasp ordinary for Scala abstraction-heavy, typeclass-heavy code. I would love to see better code exploration tools for Scala.
I learned incrementally. At first I used Scala just for properties. It's 2016, Java8 and we still don't have properties? W--T--F! (unless you count JavaFX).
Over time, I learned slowly to use vals or var, that I don't need to initialize a return value and ship it at the end, and how to build up mapping.
The syntax; I agree with you totally. I just got hired by a company doing Scala and OMG that codebase. I'm seeing all kinds of constructs I haven't used yet.
I still prefer Scala over Java, but there is a high cost to entry.
There are better options on the tooling. Eclipse rather than IDEA, Maven rather than SBT. Not perfect by any means, and the compiler is slow, but good enough to work with day-to-day.
The library ecosystem is growing every day, and the community is starting to recognize the importance of good documentation. See e.g. the Cats project, with a big emphasis on that.
Code readability in general, rough edges, and things that are difficult for newcomers to read incrementally are precisely why I'm so worried about the syntax being frozen.
Is Eclipse (Scala IDE) better than IntelliJ now? About a year ago people convinced me to switch to IntelliJ because Scala IDE was totally unusable, full of spurious compilation errors and useless refactor that introduced random symbols instead of doing its job.
Eclipse still has problems, its refactoring doesn't really work, and the UI locks up every so often, but its compiler is substantially more reliable than IntelliJ's. It's a case of picking your poison really.
Maven is a hug step backwards. SBT has its issues, but maven is god awful. Going forward though on new project, I plan on using Gradle. I find it a lot easier to work with than SBT.
Nono! Typesafe, I mean Lightbend, declared that random strings of symbols are just method names, so no need to worry about that operator overloading thing! Except methods with ":" in the name tend to work differently wrt. precedence.
(Look, I'm not on a crusade against Typesafe/Lightbend, but they've been hugely disingenous on a lot of things like this. I could have accepted it if they'd just said "yes, it's operator overloading, but better". Instead they chose this ridiculous disingenuous "nono, it's just method names!" approach. In my book, the only people who can get away get arbitrary method/function naming are the LISP/Scheme people. Because in LISP/Scheme there is no precedence to worry about.)
Yes, they're very common in build.sbt files. How else would you add library dependencies?
I know exactly what they do; the underlying reasoning is very consistent, maybe even elegant. But if you don't know and need to understand/modify a build.sbt file, it's very tricky to find out.
Cannot survive? That seems really hyperbolic to me. I think the language is in a really good state for the vast majority of users right now.
For me, the language still hits a sweet spot miles ahead of the dynamic languages in its soundness, the old school typed OOP languages in its "functionalness", and the typed functional languages in its approachability and modernity (compared to, say, Haskell). Scala's killer innovation was to find a way to apply sound typing to Ruby-like syntax, and in that, it succeeded quite nicely.
That's not to say the stagnation isn't frustrating or that there aren't great improvements to be made. I think Scala would be greatly improved if Shapeless were expressible with much less hackery. It's a testament to Scala that Shapeless is even possible, but it's still pretty unsatisfactory when it comes to regular people being able to understand such code, let alone debug it when it goes wrong.
But look at Scala through the lens of other languages. It took monumental effort to get to Java 8, Python 3, and ES6. It's unfair to paint the current Scala plateau as some kind of albatross. Especially given that just a few years back, people were complaining about language churn.
The language is in a great state in terms of what's possible, and in terms of the underlying abstractions (partly why Dotty doesn't seem like an urgent requirement to me). It's in a much less state in terms of what those things look like in code. Shapeless is great in terms of what you can do with it, but much less great in terms of what the compiler errors look like when you make a mistake. Contrast with Ceylon where similar functionality was built in from the start.
Python 3 was very much at the front of my mind as I wrote that - I think their "plateau" has killed the language (I hope I'm wrong). People were complaining about language churn, but I wasn't one of them. With Dotty an unknown number of years away and no committed schedule, I simply don't think Scala can afford to freeze for that long.
I think we have very different conceptions of "survive" and "killed". Python certainly seems alive and well to me, if not exactly the hottest thing out there.
I think Python is a dead language walking at this point. It was big enough that momentum will keep it going for a while, but that's more a case of dying slowly than living long.
Honestly no. A lot of the complex Scala you see is because Scala doesn't have syntax for something and so you have to put it together out of other things. Type lambdas and Miles Sabin's unboxed union types trick are prime examples of cases where adding some syntax would make a lot of real-world Scala a lot more readable. Likewise ADT case classes where you don't really want the class to be its own type - a little syntax would save a lot of repetitive "smart constructors".
Also there are cases where it's not more syntax that's needed, but different syntax. E.g. the way irrefutable unpacks in for/yields desugar to a (with)filter call is just dumb.
The liveness metric in tech world is simple: is the number of users / new projects currently increasing (then it's alive) or decreasing (then it's dead)?
On the other hand, Lightbend is so generic and bland, while TypeSafe, at least for those "in the know", has a nice technical ring to it.
I guess bland & non-threatening trumps meaningful in enterprisey software. Still, very disappointing, especially if it signals a lack of focus on Scala.
Meh, if you are into the academic PL community's fixation on "preventing bad", TypeSafe is a perfect name, but as soon as you step out of that bubble, it sounds just as bland and enterprisey as say...SalesForce or PeopleSoft.
Scala isn't just a safe language, heck, it is not even an especially type safe language. But Scala allows you to do more, not do the same things significantly type safer like say...Haskell, Rust, Ada, or Agda. The name "TypeSafe" sends confusing signals in that respect. Scala does increase expressiveness without sacrificing type safety, but doesn't really focusing on going beyond that. Correcting that misconception is reasonable, and Lightbend more aptly emphasizes this "do more good" aspect.
Lightbend is a generic name, but not particularly so. It doesn't have an enterprisey feeling to it, and even if it did, that wouldn't be a negative with its potential money-paying customers. As far as the "focus on Scala" go, I think Martin Odersky has already decided to focus on Scala while the company focuses on promoting the Scala ecosystem, which is also quite reasonable and should bear fruit.
When people talk about the slow "Scala" compiler I always wonder what they actually do. I mean most of the time you are lightyears slower I thinking how to solve the problem than the compiler compiles. I mean changing a file compile -> looking at the result takes on my machine mostly 1-2 seconds (incremental compilation).
Javac isn't lightyears faster and on go I would take nearly the same time, only full compilation is way way faster.
I agree. Granted, it can be easy to muck up compile times if you factor poorly, and get those cascades of "Compiling 1 file...Compiling 12 files....Compiling 100 files".
But, I also do a lot of front-end web work, and Webpack takes a lot longer to rebundle my files than Scala takes to compile. I work on a Rails monolith that takes as long to start up as my Scala project does for a fresh compile. So I think the complaints are way overblown.
The Scala compiler is excruciatingly slow for me. I frequently rely on polytypic programming techniques to prove (with a small "p") that my code is correct. The compiler simply can't keep up with me.
The end result is that my state of flow is continually interrupted, or at least under assault. Bobbling my head to trance music while implicits are resolved is the only antidote that I know of.
Do you really need so many implicits? I actually learned that they will do more harm than good. I try to avoid them, where ever I can. And actually the playframework doesn't take so long to compile, to make sbt publishLocal after a clean takes no longer than 5 minutes (travis needs 40-50 minutes not sure why) for me, which is actually really fast. I mean running every tests every time takes a while, but I think that people should start incremential compilation / test if they want a fast workflow.
My experience has been that most of people I know who complain about this are coming from backgrounds heavily tied to dynamic languages such as Ruby and Python. They'd likely complain about compile times regardless but as Scala is a bit slower they have more to point to
Actually the spurious errors didn't happen to me, however I actually use sbt tasks in intellij and deactivated every compile-server or whatever.
The only thing which happens really really often is that when I coded some hours that the errors can't be displayed inside a web view and sbt loops the error, however thats not a big deal since after fixing it it goes back to normal.
However my Scala project actually doesn't use too many "special" feature's I would say I actually don't use any obscure language feature, the only operator which I've written yet is a "~~" for a StringBuilder and else I actually wrote out EVERY type parameter to my function, etc. I would say we write our code so that it's readable inside all major ide's and is understandable by junior developers.
Meta: Recommend changing the HN title to "Typesafe (makers of Scala) Changes Name to Lightbend".
Personally, I am very interested in Scala, but didn't immediately recall that Typesafe was the company that owns it when I saw the article title. The conversation here is valuable (about roadmap, developer sentiment, etc), so don't want folks to miss out.
Since when does bending light require distorting the fabric of spacetime? All you need is two transparent materials of different densities, they don't have to be heavy, and you will bend light as it passes from one to the other, it's called refraction.
So, Typesafe pivots away from being the company behind Scala to being the company behind the "Reactive Platform (tm)".
I didn't understand the motivation at first--they announced they were going to do this a while ago--but this sentence sums it up:
> ... with more than half of our customers representing traditional Java enterprises. We continue to evolve, becoming more language agnostic ...
I can understand this. While I always liked the Typesafe brand because of it tech connotation and implicit relation to Scala, if you want to diversify outside of the Scala box, you'll have to change the name.
As a Scala fan, however, it's hard to not see this as a blow to the community. Having Typesafe behind Scala was one of the major advantages of choosing Scala, and IMHO the primary reason Scala adoption spread wider and faster that Clojure, Haskell et. al.
I was hoping the JVM community would coalesce around one post-java language and I was hoping it was Scala. But now add Kotlin to the mix of Groovy and Clojure, and the future gets murkier. Especially with the mind-share and great communities around Rust and Go.
This is probably a good thing for Typesafe/Lightbend, however. The Scala ecosystem had been tough to monetize. Putting their full weight behind commercial offerings on top of FOSS foundations seems like a better business strategy.