4 ms·

> I feel like the biggest misstep that the Scala ecosystem and Typesafe/Lightbend did was that they didn't invest more in Play Framework. 10 or 12 years ago, Pl

by lmm 2y ago

> I feel like the biggest misstep that the Scala ecosystem and Typesafe/Lightbend did was that they didn't invest more in Play Framework. 10 or 12 years ago, Play had a lot of energy and momentum, and it's a kind of thing that has broad enterprise/start up appeal. But focus was always more on Akka and what seemed like really niche architecture astronaut stuff like Actors and Actor System Clusters and Event Sourcing etc, rather than getting the basics to be super ergonomic or productive. I'd say the opposite. They pushed Play a lot. But it was never a killer app, and it never even really leveraged the strengths of Scala. People and especially companies don't switch languages for "super ergonomic and productive". They switch because they want to do something they can't do in their current language. I'm not a fan of Akka or Actors, but it made for some incredible demos that you really couldn't do in anything else except Erlang.

joshlemer 2y ago
I disagree, productivity and ergonomics drives plenty of popular tools - React, Laravel, Rails, React Native, etc.
- acjohnson55 2y ago
  Yeah, but I don't think Play (which I enjoyed) was ever going to top those, unless it had a fundamentally new idea to bring.
  - joshlemer 2y ago
    Laravel and Django didn't bring fundamentally new ideas above and beyond Rails.
- lmm 2y ago
  Hmm. Fair point for Rails and Laravel (whereas I think React had a killer app in terms of being able to make SPAs without going crazy) but those are tools that you can pick up for a one-off throwaway project - indeed I suspect most adopters didn't "move" to them so much as start doing projects in them and eventually stop doing projects in other things. Scala was never really competing in that space - I don't think anyone would ever say "let's make our website for the next tradeshow in Play" - it's a "heavy" language that needs an IDE and deep familiarity to get the best out of it (and partly that's also what JVM folks would be expecting). So it needed to play for the big core codebases, and for a while it did (particularly when there was no alternative to Spark). Could they have made Play an alternative to Rails for one-off throwaway websites? Maybe, but the thing that would have needed to be different wouldn't be pushing Play itself, but rather lighter tooling and making it easier to get from zero to pages being served. Honestly I struggle to see how they could've done it without making the compiler and build tool much faster, and either making the IDEs much more efficient (difficult) or making the language easier without an IDE (difficult, and would risk splitting efforts). And even then, you wouldn't really show the compelling advantage of Scala, which is fearless refactoring in large codebases. I don't know that it could ever have been better than Rails at what Rails does, and also we already have Rails. Whereas even if it eventually "dies", Scala has already pushed Java and Kotlin to be much better than they were.
  - joshlemer 2y ago
    I mean, I don't find that working with IntelliJ makes it any "heavier" than other languages in terms of prototyping. I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive. I think all of these frameworks - Laravel, Rails, Django, Next.js, Spring - require deep familiarity to get the best out of them. > Honestly I struggle to see how they could've done it without making the compiler and build tool much faster Well, Lightbend literally was the owner of Play, SBT, and Scalac. They were in a perfect position to make the build tool and compiler much faster. Or even if SBT can't be made much faster, ditch it and make integration with gradle and/or maven really great.
    - lmm 2y ago
      > I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive. But the first time you tried out PHP, did you have to install the IDE first? Did you have to change your existing PHP tooling setup the first time you tried out Lavarel? I would agree that IDEs are an improvement over not using them in most languages, but my feeling the "tooling curve" is much steeper for Scala than for something like PHP.
hocuspocus 2y ago
That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.
- joshlemer 2y ago
  What is so bad specifically about play?
  - KajMagnus 2y ago
    I use Play, and I think it is a good web framework, nowadays. In the past, however, upgrading to new versions, was annoying, because of pretty big changes in the API. (Don't know if this is what GP had in mind though.) And even worse (I suppose) for people who were using the different ORMs which have come and gone, instead of plain SQL. Akka has been annoying too: Adding WebSocket to my project, using Akka, was extremely much more complicated than doing the same in Nodejs (at least looking at the Nodejs docs I've seen). Today, to me, Play is feature complete and all I want is maintenance updates (and performance optimizations but not so important). And yes, that's how things look right now: Some bigger companies pay an open-source maintainer, so Play gets regular maintenance updates, but not any annoying major API changes (or so I hope), nice. Play has become boring in a good way? :- ) (Thinking about some "Use boring tech" HN posts.)
  - hocuspocus 2y ago
    Like KajMagnus mentioned: - The churn caused by breaking changes in minor versions used to be annoyingly high. - Slick looks neat at first but caused a lot of friction when used by less experienced developers. - The fact Akka is in your dependency tree encourages people to reach for it and raw actors are usually a bad choice. Akka streams work well for websockets and SSE but it's another footgun. Additionally: - It was in state of semi-abandonment for several years before Lightbend gave the project to the community. Even though there are/were big companies deploying Play apps at scale, for instance Apple. - The introduction of Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy. Sure you can not use it, or use something else (like macwire) but defaults matter. - Play-JSON depends on Jackson which is annoying in the JVM world, causing binary compatibility issues when you have diamond dependencies. - Standard library Futures are not so nice when you've experienced anything else (Scalaz Task, Cats IO, ZIO, even Twitter Future...) - Code generation from routes files is an odd choice when Scala has always been expressive and DSL friendly. - Swagger/OpenAPI integration is brittle. I've personally used Tapir since 2019 and couldn't be happier. All Play apps still running at my company are being abandoned or replaced by Spring/Java projects.

by lmm 2y ago

joshlemer 2y ago

I disagree, productivity and ergonomics drives plenty of popular tools - React, Laravel, Rails, React Native, etc.

acjohnson55 2y ago
Yeah, but I don't think Play (which I enjoyed) was ever going to top those, unless it had a fundamentally new idea to bring.
- joshlemer 2y ago
  Laravel and Django didn't bring fundamentally new ideas above and beyond Rails.
lmm 2y ago
Hmm. Fair point for Rails and Laravel (whereas I think React had a killer app in terms of being able to make SPAs without going crazy) but those are tools that you can pick up for a one-off throwaway project - indeed I suspect most adopters didn't "move" to them so much as start doing projects in them and eventually stop doing projects in other things. Scala was never really competing in that space - I don't think anyone would ever say "let's make our website for the next tradeshow in Play" - it's a "heavy" language that needs an IDE and deep familiarity to get the best out of it (and partly that's also what JVM folks would be expecting). So it needed to play for the big core codebases, and for a while it did (particularly when there was no alternative to Spark). Could they have made Play an alternative to Rails for one-off throwaway websites? Maybe, but the thing that would have needed to be different wouldn't be pushing Play itself, but rather lighter tooling and making it easier to get from zero to pages being served. Honestly I struggle to see how they could've done it without making the compiler and build tool much faster, and either making the IDEs much more efficient (difficult) or making the language easier without an IDE (difficult, and would risk splitting efforts). And even then, you wouldn't really show the compelling advantage of Scala, which is fearless refactoring in large codebases. I don't know that it could ever have been better than Rails at what Rails does, and also we already have Rails. Whereas even if it eventually "dies", Scala has already pushed Java and Kotlin to be much better than they were.
- joshlemer 2y ago
  I mean, I don't find that working with IntelliJ makes it any "heavier" than other languages in terms of prototyping. I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive. I think all of these frameworks - Laravel, Rails, Django, Next.js, Spring - require deep familiarity to get the best out of them. > Honestly I struggle to see how they could've done it without making the compiler and build tool much faster Well, Lightbend literally was the owner of Play, SBT, and Scalac. They were in a perfect position to make the build tool and compiler much faster. Or even if SBT can't be made much faster, ditch it and make integration with gradle and/or maven really great.
  - lmm 2y ago
    > I use PHP Storm for Laravel development and I never say to my self, "if only I wasn't using an IDE, maybe I could get this site put together faster". Quite the opposite, Intellij makes me super productive. But the first time you tried out PHP, did you have to install the IDE first? Did you have to change your existing PHP tooling setup the first time you tried out Lavarel? I would agree that IDEs are an improvement over not using them in most languages, but my feeling the "tooling curve" is much steeper for Scala than for something like PHP.

hocuspocus 2y ago

That is correct. Play's hype did more harm than good. I work at a company that has many legacy projects in Scala because we were/are heavily invested in Spark, and Play is a disaster overall.

joshlemer 2y ago
What is so bad specifically about play?
- KajMagnus 2y ago
  I use Play, and I think it is a good web framework, nowadays. In the past, however, upgrading to new versions, was annoying, because of pretty big changes in the API. (Don't know if this is what GP had in mind though.) And even worse (I suppose) for people who were using the different ORMs which have come and gone, instead of plain SQL. Akka has been annoying too: Adding WebSocket to my project, using Akka, was extremely much more complicated than doing the same in Nodejs (at least looking at the Nodejs docs I've seen). Today, to me, Play is feature complete and all I want is maintenance updates (and performance optimizations but not so important). And yes, that's how things look right now: Some bigger companies pay an open-source maintainer, so Play gets regular maintenance updates, but not any annoying major API changes (or so I hope), nice. Play has become boring in a good way? :- ) (Thinking about some "Use boring tech" HN posts.)
- hocuspocus 2y ago
  Like KajMagnus mentioned: - The churn caused by breaking changes in minor versions used to be annoyingly high. - Slick looks neat at first but caused a lot of friction when used by less experienced developers. - The fact Akka is in your dependency tree encourages people to reach for it and raw actors are usually a bad choice. Akka streams work well for websockets and SSE but it's another footgun. Additionally: - It was in state of semi-abandonment for several years before Lightbend gave the project to the community. Even though there are/were big companies deploying Play apps at scale, for instance Apple. - The introduction of Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy. Sure you can not use it, or use something else (like macwire) but defaults matter. - Play-JSON depends on Jackson which is annoying in the JVM world, causing binary compatibility issues when you have diamond dependencies. - Standard library Futures are not so nice when you've experienced anything else (Scalaz Task, Cats IO, ZIO, even Twitter Future...) - Code generation from routes files is an odd choice when Scala has always been expressive and DSL friendly. - Swagger/OpenAPI integration is brittle. I've personally used Tapir since 2019 and couldn't be happier. All Play apps still running at my company are being abandoned or replaced by Spring/Java projects.