1. 19
  1.  

  2. 4

    Show of hands, who is still using Scala and what for?

    1. 15

      I’m still using it, have complicated feelings, and am not sure for how much longer. But I am quite impressed with the work they’re doing for Scala 3 and root for them to make it a better language and ecosystem.

      That said, I find that you show up in every single post about Scala here to say something negative or at least fish for negativity pretty off-putting and negative. If you don’t like Scala, you’re welcome to abstain from discussions and instead focus on positive new developments in other languages you do like.

      1. 5

        ✋ using Scala for Spark, some web services deployed to Kubernetes, and some CLI tools. It’s definitely my primary language for building my own more complex tools, but I reach for Ruby and Shell for smaller stuff and Rust when I feel like it. I maintain a ~20,000 SLOC Rails app for a side business and have on more than one occasion threatened to rewrite the damned thing in Scala because the problems I continually encounter are problems solved from inception in Scala (e.g. type safety). It won’t happen because my partner strongly prefers Ruby and Rails, though.

        I’m excited about Scala 3 primarily because of the improvements to implicits. Breaking them in to clearer keywords is a dramatic improvement to explicit expressiveness, something I really value about languages. When my team at a former employer adopted Scala, we had rules limiting our use of implicits because they were such a sharp edge. That was 2012-2013 and the tooling just wasn’t helpful in tracking down compilation problems and runtime errors. I’ve taught Scala to dozens of people, mostly with a Java, Ruby, or C++ background, and the two hardest concepts to convey were implicits and co- and contravariance.

        1. 3

          Medium-sized software company in the telecom sector (~1k employees). Maybe 100-200 full time Scala devs here. It’s not exclusive, there’s a lot of Python, Java, Ruby, JS etc. We maintain a tech radar to keep track of what languages we use, since code runs inside containers on cloud VMs it can be in Fortran for all I care as long as there’s a team (or two) to support it.

          I’ve always enjoyed the language, but its principal downside is that it is very easy to turn it into Haskell and it becomes very hard to move people or teams around. So you have to keep watch that people aren’t creating free monad algebras just because they can. Advanced purely functional Scala code might be totally inaccessible to even an experienced developer coming from another language, and that is a detriment, because sometimes you just need to jump into some maintained codebase, find a bug, and fix it. Granted, Scala 3 will make this easier, there are some much welcome changes in it. Scala, as a language, itself isn’t difficult, it usually takes a week or so to get a Java developer productive with it (maybe more with different backgrounds).

          Then again I’ve always considered languages as tools for building interesting things. Productivity is what counts. The moment my team is more productive in another language we could switch if it’s worth the investment.

          Software doesn’t really have to be that good to be useful. Speed of development and iteration is more important than the strength of the type system. Sometimes it’s just cheaper to fix bugs due to bad language design than it is to understand abstractions in an expressive type system.

        2. 3

          Wasn’t this domain blocked for spamming ring?

          1. 4

            Submitters were, domain was not.

            1. 1

              I realize that submissions from this domain were kind of spammy in the past. I am not affiliated with the site.

              In contrast to the earlier submissions, I found this article interesting in terms of language design and evolution, and more likely to spark discussion.

            2. 2

              This all seems pretty good, but overloading enum for ADTs seems like an own-goal.

              1. 3

                Agree on this.

                I believe that enums-as-a-fixed-list-of-values and enums-as-ADTs share little commonality.

                Everything you want in one case is impossible to get in the other case (e. g. a values function, returning all enum values).

                My approach is to use

                @enum
                module Size {
                  module S
                  module M
                  module L
                }
                

                for the enums-as-fixed-list-of-values.

                @enum is pretty much just telling the compiler “only allow modules, not classes; and synthesize some convenience methods (like values, valueOf).

                For enums-as-ADTs I’d settle on reusing existing language elements:

                @abstract @sealed class Pet(let name: String)
                class Dog(let color: Color, let name, String) extends Pet(name)
                class Cat(let mood: Mood, let name, String) extends Pet(name)
                

                I found the “convenience” of the more concise¹ enum syntax never worth it:

                You end up with this uneasy relationship where things either work exactly like the class hierarchy above (then why have enum in the first place?) or you have slight differences which make things just different enough that you have to actually think whether to use enums or a class hierarchy.

                A good example is whether the Dog/Cats cases get their own distinct type in something like

                enum Pet(name: String) {
                    case Dog(color: Color, name, String) extends Pet(name)
                    case Cat(mood: Mood, name, String) extends Pet(name)
                }
                

                Rust followed Haskell’s course here, and if you are accustomed to Scala, it’s really really painful and infuriating.


                ¹ which – outside of toy examples – is not even true