47 ms·

Towards Scala 3

490 points by kushti 9y ago

nnq 9y ago
Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or other big cos known to give back to open-source growing any Scala codebases now?
- kprybol 9y ago
  Scala is used pretty heavily in the big data world, particularly if you are working with Spark.
  - joshlemer 9y ago
    Not to mention, Flink, Akka, Apache Beam (via the Scio library or the Java api).
    - kprybol 9y ago
      Kafka too
      - dominotw 9y ago
        Kafka switched to java 100%, afaik.
  - bitL 9y ago
    Python is still king there, even DataBricks market it that way. Scala is for advanced stuff that matters.
    - RBerenguel 9y ago
      Python is king in analysis, but for big data engineering, most of the building blocks (as mentioned elsewhere in this thread, Akka, Kafka, Flink, Spark, etc) are written in Scala
      - sandGorgon 9y ago
        It doesn't matter. Because pyspark is still the go-to language. In fact with spark 2.3 python UDF, the performance gap has also reduced. https://mindfulmachines.io/blog/2018/4/3/spark-rdds-and-dataframes https://mindfulmachines.io/blog/2018/4/3/spark-rdds-and-data...
        RBerenguel 9y ago
        Being able to pass data through Arrow is a big improvement, but there's also a lot of serialisation going on you pay in Python. Also, if you want to do anything in the fancy areas (like, write your own optimisation rule for the SparkSQL optimiser) it's Scala. Even something simple as writing a custom aggregator is impossible in Python (at least it was in 2.2, haven't checked in 2.3 or "current" 2.4)
        kprybol 9y ago
        It depends on the use case. Our work primarily revolves around extending Spark with custom pipelines, models, ensembles, etc. to be deployed into our production systems (petabyte scale). Scala was really the only way to go for us.
        sandGorgon 9y ago
        I can understand performance difference, but I have not generally seen a difference in building custom pipelines and ensembles .. although I grant I'm not at your scale yet. What kind of specific pipelines did you have trouble in pyspark ?
        RBerenguel 9y ago
- phdp 9y ago
  I know quite a few finance companies use it - Morgan Stanley and Goldman Sachs come to mind.
- pjmlp 9y ago
  F# only has access to a subset of .NET deployment scenarios, where Scala can be used pretty much everywhere there is a JVM. So most companies actually are more keen to bet on Scala than F#. OCaml/Reason world lacks the wealth of Java libraries, which are an import away on Scala. Regarding Kotlin, so far its killer use case is targeting Android, where one is stuck with an ageing Java subset. Outside of Android, it remains to be seen how it will keep up with the Java improvements coming up every 6 months now.
  - stephen123 9y ago
    Not only on JVM, scala can be used in the browser with scala.js or without a JVM with scala native.
    - GiorgioG 9y ago
      Yep - you're right... F# definitely can't be used in the browser: http://fable.io/ http://fable.io/
  - GiorgioG 9y ago
    > F# only has access to a subset of .NET deployment scenarios And what subset would that be? The only place you can't use F# IIRC is UWP application which is likely not the deciding factor in choosing F# or Scala.
    - pjmlp 9y ago
      Anything GUI related, and their respective tooling support on Visual Studio, which it never got. It is still playing catch up with VS 2017 tooling for VB.NET and C#.
      - GiorgioG 9y ago
        If you're waiting for feature parity with C# in VS, you'll never get it. There are millions of C# developers and F# devs are counted in the tens of thousands (sadly) so there's a reason for that. I don't believe most organizations considering adopting F# or Scala are considering them for GUI development so I'm not sure why you'd rule out F# because of that
- boubiyeah 9y ago
  Scala has an insanely productive and efficient streaming ecosystem with the likes of Kafka and Akka streams. You can use those with other languages but it's not nearly as nice.
  - sidlls 9y ago
    Why isn't it nearly as nice? Is there something particular about Scala such that Kafka or Akka are best implemented in it? Could you give some concrete examples (e.g. compare it with Java, C, C++, Rust, Haskell)?
    - chamakits 9y ago
      I think the parent comment was talking more about using those libraries with Scala, not necessarily implementing them. Can't speak too much about the others, but I recently looked into using Akka with Java. Akka itself had a good deal of documentation for Java users. However, other related products (look tools for monitoring Akka, etc) were clearly treating Java as a second class citizen. When there was documentation, it would be outdated, and unmaintained. I ran into this over and over again, which weighted heavily on my decision to not use Akka. I'm not quite sure if there is anything about the language that would have made it particularly challenging (doubt it), but it definitely seems like the community built around it is more Scala centric. And that in itself makes it challenging to use with anything else.
      - sidlls 9y ago
        I took the comment to mean that Scala is the best choice for having implemented, e.g. Kafka, and that other languages somehow aren't suited for it, and asked the question with that in mind.
    - lmm 9y ago
      (Compared to Java, C or C++ there's all the usual ML-family goodness - first-class functions, algebraic data types with pattern matching, type inference). Scala has a for/yield construct similar to Haskell's "do notation", which is the perfect way to work with async code - it strikes the right balance of avoiding an unreadable callback pyramid of doom, but still your async yield points visible (the difference between <- and = is about as concise as it gets, but still very visible). And having HKT and allowing you to express concepts like monads means that a whole library ecosystem can build up of standard operatons operations (e.g. traverse, cataM) that work on async futures and also on other contextual/effecty types (e.g. audit logging, database transactions). That's the big advantage it has over Rust and most other competitors, and it particularly shows in things like Kafka/Akka that need to work with async a lot, but also in large programming projects generally. (What it shows up as in practice is that you can do everything in "plain old code" - all the things that need reflection/interceptors/macros/metaclasses/agents/... in other languages are just libraries in Scala - and that makes development so much easier and bugs so much rarer) Haskell has all that - the trouble with Haskell is that "there's no way to get to there from here". I was able to go from writing Java on Friday to writing Scala on Monday - not great Scala, but working Scala, and I was just as productive as I was in Java. I couldn't've done that with Haskell.
- sgeb 9y ago
  Here's one datapoint: AutoScout24 (the vehicle vertical of Scout24, a Europe-based digital marketplace) has fully committed to Scala a couple of years ago as part of a re-platforming (microservices on AWS). It's still the recommended default language. Not a "big" company by global standards, but not small either, with around 120 engineers.
- joslin01 9y ago
  Twitter created a website "Scala School" awhile ago, so I'm guessing they didn't jump ship yet (but could be wrong). https://twitter.github.io/scala_school/ https://twitter.github.io/scala_school/
  - joshlemer 9y ago
    Twitter is still very much heavily committed to Scala.
- Bizarro 9y ago
  Yeah, I don't think Scala 3 changes anything with regards to perception and/or adoption of Scala. That ship has pretty much sailed. Martin Odersky seems like a really good language designer. I took a look at the Scala 3 languages features, and a more radical departure from historic Scala probably would have helped Scala.
  - lmm 9y ago
    Three or four years ago the biggest criticism of Scala was that releases were breaking backwards compatibility too much. On this very thread you'll find people worrying that Scala 3 will create a Python 2/3-style endless awkward transition. At this stage it's a mature language with a big established ecosystem, it can't afford to break too radically. (Did you have specific breaking changes in mind? The most important changes I'd want to make to the language - having a syntax for guaranteed-safe equality comparison and guaranteed-safe pattern matching - could be done in a backwards compatible way, and the only other thing I can think that I'd like would be Idris-style totality checking which could also be backwards compatible.)
    - Bizarro 9y ago
      I wouldn't have called it Scala 3. And if I had the big brain of Martin Odersky, 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. I don't follow Scala that much anymore, but it seems that it's mostly a reworking of the internal consistency of Scala from an implementation perspective. At least that was the gist of it I got from watching Odersky give a talk about it a couple years ago.
      - lmm 9y ago
        > 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. Wait what? In the last post you were complaining it was too close to existing scala, now you're saying it's too big a step? Again, what is the change you're actually advocating?
- afroboy 9y ago
  Twitter now is running its Scala code on GraalVM.
  - polskibus 9y ago
    Woah, can you provide a reference? I'm curious about the rationale and performance implications.
    - ErunamoJAZZ 9y ago
      https://twitter.com/graalvm/status/986587968667291648 https://twitter.com/graalvm/status/986587968667291648
      - polskibus 9y ago
        Did you find any benchmarks with hard numbers regarding performance improvement?
- misja111 9y ago
  > Just curious, what companies (or kinds of companies) are betting on Scala nowadays? LinkedIn, Twitter, The Guardian, Morgan Stanley, Barclays, Zalando. Generally speaking, Scala is used a lot by companies involved with Big Data (because they use Spark).
  - sulam 9y ago
    I’m not sure if your info is dated or mine is, but all the systems development at LNKD that was being done in Scala is now done in Java. There is some legacy Scala still but as of a couple years ago they decided no new development. Perhaps they are still using Scala in a data science context, since it is hard to avoid there, these days.
    - sidlls 9y ago
      It's trivial to avoid it in data science, with even modest to large (although not "Big") data in the few TB range. My data science team's entire stack is basically Python, with a smidge of Java and Rust for infrastructure (soa, pipelines) development.
      - sulam 9y ago
        I almost added the clarifying statement "on the JVM" but got lazy. Yes, Python is the obvious choice for data science until you hit a certain scale. It's not even clear to me that most companies doing data science in Scala have that scale -- they're just using tools and libraries companies at that scale have open sourced. You could call it cargo culting, but I think it's more nuanced than that. I think engineers can be separated into two camps roughly: those who are passionate about the language(s) they use, and those who are simply trying to get the result they need and don't care what language they use to get it. A lot of data science engineers naturally fall into the second bucket, so using Scala because a library they want to use is written in it comes naturally, even if they could get the job done in Python (possibly with a bit more wheel reinvention).
        sidlls 9y ago
- noelwelsh 9y ago
  Interesting that you see it that way. I see Haskell and Purescript usage growing, and I don't know many people interested in O'Caml / Reason. Not trying to say you're wrong---just commenting on the effect of our respective filter bubbles. As for Scala usage. I'm a Scala consultant, so I'm biased, but I'm seeing a lot of adoption. Most finance companies and most media companies are using Scala.
- joneholland 9y ago
  Expedia is a big time scala shop, but new stuff is trending towards Kotlin.
- dudul 9y ago
  F# and OCaml? What source do you use to say that? Scala is way more popular in the industry that these 2 combined.
- CookWithMe 9y ago
  I'm working since 3 years at a growing startup that has been hiring Scala Engineers at least every half year since I started. In the last ~18 months, the amount of CVs we're getting has been constantly increasing. Part of that is probably that our startups hiring matures, but it's also the kind of CV that is changing. I'd say that 3 years ago, there was an 80% chance that the applicant was highly self-motivated to learn Scala in their freetime, and tried/did introduce it at his/her current workplace. Today, there is an 80% chance that the applicant either "had to" learn it in their current workplace, or learned Scala when switching jobs. (Don't get me wrong, they're still motivated, and they took the chance when it was there!) So there is a switch from the Early Adopters to the Early Majority (where the Early Majority now has worked 1 or 2 years with Scala at their current job, and is confident enough to look for a new one). One driving force was definitely Spark, but there are a lot of Enterprise apps, unrelated to ML (usually with higher traffic requirements). The sort that would have most likely been done with Java or C# 5 years ago. It seems a lot of Enterprises introduce Scala when they try to break up their (Java) monolith into microservices. So it seems that Scala has been carving out it's place in backend/microservices with scalability requirements, and is eating part of Javas cake there.
- saosebastiao 9y ago
  I still think Scala is a better better-jav than Kotlin, but Kotlin captures that market better because of the much lower learning overhead. I'm much more of an ML-style programmer, but the thing keeping me away from OCaml is the lack of a multicore runtime. Not only is Scala's concurrency mature and performant, implicits (like having an ExecutionContext) make it extremely easy to use. Even if OCaml released it's multicore runtime today, it would take years to get to the maturity of the Scala ecosystem. Plus, occasionally I run into areas where OOP really blows away functional programming. It's nice to not have to learn a new language for those occasional times.
  - yawaramin 9y ago
    OCaml fully supports OOP (the 'O' in OCaml).
- JackFr 9y ago
  > It seems that the people wanting "better Java" all decided they like Kotlin I've been using Java and Scala exclusively for the past 10 years at two large NY banks and two fintech start-ups, and I literally do not know anyone who has ever compiled a Kotlin program. Simply extrapolating from one's own experience is fraught with peril.
- bad_user 9y ago
  N.B. Scala and its ecosystem is actually a lot more oriented towards FP than F# or OCaml for that matter. Its popularity also far surpasses F# and OCaml in jobs available, books, libraries or other metrics that count.
- dbattaglia 9y ago
  We use Scala as the primary backend language at Elastic for the Elastic Cloud SAAS & enterprise products (along with Java, Python and Go).
- dominotw 9y ago
  > functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more What if you want functional programming without having to go to MS stack and stay on JVM. You only have have two real options clojure and scala.
- SOLAR_FIELDS 9y ago
  If you make heavy use of Spark there is still no better language/ecosystem than Scala.
- applehire 9y ago
  We use Scala heavily. If kafka/Spark/Monoids/Semigroups/Cats/Algebird makes any sense to you and you are looking for a job, send your resume to mansur.ashraf@apple.com
- aphexairlines 9y ago
  Here are a bunch of job postings at Amazon citing that they use Scala: https://www.linkedin.com/jobs/amazon-scala-jobs/?country=gb https://www.linkedin.com/jobs/amazon-scala-jobs/?country=gb https://www.indeed.co.uk/cmp/Amazon.com/jobs?q=scala&l=London%2C+Greater+London https://www.indeed.co.uk/cmp/Amazon.com/jobs?q=scala&l=Londo... https://www.amazon.jobs/en/search?base_query=scala&loc_query= https://www.amazon.jobs/en/search?base_query=scala&loc_query...
AzzieElbab 9y ago
Great news! Kind of confused about scala2 and 3 sharing the same standard library. I thought that was being redesigned.
- modersky 9y ago
  The shared library we are talking about is the upcoming 2.13 library, which has the new collections design. We currently link against the 2.12 library but will switch to 2.13 once that comes out.
  - dhuramas 9y ago
    Just wanted to say- thanks for your great work in making Scala possible. And wanted to add that going through your Scala Functional Programming MOOC was one of the most rewarding experiences.
rb808 9y ago
Its fascinating process where if you're a hot new language you attract a lot of people that like shiny new things. When the next hot new language comes along and those people move on - have you attracted enough of the secondary wave to keep alive? Its going to be interesting to watch Scala adoption in the next few years.
- devit 9y ago
  Don't think it has a bright future since Rust and Kotlin share much of what brings people to Scala and are better in many ways, including and perhaps most importantly the fact they are improving faster than Scala.
  - jvican 9y ago
    I challenge the fact that Rust and Kotlin are improving faster than Scala. Scala is not only more stable, but is under active development and there are lots of discussions to improve the language over time (check our SIP meetings). Kotlin doesn't even get closer to what Scala is, and Rust is for those folks with the mentality that memory management is something worth keeping track of.
    - Cyph0n 9y ago
      Also, from my understanding, Kotlin is tied to the Intellij ecosystem, so open source tooling is lacking when compared to Scala.
      - pjmlp 9y ago
        More than that, if you want Kotlin/Native debugging support, you need to either buy Clion or AppCode, as it is not available on the community edition.
        Cyph0n 9y ago
        Charging for debugger access sounds so 90s lol
dzdt 9y ago
My big question (not answered in the FAQ) is will it be faster or slower than Scala 2.12? Having worked on a big Scala codebase, the slow compiler speed is one of the biggest downsides to the language.
- mping 9y ago
  There was experimental work to see how fast a scala compiler could be, but I think it's still far from production ready, was more of an experimente: https://github.com/gkossakowski/kentuckymule https://github.com/gkossakowski/kentuckymule
- modersky 9y ago
  It's currently about as fast as Scala 2.12, which means it compiles at roughly 3000 lines/sec. However, it supports more aggressive incremental compilation than Scala 2 so at least in my projects, which are typically 50K to 100K lines, most compiles are under a second, and I rarely see compile times over 5 seconds. There's ongoing performance work to make both Scala 2 and Scala 3 faster than they are now. A lot of what people perceive as slow compile times are actually other factors (such as inefficient macros or slow build tools).
  - jvican 9y ago
    > However, it supports more aggressive incremental compilation than Scala 2 I'm not sure what you mean here... but Scala 2 and Dotty have the same incremental compiler, and their independent bridges feature overall the same quality (which is high and heavily battle tested, for those interested).
    - Cyph0n 9y ago
      I'm not sure if you noticed, but you are replying to the designer of Scala.
      - JiminHsieh 9y ago
        I think jvican noticed this. jvican is the engineer from Scala Center which is supported by EPFL. Edit: typo
quantumwoke 9y ago
This major breaking change to the language reminds me a lot of the Py2-Py3 fiasco. I wonder how Scala's community will handle the transition given the previous issues with cross compilation in the 2.x series. Given the multitude of language alternatives in a similar space to Scala, I'm worried. Fingers crossed they can work through this.
- azernik 9y ago
  Static typing makes this kind of large-scale refactoring a LOT less scary.
- jhomedall 9y ago
  Scala 3 will still be able to use Scala 2 libraries, so it won't be quite as bad.
mavdi 9y ago
> Simplify where possible > eliminate inconsistencies and surprising behavior Oh dear god please.
- realusername 9y ago
  I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.
  - deleted 9y ago
    [deleted]
  - willtim 9y ago
    The Scala team appear to have their hearts in the right place. They seek to empower their users and have respect for them. I can't really say the same about the Go team, based on at least one Google presentation I have seen. This isn't that surprising given the goals of the projects.
    - realusername 9y ago
      I did not want to start a flame-war Scala vs Go, it's just that I like Go simplicity & readability (I also like Python and Ruby for those reasons as well) whereas I'm not a huge fan of the Perl feeling of Scala.
      - willtim 9y ago
        When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
        9y ago
rilut 9y ago
Is there any plans to include async/await on the language level?
- azernik 9y ago
  async/await is a special case of monads (expressible with a for-comprehension); it comes out to: def asyncFunction(): Future[Blah] = for { foo <- someAsynchronousOperation bar <- anotherAsynchronousOperation } yield bar.baz
  - saosebastiao 9y ago
    I find async/await to be much better for conditional execution, especially with lots of branches. For example, I had a scenario where I tried one async call and if it didn't have the information I needed, I had to make two subsequent async calls to get the information I needed before proceeding with the final call. Monadic composition was a nightmare where async/await was perfectly suited to the task.
  - clhodapp 9y ago
    For comprehensions are currently tremendously limited vs async/await. They constrain the top-level of your code structure to a tiny subset of the language.
- modersky 9y ago
  We will check first whether they can be expressed as a macro (the macro roadmap for Scala 3 is still evolving).
  - 62747478182 9y ago
    There is https://github.com/scala/scala-async https://github.com/scala/scala-async, which is already implemented as a macro, though it is a bit limited
deleted 9y ago
[deleted]
viach 9y ago
I was really hoping they implement python-ish syntax https://github.com/lampepfl/dotty/issues/2491 https://github.com/lampepfl/dotty/issues/2491 But no, "Implicit Function Types" instead. Ok.
- Cyph0n 9y ago
  So your biggest complaint is "Scala doesn't look like Python"? I mean, I love Python, but indentation-based syntax isn't that great. I think Scala is fine as it is.
  - willtim 9y ago
    Being brutally honest, compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose. I'm almost certain its creators chose the syntax in order to tempt curly-bracket programmers, not because they liked it personally. I really hope that future high-level languages will use better syntax and move on from the C/C++ influence.
    - Cyph0n 9y ago
      > compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose I have never worked extensively with Haskell or ML, but what I can say is that Scala's syntax is better than that of most other mainstream languages. Three of Scala's syntax niceties are: 1) No semicolons 2) No braces required for one-line functions 3) No constructor required: instance arguments passed in class declaration
      - s4vi0r 9y ago
        To add onto this, its not one line functions but rather functions whose body is a single expression. You can do a big for comprehension, or a if/else, or a big chain of function calls, etc. without having to add brackets. In practice you often end up not really using braces that often when writing FP style Scala.
      - 9y ago
_Codemonkeyism 9y ago
[deleted too many fanboys on HN]
- lmm 9y ago
  > Also many open source libraries in Scala land have a very short life time and will not be upgraded to Scala3. No problem with Java, but it will take months for many larger projects to remove Scala2 library dependencies from their code base. The announcement says Scala 3 will be able to call Scala 2 libraries, so even if you're right (which is not my experience of open-source Scala libraries at all FWIW) this won't be an issue.
  - _Codemonkeyism 9y ago
    Yes I've read that point, but a.) it means not 2 but 2.12 b.) what happens if the 2.12 class file depends on old Scala library code? "this won't be an issue." After a decade of Scala usage and a several 100k line project to code on, I'll believe it when I see it.
    - lmm 9y ago
      > what happens if the 2.12 class file depends on old Scala library code? Not possible - 2.12 is source- but not binary-compatible with 2.11, any "2.12 class file" will only have 2.12 dependencies. So we're talking about the release planned for 2020 having binary compatibility back to 2016 and source compatibility back to 2014. Not the same level of backwards compatibility as Java by any means, but better than many languages offer.
  - _Codemonkeyism 9y ago
    What web framework are you using? Both Lift and Play had major migration problems over the last 5 years due to cutting off support for older Scala versions.
    - lmm 9y ago
      A mix of spray/akka-http for REST backends (looking to shift to rho) and Wicket for HTML UIs. I don't think Play makes good use of Scala's strengths (frankly it didn't seem like very good code), and I didn't even realise Lift still existed.
dserban 9y ago
There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different perspective based on my own work with OOP-centric and FP-centric languages. If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs. If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. Both are equally valid ways to design complex applications, so it all comes down to individual taste. Personally I have a taste for mathematical abstractions, so Scala is better suited for my way of thinking. It's obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there. If we use this as the basis for comparison to other languages, it's very easy to understand that Scala has carved out a very powerful niche for itself and is here to stay.
- jowiar 9y ago
  I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured community.
  - nextos 9y ago
    Designing good multi-paradigm languages is very hard. I'm a big fan of Mozart-Oz and Common Lisp, and I think Odersky did a really good job with Scala. In fact, given that Common Lisp is languishing and Mozart was never a serious real world contender, Scala fills in a niche where there are not many competitors. C++, just for some use cases, Julia for others, and .NET. The fact that many organizations working on massive datasets have embraced Scala proves there are not many alternatives around, sadly.
    - auvi 9y ago
framebit 9y ago
I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT. [1] https://github.com/lihaoyi/mill https://github.com/lihaoyi/mill
- stephen 9y ago
  sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.
  - lmm 9y ago
    I've never understood what SBT was supposed to solve in the first place. A Maven plugin that supports cross-building, which we're finally now getting with Scalor, seems like what the language actually needed.
    - tomerbd 9y ago
      https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html
  - lomnakkus 9y ago
    The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools. The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be retrofitted into, say, SBT or Gradle.
    - stephen 9y ago
      Gradle does have a build cache, which can be local or remote: https://docs.gradle.org/current/userguide/build_cache.html https://docs.gradle.org/current/userguide/build_cache.html It is a newer feature, so that might be why you're unaware of it. Also, I get that the models of Bazel/Buck/Pants are fundamentally different, because they are inherently cross-language / "sit on top of other compilers" systems. And are best for mono repos. But Mill doesn't fit in that camp AFAICT.
coryfklein 9y ago
So many cool things already done and even more to come. Some parts that excite me as a Scala nerd: * One can now use implicit function types to basically build your own table language syntax that is type-safe. [1] * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2] * Null safety checks! Quoting from [3], "Adding a null value to every type has been called a "Billion Dollar Mistake" by its inventor, Tony Hoare. With the introduction of union types, we can now do better. A type like String will not carry the null value. To express that a value can be null, one will use the union type String | Null instead." * First-class enums, finally. [4] * Erased parameters: you can declare variables specifically for type-safety that _don't exist_ during run-time, improving efficiency. [5] [1] http://dotty.epfl.ch/docs/reference/implicit-function-types.html http://dotty.epfl.ch/docs/reference/implicit-function-types.... [2] http://dotty.epfl.ch/docs/reference/multiversal-equality.html http://dotty.epfl.ch/docs/reference/multiversal-equality.htm... [3] http://dotty.epfl.ch/docs/reference/overview.html http://dotty.epfl.ch/docs/reference/overview.html [4] http://dotty.epfl.ch/docs/reference/enums/enums.html http://dotty.epfl.ch/docs/reference/enums/enums.html [5] http://dotty.epfl.ch/docs/reference/erased-terms.html http://dotty.epfl.ch/docs/reference/erased-terms.html
- lmm 9y ago
  > * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2] Unfortunately it's being introduced in a fail-unsafe way that as far as I can see makes it virtually useless. If I see "x == y" in code, I have no way to be confident that this isn't an old-fashioned universal comparison without going into the details of x and y, so I'm no better off than I was without this feature.
  - coryfklein 9y ago
    Yea, I'd love a compiler switch that enables the strict mode globally, while adding the leniency on a case-by-case basis instead.
stephen 9y ago
...ships in 2020? I'm impressed with what they're doing (and love the language), and it's hard work, and their speed is faster than, say, Java's dead-pace evolution in the 2000s. But, poking around at TypeScript, I've been blown away with the MS/TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique/novel type system features, not like Java finally getting around to copying the obvious/best-practice approach to case/data classes. Granted, I'm sure the MS/TypeScript budget is huge comparatively... Seems like that's the "best" (realistic) way for dev tooling to evolve lately: come from, or attach yourself to, a ~top-5 tech company that makes their money somewhere else and can bankroll developer tools/languages (e.g. MS with TS, FB with React/Flow, Google with a myriad of things e.g. Dart & AdWords, Go). Bringing it back to Scala, seems like they were close to this (flirted with adoption/sponsorship from a few startups like FourSquare, etc.) but, thinking about it now, "software development in the large" is a huge concern for those companies (e.g. anyone with enough extra money to actually pay for language/tooling improvements), and that's never really been Scala's strong suit (compile times, painless compiler upgrades).
- manojlds 9y ago
  It's not the next release. There is 2.13 and 2.14 to be released. Are you saying Typescript has major version release every 3 months?
  - actsasbuffoon 9y ago
    Typescript does indeed do frequent releases, though they're not nearly as ambitious as Scala 3.0. A Typescript release usually has 1-3 exciting new features, and a number of smaller bug fixes and improvements.
    - benjaminjackman 9y ago
      Correct, but collectively, between now and 2020 it's almost certain in aggregate, Typescript will have significantly more `features` than Scala 3.0, and they will have the benefit of being used and iterated upon for 2+ years.
jrq 9y ago
Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. I used to write a lot of scala, and working with sbt was enough to eventually get under my skin. I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract new learners, especially with just how overwhelming all the different features can seem for someone not coming from both sides. I had ocaml and ruby under my belt when I found scala, so it was an easier curve, but lots of guys struggle with it. I don't mind showing them, and of course I learn a lot from guys with different experiences and different backgrounds, but that's sometimes a complain I hear, also. It's a language that doesn't compare very well. What is scala like? We don't know, there's only one language like it, it's a departure from many different paradigms. I'm back to writing ocaml, all said and done. I enjoyed my time with scala, and interacting with my guys on the other side of the office still doing scala is always enjoyable. Smart guys! I'm not academic enough to grasp some of the new DOT stuff, but they are excited about it. Anyways, I gave up hope a while back on scala getting rid of sbt. There are other build tools that exist, cbt, mill, maybe more, but without the blessing from lightbend or whatever they call themselves this week, it's not feasible, or responsible to deliver a solution to a client with an unofficial build setup. Of course, after five years of doing sbt I decided it's not ok to deliver sbt either. Someday! Maybe?!
- gaius 9y ago
  The thing with Scala if you’ve come from OCaml is there’s no substitute for real Hindley-Milner, and the Scala object system isn’t good enough to compensate
  - throwawayjava 9y ago
    Does anyone use Scala in cases where OCaml is a viable option? My impression has always been that Scala is "better than OCaml if you need the JVM"
    - jrq 9y ago
      Mainly Spark, but it really depends on the domain, what libraries exactly that you'll need, hell I look at what kind of deployment routine the client wants, what their maintenance crew looks like compared to what they want from me. There is plenty of scala in fintech, I can tell you that. But there's plenty of ocaml, f#, matlab, excel macros, r, kdb, cobol, fortran, c++, a vast array of different technologies. Most places that choose scala are choosing it over erlang or Java or c#, they USUALLY only choose scala over ocaml if they want to have some old ocaml code talk with new infrastructure that they want built in scala, ime. Because of how performance works and that multi core isn't working yet, ocaml is limited in application if they're willing to find or already have scala programmers.
virmundi 9y ago
How have people faired with Scala integration with Java libraries? When Scala first came out, I liked the idea. If I wanted to use X library, great, I can. As I pondered it more, this seemed terrible. Say I hug the functional side of Scala. I know what I'm doing. Then I hire a Jr Dev. She comes from the world of Java/Python where functional is no as big of thing (keeping in mind that while Python does support, to a degree, functional, many use it as a procedural/OO language in school). Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code. Side effects could start to show at odd times, which makes debugging terrible in a production environment. All that said, how have others dealt with this issue? Did you just not work directly with Java libraries? Did you use the OO side as a Better Java?
- Cyph0n 9y ago
  When interacting with a Java library, I use scala.collection.JavaConversions to convert any Java structures to the equivalent Scala collection. Once I'm done operating on the collection (map, filter, etc.), I convert it back to Java.
  - nicktelford 9y ago
    You should be using scala.collection.JavaConverters instead, as it makes the conversion explicit (by adding a ".asScala"/".asJava" method to collections). Implicit conversions (i.e. where a type is silently converted to another type) is dangerous and can lead to very surprising problems.
    - Cyph0n 9y ago
      Whoops, my bad about that. I was on mobile and forgot which of the two provides `.asScala`...
- dtech 9y ago
  > How have people faired with Scala integration with Java libraries? It's useful because the JVM ecosystem is much larger than the Scala ecosystem. There's almost always a library for your purpose. If it isn't as idiomatic Scala as you'd want you can often easy create a small wrapper. > Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code. code reviews and education
merb 9y ago
Well it won't solve the biggest problems with interop https://github.com/scala/collection-strawman/issues/283 https://github.com/scala/collection-strawman/issues/283 (sadly). I mean I can understand all the reasons not to, however It's just a pita that there is no sane way to do it, besides reimplementing either two api's or come up with your own collections.
- dtech 9y ago
  Is this really such a big problem? You can either work directly with the Java collections if the code is performance sensitive, or have a `.toScala` call at your Java -> Scala boundary and a `.toJava` call at your Scala -> Java boundary.
room271 9y ago
As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow). Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.
- jvican 9y ago
  At the Scala Center we’re working on addressing these problems. We now have working groups devoted to ease coding in Scala and make it easier for any dev to use any build tool.
  - room271 9y ago
    That's great news! Thanks for the reply.
DandyDev 9y ago
It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market for people that like the intricate and expressive type system that Scala gives you, in combination with the JVM ecosystem. People that think Kotlin is nice, but not expressive enough, for example. People who don't want to deal with Rust's memory management and/or don't have a use for that. People who think Go's simplicity is sometimes more of a burden. Why are people so intent to bash sombody else's language choices?! Go, Rust, Kotlin, Scala are all great languages in different ways. They all cater to different needs, sometimes radically different (Go vs Scala), sometimes subtly different (Kotlin vs Scala). I think there is a market for all of them, and more. And the introduction of a new language (Kotlin for example) does not necessarily spell doom for another (Scala). Let's all enjoy our own tastes and needs, and respect those of others.
- lmm 9y ago
  The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.g. https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-greater-usability/ https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... ). Only a few big players can afford the kind of investment it takes to make something like that. So much as I wish it were otherwise, I can't just sit on my island and use Scala because I think it's the best - if the language is to live, I have to convince other people it's the best. I don't begrudge other people feeling the same way about the languages they do like (provided that doesn't fall into dishonesty, as some of the claims from Kotlin advocates about e.g. null and Scala have).
  - MichaelMoser123 9y ago
sriku 9y ago
"Scala has pioneered the fusion of object-oriented and functional programming in a typed setting." What about Ocaml (1996, well before scala) and F# (2005, not too long after scala)?
- lmm 9y ago
  OCaml users tend to avoid its object system, so while it attempted to fuse object-oriented and functional I don't think we can say it succeeded. F# is, as you say, later.
  - yawaramin 9y ago
    OCamlers tend to avoid OOP mostly because we can get away with modules, functors, polymorphic variants to model subtyping, and now also GADTs and open variant types to precisely model and add cases. When we do need to use it, it is actually pretty elegant and well-designed. It's just that since we've tasted the power of the more functional abstraction techniques, OOP loses its allure.
    - lomnakkus 9y ago
      Indeed. I think that what OCaml proved is that the "O" isn't actually necessary. :)
tytytytytytytyt 9y ago
> become more opinionated by promoting programming idioms we found to work well Which idioms exactly?
clhodapp 9y ago
> Scala 3 code can use Scala 2 artifacts because the Scala 3 compiler understands the classfile format for sources compiled with Scala 2.12 and upwards. I feel like this isn't getting much attention but it is a huge deal. A big part of the reason that Python 3 went the way it did was users didn't want to upgrade until their libraries did and libraries didn't want to upgrade until their users did. With Scala 3, users can upgrade pretty rapidly, freeing libraries to upgrade without fear of leaving their users behind.
amckinlay 9y ago
Last time I tried Scala I had to give up because I couldn't understand what a "trampoline" was, or how to use it to get multi-function tail recursion to work. Probably not Scala's fault.
- mrucci 9y ago
  I found this blog post to explain trampolines quite well: http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...
- ionforce 9y ago
  What level of Scala were you trying? The things you're referring to don't sound pedestrian at all. You shouldn't let them turn you off from ALL of Scala.

490 points by kushti 9y ago

nnq 9y ago

Just curious, what companies (or kinds of companies) are betting on Scala nowadays? It seems that the people wanting "better Java" all decided they like Kotlin, and the functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more. Who's still in Scala boat? Are Google or Fb or other big cos known to give back to open-source growing any Scala codebases now?

kprybol 9y ago
Scala is used pretty heavily in the big data world, particularly if you are working with Spark.
- joshlemer 9y ago
  Not to mention, Flink, Akka, Apache Beam (via the Scio library or the Java api).
  - kprybol 9y ago
    Kafka too
    - dominotw 9y ago
      Kafka switched to java 100%, afaik.
- bitL 9y ago
  Python is still king there, even DataBricks market it that way. Scala is for advanced stuff that matters.
  - RBerenguel 9y ago
    Python is king in analysis, but for big data engineering, most of the building blocks (as mentioned elsewhere in this thread, Akka, Kafka, Flink, Spark, etc) are written in Scala
    - sandGorgon 9y ago
      It doesn't matter. Because pyspark is still the go-to language. In fact with spark 2.3 python UDF, the performance gap has also reduced. https://mindfulmachines.io/blog/2018/4/3/spark-rdds-and-dataframes https://mindfulmachines.io/blog/2018/4/3/spark-rdds-and-data...
      - RBerenguel 9y ago
        Being able to pass data through Arrow is a big improvement, but there's also a lot of serialisation going on you pay in Python. Also, if you want to do anything in the fancy areas (like, write your own optimisation rule for the SparkSQL optimiser) it's Scala. Even something simple as writing a custom aggregator is impossible in Python (at least it was in 2.2, haven't checked in 2.3 or "current" 2.4)
      - kprybol 9y ago
        It depends on the use case. Our work primarily revolves around extending Spark with custom pipelines, models, ensembles, etc. to be deployed into our production systems (petabyte scale). Scala was really the only way to go for us.
        sandGorgon 9y ago
        I can understand performance difference, but I have not generally seen a difference in building custom pipelines and ensembles .. although I grant I'm not at your scale yet. What kind of specific pipelines did you have trouble in pyspark ?
        RBerenguel 9y ago
phdp 9y ago
I know quite a few finance companies use it - Morgan Stanley and Goldman Sachs come to mind.
pjmlp 9y ago
F# only has access to a subset of .NET deployment scenarios, where Scala can be used pretty much everywhere there is a JVM. So most companies actually are more keen to bet on Scala than F#. OCaml/Reason world lacks the wealth of Java libraries, which are an import away on Scala. Regarding Kotlin, so far its killer use case is targeting Android, where one is stuck with an ageing Java subset. Outside of Android, it remains to be seen how it will keep up with the Java improvements coming up every 6 months now.
- stephen123 9y ago
  Not only on JVM, scala can be used in the browser with scala.js or without a JVM with scala native.
  - GiorgioG 9y ago
    Yep - you're right... F# definitely can't be used in the browser: http://fable.io/ http://fable.io/
- GiorgioG 9y ago
  > F# only has access to a subset of .NET deployment scenarios And what subset would that be? The only place you can't use F# IIRC is UWP application which is likely not the deciding factor in choosing F# or Scala.
  - pjmlp 9y ago
    Anything GUI related, and their respective tooling support on Visual Studio, which it never got. It is still playing catch up with VS 2017 tooling for VB.NET and C#.
    - GiorgioG 9y ago
      If you're waiting for feature parity with C# in VS, you'll never get it. There are millions of C# developers and F# devs are counted in the tens of thousands (sadly) so there's a reason for that. I don't believe most organizations considering adopting F# or Scala are considering them for GUI development so I'm not sure why you'd rule out F# because of that
boubiyeah 9y ago
Scala has an insanely productive and efficient streaming ecosystem with the likes of Kafka and Akka streams. You can use those with other languages but it's not nearly as nice.
- sidlls 9y ago
  Why isn't it nearly as nice? Is there something particular about Scala such that Kafka or Akka are best implemented in it? Could you give some concrete examples (e.g. compare it with Java, C, C++, Rust, Haskell)?
  - chamakits 9y ago
    I think the parent comment was talking more about using those libraries with Scala, not necessarily implementing them. Can't speak too much about the others, but I recently looked into using Akka with Java. Akka itself had a good deal of documentation for Java users. However, other related products (look tools for monitoring Akka, etc) were clearly treating Java as a second class citizen. When there was documentation, it would be outdated, and unmaintained. I ran into this over and over again, which weighted heavily on my decision to not use Akka. I'm not quite sure if there is anything about the language that would have made it particularly challenging (doubt it), but it definitely seems like the community built around it is more Scala centric. And that in itself makes it challenging to use with anything else.
    - sidlls 9y ago
      I took the comment to mean that Scala is the best choice for having implemented, e.g. Kafka, and that other languages somehow aren't suited for it, and asked the question with that in mind.
  - lmm 9y ago
    (Compared to Java, C or C++ there's all the usual ML-family goodness - first-class functions, algebraic data types with pattern matching, type inference). Scala has a for/yield construct similar to Haskell's "do notation", which is the perfect way to work with async code - it strikes the right balance of avoiding an unreadable callback pyramid of doom, but still your async yield points visible (the difference between <- and = is about as concise as it gets, but still very visible). And having HKT and allowing you to express concepts like monads means that a whole library ecosystem can build up of standard operatons operations (e.g. traverse, cataM) that work on async futures and also on other contextual/effecty types (e.g. audit logging, database transactions). That's the big advantage it has over Rust and most other competitors, and it particularly shows in things like Kafka/Akka that need to work with async a lot, but also in large programming projects generally. (What it shows up as in practice is that you can do everything in "plain old code" - all the things that need reflection/interceptors/macros/metaclasses/agents/... in other languages are just libraries in Scala - and that makes development so much easier and bugs so much rarer) Haskell has all that - the trouble with Haskell is that "there's no way to get to there from here". I was able to go from writing Java on Friday to writing Scala on Monday - not great Scala, but working Scala, and I was just as productive as I was in Java. I couldn't've done that with Haskell.
sgeb 9y ago
Here's one datapoint: AutoScout24 (the vehicle vertical of Scout24, a Europe-based digital marketplace) has fully committed to Scala a couple of years ago as part of a re-platforming (microservices on AWS). It's still the recommended default language. Not a "big" company by global standards, but not small either, with around 120 engineers.
joslin01 9y ago
Twitter created a website "Scala School" awhile ago, so I'm guessing they didn't jump ship yet (but could be wrong). https://twitter.github.io/scala_school/ https://twitter.github.io/scala_school/
- joshlemer 9y ago
  Twitter is still very much heavily committed to Scala.
Bizarro 9y ago
Yeah, I don't think Scala 3 changes anything with regards to perception and/or adoption of Scala. That ship has pretty much sailed. Martin Odersky seems like a really good language designer. I took a look at the Scala 3 languages features, and a more radical departure from historic Scala probably would have helped Scala.
- lmm 9y ago
  Three or four years ago the biggest criticism of Scala was that releases were breaking backwards compatibility too much. On this very thread you'll find people worrying that Scala 3 will create a Python 2/3-style endless awkward transition. At this stage it's a mature language with a big established ecosystem, it can't afford to break too radically. (Did you have specific breaking changes in mind? The most important changes I'd want to make to the language - having a syntax for guaranteed-safe equality comparison and guaranteed-safe pattern matching - could be done in a backwards compatible way, and the only other thing I can think that I'd like would be Idris-style totality checking which could also be backwards compatible.)
  - Bizarro 9y ago
    I wouldn't have called it Scala 3. And if I had the big brain of Martin Odersky, 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. I don't follow Scala that much anymore, but it seems that it's mostly a reworking of the internal consistency of Scala from an implementation perspective. At least that was the gist of it I got from watching Odersky give a talk about it a couple years ago.
    - lmm 9y ago
      > 5 years ago I would've had started thinking about an intermediate step in programming productivity, correctness - instead of doing Doty. Wait what? In the last post you were complaining it was too close to existing scala, now you're saying it's too big a step? Again, what is the change you're actually advocating?
afroboy 9y ago
Twitter now is running its Scala code on GraalVM.
- polskibus 9y ago
  Woah, can you provide a reference? I'm curious about the rationale and performance implications.
  - ErunamoJAZZ 9y ago
    https://twitter.com/graalvm/status/986587968667291648 https://twitter.com/graalvm/status/986587968667291648
    - polskibus 9y ago
      Did you find any benchmarks with hard numbers regarding performance improvement?
misja111 9y ago
> Just curious, what companies (or kinds of companies) are betting on Scala nowadays? LinkedIn, Twitter, The Guardian, Morgan Stanley, Barclays, Zalando. Generally speaking, Scala is used a lot by companies involved with Big Data (because they use Spark).
- sulam 9y ago
  I’m not sure if your info is dated or mine is, but all the systems development at LNKD that was being done in Scala is now done in Java. There is some legacy Scala still but as of a couple years ago they decided no new development. Perhaps they are still using Scala in a data science context, since it is hard to avoid there, these days.
  - sidlls 9y ago
    It's trivial to avoid it in data science, with even modest to large (although not "Big") data in the few TB range. My data science team's entire stack is basically Python, with a smidge of Java and Rust for infrastructure (soa, pipelines) development.
    - sulam 9y ago
      I almost added the clarifying statement "on the JVM" but got lazy. Yes, Python is the obvious choice for data science until you hit a certain scale. It's not even clear to me that most companies doing data science in Scala have that scale -- they're just using tools and libraries companies at that scale have open sourced. You could call it cargo culting, but I think it's more nuanced than that. I think engineers can be separated into two camps roughly: those who are passionate about the language(s) they use, and those who are simply trying to get the result they need and don't care what language they use to get it. A lot of data science engineers naturally fall into the second bucket, so using Scala because a library they want to use is written in it comes naturally, even if they could get the job done in Python (possibly with a bit more wheel reinvention).
      - sidlls 9y ago
noelwelsh 9y ago
Interesting that you see it that way. I see Haskell and Purescript usage growing, and I don't know many people interested in O'Caml / Reason. Not trying to say you're wrong---just commenting on the effect of our respective filter bubbles. As for Scala usage. I'm a Scala consultant, so I'm biased, but I'm seeing a lot of adoption. Most finance companies and most media companies are using Scala.
joneholland 9y ago
Expedia is a big time scala shop, but new stuff is trending towards Kotlin.
dudul 9y ago
F# and OCaml? What source do you use to say that? Scala is way more popular in the industry that these 2 combined.
CookWithMe 9y ago
I'm working since 3 years at a growing startup that has been hiring Scala Engineers at least every half year since I started. In the last ~18 months, the amount of CVs we're getting has been constantly increasing. Part of that is probably that our startups hiring matures, but it's also the kind of CV that is changing. I'd say that 3 years ago, there was an 80% chance that the applicant was highly self-motivated to learn Scala in their freetime, and tried/did introduce it at his/her current workplace. Today, there is an 80% chance that the applicant either "had to" learn it in their current workplace, or learned Scala when switching jobs. (Don't get me wrong, they're still motivated, and they took the chance when it was there!) So there is a switch from the Early Adopters to the Early Majority (where the Early Majority now has worked 1 or 2 years with Scala at their current job, and is confident enough to look for a new one). One driving force was definitely Spark, but there are a lot of Enterprise apps, unrelated to ML (usually with higher traffic requirements). The sort that would have most likely been done with Java or C# 5 years ago. It seems a lot of Enterprises introduce Scala when they try to break up their (Java) monolith into microservices. So it seems that Scala has been carving out it's place in backend/microservices with scalability requirements, and is eating part of Javas cake there.
saosebastiao 9y ago
I still think Scala is a better better-jav than Kotlin, but Kotlin captures that market better because of the much lower learning overhead. I'm much more of an ML-style programmer, but the thing keeping me away from OCaml is the lack of a multicore runtime. Not only is Scala's concurrency mature and performant, implicits (like having an ExecutionContext) make it extremely easy to use. Even if OCaml released it's multicore runtime today, it would take years to get to the maturity of the Scala ecosystem. Plus, occasionally I run into areas where OOP really blows away functional programming. It's nice to not have to learn a new language for those occasional times.
- yawaramin 9y ago
  OCaml fully supports OOP (the 'O' in OCaml).
JackFr 9y ago
> It seems that the people wanting "better Java" all decided they like Kotlin I've been using Java and Scala exclusively for the past 10 years at two large NY banks and two fintech start-ups, and I literally do not know anyone who has ever compiled a Kotlin program. Simply extrapolating from one's own experience is fraught with peril.
bad_user 9y ago
N.B. Scala and its ecosystem is actually a lot more oriented towards FP than F# or OCaml for that matter. Its popularity also far surpasses F# and OCaml in jobs available, books, libraries or other metrics that count.
dbattaglia 9y ago
We use Scala as the primary backend language at Elastic for the Elastic Cloud SAAS & enterprise products (along with Java, Python and Go).
dominotw 9y ago
> functional programming people now gravitate more towards either F# (for .NET ecosystem) or OCaml/Reason (for the more unixy world). And the academic/research/learning crowd seems to like Haskell more What if you want functional programming without having to go to MS stack and stay on JVM. You only have have two real options clojure and scala.
SOLAR_FIELDS 9y ago
If you make heavy use of Spark there is still no better language/ecosystem than Scala.
applehire 9y ago
We use Scala heavily. If kafka/Spark/Monoids/Semigroups/Cats/Algebird makes any sense to you and you are looking for a job, send your resume to mansur.ashraf@apple.com
aphexairlines 9y ago
Here are a bunch of job postings at Amazon citing that they use Scala: https://www.linkedin.com/jobs/amazon-scala-jobs/?country=gb https://www.linkedin.com/jobs/amazon-scala-jobs/?country=gb https://www.indeed.co.uk/cmp/Amazon.com/jobs?q=scala&l=London%2C+Greater+London https://www.indeed.co.uk/cmp/Amazon.com/jobs?q=scala&l=Londo... https://www.amazon.jobs/en/search?base_query=scala&loc_query= https://www.amazon.jobs/en/search?base_query=scala&loc_query...

AzzieElbab 9y ago

Great news! Kind of confused about scala2 and 3 sharing the same standard library. I thought that was being redesigned.

modersky 9y ago
The shared library we are talking about is the upcoming 2.13 library, which has the new collections design. We currently link against the 2.12 library but will switch to 2.13 once that comes out.
- dhuramas 9y ago
  Just wanted to say- thanks for your great work in making Scala possible. And wanted to add that going through your Scala Functional Programming MOOC was one of the most rewarding experiences.

rb808 9y ago

Its fascinating process where if you're a hot new language you attract a lot of people that like shiny new things. When the next hot new language comes along and those people move on - have you attracted enough of the secondary wave to keep alive? Its going to be interesting to watch Scala adoption in the next few years.

devit 9y ago
Don't think it has a bright future since Rust and Kotlin share much of what brings people to Scala and are better in many ways, including and perhaps most importantly the fact they are improving faster than Scala.
- jvican 9y ago
  I challenge the fact that Rust and Kotlin are improving faster than Scala. Scala is not only more stable, but is under active development and there are lots of discussions to improve the language over time (check our SIP meetings). Kotlin doesn't even get closer to what Scala is, and Rust is for those folks with the mentality that memory management is something worth keeping track of.
  - Cyph0n 9y ago
    Also, from my understanding, Kotlin is tied to the Intellij ecosystem, so open source tooling is lacking when compared to Scala.
    - pjmlp 9y ago
      More than that, if you want Kotlin/Native debugging support, you need to either buy Clion or AppCode, as it is not available on the community edition.
      - Cyph0n 9y ago
        Charging for debugger access sounds so 90s lol

dzdt 9y ago

My big question (not answered in the FAQ) is will it be faster or slower than Scala 2.12? Having worked on a big Scala codebase, the slow compiler speed is one of the biggest downsides to the language.

mping 9y ago
There was experimental work to see how fast a scala compiler could be, but I think it's still far from production ready, was more of an experimente: https://github.com/gkossakowski/kentuckymule https://github.com/gkossakowski/kentuckymule
modersky 9y ago
It's currently about as fast as Scala 2.12, which means it compiles at roughly 3000 lines/sec. However, it supports more aggressive incremental compilation than Scala 2 so at least in my projects, which are typically 50K to 100K lines, most compiles are under a second, and I rarely see compile times over 5 seconds. There's ongoing performance work to make both Scala 2 and Scala 3 faster than they are now. A lot of what people perceive as slow compile times are actually other factors (such as inefficient macros or slow build tools).
- jvican 9y ago
  > However, it supports more aggressive incremental compilation than Scala 2 I'm not sure what you mean here... but Scala 2 and Dotty have the same incremental compiler, and their independent bridges feature overall the same quality (which is high and heavily battle tested, for those interested).
  - Cyph0n 9y ago
    I'm not sure if you noticed, but you are replying to the designer of Scala.
    - JiminHsieh 9y ago
      I think jvican noticed this. jvican is the engineer from Scala Center which is supported by EPFL. Edit: typo

quantumwoke 9y ago

This major breaking change to the language reminds me a lot of the Py2-Py3 fiasco. I wonder how Scala's community will handle the transition given the previous issues with cross compilation in the 2.x series. Given the multitude of language alternatives in a similar space to Scala, I'm worried. Fingers crossed they can work through this.

azernik 9y ago
Static typing makes this kind of large-scale refactoring a LOT less scary.
jhomedall 9y ago
Scala 3 will still be able to use Scala 2 libraries, so it won't be quite as bad.

mavdi 9y ago

> Simplify where possible > eliminate inconsistencies and surprising behavior Oh dear god please.

realusername 9y ago
I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.
- deleted 9y ago
  [deleted]
- willtim 9y ago
  The Scala team appear to have their hearts in the right place. They seek to empower their users and have respect for them. I can't really say the same about the Go team, based on at least one Google presentation I have seen. This isn't that surprising given the goals of the projects.
  - realusername 9y ago
    I did not want to start a flame-war Scala vs Go, it's just that I like Go simplicity & readability (I also like Python and Ruby for those reasons as well) whereas I'm not a huge fan of the Perl feeling of Scala.
    - willtim 9y ago
      When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
      - 9y ago

rilut 9y ago

Is there any plans to include async/await on the language level?

azernik 9y ago
async/await is a special case of monads (expressible with a for-comprehension); it comes out to: def asyncFunction(): Future[Blah] = for { foo <- someAsynchronousOperation bar <- anotherAsynchronousOperation } yield bar.baz
- saosebastiao 9y ago
  I find async/await to be much better for conditional execution, especially with lots of branches. For example, I had a scenario where I tried one async call and if it didn't have the information I needed, I had to make two subsequent async calls to get the information I needed before proceeding with the final call. Monadic composition was a nightmare where async/await was perfectly suited to the task.
- clhodapp 9y ago
  For comprehensions are currently tremendously limited vs async/await. They constrain the top-level of your code structure to a tiny subset of the language.
modersky 9y ago
We will check first whether they can be expressed as a macro (the macro roadmap for Scala 3 is still evolving).
- 62747478182 9y ago
  There is https://github.com/scala/scala-async https://github.com/scala/scala-async, which is already implemented as a macro, though it is a bit limited

deleted 9y ago

[deleted]

viach 9y ago

I was really hoping they implement python-ish syntax https://github.com/lampepfl/dotty/issues/2491 https://github.com/lampepfl/dotty/issues/2491 But no, "Implicit Function Types" instead. Ok.

Cyph0n 9y ago
So your biggest complaint is "Scala doesn't look like Python"? I mean, I love Python, but indentation-based syntax isn't that great. I think Scala is fine as it is.
- willtim 9y ago
  Being brutally honest, compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose. I'm almost certain its creators chose the syntax in order to tempt curly-bracket programmers, not because they liked it personally. I really hope that future high-level languages will use better syntax and move on from the C/C++ influence.
  - Cyph0n 9y ago
    > compared to Haskell, ML and to a lesser extent Python, Scala's syntax is rather ugly and unnecessarily verbose I have never worked extensively with Haskell or ML, but what I can say is that Scala's syntax is better than that of most other mainstream languages. Three of Scala's syntax niceties are: 1) No semicolons 2) No braces required for one-line functions 3) No constructor required: instance arguments passed in class declaration
    - s4vi0r 9y ago
      To add onto this, its not one line functions but rather functions whose body is a single expression. You can do a big for comprehension, or a if/else, or a big chain of function calls, etc. without having to add brackets. In practice you often end up not really using braces that often when writing FP style Scala.
    - 9y ago

_Codemonkeyism 9y ago

[deleted too many fanboys on HN]

lmm 9y ago
> Also many open source libraries in Scala land have a very short life time and will not be upgraded to Scala3. No problem with Java, but it will take months for many larger projects to remove Scala2 library dependencies from their code base. The announcement says Scala 3 will be able to call Scala 2 libraries, so even if you're right (which is not my experience of open-source Scala libraries at all FWIW) this won't be an issue.
- _Codemonkeyism 9y ago
  Yes I've read that point, but a.) it means not 2 but 2.12 b.) what happens if the 2.12 class file depends on old Scala library code? "this won't be an issue." After a decade of Scala usage and a several 100k line project to code on, I'll believe it when I see it.
  - lmm 9y ago
    > what happens if the 2.12 class file depends on old Scala library code? Not possible - 2.12 is source- but not binary-compatible with 2.11, any "2.12 class file" will only have 2.12 dependencies. So we're talking about the release planned for 2020 having binary compatibility back to 2016 and source compatibility back to 2014. Not the same level of backwards compatibility as Java by any means, but better than many languages offer.
- _Codemonkeyism 9y ago
  What web framework are you using? Both Lift and Play had major migration problems over the last 5 years due to cutting off support for older Scala versions.
  - lmm 9y ago
    A mix of spray/akka-http for REST backends (looking to shift to rho) and Wicket for HTML UIs. I don't think Play makes good use of Scala's strengths (frankly it didn't seem like very good code), and I didn't even realise Lift still existed.

dserban 9y ago

There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different perspective based on my own work with OOP-centric and FP-centric languages. If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs. If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. Both are equally valid ways to design complex applications, so it all comes down to individual taste. Personally I have a taste for mathematical abstractions, so Scala is better suited for my way of thinking. It's obvious that Scala was specifically designed to be a solid foundation on which one can implement the concepts of a little known branch of mathematics called the category theory, and almost every design choice in the language flows from there. If we use this as the basis for comparison to other languages, it's very easy to understand that Scala has carved out a very powerful niche for itself and is here to stay.

jowiar 9y ago
I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured community.
- nextos 9y ago
  Designing good multi-paradigm languages is very hard. I'm a big fan of Mozart-Oz and Common Lisp, and I think Odersky did a really good job with Scala. In fact, given that Common Lisp is languishing and Mozart was never a serious real world contender, Scala fills in a niche where there are not many competitors. C++, just for some use cases, Julia for others, and .NET. The fact that many organizations working on massive datasets have embraced Scala proves there are not many alternatives around, sadly.
  - auvi 9y ago

framebit 9y ago

I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT. [1] https://github.com/lihaoyi/mill https://github.com/lihaoyi/mill

stephen 9y ago
sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.
- lmm 9y ago
  I've never understood what SBT was supposed to solve in the first place. A Maven plugin that supports cross-building, which we're finally now getting with Scalor, seems like what the language actually needed.
  - tomerbd 9y ago
    https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html https://www.acronymfinder.com/Sucks-Big-Time-(SBT).html
- lomnakkus 9y ago
  The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools. The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be retrofitted into, say, SBT or Gradle.
  - stephen 9y ago
    Gradle does have a build cache, which can be local or remote: https://docs.gradle.org/current/userguide/build_cache.html https://docs.gradle.org/current/userguide/build_cache.html It is a newer feature, so that might be why you're unaware of it. Also, I get that the models of Bazel/Buck/Pants are fundamentally different, because they are inherently cross-language / "sit on top of other compilers" systems. And are best for mono repos. But Mill doesn't fit in that camp AFAICT.

coryfklein 9y ago

So many cool things already done and even more to come. Some parts that excite me as a Scala nerd: * One can now use implicit function types to basically build your own table language syntax that is type-safe. [1] * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2] * Null safety checks! Quoting from [3], "Adding a null value to every type has been called a "Billion Dollar Mistake" by its inventor, Tony Hoare. With the introduction of union types, we can now do better. A type like String will not carry the null value. To express that a value can be null, one will use the union type String | Null instead." * First-class enums, finally. [4] * Erased parameters: you can declare variables specifically for type-safety that _don't exist_ during run-time, improving efficiency. [5] [1] http://dotty.epfl.ch/docs/reference/implicit-function-types.html http://dotty.epfl.ch/docs/reference/implicit-function-types.... [2] http://dotty.epfl.ch/docs/reference/multiversal-equality.html http://dotty.epfl.ch/docs/reference/multiversal-equality.htm... [3] http://dotty.epfl.ch/docs/reference/overview.html http://dotty.epfl.ch/docs/reference/overview.html [4] http://dotty.epfl.ch/docs/reference/enums/enums.html http://dotty.epfl.ch/docs/reference/enums/enums.html [5] http://dotty.epfl.ch/docs/reference/erased-terms.html http://dotty.epfl.ch/docs/reference/erased-terms.html

lmm 9y ago
> * Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2] Unfortunately it's being introduced in a fail-unsafe way that as far as I can see makes it virtually useless. If I see "x == y" in code, I have no way to be confident that this isn't an old-fashioned universal comparison without going into the details of x and y, so I'm no better off than I was without this feature.
- coryfklein 9y ago
  Yea, I'd love a compiler switch that enables the strict mode globally, while adding the leniency on a case-by-case basis instead.

stephen 9y ago

...ships in 2020? I'm impressed with what they're doing (and love the language), and it's hard work, and their speed is faster than, say, Java's dead-pace evolution in the 2000s. But, poking around at TypeScript, I've been blown away with the MS/TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique/novel type system features, not like Java finally getting around to copying the obvious/best-practice approach to case/data classes. Granted, I'm sure the MS/TypeScript budget is huge comparatively... Seems like that's the "best" (realistic) way for dev tooling to evolve lately: come from, or attach yourself to, a ~top-5 tech company that makes their money somewhere else and can bankroll developer tools/languages (e.g. MS with TS, FB with React/Flow, Google with a myriad of things e.g. Dart & AdWords, Go). Bringing it back to Scala, seems like they were close to this (flirted with adoption/sponsorship from a few startups like FourSquare, etc.) but, thinking about it now, "software development in the large" is a huge concern for those companies (e.g. anyone with enough extra money to actually pay for language/tooling improvements), and that's never really been Scala's strong suit (compile times, painless compiler upgrades).

manojlds 9y ago
It's not the next release. There is 2.13 and 2.14 to be released. Are you saying Typescript has major version release every 3 months?
- actsasbuffoon 9y ago
  Typescript does indeed do frequent releases, though they're not nearly as ambitious as Scala 3.0. A Typescript release usually has 1-3 exciting new features, and a number of smaller bug fixes and improvements.
  - benjaminjackman 9y ago
    Correct, but collectively, between now and 2020 it's almost certain in aggregate, Typescript will have significantly more `features` than Scala 3.0, and they will have the benefit of being used and iterated upon for 2+ years.

jrq 9y ago

Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. I used to write a lot of scala, and working with sbt was enough to eventually get under my skin. I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract new learners, especially with just how overwhelming all the different features can seem for someone not coming from both sides. I had ocaml and ruby under my belt when I found scala, so it was an easier curve, but lots of guys struggle with it. I don't mind showing them, and of course I learn a lot from guys with different experiences and different backgrounds, but that's sometimes a complain I hear, also. It's a language that doesn't compare very well. What is scala like? We don't know, there's only one language like it, it's a departure from many different paradigms. I'm back to writing ocaml, all said and done. I enjoyed my time with scala, and interacting with my guys on the other side of the office still doing scala is always enjoyable. Smart guys! I'm not academic enough to grasp some of the new DOT stuff, but they are excited about it. Anyways, I gave up hope a while back on scala getting rid of sbt. There are other build tools that exist, cbt, mill, maybe more, but without the blessing from lightbend or whatever they call themselves this week, it's not feasible, or responsible to deliver a solution to a client with an unofficial build setup. Of course, after five years of doing sbt I decided it's not ok to deliver sbt either. Someday! Maybe?!

gaius 9y ago
The thing with Scala if you’ve come from OCaml is there’s no substitute for real Hindley-Milner, and the Scala object system isn’t good enough to compensate
- throwawayjava 9y ago
  Does anyone use Scala in cases where OCaml is a viable option? My impression has always been that Scala is "better than OCaml if you need the JVM"
  - jrq 9y ago
    Mainly Spark, but it really depends on the domain, what libraries exactly that you'll need, hell I look at what kind of deployment routine the client wants, what their maintenance crew looks like compared to what they want from me. There is plenty of scala in fintech, I can tell you that. But there's plenty of ocaml, f#, matlab, excel macros, r, kdb, cobol, fortran, c++, a vast array of different technologies. Most places that choose scala are choosing it over erlang or Java or c#, they USUALLY only choose scala over ocaml if they want to have some old ocaml code talk with new infrastructure that they want built in scala, ime. Because of how performance works and that multi core isn't working yet, ocaml is limited in application if they're willing to find or already have scala programmers.

virmundi 9y ago

How have people faired with Scala integration with Java libraries? When Scala first came out, I liked the idea. If I wanted to use X library, great, I can. As I pondered it more, this seemed terrible. Say I hug the functional side of Scala. I know what I'm doing. Then I hire a Jr Dev. She comes from the world of Java/Python where functional is no as big of thing (keeping in mind that while Python does support, to a degree, functional, many use it as a procedural/OO language in school). Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code. Side effects could start to show at odd times, which makes debugging terrible in a production environment. All that said, how have others dealt with this issue? Did you just not work directly with Java libraries? Did you use the OO side as a Better Java?

Cyph0n 9y ago
When interacting with a Java library, I use scala.collection.JavaConversions to convert any Java structures to the equivalent Scala collection. Once I'm done operating on the collection (map, filter, etc.), I convert it back to Java.
- nicktelford 9y ago
  You should be using scala.collection.JavaConverters instead, as it makes the conversion explicit (by adding a ".asScala"/".asJava" method to collections). Implicit conversions (i.e. where a type is silently converted to another type) is dangerous and can lead to very surprising problems.
  - Cyph0n 9y ago
    Whoops, my bad about that. I was on mobile and forgot which of the two provides `.asScala`...
dtech 9y ago
> How have people faired with Scala integration with Java libraries? It's useful because the JVM ecosystem is much larger than the Scala ecosystem. There's almost always a library for your purpose. If it isn't as idiomatic Scala as you'd want you can often easy create a small wrapper. > Suddenly I have to worry about the Jr Dev doing silly things like introducing mutable Java objects into functional code. code reviews and education

merb 9y ago

Well it won't solve the biggest problems with interop https://github.com/scala/collection-strawman/issues/283 https://github.com/scala/collection-strawman/issues/283 (sadly). I mean I can understand all the reasons not to, however It's just a pita that there is no sane way to do it, besides reimplementing either two api's or come up with your own collections.

dtech 9y ago
Is this really such a big problem? You can either work directly with the Java collections if the code is performance sensitive, or have a `.toScala` call at your Java -> Scala boundary and a `.toJava` call at your Scala -> Java boundary.

room271 9y ago

As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow). Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.

jvican 9y ago
At the Scala Center we’re working on addressing these problems. We now have working groups devoted to ease coding in Scala and make it easier for any dev to use any build tool.
- room271 9y ago
  That's great news! Thanks for the reply.

DandyDev 9y ago

It's amazing how many people in this thread justify their own language choices by making negative, sweeping statements about another language (Scala in this case) that is successfully used by people other than themselves. Yes, some people who previously used Scala, now use Kotlin. And some people who would've used Scala if Kotlin didn't exist, use Kotlin. Same probably goes for Rust. But there is a big enough market for people that like the intricate and expressive type system that Scala gives you, in combination with the JVM ecosystem. People that think Kotlin is nice, but not expressive enough, for example. People who don't want to deal with Rust's memory management and/or don't have a use for that. People who think Go's simplicity is sometimes more of a burden. Why are people so intent to bash sombody else's language choices?! Go, Rust, Kotlin, Scala are all great languages in different ways. They all cater to different needs, sometimes radically different (Go vs Scala), sometimes subtly different (Kotlin vs Scala). I think there is a market for all of them, and more. And the introduction of a new language (Kotlin for example) does not necessarily spell doom for another (Scala). Let's all enjoy our own tastes and needs, and respect those of others.

lmm 9y ago
The reality is that a language lives or dies by its ecosystem - particularly when it comes to a language like Scala that's in a tightly symbiotic relationship with its IDEs (the next time someone tries to sell you a "visual programming language", look at Scala for a language that makes really effective use of the GUI for programming without compromising the things that make textual programming languages good - see e.g. https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-plugin-2018-1-inline-hints-better-structure-view-improved-refactoring-and-greater-usability/ https://blog.jetbrains.com/scala/2018/03/27/intellij-scala-p... ). Only a few big players can afford the kind of investment it takes to make something like that. So much as I wish it were otherwise, I can't just sit on my island and use Scala because I think it's the best - if the language is to live, I have to convince other people it's the best. I don't begrudge other people feeling the same way about the languages they do like (provided that doesn't fall into dishonesty, as some of the claims from Kotlin advocates about e.g. null and Scala have).
- MichaelMoser123 9y ago

sriku 9y ago

"Scala has pioneered the fusion of object-oriented and functional programming in a typed setting." What about Ocaml (1996, well before scala) and F# (2005, not too long after scala)?

lmm 9y ago
OCaml users tend to avoid its object system, so while it attempted to fuse object-oriented and functional I don't think we can say it succeeded. F# is, as you say, later.
- yawaramin 9y ago
  OCamlers tend to avoid OOP mostly because we can get away with modules, functors, polymorphic variants to model subtyping, and now also GADTs and open variant types to precisely model and add cases. When we do need to use it, it is actually pretty elegant and well-designed. It's just that since we've tasted the power of the more functional abstraction techniques, OOP loses its allure.
  - lomnakkus 9y ago
    Indeed. I think that what OCaml proved is that the "O" isn't actually necessary. :)

tytytytytytytyt 9y ago

> become more opinionated by promoting programming idioms we found to work well Which idioms exactly?

clhodapp 9y ago

> Scala 3 code can use Scala 2 artifacts because the Scala 3 compiler understands the classfile format for sources compiled with Scala 2.12 and upwards. I feel like this isn't getting much attention but it is a huge deal. A big part of the reason that Python 3 went the way it did was users didn't want to upgrade until their libraries did and libraries didn't want to upgrade until their users did. With Scala 3, users can upgrade pretty rapidly, freeing libraries to upgrade without fear of leaving their users behind.

amckinlay 9y ago

Last time I tried Scala I had to give up because I couldn't understand what a "trampoline" was, or how to use it to get multi-function tail recursion to work. Probably not Scala's fault.

mrucci 9y ago
I found this blog post to explain trampolines quite well: http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and...
ionforce 9y ago
What level of Scala were you trying? The things you're referring to don't sound pedestrian at all. You shouldn't let them turn you off from ALL of Scala.