Would love to hear about your experience moving. Do you speak French (or German?) Have been contemplating the continent as Dublin gets very expensive.
I realize this counters my own statement (after all Dublin IE has some of the same problems as the bay wrt housing) but there are still cities in Europe offering what I stated.
+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.
That model has a downside for the customer: the company has no incentive to invest to upgrade your speed, as you already pay them the one fixed amount.
Market pressures take care of that when they exist. Networking is a pure commodity business, you can squeeze a lot of cost out of it, but in the absence of competition the providers get fat, lazy and rich.
Once you deliver the fiber, the marginal cost of increasing port speed is a rounding error as you do routine infrastructure refresh.
Where I work, we’re increasing many wan links to 10Gb because the cost is marginal at scale. In some cases, it can save money versus an older slower tech!
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,...
Yes, it all went in a good way. However, this was a scary time, observing Typesafe (now Lightbend) slowly transforming into a garden variety enterprise Java consulting shop, and watching more and more core platforms like Akka being adapted back to Java...
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 :-)
> 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.
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")
I don't think that Go is a good language to compare with Scala. (I do like Go, though.) The two languages could not be more different in philosophy. Scala is maximalist - you can do things many ways, you can call java, you can have tremendously intricate types, etc. Go is minimalist - there are just enough tools to get by, and sometimes it feels like you are missing one. My experience with Scala is that you spend more time telling it what to do but not how to do it (and it is often not obvious exactly how things will be done), while in Go you have to tell it both what and how to do things, which results in longer code, and repetition, but less ambiguity. You can't add to Scala to make it more like Go - the only way to make it more Go-like is to remove from it, which is impossible.
I think a more appropriate comparison for the language would be F#, which is probably not a surprise to you. I have never used Scala professionally, so I can't give any suggestions that would improve the use of Scala for day to day programming. Years ago I was learning 1 language per year, and picked up Scala and F# that way. After completing the Coursera courses on Scala, I put together a few projects on github using it, enough to get some job feelers that ignored my "don't send me job offers." And I realized that while I enjoyed fiddling around with the language on my own, I didn't want to spend my professional time deciphering other people's Scala code, and so I dropped it. Take from that what you will - maybe I am just not cut out for it.
I do use Go professionally, although it is a minority language where I work.
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).
Yes maybe some of the success stories regarding changing from X language to Go are actually because Go enforces behavior at the language & tooling level that could potentially be enforced culturally at the company, but for whatever reason, the company has not been able to develop. Kind of, "if you don't play well with your toys, we take them away," instead of teaching them to play well from the start. When you're just a senior developer, you probably can't change the culture but you might be able to change the language for some applications.
There is the old jeremiad to not use technology to fix cultural problems, but when you're just a part of a much larger institution that may or may not have the ability to intentionally change its programmer culture, it can make a lot of sense to move to a language that reduces your reliance on those cultural behaviors if they are lacking.
Some of that could be addressed automatically in Scala with code standards enforcement like with scalacheck. And you can help with good practices like code review or pairs programming. But in a lot of places there is no appetite for "wasting time" on stuff like that (I vehemently disagree with that kind of attitude, but changing other people's view is not easy).
The advantage of Go is that left to their own devices, people will tend to gravitate towards more readable code, in a standard format, using standard tools that are pretty good in most situations. The entropy of having a bunch of people work on a project will then work in favor of coherent approach and style, instead of tending to diverge into using the tools they like best in the format they prefer.
"Go" the language is tricky to search for as just the word "go", so I wouldn't read much into that. Many job ads contain the word go, but have nothing to do with go the language. e.g. "...go to our website..." "...go above and beyond..." etc.
I just wanted to take this opportunity to thank you and the team at Lightbend. There is a clarity of thinking and expressiveness in Scala that I haven't found in other languages. I have used Scala professionally for the past 3 years and enjoy it immensely as a language.
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).
I get this feeling when looking at the OO and functional styles continuously clashing. Implicit classes make some reasoning about functionality non-local. There's a horrendous amount of complexity in the OO side: case classes, traits, mixins, and a complex type hierarchy to boot.
Most languages just don't have that many features, and you could take different, non-overlapping subsets of features have something that could have an idiomatic style of its own and is good enough to solve most problems tersely.
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.
I still have the problem of upgrading because not all of the libraries are cross compile or do work. At the end of last year we've upgraded one library which cost us many days.
Next is upgrading Lift to 3.0 which will be a nightmare (again).
"We've also invested heavily in incremental compilation in sbt."
Yes, I read this over and over again, and I see micro benchmarks posted.
Using SBT with continuous unit testing I can't feel a difference - or it is so slow with a major code base that it's still much to slow and I judge it having no progress. Either way, after years it is still too slow (newest Scala + newest SBT).
"I rarely have time for office chair sword fights anymore."
Today I expect Kotlins practically instant compilation. 10 seconds for compiling some changed files is already to much for rapid development with TDD/Web, it breaks my flow, but YMMV.
"We'll have some graphs to show you soon,"
See above, I've seen dozens of micro benchmarks that claim improvements, in the end it doesn't show up in my real projects - at least in mine and the person who migrated to Go in the linked article. And all the other blog post authors that moved away from Scala towards something faster (Kotlin, Java 8, Go, ...)
But as I've said, I've moved on to Kotlin for new projects because for me Scala is a lost course.
Another site note: I would never argue with my users and tell them how wrong they are about the product and that their perception of the lack of some feature or quality is wrong.
