28 ms·

What's Next for Scala

299 points by arbhassan 6y ago

rethab 6y ago
I'm particularly interested in how this plays out with dotty. My understanding was that lightbend was at some going to take over that compiler from EPFL, but taking over a compiler (the second, besides the current/old one) at the same time they are laying people off?
- AheadOfTime295 6y ago
  Announcement on Dotty as the future Scala 3 came from Scala Center (EPFL) not Typesafe/Lightbend. AFAIK Typesafe/Lightbend has made no commitment to Scala 3. Too bad the roadmap for Scala 2.14 has been scrapped.
  - spir 6y ago
    I've worked with Dotty a bit and read about it a lot. I am very excited about Scala 3 :) Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the get-go. I expect that most Scala programmers and companies will want to write Scala 3 code asap. Within the Scala community, the only truly divisive aspect of Scala 3 afaik is the introduction of optional python-style and Haskell-style syntax with significant whitespace. I was stridently against significant whitespace and now prefer it after having tried coding Scala 3 for awhile.
    - jmeister 6y ago
      Thanks for this info, very useful and exciting. I stopped using scala around 5 years back, want to get back to it. Would you recommend jumping straight to dotty? I’ve been doing a mostly python and a bit of Haskell in the meantime.
      - spir 6y ago
        I'd jump straight to dotty! You may as well learn the latest 'n greatest.
    - jane_red 6y ago
      > It will take years for large codebases to be upgraded to Scala 3 Which for production level code bases means never. I can't even imagine what we are going to do with our 7 year old Scala code base.
      - vvillena 6y ago
        It's the Java 1.4/Java 6/Java 8 problem all over again. Big companies refuse to keep up with the base languages, and important parts of the ecosystem (e.g. Spark) fall behind the language.
  - maddening 6y ago
    2.14 was supposed to be a stepping stone between 2 and 3, released only so that migration could be easier. They skipped it because apparently source code differences between valid 2.13 and 3.0 aren't that great. From what I saw it is mostly about migrating macros, the rest most likely would still work.
totalperspectiv 6y ago
As one of those new people boosting recent numbers, Scala is great! I use vscode with Metals and had no jvm experience before. sbt is annoying, Mill seems super promising, and graalvm native images basically mean that if I was going to do it in python, I might as well use scala now.
- walkingolof 6y ago
  Scala 3 have a Python feeling over it with optional braces indentation (https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html https://dotty.epfl.ch/docs/reference/other-new-features/inde...) I wrote an example using this new (optional syntax) https://github.com/olofwalker/ting https://github.com/olofwalker/ting, if anyone wants to have a look.
  - 3fe9a03ccd14ca5 6y ago
    Maybe it’s just me, but “optional” is a word I hate seeing in language design, because I’m thinking of how many code reviewers I’ve met that have a hard time with “optional”.
  - discreteevent 6y ago
    It's been about 10 years since I did some work with Scala. I really like the syntax and the way your project uses it. Seems immediately legible and simple.
- tlarkworthy 6y ago
  I just use maven for Scala compilation. I want to avoid Turing computable build tools (yes I know u can load plugins with maven but it is at least stiving for a declarative model)
- mchisto 6y ago
  What's your problem with SBT? I've been using IntelliJ + SBT since I started with Scala and it has been working well for me.
  - 6y ago
AheadOfTime295 6y ago
Farewells piling up: Six years at Lightbend, by Eugene Yokota (Scala sbt, scalaxb, scopt) https://news.ycombinator.com/item?id=22836399 https://news.ycombinator.com/item?id=22836399
trevyn 6y ago
>it seemed to peak around 2016 https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=scala,golang,rust https://trends.google.com/trends/explore?cat=5&date=all&geo=... Early 2017, perhaps! Are Go and Rust seen as competitors to Scala?
- capableweb 6y ago
  Remember that Google Trends just measures search traffic. Also, handy tip, select "Programming Language" instead of "Term", the graph changes slightly with that: https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=%2Fm%2F091hdj,%2Fm%2F09gbxjr,%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?cat=5&date=all&geo=... Another tip, by default Google Trends just show data from the US, which is not very interesting, select Wordwide to get a better picture: https://trends.google.com/trends/explore?cat=5&date=all&q=%2Fm%2F091hdj,%2Fm%2F09gbxjr,%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?cat=5&date=all&q=%2... Competitors are hard to say as there would different categories. Some workplaces would only choose a JVM language, then Scala's competitors are Java itself, Clojure and alike. Go and Rust have mainly been described as "system" languages but they take vastly different approaches from each other. If you be a bit more specific on what you're compared them on, it'll be easier to know if they are competitors or not.
- ashtonkem 6y ago
  Depends who Scala was a competitor to. If you viewed Scala as a competitor to Java, then Go is a competitor to Scala and not Rust; because Go is a competitor to Java in my opinion.
  - pjmlp 6y ago
    Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries. If Go 2.0 ever happens, it will be a competitor to Java 5.
    - ashtonkem 6y ago
      So, it depends on what you’re talking about; language or organizational need. Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you’re talking about how teams use Java and Go, they’re a good match now. Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and moving them around. From an organizational perspective there are a ton of Java shops that use Java for similar reasons, plus the ability to cheaply and quickly acquire contractors who know Java.
AheadOfTime295 6y ago
For context see Lightbend secures 25MM funding round, proceeds to layoff Scala contributors https://news.ycombinator.com/item?id=22842166 https://news.ycombinator.com/item?id=22842166
- marvy 6y ago
  I don't follow Scala (never wrote a single line), so I didn't realize the company changed names from Typesafe to Lightbend. Here's a question: how on earth do they make any money? The Wikipedia article makes an offhand mention of something called Lightbend subscription; is that what keeps them afloat?
  - joshlemer 6y ago
    A lot of it is consulting, and they also have some proprietary and/or hosted services, and even akka plugins that they charge for.
    - marvy 6y ago
      thanks
- dang 6y ago
  Also https://news.ycombinator.com/item?id=22836399 https://news.ycombinator.com/item?id=22836399 ("Six years at Lightbend")
pjmlp 6y ago
Since the post mentions Scala Native, all these guest language projects that eschew the platform that made them famous and try to pursue the dream of being their own platform, while building an ecosystem, GC and optimising compiler from scratch (even if they build on LLVM or compile via C/C++), would be much better taking advantage of AOT and JIT caches from several JVM implementations instead of pretending they don't exist.
- kasperni 6y ago
  Looking at the commit log, Scala Native looks pretty dead https://github.com/scala-native/scala-native/commits/master https://github.com/scala-native/scala-native/commits/master
  - maddening 6y ago
    Previous maintainer left EPFL so nothing was happening there. But Scala Center took over the project so they will start maintaining it. AFAIR snnouncement was on Gitter by the same guy who maintains Scala.js. I guess it will take some time for them to catch up with the rest.
- spir 6y ago
  In my mind, GraalVM native compilation has superseded scala-native. GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect. Scala is now a great choice for CLI tools.
  - vbezhenar 6y ago
    > The native executables are slim What's the size of hello_world.exe?
    - LandR 6y ago
      Dunno about Scala, but Clojure - another JVM language, has a GraalVM native executable for Hello WOrld about 8MB. Not that slim.
wiradikusuma 6y ago
I love Scala! It's the language that enlightened me and be more productive. Now, every time I code in other languages (e.g. Dart for Flutter, or JS for web stuff), I grumble when I can't find "standard" features such as "map", pattern matching, optional and named params, implicits. Also, when I code in Scala, I frequently google and end up learning something new about the language. I know it sounds like distraction/wasting time, but there's a certain satisfaction when I found the "Scalaic" way of doing things, like, "There's gotta be a one-liner way of doing this." Of course, my complain is still compile time (yes it's significantly faster, but I'm impatient).
- erton23 6y ago
  You would be enlightened the same way or even more if you started with Haskell. That is, it is not Scala you are so excited about but the functional programming. Btw, the actual thing to be inspired with in Scala is immutability and Option/Some/None instead of null. These are the things that make you code stable and reliable.
_bxg1 6y ago
> It's not Clojure-dead What does this mean? I thought Clojure has a dedicated, if small, user base.
- diggan 6y ago
  I guess in the authors mind, dead here means it's stable, solves its problems well and doesn't try to attract developers with shiny new features but instead focuses on enhancing the core experience which gets better. As a Clojure/Script developer, I could understand that Clojure looks dead from the outside if you're a JS developer, you're used to new language features being shoehorned into the language every year. But for someone inside the Clojure ecosystem who used to be a JS developer, it's a breath of fresh air when I can take a 4 year old library and include it, everything works and no bugs are to be found. If there is a bug, I can patch it from the outside, if I really have to. Clojure in general lends itself very well to be extended from the outside (like what clojure.spec is currently doing [and many others]) so the core language doesn't really have to change anymore, we're just building libraries on top of the language which extends the language.
  - _bxg1 6y ago
    The dig at JS developers is completely uncalled-for. I'm a JS developer and I admire the way Clojure has seemed to skip both the hype and disillusionment phases and jump straight to the productivity plateau.
    - simongray 6y ago
      Clojure did have quite a bit of hype 5-10 years ago and a bit of slowdown in 2017-2018 where this meme of "Clojure is dead" probably started.
      - rlander 6y ago
        Agree. But slowdown in internet hype doesn’t mean slowdown in industry adoption though.
3fe9a03ccd14ca5 6y ago
Scala has the reputation of being fun to create stuff with, but horrendous when understanding other people’s creations. Is this still true?
- spir 6y ago
  It's less true now because some of the patterns associated with code that's difficult to understand have been deprecated or flagged by the community to avoid. For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern. Another example is that it's now (more or less) recognized within the community that it's not preferable to dogmatically adhere to a particular style of programming, such as pure functional or reactive/actors. It's better to use the right tool for the right problem. Whole classes of confusing code are now prevented or mitigated by language changes in Scala 3. For example, Scala 2's implicits are famously hard to learn and follow within a codebase. One reason for this is that in Scala 2 the keyword "implicit" was overloaded into a few common patterns, including the aforementioned implicit conversions, typeclass instances, and dependency injection. Scala 3 introduces new constructs and keywords to split out these patterns into separate language features, making them easier to learn and more understandable within a codebase.
  - smabie 6y ago
    > For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern. I don't have experience with Scala 3 or Scala 2.13, but I don't believe this is true. Implicit conversions cannot be applied more than once.
  - EdwardDiego 6y ago
    > For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern. Oh God I'm having flashbacks to using Lift in... 2012? There were about four levels of implicit conversions between my model and the final JSON, trying to understand that was hard. That said, David Pollak the founder of Liftweb was amazingly helpful on on their mailing list.
seahawks78 6y ago
I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following: 1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes. Nothing wrong with that. But that also means language features are added not to solve a practical problem but mostly to show that "it can be done"/"prove a point". When you are awake at 3 AM early in the morning because a release made in the evening went awry and you are trying to grep though logs/code to see what caused the issue I can assure you that debates about "pure" versus "impure", Monads, Kleisli arrow will be further from your mind. So the problem that Scala seems to suffer from is that of "image". 2) Second, Scala is neither a fully functional (FP) nor object oriented (OOP). Support for mixed/multi-paradigm sounds nice on paper but let me ask this question: do you know of any hard core FP programmer who is excited about inheritance or abstract classes or other OOP features? Vice-versa the same thing can be said about many OOP programmers lukewarm response towards many functional features of Scala. I believe that support for mixed/multiple paradigms has hindered large scale adoption of Scala. The language seems to be caught at cross-roads not knowing which way to advance next. 3) Third is lack of niche. True, I absolutely love "Spark" and primarily use it to extract/manipulate data from HDFS/Hive storage but I am gradually gravitating towards "Python" libraries due to their ease of use. What about better Java? Kotlin check. What about sidecar systems used by DevOps? Go check. What about a better designed system language? Rust check. The days of pure general purpose programming languages are truly over and Scala will be in great peril if it fails to expand into newer niches. Without broadening its programmer base it will finally run out of people that can design newer language features in light of ever advancing progresses in processor, OS and memory architectures. Just my two cents.
- dominotw 6y ago
  Agreed. I switched from scala to python and oh man what a relief. Scala is a heavy weight languange. By heavyweight I mean, 1. Even intellij struggles to figure out the meaning of implicits in the given context. And then there are macros. 2. Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. There is always a nagging feeling that you don't 'get it' when you program in scala. Here is an example of scala conference in 2020: https://scaladays.org/2020/berlin/schedule https://scaladays.org/2020/berlin/schedule Features talks like these. > a. Composition with Functional Effects > b. Scala 3 and Abstract Algebra > c. Describable, typesafe computations for the less monadically inclined > d. Understanding Scala's Type System > e. Roll your own Effect System 3. Every code base is written in its own flavor of scala. I was spending absurd amount of time "learning scala", now i look back at that and cringe.
dkarl 6y ago
I think a major reason Scala flourished was a big reason it has struggled as well: it opened the doors for many people to new and fundamentally different programming paradigms such as actor systems and functional programming. Many people got excited and implemented these new paradigms in production systems without regard to the immaturity of their own grasp of the concepts (think of how many years of imperative/OO programming you had under your belt before feeling confident of setting the style for a project), the learning curve they were non-consensually committing their coworkers to, and the hiring, productivity, and morale burden they were saddling their employers with. From the management point of view, allowing Scala in the door meant running the risk of waking up one day with a bunch of Scalaz in the codebase, one grinning functional programmer happy as a pig in shit, and the rest of the team shouting and cursing. Likewise, on top of the real problems created by ill-conceived adoption, the irrational backlash against new paradigms is real as well. I'm old enough to remember the fuss over OO programming. Many experienced, successful coders were scared that they were about to become personally obsolete. Some OO proponents insinuated — and panicked veteran coders believed — that a large number of procedural programmers would have to retire or switch careers because they were too old or not intellectually nimble enough to adapt to object-oriented programming. Major companies such as Sun responded to these fears with a marketing blitz to prove their their OO technology was simple and easy to learn and would herald a new age of programmer productivity. Programmer culture was more driven by magazines and books in those days and therefore much more easily influenced by industry marketing. The "simplicity" of Java was an invention of Sun marketing, a successful self-fulfilling prophecy as Java became so familiar that similarity to it became millions of programmers' benchmark of simplicity. There has been no total war marketing blitz for functional or actor-based programming from a company with the same stature that Sun had in the 1990s. The emotional reaction, the resentment at feeling a step behind the future, the anxiety about whether you will ever be as comfortable and confident in the new paradigm, operate virtually in a vacuum, or worse, in the echo chamber of the internet. Whatever latent fear of functional programming a person feels, the prospect of using Scala will bring it to the fore. The only countervailing force is the (usually lone) individual pushing adoption, and they are unlikely to be up to the challenge. There is a tension between programmers who are more oriented towards business problems, or who just want to get their job done and go home, and the programmers who get excited about different and potentially better ways to express programs. They both think of themselves as humble and results-oriented and have a hard time accepting each other as being equally humble and results-oriented in their own way. They both experience the other as snobbish, condescending, and threatening to their self-image as good engineers. Sadly, the root of the problem is that Scala is expressive and powerful enough to be a natural vehicle for these new paradigms. An engineering organization should not fear expressive power, because they should have a culture that is incompatible with a single engineer (or a small cabal) committing their peers to a learning curve without consultation, debate over the cost and payoff, and buy-in from the team. Unfortunately, there seems to be an assumption that beyond choosing a language, you have no ability to consciously choose a style. I.e., Scala-as-a-better-Java (the least imaginative approach, but not a bad one) is an impossibility. This is grounded in the assumption that any aspect of a language that can be abused, will be abused, and that engineers cannot make collective decisions about how they will work together, which are odd assumptions to make about the behavior of highly paid professionals. As someone who wrote C++ professionally for many years, I can testify that it is possible for engineers to conform to coding standards that restrict them to a strict subset of the expressive power of a language. However, it sometimes requires management authority to bring people in line -- and perhaps this is a deal-breaker in an industry where teams of engineers are supposed to be entirely self-managing.
seertaak 6y ago
The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Their decision to embrace whitespace sensitivity, while simplifying the syntax for predominant use-cases (again, union types!) betokens flexibility, and a desire to swing for the rafters. The only thing that saddens me somewhat is that Scala Native does feel like a bit of a second class citizen. The `stackalloc` feels a little sad (coming from C++ -- it should be inverted!). I wonder if it's possible for Typesafe to leverage Scala Native in a manner akin to Python with Numba/Cython. With whitespace indentation - native code inlined and FFI'd automatically - right there with the rest of the nice JVM stuff. I can't resist citing my email from Feb '07 asking (politely) why we needed a 'new' keyword. Dotty apparently removes the need for that keyword. Should have listened earlier, team Scala ;) http://www.scala-archive.org/quot-new-quot-keyword-td1989540.html http://www.scala-archive.org/quot-new-quot-keyword-td1989540...
- spir 6y ago
  Here's a great talk given by Martin Odersky, "A Tour of Scala 3" https://www.youtube.com/watch?v=_Rnrx2lo9cw https://www.youtube.com/watch?v=_Rnrx2lo9cw That talk is almost a year old now :) a lot of progress has been made towards launching Scala 3. The latest Dotty release was March 18 https://dotty.epfl.ch/blog/index.html https://dotty.epfl.ch/blog/index.html Scala 3 combined with Scala.js and GraalVM native compilation will be a killer stack :). You can write code that's as high level as python and typesafe as Haskell. Use the same code on the backend and in-browser with Scala.js. Compile your code to statically linked native executables with instant startup time, great for CLI tools. In terms of developer experience, Scala 3's compiler is much faster than Scala 2 because the data structure representing incremental compilation is not rebuilt for each compiler phase. The faster compiler can be used with Microsoft's Language Server for a delightful IDE experience, especially in VS Code which is the current recommended editor for Scala 3.
- AheadOfTime295 6y ago
  A word of caution on Scala 3: Scala 3 still in beta, lacks clear roadmap, allows choosing between two syntaxes (python-style vs braces). Dotty Community Build lacking Lightbend frameworks (no Akka, no Play, no sbt) With the recent layoffs at Lightbend of Scala 2.x core contributors, a full endorsement of Scala 3 would certainly help.
brunojppb 6y ago
Scala and the Play Framework became my tool belt for whatever web application I need. It has all the batteries included, it’s stable and rock-solid. It never felt so good to use a “boring” stack.
deleted 6y ago
[deleted]
lemiffe 6y ago
Kotlin
lihaoyi 6y ago
Author here. The full title is “The Death of Hype: What’s Next for Scala”, and the full title is significant. This article is as much about the initial hype and its decline as it is about the future prospects of the language. It very much isn’t an official or even unofficial roadmap for the language, which is what the shortened title makes it sound like.
- arbhassan 6y ago
  I posted it with the original title. I don't know why the HN moderators almost always change titles. Happened to me a couple of times.
  - deleted 6y ago
    [deleted]
- brudgers 6y ago
  My take is that “death of hype” could be prefixed to a lot of article titles submitted to Hacker News. It’s not that it isn’t meaningful to you as the author or that it’s not a theme of the article or that Hacker News doesn’t encourage the submission of original titles. It’s that “death of hype” doesn’t make Hacker News better because it amps up the attack surface for low quality comments about the title, or Scala hype, or somebody’s least favorite hyped languages in general. Basically it opens the door to a lot of nonexpert comments of outrage without creating value for people who click the link because those people see “death of hype” with an <h> tag.
- elmalto 6y ago
  I saw a lot of myself in your article. Came to scala in 2014 via spark, wrote a lot of OOP code and then slowly moved into the FP space. These days I find myself writing python a lot (for machine learning) but just miss the type safety net I get with scala
jane_red 6y ago
Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains high. Your more experienced colleagues will not allow to write anything that even remotely smells OOP. This delays the time when you can be productive. Third, on paper Scala tries to serve both object oriented and functional worlds but in practice the the latter is the unconditional standard. Although I like the positive tone of the article, I find it difficult to agree with Scala ever becoming mainstream.
- wpietri 6y ago
  Yeah, I was also excited about Scala. Went to a conference in 2010; eventually took the Odersky course and tried it for some personal projects. I ended up abandoning it, and for me Bruce Eckels captured a big part of why, talking about it as a "landscape of cliffs". [1] Every time I thought I knew what was going on, I tripped over something and ended up in a chasm. With much study and effort I could dig myself out of that hole, but soon enough I'd be in another one, trying to understand some abstruse bit of type magic when I just wanted to render a web page or something. It also reminds me of the famous Kernighan quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [2] Scala might be optimal for some group of people, but definitely not for me, and I think not for a mainstream developer audience either. [1] https://www.bruceeckel.com/2015/08/29/what-i-do/ https://www.bruceeckel.com/2015/08/29/what-i-do/ [2] https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
- yashap 6y ago
  IMO, it really depends on the team you join, as with most programming projects. Scala can be used in a classic mutable OOP manner, as if you were writing Java in 2005, or if you heavily buy into pure FB libraries it can be used basically like it's Haskell, but IMO neither of these approaches embrace the strengths of the language. It's meant to be a true mix of OOP and functional paradigms, not going extreme one way or the other. The object oriented aspects let you embrace great OOP software architecture patterns like Domain Driven Design, so that you can really model the business domain clearly and faithfully. Then the functional aspects allow you to implement a "functional core, imperative shell" style, that's really easy to reason about, and easy to make concurrent (safely), while also having excellent/safe/descriptive types like Future/Option/Try and ADTs. It sounds like you've worked with a group of people who want to treat Scala like it's Haskell, but that's a minority community that IMO isn't really embracing the strengths of the language. I've worked on projects that go all-in on libs like Cats and Scalaz, and I agree that they're mostly unnecessary complexity that also obscure the modelling of the business domain. You're going to massively confuse newcomers with all the Applicative/Effect/Monad/Monoid/Functor/etc. talk, for next to no benefit. Actors are a bit of a different story - excellent for the 1% of times where you really need them (lots of mutable state and lots of concurrency), but 99% of the time you don't need them. Some devs are enamoured with the mathematical purity of pure functional programming, without properly considering how hard it is to understand for most other devs. If you let these types take over your company, that’s a cultural problem, not really a language problem. Odersky describes why he created the language here: https://www.signifytechnology.com/blog/2018/01/why-scala https://www.signifytechnology.com/blog/2018/01/why-scala > ... programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges. I completely agree, and have yet to find a better language than Scala for the above demands, assuming you really embrace the OOP/functional mix. I've been writing lots of Scala at my day job for the past ~5 years, and it's my favourite language. I've worked on backends in Scala, Java, Go, Python, PHP and Node, and prefer Scala to all of them. I also agree with Li Haoyi - it's becoming a really solid, stable, reliable language, with improvements focused on the build tools, compiler, and the odd language wart, without significant changes to syntax/style, which is great. It does take awhile to learn, and you do have to be careful about what style you program in, but I think if you just embrace the language's OOP/functional fix, and for "core style" mostly stick with the standard library (Future/Try/Option/etc.) vs. going crazy with Cats/Scalaz/Akka/etc. (unless you REALLY need Akka specifically), it's an outstanding language.
sandGorgon 6y ago
>Currently Scala is overwhelmingly used for backend services and/or Spark data pipelines, This is also being taken over by Python. Databricks Koalas is a pandas interface on top of Spark - https://koalas.readthedocs.io/en/latest/ https://koalas.readthedocs.io/en/latest/ PySpark was already there (and very much in production). But Koalas (in beta) completely changes the go-to production aspects of spark.
lcall 6y ago
I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume any project maintainer must learn scala to expert level. I failed (in one attempt on a scala mailing list) to pitch to the scala community the idea of having language levels: a compiler switch or the like that would guarantee that a given project will be maintainable by java programmers with only N (1-2 I hope, for the first level) hours of scala training or study, maybe another level for adding certain features (or listing them in a config file), and full-on expert. So teams can be formed with realistic long-term maintainability in mind. Edit: This may be practical with add-ons I didn't try yet. 3) It was unclear what would be the best reasonable, maintainable way to use sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows, mac. Maybe call a native code library for each? Sounds like lots of work and maintenance to do it well.) 4) Startup times, future viability of scala native (edit: or equivalent), and whether it helps or adds enough more complexity given all the above, to just learn Rust and (hopefully) simplify life (in some ways). 5) And you have to learn java first (for those who didn't know it already), and know its libraries and idioms to some extent. Will that still likely be true? Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme), in a way that is hopefully/eventually at a complexity level that is inviting to other devs, but with plenty of learning headroom for my future growth.
- deleted 6y ago
  [deleted]
- vvillena 6y ago
  Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple. One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things. What you have to learn, at least in a basic form, is how the JVM works.
zylepe 6y ago
I’ve been using Scala as my main programming language for over 5 years. I’ve found my “plateau of enlightenment” by sticking to a subset of the features: case classes, for comprehensions, futures, immutability, pattern matching. By avoiding things like implicit, overly complex types, defining/overloading operators, and being dogmatic about FP/OOP I find the language stays out of your way and lets you write code that reads like what you’re trying to do.
- tormeh 6y ago
  I've done the same by being lazy, mainly treating it as a better Java and only learning new stuff when necessary or obviously beneficial. I want to write good programs, not fancy code. My advice: - Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way - Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with caution -- Except parallel collections. Use those liberally - No Scalaz or any other FP-crusader stuff ever - Macros and implicits should be rejected by default in code review. Amazing justifications required - Enforce coding rules with linters. This applies for any language, but especially important for dynamic and non-straightjacket languages
  - jnbiche 6y ago
    OK, here's my question then. You're embracing Option type and yet presumably avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"), right? So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types. So do you match on every one, and nest match expressions inside match expressions inside match expressions? That can get very, very messy and even confusing.
    - 11Di 6y ago
      For comprehensions should alleviate the examples you have given with regards to readability. Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent.
dlandis 6y ago
Scala is an awesome language and studying it helped me improve as a programmer more than I can describe. That being said, even though Haoyi said he doesn’t think Java has “caught up”, the fact is it has closed the gap significantly on the language side, and will always remain ahead in other ways (performance as one example). OpenJDK 14 is an outstanding general purpose development platform, and the days are long gone of anyone actually _needing_ an alternate JVM based language, whereas 10 years ago (or maybe even 5) there was a desperate need.
- dkarl 6y ago
  If you think of it in terms of the words "need" and "alternative" then you will find a reason not to use Scala. Personally, I have found it painful to watch Java tack on Scala features years late and in awkward and clumsy ways. Encountering ideas first in Scala and then in Java is too often like learning math from a modern textbook and then looking at the same math in a textbook from a hundred years ago. You appreciate how decades of small improvements have made the subject less intellectually taxing despite the fundamental content not changing at all. For Java to end up on the wrong side of this comparison even when it implements features years later, to me marks it as a language in terminal decline, no matter if its popularity has begun to reflect it yet.
tunesmith 6y ago
I'm sad not because Scala is dying but because it will embolden the many loud voices who like to proclaim it as dying, while others will believe them. Meanwhile, it will continue to progress. I became a better java programmer, a better php programmer, and a better javascript programmer by studying Scala. I became better at distributed systems concepts by studying Akka. I'm sure I will become better at a lot of other things by studying Akka Typed and Dotty. It's a language that clarifies your thinking in a way that brings better practices to other spheres. It's absolutely worth learning. I've also had the experience of using it on undisciplined teams and that sucked. One overly "clever" programmer can turn off a sufficient number of other programmers and give it a bad rep. I don't think a language being expressive is sufficient cause to blame the language for that, though.
snambi 6y ago
Next Step for Scala: Shutdown.
iLemming 6y ago
> It's not Clojure-dead It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten. Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them. - Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²" - Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³" - R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴." - Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵" - JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff like React Hooks, and Clojure people: "Hmmm... actually we had a better way of dealing with stateful UI components for a few years now. We've been trying to tell you, but you never listened..." They've been saying, "Clojure is dead" for years now. But despite all the odds, Clojure is very much alive and thriving. It's the most popular language within languages with a strong FP emphasis. Just look around - it has more books, more jobs, more podcasts, more conferences, and meetups than of Haskell, OCaml, Purescript, Elm, Elixir, F#. I suggest people from other PL communities learn from Clojure people. It is a small but diverse and very friendly community of pragmatists - while others keep shoveling the same shit from one corner to another, trying to re-invent things over and over again, Clojurists keep borrowing good ideas and filtering out bad ones. And calmly and quietly keep building cool stuff and getting paid for it⁶. ¹ https://dragan.rocks https://dragan.rocks ² https://github.com/clj-python/libpython-clj https://github.com/clj-python/libpython-clj ³ https://github.com/candid82/joker https://github.com/candid82/joker ⁴ https://github.com/scicloj/clojisr https://github.com/scicloj/clojisr ⁵ https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl ⁶ https://bit.ly/3a3wxNH https://bit.ly/3a3wxNH
zmmmmm 6y ago
I've taken several passes at Scala but the thing that always stops me is that I find it really hard to read unfamiliar code, including the core API implementations. The only Scala code I find easy to read is impure semi-object oriented code which is the non-idiomatic code that the Scala community tries not to write. I'm not sure if there's some point at which a penny drops and it all starts to become easy, but even if that is true, the time period it takes for that to happen is a real hurdle for newcomers. To me, you have to be intrinsically motivated to become productive in Scala because of that early friction. Which is fine if you are, but if you're looking at a team of programmers and thinking "how do I get them all over that line" when about half of them have no intrinsic motivation to do that, it's a real disincentive to use the language.
smabie 6y ago
Hands down, Scala is my favorite language. The world-class type system combined with its very practical nature make it a natural fit for really any server backend. And now with GraalVM, Scala hopefully will make inroads into desktop and command-line apps (start-up time has always been an issue, until now). Scala 3 looks pretty amazing and the future is bright!
cutler 6y ago
Scala faces tough competition from Kotlin which has two huge platforms - Android and Spring/Pivotal. Arrow (https://arrow-kt.io https://arrow-kt.io), is enough to satisfy all but the most zealous FP purists whilst maintaining first-class inter-op with the host language. I foresee a lot of new projects adopting Kotlin where once they might have favoured Scala.
agumonkey 6y ago
It is fun to see python being the beacon of friendly library design :)
cutler 6y ago
One of the most off-putting experiences when starting with Scala is the lack of a dedicated Scala repository such as Clojars for Clojure. Floundering around in Maven Central trying to get an idea of what's available for Scala is an exercise in futility and enough to make you want to give-up before you've even started.
- sideeffffect 6y ago
  https://index.scala-lang.org/ https://index.scala-lang.org/
  - cutler 6y ago
    Great. I stand corrected. How long has that been up? Last time I started with Scala it didn't exist.
    - acjohnson55 6y ago
      Probably about 3 years
    - maddening 6y ago
      More than 3 years. I've been using it for that long but it was pretty functional and full even 3 years ago.
- deleted 6y ago
  [deleted]
fulafel 6y ago
What's with the quote's casual Clojure dissing? Clojure seems more popular and growing more than Scala, from where I sit. Kotlin is not eating into Clojure's user base like Scala, which makes sense.
barnyfried 6y ago
Engineers are really horrible salespeople. And maybe thats a good thing in the case of Scala. The functional programming paradigm has little or nothing to show for itself in the many years since this resurgence started. It personally has done nothing for me, not made my job easier, not allowed me to be more productive, and is not even really interesting. Any more interesting than LISP was in the 70s. Scala is slow, wastes time celebrating its syntax of supposed correctness. Is a pretty bad JVM integrator. It cant get out of its own way and neither can its programmers. I am open to learning new languages, we all should be, just to keep learning. But lets be honest folks. Scala is a highly opinionated academic and inevitably selfish decision to make over any other mainstream language.

299 points by arbhassan 6y ago

I'm particularly interested in how this plays out with dotty. My understanding was that lightbend was at some going to take over that compiler from EPFL, but taking over a compiler (the second, besides the current/old one) at the same time they are laying people off?

AheadOfTime295 6y ago
Announcement on Dotty as the future Scala 3 came from Scala Center (EPFL) not Typesafe/Lightbend. AFAIK Typesafe/Lightbend has made no commitment to Scala 3. Too bad the roadmap for Scala 2.14 has been scrapped.
- spir 6y ago
  I've worked with Dotty a bit and read about it a lot. I am very excited about Scala 3 :) Scala 3 isn't a python2/python3 situation. It will take years for large codebases to be upgraded to Scala 3. However, the tools to migrate code from Scala 2 to Scala 3 will be reliable and highly automated, due to Scala's strong type system. Most popular Scala libraries and frameworks will be available on Scala 3 right from the get-go. I expect that most Scala programmers and companies will want to write Scala 3 code asap. Within the Scala community, the only truly divisive aspect of Scala 3 afaik is the introduction of optional python-style and Haskell-style syntax with significant whitespace. I was stridently against significant whitespace and now prefer it after having tried coding Scala 3 for awhile.
  - jmeister 6y ago
    Thanks for this info, very useful and exciting. I stopped using scala around 5 years back, want to get back to it. Would you recommend jumping straight to dotty? I’ve been doing a mostly python and a bit of Haskell in the meantime.
    - spir 6y ago
      I'd jump straight to dotty! You may as well learn the latest 'n greatest.
  - jane_red 6y ago
    > It will take years for large codebases to be upgraded to Scala 3 Which for production level code bases means never. I can't even imagine what we are going to do with our 7 year old Scala code base.
    - vvillena 6y ago
      It's the Java 1.4/Java 6/Java 8 problem all over again. Big companies refuse to keep up with the base languages, and important parts of the ecosystem (e.g. Spark) fall behind the language.
- maddening 6y ago
  2.14 was supposed to be a stepping stone between 2 and 3, released only so that migration could be easier. They skipped it because apparently source code differences between valid 2.13 and 3.0 aren't that great. From what I saw it is mostly about migrating macros, the rest most likely would still work.

totalperspectiv 6y ago

As one of those new people boosting recent numbers, Scala is great! I use vscode with Metals and had no jvm experience before. sbt is annoying, Mill seems super promising, and graalvm native images basically mean that if I was going to do it in python, I might as well use scala now.

walkingolof 6y ago
Scala 3 have a Python feeling over it with optional braces indentation (https://dotty.epfl.ch/docs/reference/other-new-features/indentation.html https://dotty.epfl.ch/docs/reference/other-new-features/inde...) I wrote an example using this new (optional syntax) https://github.com/olofwalker/ting https://github.com/olofwalker/ting, if anyone wants to have a look.
- 3fe9a03ccd14ca5 6y ago
  Maybe it’s just me, but “optional” is a word I hate seeing in language design, because I’m thinking of how many code reviewers I’ve met that have a hard time with “optional”.
- discreteevent 6y ago
  It's been about 10 years since I did some work with Scala. I really like the syntax and the way your project uses it. Seems immediately legible and simple.
tlarkworthy 6y ago
I just use maven for Scala compilation. I want to avoid Turing computable build tools (yes I know u can load plugins with maven but it is at least stiving for a declarative model)
mchisto 6y ago
What's your problem with SBT? I've been using IntelliJ + SBT since I started with Scala and it has been working well for me.
- 6y ago

AheadOfTime295 6y ago

Farewells piling up: Six years at Lightbend, by Eugene Yokota (Scala sbt, scalaxb, scopt) https://news.ycombinator.com/item?id=22836399 https://news.ycombinator.com/item?id=22836399

trevyn 6y ago

>it seemed to peak around 2016 https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=scala,golang,rust https://trends.google.com/trends/explore?cat=5&date=all&geo=... Early 2017, perhaps! Are Go and Rust seen as competitors to Scala?

capableweb 6y ago
Remember that Google Trends just measures search traffic. Also, handy tip, select "Programming Language" instead of "Term", the graph changes slightly with that: https://trends.google.com/trends/explore?cat=5&date=all&geo=US&q=%2Fm%2F091hdj,%2Fm%2F09gbxjr,%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?cat=5&date=all&geo=... Another tip, by default Google Trends just show data from the US, which is not very interesting, select Wordwide to get a better picture: https://trends.google.com/trends/explore?cat=5&date=all&q=%2Fm%2F091hdj,%2Fm%2F09gbxjr,%2Fm%2F0dsbpg6 https://trends.google.com/trends/explore?cat=5&date=all&q=%2... Competitors are hard to say as there would different categories. Some workplaces would only choose a JVM language, then Scala's competitors are Java itself, Clojure and alike. Go and Rust have mainly been described as "system" languages but they take vastly different approaches from each other. If you be a bit more specific on what you're compared them on, it'll be easier to know if they are competitors or not.
ashtonkem 6y ago
Depends who Scala was a competitor to. If you viewed Scala as a competitor to Java, then Go is a competitor to Scala and not Rust; because Go is a competitor to Java in my opinion.
- pjmlp 6y ago
  Go is a competitor to Java 1.0, it still needs to grow a bit more if it wants to compete with Java 14 and its 25 years of tooling and libraries. If Go 2.0 ever happens, it will be a competitor to Java 5.
  - ashtonkem 6y ago
    So, it depends on what you’re talking about; language or organizational need. Go is an imperfect match for Java The language, largely because of the whole Generics thing. But if you’re talking about how teams use Java and Go, they’re a good match now. Go was designed for large companies like Google to have a huge number of engineers and produce consistent, quality code, all while constantly on boarding people and moving them around. From an organizational perspective there are a ton of Java shops that use Java for similar reasons, plus the ability to cheaply and quickly acquire contractors who know Java.

AheadOfTime295 6y ago

For context see Lightbend secures 25MM funding round, proceeds to layoff Scala contributors https://news.ycombinator.com/item?id=22842166 https://news.ycombinator.com/item?id=22842166

marvy 6y ago
I don't follow Scala (never wrote a single line), so I didn't realize the company changed names from Typesafe to Lightbend. Here's a question: how on earth do they make any money? The Wikipedia article makes an offhand mention of something called Lightbend subscription; is that what keeps them afloat?
- joshlemer 6y ago
  A lot of it is consulting, and they also have some proprietary and/or hosted services, and even akka plugins that they charge for.
  - marvy 6y ago
    thanks
dang 6y ago
Also https://news.ycombinator.com/item?id=22836399 https://news.ycombinator.com/item?id=22836399 ("Six years at Lightbend")

pjmlp 6y ago

Since the post mentions Scala Native, all these guest language projects that eschew the platform that made them famous and try to pursue the dream of being their own platform, while building an ecosystem, GC and optimising compiler from scratch (even if they build on LLVM or compile via C/C++), would be much better taking advantage of AOT and JIT caches from several JVM implementations instead of pretending they don't exist.

kasperni 6y ago
Looking at the commit log, Scala Native looks pretty dead https://github.com/scala-native/scala-native/commits/master https://github.com/scala-native/scala-native/commits/master
- maddening 6y ago
  Previous maintainer left EPFL so nothing was happening there. But Scala Center took over the project so they will start maintaining it. AFAIR snnouncement was on Gitter by the same guy who maintains Scala.js. I guess it will take some time for them to catch up with the rest.
spir 6y ago
In my mind, GraalVM native compilation has superseded scala-native. GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect. Scala is now a great choice for CLI tools.
- vbezhenar 6y ago
  > The native executables are slim What's the size of hello_world.exe?
  - LandR 6y ago
    Dunno about Scala, but Clojure - another JVM language, has a GraalVM native executable for Hello WOrld about 8MB. Not that slim.

wiradikusuma 6y ago

I love Scala! It's the language that enlightened me and be more productive. Now, every time I code in other languages (e.g. Dart for Flutter, or JS for web stuff), I grumble when I can't find "standard" features such as "map", pattern matching, optional and named params, implicits. Also, when I code in Scala, I frequently google and end up learning something new about the language. I know it sounds like distraction/wasting time, but there's a certain satisfaction when I found the "Scalaic" way of doing things, like, "There's gotta be a one-liner way of doing this." Of course, my complain is still compile time (yes it's significantly faster, but I'm impatient).

erton23 6y ago
You would be enlightened the same way or even more if you started with Haskell. That is, it is not Scala you are so excited about but the functional programming. Btw, the actual thing to be inspired with in Scala is immutability and Option/Some/None instead of null. These are the things that make you code stable and reliable.

_bxg1 6y ago

> It's not Clojure-dead What does this mean? I thought Clojure has a dedicated, if small, user base.

diggan 6y ago
I guess in the authors mind, dead here means it's stable, solves its problems well and doesn't try to attract developers with shiny new features but instead focuses on enhancing the core experience which gets better. As a Clojure/Script developer, I could understand that Clojure looks dead from the outside if you're a JS developer, you're used to new language features being shoehorned into the language every year. But for someone inside the Clojure ecosystem who used to be a JS developer, it's a breath of fresh air when I can take a 4 year old library and include it, everything works and no bugs are to be found. If there is a bug, I can patch it from the outside, if I really have to. Clojure in general lends itself very well to be extended from the outside (like what clojure.spec is currently doing [and many others]) so the core language doesn't really have to change anymore, we're just building libraries on top of the language which extends the language.
- _bxg1 6y ago
  The dig at JS developers is completely uncalled-for. I'm a JS developer and I admire the way Clojure has seemed to skip both the hype and disillusionment phases and jump straight to the productivity plateau.
  - simongray 6y ago
    Clojure did have quite a bit of hype 5-10 years ago and a bit of slowdown in 2017-2018 where this meme of "Clojure is dead" probably started.
    - rlander 6y ago
      Agree. But slowdown in internet hype doesn’t mean slowdown in industry adoption though.

3fe9a03ccd14ca5 6y ago

Scala has the reputation of being fun to create stuff with, but horrendous when understanding other people’s creations. Is this still true?

spir 6y ago
It's less true now because some of the patterns associated with code that's difficult to understand have been deprecated or flagged by the community to avoid. For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern. Another example is that it's now (more or less) recognized within the community that it's not preferable to dogmatically adhere to a particular style of programming, such as pure functional or reactive/actors. It's better to use the right tool for the right problem. Whole classes of confusing code are now prevented or mitigated by language changes in Scala 3. For example, Scala 2's implicits are famously hard to learn and follow within a codebase. One reason for this is that in Scala 2 the keyword "implicit" was overloaded into a few common patterns, including the aforementioned implicit conversions, typeclass instances, and dependency injection. Scala 3 introduces new constructs and keywords to split out these patterns into separate language features, making them easier to learn and more understandable within a codebase.
- smabie 6y ago
  > For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern. I don't have experience with Scala 3 or Scala 2.13, but I don't believe this is true. Implicit conversions cannot be applied more than once.
- EdwardDiego 6y ago
  > For example, implicit conversions are now disabled by default. It's possible in Scala to pass a Foo to a function requiring a Bar due to a chain of automatic conversions from Foo -> Baz -> BazMutable -> Bar. This is fun and magical but difficult to understand and debug. The community and language itself now suggests against this pattern. Oh God I'm having flashbacks to using Lift in... 2012? There were about four levels of implicit conversions between my model and the final JSON, trying to understand that was hard. That said, David Pollak the founder of Liftweb was amazingly helpful on on their mailing list.

seahawks78 6y ago

I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following: 1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis purposes. Nothing wrong with that. But that also means language features are added not to solve a practical problem but mostly to show that "it can be done"/"prove a point". When you are awake at 3 AM early in the morning because a release made in the evening went awry and you are trying to grep though logs/code to see what caused the issue I can assure you that debates about "pure" versus "impure", Monads, Kleisli arrow will be further from your mind. So the problem that Scala seems to suffer from is that of "image". 2) Second, Scala is neither a fully functional (FP) nor object oriented (OOP). Support for mixed/multi-paradigm sounds nice on paper but let me ask this question: do you know of any hard core FP programmer who is excited about inheritance or abstract classes or other OOP features? Vice-versa the same thing can be said about many OOP programmers lukewarm response towards many functional features of Scala. I believe that support for mixed/multiple paradigms has hindered large scale adoption of Scala. The language seems to be caught at cross-roads not knowing which way to advance next. 3) Third is lack of niche. True, I absolutely love "Spark" and primarily use it to extract/manipulate data from HDFS/Hive storage but I am gradually gravitating towards "Python" libraries due to their ease of use. What about better Java? Kotlin check. What about sidecar systems used by DevOps? Go check. What about a better designed system language? Rust check. The days of pure general purpose programming languages are truly over and Scala will be in great peril if it fails to expand into newer niches. Without broadening its programmer base it will finally run out of people that can design newer language features in light of ever advancing progresses in processor, OS and memory architectures. Just my two cents.

dominotw 6y ago
Agreed. I switched from scala to python and oh man what a relief. Scala is a heavy weight languange. By heavyweight I mean, 1. Even intellij struggles to figure out the meaning of implicits in the given context. And then there are macros. 2. Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. There is always a nagging feeling that you don't 'get it' when you program in scala. Here is an example of scala conference in 2020: https://scaladays.org/2020/berlin/schedule https://scaladays.org/2020/berlin/schedule Features talks like these. > a. Composition with Functional Effects > b. Scala 3 and Abstract Algebra > c. Describable, typesafe computations for the less monadically inclined > d. Understanding Scala's Type System > e. Roll your own Effect System 3. Every code base is written in its own flavor of scala. I was spending absurd amount of time "learning scala", now i look back at that and cringe.

dkarl 6y ago

I think a major reason Scala flourished was a big reason it has struggled as well: it opened the doors for many people to new and fundamentally different programming paradigms such as actor systems and functional programming. Many people got excited and implemented these new paradigms in production systems without regard to the immaturity of their own grasp of the concepts (think of how many years of imperative/OO programming you had under your belt before feeling confident of setting the style for a project), the learning curve they were non-consensually committing their coworkers to, and the hiring, productivity, and morale burden they were saddling their employers with. From the management point of view, allowing Scala in the door meant running the risk of waking up one day with a bunch of Scalaz in the codebase, one grinning functional programmer happy as a pig in shit, and the rest of the team shouting and cursing. Likewise, on top of the real problems created by ill-conceived adoption, the irrational backlash against new paradigms is real as well. I'm old enough to remember the fuss over OO programming. Many experienced, successful coders were scared that they were about to become personally obsolete. Some OO proponents insinuated — and panicked veteran coders believed — that a large number of procedural programmers would have to retire or switch careers because they were too old or not intellectually nimble enough to adapt to object-oriented programming. Major companies such as Sun responded to these fears with a marketing blitz to prove their their OO technology was simple and easy to learn and would herald a new age of programmer productivity. Programmer culture was more driven by magazines and books in those days and therefore much more easily influenced by industry marketing. The "simplicity" of Java was an invention of Sun marketing, a successful self-fulfilling prophecy as Java became so familiar that similarity to it became millions of programmers' benchmark of simplicity. There has been no total war marketing blitz for functional or actor-based programming from a company with the same stature that Sun had in the 1990s. The emotional reaction, the resentment at feeling a step behind the future, the anxiety about whether you will ever be as comfortable and confident in the new paradigm, operate virtually in a vacuum, or worse, in the echo chamber of the internet. Whatever latent fear of functional programming a person feels, the prospect of using Scala will bring it to the fore. The only countervailing force is the (usually lone) individual pushing adoption, and they are unlikely to be up to the challenge. There is a tension between programmers who are more oriented towards business problems, or who just want to get their job done and go home, and the programmers who get excited about different and potentially better ways to express programs. They both think of themselves as humble and results-oriented and have a hard time accepting each other as being equally humble and results-oriented in their own way. They both experience the other as snobbish, condescending, and threatening to their self-image as good engineers. Sadly, the root of the problem is that Scala is expressive and powerful enough to be a natural vehicle for these new paradigms. An engineering organization should not fear expressive power, because they should have a culture that is incompatible with a single engineer (or a small cabal) committing their peers to a learning curve without consultation, debate over the cost and payoff, and buy-in from the team. Unfortunately, there seems to be an assumption that beyond choosing a language, you have no ability to consciously choose a style. I.e., Scala-as-a-better-Java (the least imaginative approach, but not a bad one) is an impossibility. This is grounded in the assumption that any aspect of a language that can be abused, will be abused, and that engineers cannot make collective decisions about how they will work together, which are odd assumptions to make about the behavior of highly paid professionals. As someone who wrote C++ professionally for many years, I can testify that it is possible for engineers to conform to coding standards that restrict them to a strict subset of the expressive power of a language. However, it sometimes requires management authority to bring people in line -- and perhaps this is a deal-breaker in an industry where teams of engineers are supposed to be entirely self-managing.

seertaak 6y ago

The Scala team pulled out all the stops with Dotty. It's a real tour de force, on a par with the sea change of C++11. Even with the plaudits he's earned, Martin Odersky is for me in the top three language designers of our time. (I'm sure I'm being unfair to other members of his team with this comment, though.) Dotty's union types are a thing of beauty, its implicits are really second to none, and _so_ damn useful. Their decision to embrace whitespace sensitivity, while simplifying the syntax for predominant use-cases (again, union types!) betokens flexibility, and a desire to swing for the rafters. The only thing that saddens me somewhat is that Scala Native does feel like a bit of a second class citizen. The `stackalloc` feels a little sad (coming from C++ -- it should be inverted!). I wonder if it's possible for Typesafe to leverage Scala Native in a manner akin to Python with Numba/Cython. With whitespace indentation - native code inlined and FFI'd automatically - right there with the rest of the nice JVM stuff. I can't resist citing my email from Feb '07 asking (politely) why we needed a 'new' keyword. Dotty apparently removes the need for that keyword. Should have listened earlier, team Scala ;) http://www.scala-archive.org/quot-new-quot-keyword-td1989540.html http://www.scala-archive.org/quot-new-quot-keyword-td1989540...

spir 6y ago
Here's a great talk given by Martin Odersky, "A Tour of Scala 3" https://www.youtube.com/watch?v=_Rnrx2lo9cw https://www.youtube.com/watch?v=_Rnrx2lo9cw That talk is almost a year old now :) a lot of progress has been made towards launching Scala 3. The latest Dotty release was March 18 https://dotty.epfl.ch/blog/index.html https://dotty.epfl.ch/blog/index.html Scala 3 combined with Scala.js and GraalVM native compilation will be a killer stack :). You can write code that's as high level as python and typesafe as Haskell. Use the same code on the backend and in-browser with Scala.js. Compile your code to statically linked native executables with instant startup time, great for CLI tools. In terms of developer experience, Scala 3's compiler is much faster than Scala 2 because the data structure representing incremental compilation is not rebuilt for each compiler phase. The faster compiler can be used with Microsoft's Language Server for a delightful IDE experience, especially in VS Code which is the current recommended editor for Scala 3.
AheadOfTime295 6y ago
A word of caution on Scala 3: Scala 3 still in beta, lacks clear roadmap, allows choosing between two syntaxes (python-style vs braces). Dotty Community Build lacking Lightbend frameworks (no Akka, no Play, no sbt) With the recent layoffs at Lightbend of Scala 2.x core contributors, a full endorsement of Scala 3 would certainly help.

brunojppb 6y ago

Scala and the Play Framework became my tool belt for whatever web application I need. It has all the batteries included, it’s stable and rock-solid. It never felt so good to use a “boring” stack.

deleted 6y ago

[deleted]

lemiffe 6y ago

Kotlin

lihaoyi 6y ago

Author here. The full title is “The Death of Hype: What’s Next for Scala”, and the full title is significant. This article is as much about the initial hype and its decline as it is about the future prospects of the language. It very much isn’t an official or even unofficial roadmap for the language, which is what the shortened title makes it sound like.

arbhassan 6y ago
I posted it with the original title. I don't know why the HN moderators almost always change titles. Happened to me a couple of times.
- deleted 6y ago
  [deleted]
brudgers 6y ago
My take is that “death of hype” could be prefixed to a lot of article titles submitted to Hacker News. It’s not that it isn’t meaningful to you as the author or that it’s not a theme of the article or that Hacker News doesn’t encourage the submission of original titles. It’s that “death of hype” doesn’t make Hacker News better because it amps up the attack surface for low quality comments about the title, or Scala hype, or somebody’s least favorite hyped languages in general. Basically it opens the door to a lot of nonexpert comments of outrage without creating value for people who click the link because those people see “death of hype” with an <h> tag.
elmalto 6y ago
I saw a lot of myself in your article. Came to scala in 2014 via spark, wrote a lot of OOP code and then slowly moved into the FP space. These days I find myself writing python a lot (for machine learning) but just miss the type safety net I get with scala

jane_red 6y ago

Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains high. Your more experienced colleagues will not allow to write anything that even remotely smells OOP. This delays the time when you can be productive. Third, on paper Scala tries to serve both object oriented and functional worlds but in practice the the latter is the unconditional standard. Although I like the positive tone of the article, I find it difficult to agree with Scala ever becoming mainstream.

wpietri 6y ago
Yeah, I was also excited about Scala. Went to a conference in 2010; eventually took the Odersky course and tried it for some personal projects. I ended up abandoning it, and for me Bruce Eckels captured a big part of why, talking about it as a "landscape of cliffs". [1] Every time I thought I knew what was going on, I tripped over something and ended up in a chasm. With much study and effort I could dig myself out of that hole, but soon enough I'd be in another one, trying to understand some abstruse bit of type magic when I just wanted to render a web page or something. It also reminds me of the famous Kernighan quote: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." [2] Scala might be optimal for some group of people, but definitely not for me, and I think not for a mainstream developer audience either. [1] https://www.bruceeckel.com/2015/08/29/what-i-do/ https://www.bruceeckel.com/2015/08/29/what-i-do/ [2] https://en.wikiquote.org/wiki/Brian_Kernighan https://en.wikiquote.org/wiki/Brian_Kernighan
yashap 6y ago
IMO, it really depends on the team you join, as with most programming projects. Scala can be used in a classic mutable OOP manner, as if you were writing Java in 2005, or if you heavily buy into pure FB libraries it can be used basically like it's Haskell, but IMO neither of these approaches embrace the strengths of the language. It's meant to be a true mix of OOP and functional paradigms, not going extreme one way or the other. The object oriented aspects let you embrace great OOP software architecture patterns like Domain Driven Design, so that you can really model the business domain clearly and faithfully. Then the functional aspects allow you to implement a "functional core, imperative shell" style, that's really easy to reason about, and easy to make concurrent (safely), while also having excellent/safe/descriptive types like Future/Option/Try and ADTs. It sounds like you've worked with a group of people who want to treat Scala like it's Haskell, but that's a minority community that IMO isn't really embracing the strengths of the language. I've worked on projects that go all-in on libs like Cats and Scalaz, and I agree that they're mostly unnecessary complexity that also obscure the modelling of the business domain. You're going to massively confuse newcomers with all the Applicative/Effect/Monad/Monoid/Functor/etc. talk, for next to no benefit. Actors are a bit of a different story - excellent for the 1% of times where you really need them (lots of mutable state and lots of concurrency), but 99% of the time you don't need them. Some devs are enamoured with the mathematical purity of pure functional programming, without properly considering how hard it is to understand for most other devs. If you let these types take over your company, that’s a cultural problem, not really a language problem. Odersky describes why he created the language here: https://www.signifytechnology.com/blog/2018/01/why-scala https://www.signifytechnology.com/blog/2018/01/why-scala > ... programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges. I completely agree, and have yet to find a better language than Scala for the above demands, assuming you really embrace the OOP/functional mix. I've been writing lots of Scala at my day job for the past ~5 years, and it's my favourite language. I've worked on backends in Scala, Java, Go, Python, PHP and Node, and prefer Scala to all of them. I also agree with Li Haoyi - it's becoming a really solid, stable, reliable language, with improvements focused on the build tools, compiler, and the odd language wart, without significant changes to syntax/style, which is great. It does take awhile to learn, and you do have to be careful about what style you program in, but I think if you just embrace the language's OOP/functional fix, and for "core style" mostly stick with the standard library (Future/Try/Option/etc.) vs. going crazy with Cats/Scalaz/Akka/etc. (unless you REALLY need Akka specifically), it's an outstanding language.

sandGorgon 6y ago

>Currently Scala is overwhelmingly used for backend services and/or Spark data pipelines, This is also being taken over by Python. Databricks Koalas is a pandas interface on top of Spark - https://koalas.readthedocs.io/en/latest/ https://koalas.readthedocs.io/en/latest/ PySpark was already there (and very much in production). But Koalas (in beta) completely changes the go-to production aspects of spark.

lcall 6y ago

I wanted Scala to be my "better Java" for a long time, mainly because it seemed to have plentiful headroom as I seek to learn more. The community enthusiasm was also contagious. But: 1) the ecosystem makes it seems like I need to be a genius enough to learn a new DSL a bit too often, and everything is so...complex, which leads to... 2) It is hard to pitch to an organization because of the learning curve if you assume any project maintainer must learn scala to expert level. I failed (in one attempt on a scala mailing list) to pitch to the scala community the idea of having language levels: a compiler switch or the like that would guarantee that a given project will be maintainable by java programmers with only N (1-2 I hope, for the first level) hours of scala training or study, maybe another level for adding certain features (or listing them in a config file), and full-on expert. So teams can be formed with realistic long-term maintainability in mind. Edit: This may be practical with add-ons I didn't try yet. 3) It was unclear what would be the best reasonable, maintainable way to use sqlite. (Edit: in a multiplatform way to include at least BSD, linux, windows, mac. Maybe call a native code library for each? Sounds like lots of work and maintenance to do it well.) 4) Startup times, future viability of scala native (edit: or equivalent), and whether it helps or adds enough more complexity given all the above, to just learn Rust and (hopefully) simplify life (in some ways). 5) And you have to learn java first (for those who didn't know it already), and know its libraries and idioms to some extent. Will that still likely be true? Comments welcome. (I enjoyed the article.) Maybe I'm just the type that wants to hit the sweet spot between what C, Java, and Scala do (edit: and Scheme), in a way that is hopefully/eventually at a complexity level that is inviting to other devs, but with plenty of learning headroom for my future growth.

deleted 6y ago
[deleted]
vvillena 6y ago
Scala dev here. "Having to learn Java" is not true at all, unless you interact with Java dependencies in special ways, or if you maintain a Java API for your Scala code. There are Scala libraries for almost anything, and it's easy to use some Java libs here and there. Creating wrappers is also simple. One of the coolest things about Scala it that it already contains lots of Java best practices. Case classes, singleton and companion objects, traits, powerful generics... almost every Scala feature is a builtin answer for a Java pattern. Hell, even implicits in all its various forms are elegant solutions to common Java problems. People getting creative with these features is an entirely different issue. It's possible, and desirable, to use Scala to craft simple, elegant, and understandable code. Fancy but unmaintainable code should not ever be accepted: it's the job of the developer to teach the reader what the code does, and while this is true in any language, is more important when coding Scala, because the multiparadigm approach means there are multiple ways to solve things. What you have to learn, at least in a basic form, is how the JVM works.

zylepe 6y ago

I’ve been using Scala as my main programming language for over 5 years. I’ve found my “plateau of enlightenment” by sticking to a subset of the features: case classes, for comprehensions, futures, immutability, pattern matching. By avoiding things like implicit, overly complex types, defining/overloading operators, and being dogmatic about FP/OOP I find the language stays out of your way and lets you write code that reads like what you’re trying to do.

tormeh 6y ago
I've done the same by being lazy, mainly treating it as a better Java and only learning new stuff when necessary or obviously beneficial. I want to write good programs, not fancy code. My advice: - Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way - Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with caution -- Except parallel collections. Use those liberally - No Scalaz or any other FP-crusader stuff ever - Macros and implicits should be rejected by default in code review. Amazing justifications required - Enforce coding rules with linters. This applies for any language, but especially important for dynamic and non-straightjacket languages
- jnbiche 6y ago
  OK, here's my question then. You're embracing Option type and yet presumably avoiding monads, applicatives, and functors (avoiding "FP-crusader stuff"), right? So what happens when you are dealing with multiple option types, like you two optional ints you need to add together? Or you have an optional field in an optional object? This happens all the time in code that heavily uses Option types. So do you match on every one, and nest match expressions inside match expressions inside match expressions? That can get very, very messy and even confusing.
  - 11Di 6y ago
    For comprehensions should alleviate the examples you have given with regards to readability. Although yes there are other more complex instances in which nested matches might come up. Generally I would think to handle them by creating a function that contains the next layer of matching instead of trying to come up with an uber function. Adds a bit more verbosity perhaps but I find it is fairly easy to follow and show intent.

dlandis 6y ago

Scala is an awesome language and studying it helped me improve as a programmer more than I can describe. That being said, even though Haoyi said he doesn’t think Java has “caught up”, the fact is it has closed the gap significantly on the language side, and will always remain ahead in other ways (performance as one example). OpenJDK 14 is an outstanding general purpose development platform, and the days are long gone of anyone actually _needing_ an alternate JVM based language, whereas 10 years ago (or maybe even 5) there was a desperate need.

dkarl 6y ago
If you think of it in terms of the words "need" and "alternative" then you will find a reason not to use Scala. Personally, I have found it painful to watch Java tack on Scala features years late and in awkward and clumsy ways. Encountering ideas first in Scala and then in Java is too often like learning math from a modern textbook and then looking at the same math in a textbook from a hundred years ago. You appreciate how decades of small improvements have made the subject less intellectually taxing despite the fundamental content not changing at all. For Java to end up on the wrong side of this comparison even when it implements features years later, to me marks it as a language in terminal decline, no matter if its popularity has begun to reflect it yet.

tunesmith 6y ago

I'm sad not because Scala is dying but because it will embolden the many loud voices who like to proclaim it as dying, while others will believe them. Meanwhile, it will continue to progress. I became a better java programmer, a better php programmer, and a better javascript programmer by studying Scala. I became better at distributed systems concepts by studying Akka. I'm sure I will become better at a lot of other things by studying Akka Typed and Dotty. It's a language that clarifies your thinking in a way that brings better practices to other spheres. It's absolutely worth learning. I've also had the experience of using it on undisciplined teams and that sucked. One overly "clever" programmer can turn off a sufficient number of other programmers and give it a bad rep. I don't think a language being expressive is sufficient cause to blame the language for that, though.

snambi 6y ago

Next Step for Scala: Shutdown.

iLemming 6y ago

> It's not Clojure-dead It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten. Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them. - Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²" - Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³" - R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴." - Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵" - JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff like React Hooks, and Clojure people: "Hmmm... actually we had a better way of dealing with stateful UI components for a few years now. We've been trying to tell you, but you never listened..." They've been saying, "Clojure is dead" for years now. But despite all the odds, Clojure is very much alive and thriving. It's the most popular language within languages with a strong FP emphasis. Just look around - it has more books, more jobs, more podcasts, more conferences, and meetups than of Haskell, OCaml, Purescript, Elm, Elixir, F#. I suggest people from other PL communities learn from Clojure people. It is a small but diverse and very friendly community of pragmatists - while others keep shoveling the same shit from one corner to another, trying to re-invent things over and over again, Clojurists keep borrowing good ideas and filtering out bad ones. And calmly and quietly keep building cool stuff and getting paid for it⁶. ¹ https://dragan.rocks https://dragan.rocks ² https://github.com/clj-python/libpython-clj https://github.com/clj-python/libpython-clj ³ https://github.com/candid82/joker https://github.com/candid82/joker ⁴ https://github.com/scicloj/clojisr https://github.com/scicloj/clojisr ⁵ https://github.com/clojerl/clojerl https://github.com/clojerl/clojerl ⁶ https://bit.ly/3a3wxNH https://bit.ly/3a3wxNH

zmmmmm 6y ago

I've taken several passes at Scala but the thing that always stops me is that I find it really hard to read unfamiliar code, including the core API implementations. The only Scala code I find easy to read is impure semi-object oriented code which is the non-idiomatic code that the Scala community tries not to write. I'm not sure if there's some point at which a penny drops and it all starts to become easy, but even if that is true, the time period it takes for that to happen is a real hurdle for newcomers. To me, you have to be intrinsically motivated to become productive in Scala because of that early friction. Which is fine if you are, but if you're looking at a team of programmers and thinking "how do I get them all over that line" when about half of them have no intrinsic motivation to do that, it's a real disincentive to use the language.

smabie 6y ago

Hands down, Scala is my favorite language. The world-class type system combined with its very practical nature make it a natural fit for really any server backend. And now with GraalVM, Scala hopefully will make inroads into desktop and command-line apps (start-up time has always been an issue, until now). Scala 3 looks pretty amazing and the future is bright!

cutler 6y ago

Scala faces tough competition from Kotlin which has two huge platforms - Android and Spring/Pivotal. Arrow (https://arrow-kt.io https://arrow-kt.io), is enough to satisfy all but the most zealous FP purists whilst maintaining first-class inter-op with the host language. I foresee a lot of new projects adopting Kotlin where once they might have favoured Scala.

agumonkey 6y ago

It is fun to see python being the beacon of friendly library design :)

cutler 6y ago

One of the most off-putting experiences when starting with Scala is the lack of a dedicated Scala repository such as Clojars for Clojure. Floundering around in Maven Central trying to get an idea of what's available for Scala is an exercise in futility and enough to make you want to give-up before you've even started.

sideeffffect 6y ago
https://index.scala-lang.org/ https://index.scala-lang.org/
- cutler 6y ago
  Great. I stand corrected. How long has that been up? Last time I started with Scala it didn't exist.
  - acjohnson55 6y ago
    Probably about 3 years
  - maddening 6y ago
    More than 3 years. I've been using it for that long but it was pretty functional and full even 3 years ago.
deleted 6y ago
[deleted]

fulafel 6y ago

What's with the quote's casual Clojure dissing? Clojure seems more popular and growing more than Scala, from where I sit. Kotlin is not eating into Clojure's user base like Scala, which makes sense.

barnyfried 6y ago

Engineers are really horrible salespeople. And maybe thats a good thing in the case of Scala. The functional programming paradigm has little or nothing to show for itself in the many years since this resurgence started. It personally has done nothing for me, not made my job easier, not allowed me to be more productive, and is not even really interesting. Any more interesting than LISP was in the 70s. Scala is slow, wastes time celebrating its syntax of supposed correctness. Is a pretty bad JVM integrator. It cant get out of its own way and neither can its programmers. I am open to learning new languages, we all should be, just to keep learning. But lets be honest folks. Scala is a highly opinionated academic and inevitably selfish decision to make over any other mainstream language.