42 ms·

Scala projects are difficult to maintain

166 points by MrPowers 6y ago

PaulHoule 6y ago
This is so even at a low-level. Look at the beautiful code examples in a Scala book and you might be seduced, but make a small change and there is nothing beautiful about it.
- nullifidian 6y ago
  Does rust have this issue? Anyone with experience?
  - tormeh 6y ago
    I love Rust, but it always looks ugly.
    - pornel 6y ago
      It's the semantics that counts.
  - KingOfCoders 6y ago
    Wrote 100k+ lines of Scala, now write Rust. It's very different, Rust has much more noise (but I like Rust as a language a lot) and doesn't look beautiful.
  - terhechte 6y ago
    I did a lot of Scala some years ago and also ended up in sort of a ragequit. Nowadays I'm mostly doing Rust or Swift. Rust, of course, has a steep learning curve due to the lifetime & borrowing system. However, the errors are usually very easy to understand. In the rare case where they aren't, it is easy enough to figure out what's wrong by searching for the error message. One of the Scala issues I had was that the error was the compiler throwing up a stream of sigils because some generic requirement didn't hold and it was very very difficult to search for, let alone understand what was wrong. Granted, it's been almost 6 years since I stopped using Scala. The experience that broke me back then was trying to use Slick, a typesafe Scala ORM. I forgot the details but I remember it was astonishingly hard to use back then and I couldn't for the life of me tell what was wrong because the compiler error message was so cryptic.
    - thinkharderdev 6y ago
      Yeah, it has gotten tremendously better in the last couple years when it comes to cryptic compiler errors. But even then Slick was a particularly egregious example. I had many WTF moments using Slick a few years back.
    - AzzieElbab 6y ago
      Yeah slicks errors were terrifying back in the days. They fixed both slick and scala to simply tell you which implicits were missing
    - AheadOfTime295 6y ago
      The maintainer of Slick was in the last round of layoffs at Lightbend. Not sure who maintains Slick these days. https://news.ycombinator.com/item?id=22854494 https://news.ycombinator.com/item?id=22854494
  - tgv 6y ago
    In my little experience with rust, things can get ugly very quickly, but it depends very much on the task. I wrote a game server monitor, and a fairly extensive command line calculator in rust, and that code for all those looks quite fancy. I wrote a tool that converts a lexicon to a trie and one that can do error correction using that trie, and that has some quirks. I also tried porting an Earley parser from C, and that took a nasty turn, since it relies a lot on pointer sharing. I have more experience writing in Go, and I think the code for all would look similar-ish. Go is a bit of a grey language, but it gets the job done without a lot of refactoring and restructuring.
  - hota_mazi 6y ago
    Rust was a surprise to me. I didn't expect to like it (I'm a Kotlin person) but I ended up pretty happy with it overall. I'm happy to pay the complexity tax associated with the borrow checker. You get outstanding performance and you usually don't need to dive deep into lifetimes to get some basic code running. The language itself is reasonably pleasant but is missing some key features that really annoy me: - No overloading - No default parameters - No named parameters - Awkward constructor syntax which causes a lot of copy/pasting boiler plate But overall, I'd say Rust is safely in my #2 spot, with Kotlin a bit ahead at #1.
- thinkharderdev 6y ago
  Interesting. I've had the opposite experience. Setting aside the question of beauty (which can often be pretty subjective), I usually find that scaling up solutions you might see in a libraries documentation (which are necessarily simple) to more complex "real world" solutions is generally easier in Scala than in other languages. I don't know quite how to describe why that is other than to say that the composition of primitives concepts in Scala seems to be more consistent and principled than in other languages I've used. The only concrete case I can think of where your sentiment rings true is when you try and do some fancy dependent-typing thing for strict type safety and you end up having to right some (VERY) ugly type lambdas. But then again that has mostly gone away with how 2.13+ handles existential types and of course with the Kind Projector compiler plugin.
- asimpletune 6y ago
  Yeah I’ve had totally the opposite experience. I would inherit dumpster fire Scala code based and found the language always gave me the tools I would need to apply refactorings with surgical precision, always maintaining some invariant (e.g. code compiles, test pass, etc...) for each commit. By the end of whatever work I was doing, there was always the added benefit of the code base looking and feeling much better. Plus it’d take maybe 1/5 as much time to do a huge refactor compared to my experience in say Java. I really don’t understand why people have such a hard time with Scala, other than its very different from imperative ways or doing things.
marcinzm 6y ago
>Python projects that are built with Python 3.6 are usable in Python 3.7 projects for example. This has not been my experience in the Machine Learning space.
- high_density 6y ago
  for most simple HTTP webservers, python maintains somewhat OK-ish source/binary compatibility between python-versions. But my experience with scala was things breaking between scala-versions / waiting for some library to compile with next scala-version... I'm surprised why scala couldn't solve it better than python -- I mean, scala's a compiled language, so it should have more wriggle-room...
  - AzzieElbab 6y ago
    it is intentional. scala maintainers want to keep the language evolving faster than python/java. if you look at scala3/dotty, it actually is a very different language than scala2
  - Someone 6y ago
    Scala’s type system doesn’t map perfectly to that of the JVM, so they had to bend the latter to implement scala. That’s similar to how C++ compilers bend the rules to confirm with C linkers (https://en.wikipedia.org/wiki/Name_mangling#C++ https://en.wikipedia.org/wiki/Name_mangling#C++), but much more complex because of the richer type system of the JVM. Scala developers aren’t willing to freeze that mapping, partly because they found out better ways to do such mappings, and partly because they keep changing the language, changing what was the best way to do that mapping. I think it’s easier for interpreted languages to keep their internals compatible. They are willing to give up some speed for convenience, so even if they think “I wish we had done that differently”, the pressure to change it isn’t that high. They also keep more metadata around. In some cases, that enables them to discover “this is using the old way to do Foo”, and fix that up to use the new way.
- lindig 6y ago
  Python is distributed in source code and it sounds like Scala dependencies are distributed as JAR files. The compatibility problems when moving compilers are not entirely unexpected, I'd say.
tormeh 6y ago
> Scala can also bring out the weirdness in programmers and create codebases that are incredibly difficult to follow, independent of the maintenance cost. Some programmers are more interested in functional programming paradigms and category theory than the drudgery of generating business value for paying customers. This is the tragedy of Scala. The maintenance cost is bearable. In return you get a language that dares to shed legacy cruft and fix bugs. Trash fire code bases, on the other hand, are hard to deal with.
- forty 6y ago
  To be honest I'm also seeing this with Typescript for example. I have seen some much energy wasted just for the pleasure of using RambdaJS[1] with TS. It's probably even worse than with Scala, because at least with Scala the language is on your side to do FP. [1] https://ramdajs.com/ https://ramdajs.com/
  - weatherlight 6y ago
    I've used typescript with lodash/fp (a similar FP library) and I found it to be an absolute joy. Once the team decided to really use lodash/fp for data manipulation, and the basis for composable logic, we really start to move quick. We came up with our own linting guide, and guidelines for writing extensible and composable code. I've never coded in Scala, but I've shipped production code in languages that support multiple paradigms. Conventions are important. Things need need to be agreed upon and done in a certain way or your code base will become a tangled mess.
syats 6y ago
I have only marginal experience with both but.. isn't this the case also with java nowadays?
- MrPowers 6y ago
  Don't have a lot of Java experience, but think it's backwards compatible, even across major versions, whereas Scala isn't even backwards compatible for minor versions.
  - thinkharderdev 6y ago
    Minor versions are not binary compatible but in general it is trivial to cross-compile for different Scala versions if you are writing a library and SBT makes it pretty simple to use the right binary for your projects Scala version. As the author mentions this sort of breaks down when library authors drop support for older Scala versions. In my experience though that is primarily an issue with Spark being way behind in Scala version support.
- loginatnine 6y ago
  Not quite, java binaries are backward compatible (but they are not forward compatible). This means that as long as your runtime and build binaries stay relatively recent (by that I mean java 8 and up at this present date), you won't get any compatibility problem.
flurdy 6y ago
> Difficult to publish to Maven No more than Java, but also why most Scala projects publish to Bintray as it much smoother. Oh wait... https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocen...
- taeric 6y ago
  Java, you just have to publish a version, right? My understanding with scala was that many of the versions are not compatible with each other.
commandlinefan 6y ago
Scala has a Lisp-like quality in that I feel like I should love it. On a certain, 30,000-ft level, I do, but when I'm actually trying to solve a real problem I usually end up just doing it in Java and then "translating" it back into Scala.
- taeric 6y ago
  I'm curious, what is the lisp like quality? I like scala. I haven't used it for anything big, though. And hard to argue that it has an interesting approach to discipline. Lisp, though, I like to use. I'm not as impressed with myself for getting something working in it. I am impressed that all of my books have code still work.
  - commandlinefan 6y ago
    I mean I feel like I should love Lisp the way I feel like I should love Scala - int he abstract I do, but practically neither is my go-to.
    - taeric 6y ago
      Fair. I didn't know if there was any practice overlap. For me, lisp is bigger in the meta programming. Really pulls the covers back on how things relate. Not just in how to put the code together, but how to look at the data. Scala was my first big intro to category theory. Helped me see relations in some higher ideas. Many, though, are hard to see a priori.
      - orwin 6y ago
        The issue i have with metaprogramming (lisp or elixir but also C++ macro) is that it is easy to forget, unlike most programming principle. It require you to twist your mind, and if you stop for two-three years, it require efforts to put your head back in that space.
        taeric 6y ago
manishsharan 6y ago
Not to brag but I recently ported our legacy java code base written for Java 1.5 to Java 8. The only change we made was to swap the jdbc jar as we also upgraded our Oracle DB.
- oblio 6y ago
  8 to 11 can be a bit trickier, though. Subsequent upgrades should be boring again, but 8->9 can get interesting.
  - thomascgalvin 6y ago
    I just upgraded a spring boot app from 8 to 15, and it was seamless. It's been long enough now that most major dependencies just work with 9+ again.
    - EdwardDiego 6y ago
      Trying to upgrade stuff like Spring from 4.3 because you need 5.1 to run on Java 11+ is where we've felt the pain the most, but then we were doing some awful Spring stuff.
- spicybright 6y ago
  Damn dude, nice work. We've going 8 -> 11 right now and it's a pain in the butt.
  - MockObject 6y ago
    What pain are you having specifically?
    - erik_seaberg 6y ago
      A former co-worker wrote a saga about trying to use modules in today’s Java ecosystem: https://www.theoryofgeek.com/articles/fomo-java-module-edition https://www.theoryofgeek.com/articles/fomo-java-module-editi... TL;DR: anyone doing it wrong anywhere breaks you, and it’s only a win if you feel a need to rip pieces out of your JVM.
wpietri 6y ago
I feel this one. I really liked the ambition and ideas of Scala, and after I took Odersky's own Scala course, I was all charged up to use it. But so many things about it end up being a giant pain in the ass that it just wasn't worth it to me for general-purpose coding.
pabs3 6y ago
Also Scala is not (yet) bootstrappable and the first binaries depended on proprietary software. https://bootstrappable.org/projects/jvm-languages.html https://bootstrappable.org/projects/jvm-languages.html https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specific_Languages#Scala https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specif...
- miloignis 6y ago
  Now that's an interesting thought. Since someone was already working on a bootstrapping compiler, I suppose that's the best way, but since the JVM is so high level in general, and doesn't normally have many optimizations at the bytecode level, I almost wonder if it wouldn't be easier to start from one of the early compilers de-compiled into Java instead.
  - pabs3 6y ago
    A de-compiled compiler is not something software freedom purists like the Bootstrappable Builds folks would touch with a 6-foot pole. Their approach is to write secondary smaller implementations of the same thing in other languages and use those to build the larger thing. The seed of their bootstrap less than 1000 bytes of hand-written machine code (not assembly), and they are working on eventually reaching a full Linux distro.
anthonyskipper 6y ago
I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really miss the FP awesomeness honestly... but simplicity trumps doing either of those things well.
- KingOfCoders 6y ago
  We chose Scala, had so many problems with the eco system and compiler and community, still love the language, it's the programming language I've enjoyed most, but glad we sold the startup.
- tootie 6y ago
  I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.
  - mumblemumble 6y ago
    I didn't run into problems with recruiting in general being too difficult. Plenty of people are interested in FP and are eager to do it professionally. But recruiting the right mix of people can be a challenge. Scala tends to attract people with an experimental temperament, and scare away more conservative developers. A team needs a healthy mix of both, though. It's the creative tension among different attitudes about how to write code that yields the best work in the long run.
    - worldsayshi 6y ago
      In contrast I think that going all in on Java scares away people who like to experiment.
thinkharderdev 6y ago
Meh, the complaints fall basically in two categories: 1. Open source libraries are sometimes not maintained which is absolutely true but also just a general hazard of the open source software ecosystem. The solution in most cases is to just not use open source libraries that are somebody's hobby project (which the author very sensibly recommends). But that is true whether you are using Scala or not. 2. Spark is weird. Which is true but that seems like it is more to do with the idiosyncratic nature of Spark than it is anything to do with Scala. That is, Spark development is sort of its own category and poses certain problems that are pretty specific to Spark and you don't necessarily run into when you are building non-Spark project in Scala.
- MrPowers 6y ago
  Some responses: 1. Yea, but languages that are backwards compatible have libs that are useful for way longer. I can still use Java JAR files that were built with Java 8, and published many years ago. The open source libs get stale so much quicker in Scala. 2. I'd actually argue that Spark is less weird that some other dependencies. If you look at the cats README (https://github.com/typelevel/cats https://github.com/typelevel/cats) there is this caveat: Cats relies on improved type inference via the fix for SI-2712, which is not enabled by default. For Scala 2.11.9+ or 2.12 you should add the following to your build.sbt: scalacOptions += "-Ypartial-unification" More cats specific stuff here: https://github.com/sbt/sbt/releases/tag/v1.5.0-RC2 https://github.com/sbt/sbt/releases/tag/v1.5.0-RC2 I use Spark a lot so used that for the examples, but think other libs cause even weirder maintenance challenges.
  - thinkharderdev 6y ago
    Fair enough, the whole SI-2712 debacle is indeed a source of issues well beyond Spark but in general it's just a matter of adding a compiler flag to sort it out. The other example is of course the whole mess of macros... On the other side though, strict backwards compat creates it's own set of costs (that are often harder to quantify. Java backwards compatibility is great but it seems like it is also at least prat of the reason Java moves at such a glacial pace.
  - 6y ago
deleted 6y ago
[deleted]
AzzieElbab 6y ago
why not spark is a maintenance nightmare?
bg4 6y ago
In my experience, it's easier for many developers to blame the tools and language rather than admit the dumpster fire of a codebase was entirely their doing and their responsibility.
- devmunchies 6y ago
  fentanyl is 50-100x more potent than morphine. Its still the user's fault for overdosing, but overdosing is easier to do with fent. Pepsi is more potent (sugar) than an apple, easier to get fat. Still the consumer's fault. My point is the choice of language may require more energy to enforce better code practices. Scala is so feature packed that it makes it easy for a developer to... overdose.
  - thinkharderdev 6y ago
    Counterpoint. A focus on type-safety makes Scala less likely to suffer from too-clever-by-half solutions. Sometimes a group of developers will be smart enough to create an overly-complicated solution that still type checks and works (see the original Slick library...) but for most normal teams, the compiler is a guard against overly ambitious type magic. On the other hand, I've seen my fair share of too-clever uses of runtime reflection (Java) or weird metaprogramming (Python/JS) techniques, except they were not only too-clever but actually just didn't work and would fail miserably at inopportune times.
- arcturus17 6y ago
  It may be reasonable to think however that some technologies are more conducive to dumpster fires than others.
- imtringued 6y ago
  A more complicated language needs more skills and more skills mean you are inexperienced in at least some of those skills and inexperience causes dumpster fire codebases. When I started software development I had "hammer and nail syndrome" for absolutely everything. I figured out something new and then used it everywhere. Experimenting in this way is necessary but you absolutely want to avoid it in a production codebase. Over time you have run out of hammers and nails to play around with. You've developed the ability to judge where and when a specific hammer is most effective and when it shouldn't be used at all. Scala offers you a wide variety of hammers and nails. You'll have to experiment a lot.
weatherlight 6y ago
I feel like conventions would solve this problem. There's lots of programming languages that cater to multiple paradigms. Ruby and Javascript come to mind, conventions really do help when dealing with specific problems/frameworks. I'm not sure I agree with OPs blog post. This line specifically stuck out to me. "Scala should be avoided for easier problems that don’t require advance programming language features." What are advanced programming features? Isn't this just a matter of where you are coming to Scala from?
coding123 6y ago
I use Scala for exactly 1 thing: Spark. No intention to use it for anything else.
jmartrican 6y ago
> Scala libraries need to be cross compiled with different Scala versions. This seems like a big turn off. Question to any Scala dev's out there. Does this get in the way? And does it make upgrading Scala versions difficult?
- MrPowers 6y ago
  Upgrading Spark from Scala 2.11 to Scala 2.12 was a huge effort. See here for more discussion: https://contributors.scala-lang.org/t/spark-as-a-scala-gateway-drug-and-the-2-12-failure/1747 https://contributors.scala-lang.org/t/spark-as-a-scala-gatew... Some projects are easier to upgrade, but for complex projects, minor Scala version bumps can be quite challenging.
  - AheadOfTime295 6y ago
    And the story goes on: upgrading Spark to Scala 2.13 https://issues.apache.org/jira/browse/SPARK-25075 https://issues.apache.org/jira/browse/SPARK-25075
- thinkharderdev 6y ago
  Scala minor versions are not binary compatible. So if you try and use a library compiled for 2.12 in a project that is using 2.13 it won't work. In practice though it is not a major issue. It is easy for library authors to cross-compile for different versions and SBT handles fetching to correct binary dependency for your project. And in general, binary incompatibility doesn't mean source incompatibility. So generally uprgrading your projects scala version is as simple as changing the scalaVersion in your build.sbt. The exceptions are: 1. If you have a dependency that hasn't been cross-compiled for the new Scala version yet. So if you are trying to upgrade as soon as a new Scala minor version comes out then you may have issues if you have a lot of dependencies. 2. If you are trying to publish a library compiled for multiple older Scala versions then you can run into source compatibility issues. For instance, if you are using a method/interface that is new as of Scala 2.13 you won't be able to cross-compile to Scala 2.12.
gregorygoc 6y ago
I’ve seen lots of projects succeed in Scala, and I’ve seen some fail. The latter was usually caused by writing spaghetti code crap instead of language complexity itself. Obviously some programmers blamed the language, but the harsh reality is that competent engineers can make things work beautifully.
phekunde 6y ago
Have you tried C++, Rust, Java or any other language? They all at some point in the development cycle become a maintenance nightmare. I will let you on a secret, we software developers create problems and then solve those problems. That is how software developer jobs are retained :)
- mumblemumble 6y ago
  They all have their tipping points. They don't all herd you toward that tipping point at the same pace.
- MrPowers 6y ago
  I maintain open source libs in Python, Ruby, and Scala - the Scala libs are a lot more difficult to maintain. Certain languages prioritize backwards compatibility and maintainability over new features / complicated programming stuff. The maintenance burden is dramatically different for different languages in my experience.
- pornel 6y ago
  I have no complaints about Rust after it released 1.0. My oldest projects still build fine with the latest compiler (unlike my Node.js projects.) When I read the article I was shocked that 2.11/2.12/2.13 could be breaking changes that prevent existing libraries from working, and so badly that they take years to catch up.
- karmasimida 6y ago
  I mean that isn't the argument. Scala's problem is no unified paradigm is proposed or accepted at community level. 'Dumb' languages like Java/Go limited the style choices one programmer could take within the language, but Scala seems to encourage the opposite.
- attractivechaos 6y ago
  Software engineers solve simple existing problems by creating complex new problems.
karmasimida 6y ago
It is ironic that a language named itself as Scala, doesn't really scale with the team sizes.
- haakon 6y ago
  It was originally called Scala because the language itself could "scale"; the grammar was so flexible that you could use it to seemingly write new language constructs. For example `while` or `repeat` loops are expressible with functions, and it looks natural because dots can be replaced with spaces in many cases. Functions can have many special characters as names, and functions can be called in-fix, and so on. People took these possibilities and ran with them, creating all sorts of wonderfully illegible DSLs. It was widely recognised as a bad idea.
paedubucher 6y ago
I am really a beginner of both Scala and functional programming. I took the first Coursera course on Scala, and I got really frightened when I noticed that you can express many things in either the functional or in the object-oriented paradigm. One example is pattern matching vs. polymorphism. When you mix up those ideas throughout your code base, it might become really hard to understand. This is just a thought that I had, and I wonder if that's actually a relevant issue in practice.
- chriswarbo 6y ago
  FYI this is known as the "expression problem" https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem
  - paedubucher 6y ago
    Wow, thanks! It's always good to see if one's intuitive concerns are actually well-known computer science problems.
dfgdghdf 6y ago
Is the Scala language simply too big? I tried to learn it once (years ago) and quickly found myself overwhelmed by the number of concepts. I remember feeling like 80% of power of the language could have been achieved with 20% of the complexity. The latest Java releases are somewhat proving this with functional interfaces and records.
- MrPowers 6y ago
  There are certainly folks that argue the language it too big. Here's a great talk arguing that a lot of language features should be eliminated and Scala should be made a functional programming language: https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=Scalape%C3%B1o https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=... I'm personally in the camp of "keep Scala huge and weird and multi-paradigm, but just make less breaking changes and focus all efforts on making the ecosystem more stable".
  - lptk 6y ago
    Worth noting that the presenter of this talk has done a complete 180 on subtyping as he's now using subtyping and variance in the core of his flagship library ZIO. He realized it was sometimes better to use the language's strengths rather than denigrate them for "ideological" reasons. Also worth noting that Scala is not a "very big" language in any sense that I know of. It has a lot fewer features than C#, for instance. And probably a comparable amount to TypeScript.
- chriswarbo 6y ago
  I've been at a Scala shop for just over a year, and it's certainly the case that there's a lot of overlap between language features. Personally I prefer having to make judgement calls as needed, rather than being shoehorned into a one-size-fits-all approach (e.g. like Java's class-based, single-inheritance OOP). One thing I find encouraging is that Scala features may become deprecated (either explicitly or de facto) if an overlapping feature is added that works 'better'. Examples I've come across are Manifest getting replaced by TypeTag and implicit coercions getting replaced by implicit classes.
- 6y ago
johndoe42377 6y ago
This is why lots of projects in all languages import dependencies and recompile them themselves. Little bit more work when upgrading, but much less pain.
dudul 6y ago
"Open source libraries are often abandoned, especially in Scala." Is this claim backed by anything?
dmarlow 6y ago
I've been on C# for over a decade and I'm still very happy with it. I think it's highly underrated in the startup space. When helping start my current startup, one of the founders asked why I chose C# as he was asked by others why we'd pick that language/stack as it's not common for SF startups. I told him that it's less about the language and I could do just about anything with it. It's turned out great and of all the things to worry about, the language hasn't ever come up again.
- kemiller2002 6y ago
  C# is definitely not sexy, but it is well documented, and there is plenty of help. I don't see why more companies go this route (not just C#, but any language that fits this). Boring is good when you have a short timeframe and it has to work well with minimal fuss.
  - ywei3410 6y ago
    "Boring" languages almost always equal more boilerplate. Personally, I'll take an expressive, GC'ed language, but write "boring"-ish code when I'm on a short time-frame and I have few developers. EDIT. Just realised this sounds needlessly antagonistic; the point I'm trying to make is that "boring" is too coarse a measurement. Java 1.8 is more "boring" with it's required explicit type declarations, but I would /always/ pick a newer Java version to avoid the boilerplate.
- woohoo7676 6y ago
  Agreed - the startup I work with now uses C# and its been very solid. The tooling is good, and the lang has never gotten in the way of getting work done.
hotz 6y ago
I wouldn't trust my colleagues with it. I'd dread any tool that allows them to achieve even more over engineering feats.
dustingetz 6y ago
The problem is that functional programming is a really good idea but nobody has figured out (yet) the specific industry applications where it makes possible new things that weren't possible before. Mapreduce was a big win but you can do it in java. Spark was a big win but you can drive it from python. How do you make a better CRUD app in Scala? Serving http requests but with monads is not the answer.
- valenterry 6y ago
  You could say the same about OOP though. Just like FP, OOP doesn't make new things possible, it just makes some things much easier.
  - dustingetz 6y ago
    java succeeded because of managed memory, which made it possible to build systems that didn’t randomly segfault by default
ydnaclementine 6y ago
I think about scala a bit because the second biggest chess website (lichess) is open source and written in play framework/scala. Was interested in learning some scala to help contribute since I play on the site so often Wonder if they've run into these issues with the language though
- lptk 6y ago
  They almost certainly run into these issues, but like most of the community, they probably think the cost is well worth bearing, given the advantages the language gives you. Once you're used to the way it works, and if you're using well-maintained libraries, I find that it's really not such a big deal. Though it's always awkward to have transitive dependency conflicts, and those are best avoided if possible.
blackoil 6y ago
As an old pragmatic, I believe for a new startup language of choice must be Java/C#. * Stable, Well understood language. * Rich ecosystem. * Fast enough. * Plenty of developers to hire from. * Scales well to large projects. No other language/ecosystem ticks all the checkboxes.
- dcolkitt 6y ago
  Go? Typescript? C++1x?
  - gbersac 6y ago
    C++ is much more complex than Scala! Typescript is great because you can create back and front in the same language.
  - camjohnson26 6y ago
    Python, Ruby, JavaScript
- mumblemumble 6y ago
  If the list is meant to be universal, I would strike the last two from it, and clarify that "fast enough" means, "Fast enough for the problem you're trying to solve." Working from the bottom: Scaling well to large projects is only a concern if you expect your individual projects to become large. I've worked on monoliths, and I've worked on systems that follow more of a Unix philosophy. In the former case, we had one project with a 7 digit line count. In the latter case, it was rare for a single application's codebase to grow to more than a few thousand lines of code. "Plenty of developers to hire from" is often optimizing for the wrong problem. In many lines of business, domain expertise is a much more valuable skill, because it can only be developed through years of first-hand experience. A new programming language, on the other hand, can typically be taught to a reasonably skilled programmer in no more than a couple weeks. Also, when you're just starting out, the single best programming language you can pick is the one that the people actually starting the business already know the best. They will not have senior mentors to help them learn the best way to use a new language. Finally, "fast enough" is not a single target or a strict hierarchy. I used to work at a shop where we used Python, C#, and C++. Only C++ was fast enough, performance-wise, for some problems. Only Python was fast enough, productivity-wise, for other problems. C# covered the (large) middle ground. It's also not a strict hierarchy. At my current job, I'm in the middle of a project to replace some Java components with Python. Java has not proven to be fast enough, performance-wise, for this particular problem, while Python gets us there with room to spare.
practice9 6y ago
Some of the worst and unmaintainable code I've ever seen was written in Python & Java. While some of the cleanest codebases were written in Scala and Javascript. The problem is not the language, but the team & overall approach to development (rushing to deploy bad code because your manager said so; lack of code review). Tooling can be better, but it was massively improved over last 2 years
- flurdy 6y ago
  I have seen quagmire in several languages at various small and very large companies. So many withered and bloated Java apps that is hard to maintain. And I agree it is not the language, it is the stewardship. Who they hire, how they manage their tech, culture, pairing/mob, quality over speed etc. And the reality that all codebases rot, at different speeds depending on these factors, but eventually they all rot. I have seen well maintained large Scala architectures, at very large organisations because of great stewardship of the projects and people. And I have seen car-crash bundle of apps in Scala because they hired rockstar developers that incorporated every shiny feature continuously leaving it unmaintainable by the rest. Or by recent Java converts that were not mentored well enough so still writing Java code in Scala. I love Scala but with bad HR processes and weak leadership it will ground to a halt. And they will blame the language not themselves. But the same would probably have happened with any language.
- switchbak 6y ago
  I've written a ton of code in a bunch of different languages, and you're exactly on point here. It's got everything to do with discipline and time spent on creating and keeping a codebase simple and well factored. If you don't have a team doing that, you're going to have problems. Scala is a sharp tool, in the wrong hands you're gonna slice your toes off. In the right hands, you can create simple, elegant solutions to challenging problems.
The_rationalist 6y ago
Scala 3 should help simplify the language and reduce abuse of features like implicits: https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html
didibus 6y ago
That's one of the reasons I prefer Clojure over Scala, it has rock solid stability, and a great track record of backwards compatibility.
rabzu 6y ago
I used Scala for all my startups since 2015. Currently, we moved everything to scala ZIO last year. In a nutshell we love Scala.
AzzieElbab 6y ago
But Java had adopted about 75% of scala’s features from 5 years ago. Mostly with some quirky limitations and bloated syntax. What exactly makes it easier for people to understand is beyond me
- hota_mazi 6y ago
  Because less is more. What makes Java and Kotlin more popular languages than Scala is that both Java and Kotlin are being extremely deliberate in choosing what features they include and more importantly, which not to include. Scala includes everything by default because it allows the EPFL to submit a lot of papers to conferences.
  - valenterry 6y ago
    Why do you think Scala has more features than Java/Kotlin? I think it's the opposite. For example null: where Kotlin has a special operator and semantics, Scala simply has the "Option" type in the std lib.
    - hota_mazi 6y ago
      Do you seriously think Scala has fewer features than Java and Kotlin?
      - AzzieElbab 6y ago
        But there is no such thing as Java. It is Java plus spring plus guava plus something else for immutables
        hota_mazi 6y ago
        All languages have their libraries and design patterns, not sure how your comment answers my question.
        thinkharderdev 6y ago
dehrmann 6y ago
> Publishing open source project to Maven is way more difficult than most language ecosystems. Maybe this is a feature, not a bug. I won't call out the language/repo, but I was able to gain admin access for a library my company published with just an email from my company's domain. There are major security issues with "easy." There are also quality issues. You're more likely to publish something if you think it has value; I've published work to Maven Central, but only the high-quality, reusable work.
- uDontKnowMe 6y ago
  Would have to disagree here. Just raising the bar higher for publishing at all doesn't increase quality of libraries available. Consider how open source in general really became much more the norm after Github made it trivially easy to publish and collaborate on code.
JD557 6y ago
I might be a bit biased, since I've been writing Scala professionally for years. While most of the article rings true, I wanted to share some counter-arguments: 1) A lot of the problems mentioned are only really noticeable if you use Spark, which really lags behind in Scala versions compared to the rest of the ecosystem. As someone who doesn't use Spark, I don't really feel much of the "Scala minor versions" pain. 2) While not great, cross-compilation/publishing is not that bad (there are plugins like `sbt-release` and `sbt-crossproject` that pretty much take care of it). 3) I mostly disagree with the "Difficult to publish to Maven" point. I'm not saying that it's easy, but I enjoy the fact that it's not as trivial like other languages. I would argue that this whole process makes [1] almost impossible, which is a plus for me. 1: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...
- worace 6y ago
  Yeah point 3 is underappreciated for sure. > You need to open a JIRA ticket to get a namespace, create GPG keys, register keys in a keyserver, and add SBT plugins just to get a manual publishing process working. It’s a lot more work than publishing to PyPI or RubyGems. It's a little annoying to have to go through that, but you only have to do it once per domain, and the turnaround from the people who manage the sonatype jira is usually pretty quick. In return the ecosystem gets a lot of protection from the kind of exploits you mentioned.
typon 6y ago
The same complexity problem of Scala is where I see Rust going
- haakon 6y ago
  Can you elaborate? Is Rust gradually becoming more complex?
pjmlp 6y ago
Which is why at the end of the day I always pick the platform language for production code. As long as the platform is relevant everything moves along without extra layers of tooling and idiomatic wrapper libraries for platform APIs. Might not have all the bells and whistles, not so shinny, but it works and I don't need to care about my replacement having headaches.
adamw1pl 6y ago
Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem catches up and actually makes good use of what's introduced in Java 11+. On the other hand, yes - Scala is in many ways a research language. It's got a number of novel features, starting from the blend of FP and OO, through implicits, ending with metaprogramming. The dark side of introducing features that other languages don't have, is that they sometimes need polishing or complete removal. That impacts the compiler (which evolves as well - compiling Scala code is much more complex than the rather straightforward translation of Java to bytecode) and high-level language features alike. The bright side is that software engineering is very far from being a "done field" (or at least I refuse to believe it is such). There's a lot to be discovered as to how we can write code that is readable, performant and - yes - maintainable. "Wait, but if you said Scala is a research language, is it safe for business usage?" Yes - while Scala has a research side to it, it also is a language used successfully in many companies. It has a lot of libraries that are maintained, the language authors pay a lot of attention to binary compatibility (with well-defined limits - you know what to expect!). Businesses have benefited from using the newest available technology in many fields, and I doubt software engineering should be different. Of course, you shouldn't be reckless - but using technology from 20 years ago "just to be safe" isn't always a recipe for success. Yes, you can build great systems with Java and Go. Same is true for Scala. And yes, you can build totally unmaintainable systems in Scala, but in Java and Go as well. Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free. You like the library, it solved your problem - great, you can use it for free. But if you want it maintained above what the library author donates, either through their time or through corporate sponsorship - well, you can't have any expectations here. I'm sure a lot of these migrations problems could be solved, given a reasonable business offer.
- sameei 6y ago
  > Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free True! but why Spark & Flink, which are backed with business, didn't bother themselves to catch up with changes in Scala! they delayed their upgrade to 2.12, not mention 2.13! and as far as I know the 3.0 hasn't been discussed yet! Am I right? In general I'm happy and thankful that I learned Scala! it shaped my perspective to combine programming paradigms and pick best practices from each one rather than sticking to a single paradigm. But for work that I wanna last long enough, I can't accept it, as there is no realm of calmness in view. Software Industry is a young industry and complex, like any other profession, and a developer need to think about lots of other things as well, not just the language and possible pattern/syntaxes it has to keep up with! I think the value that Scala brings into industry is what that prevents it from becoming the rival to others.
willtemperley 6y ago
I use Scala for e.g. running Hadoop map-reduce jobs or building REST endpoints. I’d never write a reusable library in Scala though for the reasons pointed out in the article, binary compatibility is not something Scala cares about. I’m never going to use a library written in Scala for the same reason, plus chances are I’d have to spend hours fiddling with SBT to rebuild it at some point. Scala (with Maven) at the top please, then Java all the way down thanks.
AtlasBarfed 6y ago
I've been looking for a video/presentation from one of the main Scala contributors before he left the team. I think I saw it about 8 years ago. It was highly critical. One of the main slides the stood out was discussing something like 20 or 30 different kinds of "types" in Scala. I cannot find it anymore, it may have disappeared with the political "drama" I've heard happened within Scala that included attempts to blackball people. I've never personally coded in it, I use groovy on the JVM and it satisfies my needs but it has nothing to brag about in terms of avoiding spaghetti code. It has all the same problems of bootstrapping any language that isn't a "X but distinctly better/easier/more features/fixes major problems in X". A big big lift. I think only Rust is a language that is sufficiently different that has any real long term chance.
- joshlemer 6y ago
  You're thinking of Paul Phillips https://www.youtube.com/results?search_query=paul+philips+scala https://www.youtube.com/results?search_query=paul+philips+sc...
cryptos 6y ago
After being a big fan of Scala about 10 years ago, I think that Kotlin is better suited in almost all cases. Kotlin is much easier to learn (especially if you know a similar language like Java, C# or TypeScript), much easier to read and understand and has much better long term stability. The support in IntelliJ is also better. Scala causes performance issues from time to time in IntelliJ and there are some language constructs that the IDE doesn't really understand in all cases. JetBrains build Kotlin as a programming language for industrial projects - and it shows.
DizzyStatement 6y ago
Well, in my humble opinion, I believe most people that choose scala, thinking of it "the better java" usually gets frustrated, especially when they start off using the "cool" stuff people say on twitter. Tbh, I've been programming in scala for 5 or 6 years now and have never worked with "proper" FP libraries like cats or zio. All the companies I've been working with, have used the lightbend stack, so basically play framework, which is easy to learn for someone coming from java/spring and the most different, Akka streams. One day one of my java colleagues started an argument saying scala was too complex etc etc. I asked based on which code? He mentioned scalaz. So tell me what the hell someone who has never programmed in scala before was doing looking at scalaz code? No wonder why a novice would think of it. The bottom line is that if you are new to scala and/or has no experienced developer nearby but still want to try out scala, just stick with the standard library and use play for your rest services. When you are confident enough with the language, if interested, have a look at the FP libraries.
ttymck 6y ago
I am an order of magnitude more productive in Scala, compared to python. The compiler does so much for me, I can focus on just writing my domain. Frankly, I think Scala is just good at exposing weak programmers and teams with poor discipline. I've seen far worse codebases in python where there's no disciple: all methods are public, monkey patch classes at runtime, etc. I think articles like this are so common because Scala is easy to pick on. "Implicits are bad" is more interesting than "Implicits have a very specific usefulness", but Implicits are peculiar and unique to scala so the language gets lampooned. "Private methods make code more maintainable" may be just as true, but no one says Python is universally hard to maintain -- so long as the person behind the keyboard knows what they are doing.

166 points by MrPowers 6y ago

This is so even at a low-level. Look at the beautiful code examples in a Scala book and you might be seduced, but make a small change and there is nothing beautiful about it.

nullifidian 6y ago
Does rust have this issue? Anyone with experience?
- tormeh 6y ago
  I love Rust, but it always looks ugly.
  - pornel 6y ago
    It's the semantics that counts.
- KingOfCoders 6y ago
  Wrote 100k+ lines of Scala, now write Rust. It's very different, Rust has much more noise (but I like Rust as a language a lot) and doesn't look beautiful.
- terhechte 6y ago
  I did a lot of Scala some years ago and also ended up in sort of a ragequit. Nowadays I'm mostly doing Rust or Swift. Rust, of course, has a steep learning curve due to the lifetime & borrowing system. However, the errors are usually very easy to understand. In the rare case where they aren't, it is easy enough to figure out what's wrong by searching for the error message. One of the Scala issues I had was that the error was the compiler throwing up a stream of sigils because some generic requirement didn't hold and it was very very difficult to search for, let alone understand what was wrong. Granted, it's been almost 6 years since I stopped using Scala. The experience that broke me back then was trying to use Slick, a typesafe Scala ORM. I forgot the details but I remember it was astonishingly hard to use back then and I couldn't for the life of me tell what was wrong because the compiler error message was so cryptic.
  - thinkharderdev 6y ago
    Yeah, it has gotten tremendously better in the last couple years when it comes to cryptic compiler errors. But even then Slick was a particularly egregious example. I had many WTF moments using Slick a few years back.
  - AzzieElbab 6y ago
    Yeah slicks errors were terrifying back in the days. They fixed both slick and scala to simply tell you which implicits were missing
  - AheadOfTime295 6y ago
    The maintainer of Slick was in the last round of layoffs at Lightbend. Not sure who maintains Slick these days. https://news.ycombinator.com/item?id=22854494 https://news.ycombinator.com/item?id=22854494
- tgv 6y ago
  In my little experience with rust, things can get ugly very quickly, but it depends very much on the task. I wrote a game server monitor, and a fairly extensive command line calculator in rust, and that code for all those looks quite fancy. I wrote a tool that converts a lexicon to a trie and one that can do error correction using that trie, and that has some quirks. I also tried porting an Earley parser from C, and that took a nasty turn, since it relies a lot on pointer sharing. I have more experience writing in Go, and I think the code for all would look similar-ish. Go is a bit of a grey language, but it gets the job done without a lot of refactoring and restructuring.
- hota_mazi 6y ago
  Rust was a surprise to me. I didn't expect to like it (I'm a Kotlin person) but I ended up pretty happy with it overall. I'm happy to pay the complexity tax associated with the borrow checker. You get outstanding performance and you usually don't need to dive deep into lifetimes to get some basic code running. The language itself is reasonably pleasant but is missing some key features that really annoy me: - No overloading - No default parameters - No named parameters - Awkward constructor syntax which causes a lot of copy/pasting boiler plate But overall, I'd say Rust is safely in my #2 spot, with Kotlin a bit ahead at #1.
thinkharderdev 6y ago
Interesting. I've had the opposite experience. Setting aside the question of beauty (which can often be pretty subjective), I usually find that scaling up solutions you might see in a libraries documentation (which are necessarily simple) to more complex "real world" solutions is generally easier in Scala than in other languages. I don't know quite how to describe why that is other than to say that the composition of primitives concepts in Scala seems to be more consistent and principled than in other languages I've used. The only concrete case I can think of where your sentiment rings true is when you try and do some fancy dependent-typing thing for strict type safety and you end up having to right some (VERY) ugly type lambdas. But then again that has mostly gone away with how 2.13+ handles existential types and of course with the Kind Projector compiler plugin.
asimpletune 6y ago
Yeah I’ve had totally the opposite experience. I would inherit dumpster fire Scala code based and found the language always gave me the tools I would need to apply refactorings with surgical precision, always maintaining some invariant (e.g. code compiles, test pass, etc...) for each commit. By the end of whatever work I was doing, there was always the added benefit of the code base looking and feeling much better. Plus it’d take maybe 1/5 as much time to do a huge refactor compared to my experience in say Java. I really don’t understand why people have such a hard time with Scala, other than its very different from imperative ways or doing things.

marcinzm 6y ago

>Python projects that are built with Python 3.6 are usable in Python 3.7 projects for example. This has not been my experience in the Machine Learning space.

high_density 6y ago
for most simple HTTP webservers, python maintains somewhat OK-ish source/binary compatibility between python-versions. But my experience with scala was things breaking between scala-versions / waiting for some library to compile with next scala-version... I'm surprised why scala couldn't solve it better than python -- I mean, scala's a compiled language, so it should have more wriggle-room...
- AzzieElbab 6y ago
  it is intentional. scala maintainers want to keep the language evolving faster than python/java. if you look at scala3/dotty, it actually is a very different language than scala2
- Someone 6y ago
  Scala’s type system doesn’t map perfectly to that of the JVM, so they had to bend the latter to implement scala. That’s similar to how C++ compilers bend the rules to confirm with C linkers (https://en.wikipedia.org/wiki/Name_mangling#C++ https://en.wikipedia.org/wiki/Name_mangling#C++), but much more complex because of the richer type system of the JVM. Scala developers aren’t willing to freeze that mapping, partly because they found out better ways to do such mappings, and partly because they keep changing the language, changing what was the best way to do that mapping. I think it’s easier for interpreted languages to keep their internals compatible. They are willing to give up some speed for convenience, so even if they think “I wish we had done that differently”, the pressure to change it isn’t that high. They also keep more metadata around. In some cases, that enables them to discover “this is using the old way to do Foo”, and fix that up to use the new way.
lindig 6y ago
Python is distributed in source code and it sounds like Scala dependencies are distributed as JAR files. The compatibility problems when moving compilers are not entirely unexpected, I'd say.

tormeh 6y ago

> Scala can also bring out the weirdness in programmers and create codebases that are incredibly difficult to follow, independent of the maintenance cost. Some programmers are more interested in functional programming paradigms and category theory than the drudgery of generating business value for paying customers. This is the tragedy of Scala. The maintenance cost is bearable. In return you get a language that dares to shed legacy cruft and fix bugs. Trash fire code bases, on the other hand, are hard to deal with.

forty 6y ago
To be honest I'm also seeing this with Typescript for example. I have seen some much energy wasted just for the pleasure of using RambdaJS[1] with TS. It's probably even worse than with Scala, because at least with Scala the language is on your side to do FP. [1] https://ramdajs.com/ https://ramdajs.com/
- weatherlight 6y ago
  I've used typescript with lodash/fp (a similar FP library) and I found it to be an absolute joy. Once the team decided to really use lodash/fp for data manipulation, and the basis for composable logic, we really start to move quick. We came up with our own linting guide, and guidelines for writing extensible and composable code. I've never coded in Scala, but I've shipped production code in languages that support multiple paradigms. Conventions are important. Things need need to be agreed upon and done in a certain way or your code base will become a tangled mess.

syats 6y ago

I have only marginal experience with both but.. isn't this the case also with java nowadays?

MrPowers 6y ago
Don't have a lot of Java experience, but think it's backwards compatible, even across major versions, whereas Scala isn't even backwards compatible for minor versions.
- thinkharderdev 6y ago
  Minor versions are not binary compatible but in general it is trivial to cross-compile for different Scala versions if you are writing a library and SBT makes it pretty simple to use the right binary for your projects Scala version. As the author mentions this sort of breaks down when library authors drop support for older Scala versions. In my experience though that is primarily an issue with Spark being way behind in Scala version support.
loginatnine 6y ago
Not quite, java binaries are backward compatible (but they are not forward compatible). This means that as long as your runtime and build binaries stay relatively recent (by that I mean java 8 and up at this present date), you won't get any compatibility problem.

flurdy 6y ago

> Difficult to publish to Maven No more than Java, but also why most Scala projects publish to Bintray as it much smoother. Oh wait... https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/ https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocen...

taeric 6y ago
Java, you just have to publish a version, right? My understanding with scala was that many of the versions are not compatible with each other.

commandlinefan 6y ago

Scala has a Lisp-like quality in that I feel like I should love it. On a certain, 30,000-ft level, I do, but when I'm actually trying to solve a real problem I usually end up just doing it in Java and then "translating" it back into Scala.

taeric 6y ago
I'm curious, what is the lisp like quality? I like scala. I haven't used it for anything big, though. And hard to argue that it has an interesting approach to discipline. Lisp, though, I like to use. I'm not as impressed with myself for getting something working in it. I am impressed that all of my books have code still work.
- commandlinefan 6y ago
  I mean I feel like I should love Lisp the way I feel like I should love Scala - int he abstract I do, but practically neither is my go-to.
  - taeric 6y ago
    Fair. I didn't know if there was any practice overlap. For me, lisp is bigger in the meta programming. Really pulls the covers back on how things relate. Not just in how to put the code together, but how to look at the data. Scala was my first big intro to category theory. Helped me see relations in some higher ideas. Many, though, are hard to see a priori.
    - orwin 6y ago
      The issue i have with metaprogramming (lisp or elixir but also C++ macro) is that it is easy to forget, unlike most programming principle. It require you to twist your mind, and if you stop for two-three years, it require efforts to put your head back in that space.
      - taeric 6y ago

manishsharan 6y ago

Not to brag but I recently ported our legacy java code base written for Java 1.5 to Java 8. The only change we made was to swap the jdbc jar as we also upgraded our Oracle DB.

oblio 6y ago
8 to 11 can be a bit trickier, though. Subsequent upgrades should be boring again, but 8->9 can get interesting.
- thomascgalvin 6y ago
  I just upgraded a spring boot app from 8 to 15, and it was seamless. It's been long enough now that most major dependencies just work with 9+ again.
  - EdwardDiego 6y ago
    Trying to upgrade stuff like Spring from 4.3 because you need 5.1 to run on Java 11+ is where we've felt the pain the most, but then we were doing some awful Spring stuff.
spicybright 6y ago
Damn dude, nice work. We've going 8 -> 11 right now and it's a pain in the butt.
- MockObject 6y ago
  What pain are you having specifically?
  - erik_seaberg 6y ago
    A former co-worker wrote a saga about trying to use modules in today’s Java ecosystem: https://www.theoryofgeek.com/articles/fomo-java-module-edition https://www.theoryofgeek.com/articles/fomo-java-module-editi... TL;DR: anyone doing it wrong anywhere breaks you, and it’s only a win if you feel a need to rip pieces out of your JVM.

wpietri 6y ago

I feel this one. I really liked the ambition and ideas of Scala, and after I took Odersky's own Scala course, I was all charged up to use it. But so many things about it end up being a giant pain in the ass that it just wasn't worth it to me for general-purpose coding.

pabs3 6y ago

Also Scala is not (yet) bootstrappable and the first binaries depended on proprietary software. https://bootstrappable.org/projects/jvm-languages.html https://bootstrappable.org/projects/jvm-languages.html https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specific_Languages#Scala https://bootstrapping.miraheze.org/wiki/Bootstrapping_Specif...

miloignis 6y ago
Now that's an interesting thought. Since someone was already working on a bootstrapping compiler, I suppose that's the best way, but since the JVM is so high level in general, and doesn't normally have many optimizations at the bytecode level, I almost wonder if it wouldn't be easier to start from one of the early compilers de-compiled into Java instead.
- pabs3 6y ago
  A de-compiled compiler is not something software freedom purists like the Bootstrappable Builds folks would touch with a 6-foot pole. Their approach is to write secondary smaller implementations of the same thing in other languages and use those to build the larger thing. The seed of their bootstrap less than 1000 bytes of hand-written machine code (not assembly), and they are working on eventually reaching a full Linux distro.

anthonyskipper 6y ago

I had a startup that went all in on scala. By the time we realized we chose the wrong language it was too late. Complexity is the primary issue with the scala language... when the whole goal is to have a scalable language which in itself is diametrically opposed to simplicity, your language is dead on arrival. After using Scala, Go seemed like a dream come true. We really loved the integration of OO and FP, really miss the FP awesomeness honestly... but simplicity trumps doing either of those things well.

KingOfCoders 6y ago
We chose Scala, had so many problems with the eco system and compiler and community, still love the language, it's the programming language I've enjoyed most, but glad we sold the startup.
tootie 6y ago
I only witnessed from the outside, but saw a similar story play out. A client had bet on Scala for a new platform and made it about 6 months in before throwing in the towel and rewriting the whole thing in in Java. It's too hard to recruit and the tooling isn't mature enough.
- mumblemumble 6y ago
  I didn't run into problems with recruiting in general being too difficult. Plenty of people are interested in FP and are eager to do it professionally. But recruiting the right mix of people can be a challenge. Scala tends to attract people with an experimental temperament, and scare away more conservative developers. A team needs a healthy mix of both, though. It's the creative tension among different attitudes about how to write code that yields the best work in the long run.
  - worldsayshi 6y ago
    In contrast I think that going all in on Java scares away people who like to experiment.

thinkharderdev 6y ago

Meh, the complaints fall basically in two categories: 1. Open source libraries are sometimes not maintained which is absolutely true but also just a general hazard of the open source software ecosystem. The solution in most cases is to just not use open source libraries that are somebody's hobby project (which the author very sensibly recommends). But that is true whether you are using Scala or not. 2. Spark is weird. Which is true but that seems like it is more to do with the idiosyncratic nature of Spark than it is anything to do with Scala. That is, Spark development is sort of its own category and poses certain problems that are pretty specific to Spark and you don't necessarily run into when you are building non-Spark project in Scala.

MrPowers 6y ago
Some responses: 1. Yea, but languages that are backwards compatible have libs that are useful for way longer. I can still use Java JAR files that were built with Java 8, and published many years ago. The open source libs get stale so much quicker in Scala. 2. I'd actually argue that Spark is less weird that some other dependencies. If you look at the cats README (https://github.com/typelevel/cats https://github.com/typelevel/cats) there is this caveat: Cats relies on improved type inference via the fix for SI-2712, which is not enabled by default. For Scala 2.11.9+ or 2.12 you should add the following to your build.sbt: scalacOptions += "-Ypartial-unification" More cats specific stuff here: https://github.com/sbt/sbt/releases/tag/v1.5.0-RC2 https://github.com/sbt/sbt/releases/tag/v1.5.0-RC2 I use Spark a lot so used that for the examples, but think other libs cause even weirder maintenance challenges.
- thinkharderdev 6y ago
  Fair enough, the whole SI-2712 debacle is indeed a source of issues well beyond Spark but in general it's just a matter of adding a compiler flag to sort it out. The other example is of course the whole mess of macros... On the other side though, strict backwards compat creates it's own set of costs (that are often harder to quantify. Java backwards compatibility is great but it seems like it is also at least prat of the reason Java moves at such a glacial pace.
- 6y ago

deleted 6y ago

[deleted]

AzzieElbab 6y ago

why not spark is a maintenance nightmare?

bg4 6y ago

In my experience, it's easier for many developers to blame the tools and language rather than admit the dumpster fire of a codebase was entirely their doing and their responsibility.

devmunchies 6y ago
fentanyl is 50-100x more potent than morphine. Its still the user's fault for overdosing, but overdosing is easier to do with fent. Pepsi is more potent (sugar) than an apple, easier to get fat. Still the consumer's fault. My point is the choice of language may require more energy to enforce better code practices. Scala is so feature packed that it makes it easy for a developer to... overdose.
- thinkharderdev 6y ago
  Counterpoint. A focus on type-safety makes Scala less likely to suffer from too-clever-by-half solutions. Sometimes a group of developers will be smart enough to create an overly-complicated solution that still type checks and works (see the original Slick library...) but for most normal teams, the compiler is a guard against overly ambitious type magic. On the other hand, I've seen my fair share of too-clever uses of runtime reflection (Java) or weird metaprogramming (Python/JS) techniques, except they were not only too-clever but actually just didn't work and would fail miserably at inopportune times.
arcturus17 6y ago
It may be reasonable to think however that some technologies are more conducive to dumpster fires than others.
imtringued 6y ago
A more complicated language needs more skills and more skills mean you are inexperienced in at least some of those skills and inexperience causes dumpster fire codebases. When I started software development I had "hammer and nail syndrome" for absolutely everything. I figured out something new and then used it everywhere. Experimenting in this way is necessary but you absolutely want to avoid it in a production codebase. Over time you have run out of hammers and nails to play around with. You've developed the ability to judge where and when a specific hammer is most effective and when it shouldn't be used at all. Scala offers you a wide variety of hammers and nails. You'll have to experiment a lot.

weatherlight 6y ago

I feel like conventions would solve this problem. There's lots of programming languages that cater to multiple paradigms. Ruby and Javascript come to mind, conventions really do help when dealing with specific problems/frameworks. I'm not sure I agree with OPs blog post. This line specifically stuck out to me. "Scala should be avoided for easier problems that don’t require advance programming language features." What are advanced programming features? Isn't this just a matter of where you are coming to Scala from?

coding123 6y ago

I use Scala for exactly 1 thing: Spark. No intention to use it for anything else.

jmartrican 6y ago

> Scala libraries need to be cross compiled with different Scala versions. This seems like a big turn off. Question to any Scala dev's out there. Does this get in the way? And does it make upgrading Scala versions difficult?

MrPowers 6y ago
Upgrading Spark from Scala 2.11 to Scala 2.12 was a huge effort. See here for more discussion: https://contributors.scala-lang.org/t/spark-as-a-scala-gateway-drug-and-the-2-12-failure/1747 https://contributors.scala-lang.org/t/spark-as-a-scala-gatew... Some projects are easier to upgrade, but for complex projects, minor Scala version bumps can be quite challenging.
- AheadOfTime295 6y ago
  And the story goes on: upgrading Spark to Scala 2.13 https://issues.apache.org/jira/browse/SPARK-25075 https://issues.apache.org/jira/browse/SPARK-25075
thinkharderdev 6y ago
Scala minor versions are not binary compatible. So if you try and use a library compiled for 2.12 in a project that is using 2.13 it won't work. In practice though it is not a major issue. It is easy for library authors to cross-compile for different versions and SBT handles fetching to correct binary dependency for your project. And in general, binary incompatibility doesn't mean source incompatibility. So generally uprgrading your projects scala version is as simple as changing the scalaVersion in your build.sbt. The exceptions are: 1. If you have a dependency that hasn't been cross-compiled for the new Scala version yet. So if you are trying to upgrade as soon as a new Scala minor version comes out then you may have issues if you have a lot of dependencies. 2. If you are trying to publish a library compiled for multiple older Scala versions then you can run into source compatibility issues. For instance, if you are using a method/interface that is new as of Scala 2.13 you won't be able to cross-compile to Scala 2.12.

gregorygoc 6y ago

I’ve seen lots of projects succeed in Scala, and I’ve seen some fail. The latter was usually caused by writing spaghetti code crap instead of language complexity itself. Obviously some programmers blamed the language, but the harsh reality is that competent engineers can make things work beautifully.

phekunde 6y ago

Have you tried C++, Rust, Java or any other language? They all at some point in the development cycle become a maintenance nightmare. I will let you on a secret, we software developers create problems and then solve those problems. That is how software developer jobs are retained :)

mumblemumble 6y ago
They all have their tipping points. They don't all herd you toward that tipping point at the same pace.
MrPowers 6y ago
I maintain open source libs in Python, Ruby, and Scala - the Scala libs are a lot more difficult to maintain. Certain languages prioritize backwards compatibility and maintainability over new features / complicated programming stuff. The maintenance burden is dramatically different for different languages in my experience.
pornel 6y ago
I have no complaints about Rust after it released 1.0. My oldest projects still build fine with the latest compiler (unlike my Node.js projects.) When I read the article I was shocked that 2.11/2.12/2.13 could be breaking changes that prevent existing libraries from working, and so badly that they take years to catch up.
karmasimida 6y ago
I mean that isn't the argument. Scala's problem is no unified paradigm is proposed or accepted at community level. 'Dumb' languages like Java/Go limited the style choices one programmer could take within the language, but Scala seems to encourage the opposite.
attractivechaos 6y ago
Software engineers solve simple existing problems by creating complex new problems.

karmasimida 6y ago

It is ironic that a language named itself as Scala, doesn't really scale with the team sizes.

haakon 6y ago
It was originally called Scala because the language itself could "scale"; the grammar was so flexible that you could use it to seemingly write new language constructs. For example `while` or `repeat` loops are expressible with functions, and it looks natural because dots can be replaced with spaces in many cases. Functions can have many special characters as names, and functions can be called in-fix, and so on. People took these possibilities and ran with them, creating all sorts of wonderfully illegible DSLs. It was widely recognised as a bad idea.

paedubucher 6y ago

I am really a beginner of both Scala and functional programming. I took the first Coursera course on Scala, and I got really frightened when I noticed that you can express many things in either the functional or in the object-oriented paradigm. One example is pattern matching vs. polymorphism. When you mix up those ideas throughout your code base, it might become really hard to understand. This is just a thought that I had, and I wonder if that's actually a relevant issue in practice.

chriswarbo 6y ago
FYI this is known as the "expression problem" https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem
- paedubucher 6y ago
  Wow, thanks! It's always good to see if one's intuitive concerns are actually well-known computer science problems.

dfgdghdf 6y ago

Is the Scala language simply too big? I tried to learn it once (years ago) and quickly found myself overwhelmed by the number of concepts. I remember feeling like 80% of power of the language could have been achieved with 20% of the complexity. The latest Java releases are somewhat proving this with functional interfaces and records.

MrPowers 6y ago
There are certainly folks that argue the language it too big. Here's a great talk arguing that a lot of language features should be eliminated and Scala should be made a functional programming language: https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=Scalape%C3%B1o https://www.youtube.com/watch?v=v8IQ-X2HkGE&t=1s&ab_channel=... I'm personally in the camp of "keep Scala huge and weird and multi-paradigm, but just make less breaking changes and focus all efforts on making the ecosystem more stable".
- lptk 6y ago
  Worth noting that the presenter of this talk has done a complete 180 on subtyping as he's now using subtyping and variance in the core of his flagship library ZIO. He realized it was sometimes better to use the language's strengths rather than denigrate them for "ideological" reasons. Also worth noting that Scala is not a "very big" language in any sense that I know of. It has a lot fewer features than C#, for instance. And probably a comparable amount to TypeScript.
chriswarbo 6y ago
I've been at a Scala shop for just over a year, and it's certainly the case that there's a lot of overlap between language features. Personally I prefer having to make judgement calls as needed, rather than being shoehorned into a one-size-fits-all approach (e.g. like Java's class-based, single-inheritance OOP). One thing I find encouraging is that Scala features may become deprecated (either explicitly or de facto) if an overlapping feature is added that works 'better'. Examples I've come across are Manifest getting replaced by TypeTag and implicit coercions getting replaced by implicit classes.
6y ago

johndoe42377 6y ago

This is why lots of projects in all languages import dependencies and recompile them themselves. Little bit more work when upgrading, but much less pain.

dudul 6y ago

"Open source libraries are often abandoned, especially in Scala." Is this claim backed by anything?

dmarlow 6y ago

I've been on C# for over a decade and I'm still very happy with it. I think it's highly underrated in the startup space. When helping start my current startup, one of the founders asked why I chose C# as he was asked by others why we'd pick that language/stack as it's not common for SF startups. I told him that it's less about the language and I could do just about anything with it. It's turned out great and of all the things to worry about, the language hasn't ever come up again.

kemiller2002 6y ago
C# is definitely not sexy, but it is well documented, and there is plenty of help. I don't see why more companies go this route (not just C#, but any language that fits this). Boring is good when you have a short timeframe and it has to work well with minimal fuss.
- ywei3410 6y ago
  "Boring" languages almost always equal more boilerplate. Personally, I'll take an expressive, GC'ed language, but write "boring"-ish code when I'm on a short time-frame and I have few developers. EDIT. Just realised this sounds needlessly antagonistic; the point I'm trying to make is that "boring" is too coarse a measurement. Java 1.8 is more "boring" with it's required explicit type declarations, but I would /always/ pick a newer Java version to avoid the boilerplate.
woohoo7676 6y ago
Agreed - the startup I work with now uses C# and its been very solid. The tooling is good, and the lang has never gotten in the way of getting work done.

hotz 6y ago

I wouldn't trust my colleagues with it. I'd dread any tool that allows them to achieve even more over engineering feats.

dustingetz 6y ago

The problem is that functional programming is a really good idea but nobody has figured out (yet) the specific industry applications where it makes possible new things that weren't possible before. Mapreduce was a big win but you can do it in java. Spark was a big win but you can drive it from python. How do you make a better CRUD app in Scala? Serving http requests but with monads is not the answer.

valenterry 6y ago
You could say the same about OOP though. Just like FP, OOP doesn't make new things possible, it just makes some things much easier.
- dustingetz 6y ago
  java succeeded because of managed memory, which made it possible to build systems that didn’t randomly segfault by default

ydnaclementine 6y ago

I think about scala a bit because the second biggest chess website (lichess) is open source and written in play framework/scala. Was interested in learning some scala to help contribute since I play on the site so often Wonder if they've run into these issues with the language though

lptk 6y ago
They almost certainly run into these issues, but like most of the community, they probably think the cost is well worth bearing, given the advantages the language gives you. Once you're used to the way it works, and if you're using well-maintained libraries, I find that it's really not such a big deal. Though it's always awkward to have transitive dependency conflicts, and those are best avoided if possible.

blackoil 6y ago

As an old pragmatic, I believe for a new startup language of choice must be Java/C#. * Stable, Well understood language. * Rich ecosystem. * Fast enough. * Plenty of developers to hire from. * Scales well to large projects. No other language/ecosystem ticks all the checkboxes.

dcolkitt 6y ago
Go? Typescript? C++1x?
- gbersac 6y ago
  C++ is much more complex than Scala! Typescript is great because you can create back and front in the same language.
- camjohnson26 6y ago
  Python, Ruby, JavaScript
mumblemumble 6y ago
If the list is meant to be universal, I would strike the last two from it, and clarify that "fast enough" means, "Fast enough for the problem you're trying to solve." Working from the bottom: Scaling well to large projects is only a concern if you expect your individual projects to become large. I've worked on monoliths, and I've worked on systems that follow more of a Unix philosophy. In the former case, we had one project with a 7 digit line count. In the latter case, it was rare for a single application's codebase to grow to more than a few thousand lines of code. "Plenty of developers to hire from" is often optimizing for the wrong problem. In many lines of business, domain expertise is a much more valuable skill, because it can only be developed through years of first-hand experience. A new programming language, on the other hand, can typically be taught to a reasonably skilled programmer in no more than a couple weeks. Also, when you're just starting out, the single best programming language you can pick is the one that the people actually starting the business already know the best. They will not have senior mentors to help them learn the best way to use a new language. Finally, "fast enough" is not a single target or a strict hierarchy. I used to work at a shop where we used Python, C#, and C++. Only C++ was fast enough, performance-wise, for some problems. Only Python was fast enough, productivity-wise, for other problems. C# covered the (large) middle ground. It's also not a strict hierarchy. At my current job, I'm in the middle of a project to replace some Java components with Python. Java has not proven to be fast enough, performance-wise, for this particular problem, while Python gets us there with room to spare.

practice9 6y ago

Some of the worst and unmaintainable code I've ever seen was written in Python & Java. While some of the cleanest codebases were written in Scala and Javascript. The problem is not the language, but the team & overall approach to development (rushing to deploy bad code because your manager said so; lack of code review). Tooling can be better, but it was massively improved over last 2 years

flurdy 6y ago
I have seen quagmire in several languages at various small and very large companies. So many withered and bloated Java apps that is hard to maintain. And I agree it is not the language, it is the stewardship. Who they hire, how they manage their tech, culture, pairing/mob, quality over speed etc. And the reality that all codebases rot, at different speeds depending on these factors, but eventually they all rot. I have seen well maintained large Scala architectures, at very large organisations because of great stewardship of the projects and people. And I have seen car-crash bundle of apps in Scala because they hired rockstar developers that incorporated every shiny feature continuously leaving it unmaintainable by the rest. Or by recent Java converts that were not mentored well enough so still writing Java code in Scala. I love Scala but with bad HR processes and weak leadership it will ground to a halt. And they will blame the language not themselves. But the same would probably have happened with any language.
switchbak 6y ago
I've written a ton of code in a bunch of different languages, and you're exactly on point here. It's got everything to do with discipline and time spent on creating and keeping a codebase simple and well factored. If you don't have a team doing that, you're going to have problems. Scala is a sharp tool, in the wrong hands you're gonna slice your toes off. In the right hands, you can create simple, elegant solutions to challenging problems.

The_rationalist 6y ago

Scala 3 should help simplify the language and reduce abuse of features like implicits: https://docs.scala-lang.org/scala3/new-in-scala3.html https://docs.scala-lang.org/scala3/new-in-scala3.html

didibus 6y ago

That's one of the reasons I prefer Clojure over Scala, it has rock solid stability, and a great track record of backwards compatibility.

rabzu 6y ago

I used Scala for all my startups since 2015. Currently, we moved everything to scala ZIO last year. In a nutshell we love Scala.

AzzieElbab 6y ago

But Java had adopted about 75% of scala’s features from 5 years ago. Mostly with some quirky limitations and bloated syntax. What exactly makes it easier for people to understand is beyond me

hota_mazi 6y ago
Because less is more. What makes Java and Kotlin more popular languages than Scala is that both Java and Kotlin are being extremely deliberate in choosing what features they include and more importantly, which not to include. Scala includes everything by default because it allows the EPFL to submit a lot of papers to conferences.
- valenterry 6y ago
  Why do you think Scala has more features than Java/Kotlin? I think it's the opposite. For example null: where Kotlin has a special operator and semantics, Scala simply has the "Option" type in the std lib.
  - hota_mazi 6y ago
    Do you seriously think Scala has fewer features than Java and Kotlin?
    - AzzieElbab 6y ago
      But there is no such thing as Java. It is Java plus spring plus guava plus something else for immutables
      - hota_mazi 6y ago
        All languages have their libraries and design patterns, not sure how your comment answers my question.
      - thinkharderdev 6y ago

dehrmann 6y ago

> Publishing open source project to Maven is way more difficult than most language ecosystems. Maybe this is a feature, not a bug. I won't call out the language/repo, but I was able to gain admin access for a library my company published with just an email from my company's domain. There are major security issues with "easy." There are also quality issues. You're more likely to publish something if you think it has value; I've published work to Maven Central, but only the high-quality, reusable work.

uDontKnowMe 6y ago
Would have to disagree here. Just raising the bar higher for publishing at all doesn't increase quality of libraries available. Consider how open source in general really became much more the norm after Github made it trivially easy to publish and collaborate on code.

JD557 6y ago

I might be a bit biased, since I've been writing Scala professionally for years. While most of the article rings true, I wanted to share some counter-arguments: 1) A lot of the problems mentioned are only really noticeable if you use Spark, which really lags behind in Scala versions compared to the rest of the ecosystem. As someone who doesn't use Spark, I don't really feel much of the "Scala minor versions" pain. 2) While not great, cross-compilation/publishing is not that bad (there are plugins like `sbt-release` and `sbt-crossproject` that pretty much take care of it). 3) I mostly disagree with the "Difficult to publish to Maven" point. I'm not saying that it's easy, but I enjoy the fact that it's not as trivial like other languages. I would argue that this whole process makes [1] almost impossible, which is a plus for me. 1: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610 https://medium.com/@alex.birsan/dependency-confusion-4a5d60f...

worace 6y ago
Yeah point 3 is underappreciated for sure. > You need to open a JIRA ticket to get a namespace, create GPG keys, register keys in a keyserver, and add SBT plugins just to get a manual publishing process working. It’s a lot more work than publishing to PyPI or RubyGems. It's a little annoying to have to go through that, but you only have to do it once per domain, and the turnaround from the people who manage the sonatype jira is usually pretty quick. In return the ecosystem gets a lot of protection from the kind of exploits you mentioned.

typon 6y ago

The same complexity problem of Scala is where I see Rust going

haakon 6y ago
Can you elaborate? Is Rust gradually becoming more complex?

pjmlp 6y ago

Which is why at the end of the day I always pick the platform language for production code. As long as the platform is relevant everything moves along without extra layers of tooling and idiomatic wrapper libraries for platform APIs. Might not have all the bells and whistles, not so shinny, but it works and I don't need to care about my replacement having headaches.

adamw1pl 6y ago

Many people talk about Java, Go and similar, contrasting it with Scala, but I think it misses one crucial point. Java and Go are in many ways "done" languages. They evolve very little. Correct me if I'm wrong, but I don't think Go changed significantly since 1.x. Java hasn't been evolving almost at all until recently, and the changes introduced now are still conservative, and it will take ages before the ecosystem catches up and actually makes good use of what's introduced in Java 11+. On the other hand, yes - Scala is in many ways a research language. It's got a number of novel features, starting from the blend of FP and OO, through implicits, ending with metaprogramming. The dark side of introducing features that other languages don't have, is that they sometimes need polishing or complete removal. That impacts the compiler (which evolves as well - compiling Scala code is much more complex than the rather straightforward translation of Java to bytecode) and high-level language features alike. The bright side is that software engineering is very far from being a "done field" (or at least I refuse to believe it is such). There's a lot to be discovered as to how we can write code that is readable, performant and - yes - maintainable. "Wait, but if you said Scala is a research language, is it safe for business usage?" Yes - while Scala has a research side to it, it also is a language used successfully in many companies. It has a lot of libraries that are maintained, the language authors pay a lot of attention to binary compatibility (with well-defined limits - you know what to expect!). Businesses have benefited from using the newest available technology in many fields, and I doubt software engineering should be different. Of course, you shouldn't be reckless - but using technology from 20 years ago "just to be safe" isn't always a recipe for success. Yes, you can build great systems with Java and Go. Same is true for Scala. And yes, you can build totally unmaintainable systems in Scala, but in Java and Go as well. Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free. You like the library, it solved your problem - great, you can use it for free. But if you want it maintained above what the library author donates, either through their time or through corporate sponsorship - well, you can't have any expectations here. I'm sure a lot of these migrations problems could be solved, given a reasonable business offer.

sameei 6y ago
> Finally, a side note about OSS. I don't think it's fair to expect anybody to maintain any kind of library in any language for free True! but why Spark & Flink, which are backed with business, didn't bother themselves to catch up with changes in Scala! they delayed their upgrade to 2.12, not mention 2.13! and as far as I know the 3.0 hasn't been discussed yet! Am I right? In general I'm happy and thankful that I learned Scala! it shaped my perspective to combine programming paradigms and pick best practices from each one rather than sticking to a single paradigm. But for work that I wanna last long enough, I can't accept it, as there is no realm of calmness in view. Software Industry is a young industry and complex, like any other profession, and a developer need to think about lots of other things as well, not just the language and possible pattern/syntaxes it has to keep up with! I think the value that Scala brings into industry is what that prevents it from becoming the rival to others.

willtemperley 6y ago

I use Scala for e.g. running Hadoop map-reduce jobs or building REST endpoints. I’d never write a reusable library in Scala though for the reasons pointed out in the article, binary compatibility is not something Scala cares about. I’m never going to use a library written in Scala for the same reason, plus chances are I’d have to spend hours fiddling with SBT to rebuild it at some point. Scala (with Maven) at the top please, then Java all the way down thanks.

AtlasBarfed 6y ago

I've been looking for a video/presentation from one of the main Scala contributors before he left the team. I think I saw it about 8 years ago. It was highly critical. One of the main slides the stood out was discussing something like 20 or 30 different kinds of "types" in Scala. I cannot find it anymore, it may have disappeared with the political "drama" I've heard happened within Scala that included attempts to blackball people. I've never personally coded in it, I use groovy on the JVM and it satisfies my needs but it has nothing to brag about in terms of avoiding spaghetti code. It has all the same problems of bootstrapping any language that isn't a "X but distinctly better/easier/more features/fixes major problems in X". A big big lift. I think only Rust is a language that is sufficiently different that has any real long term chance.

joshlemer 6y ago
You're thinking of Paul Phillips https://www.youtube.com/results?search_query=paul+philips+scala https://www.youtube.com/results?search_query=paul+philips+sc...

cryptos 6y ago

After being a big fan of Scala about 10 years ago, I think that Kotlin is better suited in almost all cases. Kotlin is much easier to learn (especially if you know a similar language like Java, C# or TypeScript), much easier to read and understand and has much better long term stability. The support in IntelliJ is also better. Scala causes performance issues from time to time in IntelliJ and there are some language constructs that the IDE doesn't really understand in all cases. JetBrains build Kotlin as a programming language for industrial projects - and it shows.

DizzyStatement 6y ago

Well, in my humble opinion, I believe most people that choose scala, thinking of it "the better java" usually gets frustrated, especially when they start off using the "cool" stuff people say on twitter. Tbh, I've been programming in scala for 5 or 6 years now and have never worked with "proper" FP libraries like cats or zio. All the companies I've been working with, have used the lightbend stack, so basically play framework, which is easy to learn for someone coming from java/spring and the most different, Akka streams. One day one of my java colleagues started an argument saying scala was too complex etc etc. I asked based on which code? He mentioned scalaz. So tell me what the hell someone who has never programmed in scala before was doing looking at scalaz code? No wonder why a novice would think of it. The bottom line is that if you are new to scala and/or has no experienced developer nearby but still want to try out scala, just stick with the standard library and use play for your rest services. When you are confident enough with the language, if interested, have a look at the FP libraries.

ttymck 6y ago

I am an order of magnitude more productive in Scala, compared to python. The compiler does so much for me, I can focus on just writing my domain. Frankly, I think Scala is just good at exposing weak programmers and teams with poor discipline. I've seen far worse codebases in python where there's no disciple: all methods are public, monkey patch classes at runtime, etc. I think articles like this are so common because Scala is easy to pick on. "Implicits are bad" is more interesting than "Implicits have a very specific usefulness", but Implicits are peculiar and unique to scala so the language gets lampooned. "Private methods make code more maintainable" may be just as true, but no one says Python is universally hard to maintain -- so long as the person behind the keyboard knows what they are doing.