+1 I use them in Lausanne. 777 CHF/year is a great deal!
Interesting model: the price is the same for everyone, while bandwidth is the maximum they can offer in your location. Excellent support. I bought a TP-LINK MC220L + patch cables from them, and hooked up an edgerouter lite for PPPoE & VLAN tagging. Already had a wifi router (google wifi), which sadly can't do VLAN tagging. Haven't noticed any issues with the double NATing.
It was a necessary transition because we need to keep attracting customers that initially are reluctant to invest in Scala training. We've found our Java APIs to be a potent gateway drug to Scala, with many of our customers who begin with the Java APIs quickly realizing they'll be even more productive with Scala :-)
The renaming never affected the staffing of the Scala team at Lightbend -- we've been doing about 2/3 of core Scala development (major thank you to the community for the other third!) since 2.10 (when I went from post-doc in Martin's lab to the Scala team lead position).
In my opinion, it was a good thing that feature development slowed down in Scala 2.x (while Martin pushed the research frontier forward in Dotty), so we could focus on (in no particular order) compiler performance, a new back-end and optimizer, Java 8 support, modularization,...
> I am reluctant in part because Scala.js does not quite have financial support of Lightbend. Or so it seems, it's a bit hard to tell where Lightbend ends and the non-profit Scala Center begins.
As the Scala team lead at Lightbend, I'd love to have a few members of my team focus on scala.js and scala-native. We do financially support their development (most recently, as part of our funding of the Scala Center).
As a business, it's a bit of a chicken-and-egg problem: our customers usually indicate they are hesitant to switch from JS for their frontend work. It would be great to have more customers provide feedback like yours (via our customer surveys)!
Procedure syntax (the last two lines, lacking the `=`) will be deprecated in Scala 2.13. The two variants before those are due to type inference. Are you really arguing against type inference?
The empty argument list `()` is a convention to denote that a method has a side-effect, whereas a method with no argument list at all is considered pure.
Thanks for your balanced reply. Sadly, some people see it as a badge of honor to write super clever code that's essentially write-only, and Scala somehow triggers this in them :-)
We, as the Scala community, play an important role in shaping the culture of programming in Scala as one that embraces simplicity as the true elegance, maintainability and testability, friendliness and openness to criticism. The language will remain flexible (though we're always looking to remove warts), it's really up to your company culture to decide how to use it (which is different for different teams over time).
Many big players, such as Twitter, have done a great job with that (and continue to do so).
I'm always eager to learn how we can improve Scala, especially as we kick of the Scala 2.13 cycle (hard at work on compiler performance and standard library improvements). Email is 'adriaan.at("lightbend.com")
Thanks, glad you like it! We at Lightbend (my employer) don't think of ourselves as very corporate, but we definitely sponsor Scala development. My team is hard at work on Scala 2.13 (well, except the part of it that's commenting on HN stories).
The only thing on your list on your blog [1] that's still true is that we care about PL research. Since 2.10, we've worked really hard on improving the migration between major versions, and the feedback has been very positive. We'll keep working on finding the right balance between ease of migration and fixing issues in the libraries. Scala 2.13 will be a library release, with further modularisation of the library (towards a core that we can evolve much more slowly, and modules that can move more quickly, but where you can opt to stay with older versions as you prefer).
We've also invested heavily in incremental compilation in sbt. Sbt is meant for use as a shell, and it's super powerful when used like that. When I'm hacking the compiler in IntelliJ, recompiles of some of the biggest source files in the compiler (Typers.scala, say) take just a few seconds. I rarely have time for office chair sword fights anymore.
With Scala 2.13, half of my team at Lightbend is dedicated to compiler performance. We'll have some graphs to show you soon, but our internal benchmarking shows our performance has steadily improved since 2.10.
Yep, 2.11.9 is the last planned release, but we would release another one for security fixes or anything as severe. If we get customer requests for backports, we (usually) also release those publicly.
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 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.
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.
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.
True Scala 2.12 generates byte code that requires a Java 8 VM. Scala 2.11 will be supported for a while longer, with as many as the 2.12 features implemented there first (those that don't require Java 8).
Keen eye! The release is tagged and the artifacts are indeed on maven central, but we are holding the official announcement for a few days to be able to launch with a nice set of community libraries already published. So much for flying under the radar :-)