Hacker News new | ask | show | jobs
by joshlemer 495 days ago
> Slick

Totally agreed, Slick is definitely not a good way to access the database. It massively over complicates things and was a massive oil spill that destroyed the maintainability of many codebases. But that's not really Play, specifically, just a library that lots of people used with Play. I personally was always more a fan of https://scalikejdbc.org/, if not just plain JDBC

> It was in state of semi-abandonment for several years

Yes, this is my main complaint. I remember on the front page for like 5 years after TypeSafe Activator had been totally removed from the internet, the Play website was still showing Activator commands. To this day, the Play site still hasn't removed their line about how they support CoffeeScript and Less.

> Guice (in 2.4 afaik) was a terrible mistake, completely unnecessary and at odds with the Scala philosophy > Play-JSON depends on Jackson > Standard library Futures are not so nice

Well, it turned out that the Scala Philosophy wasn't the be-all and end-all anyways, and was always changing (at some point DSL's were in, then they were out. The way people encode TypeClasses changed over the years, selectDynamic/applyDynamic were in and then they were out, symbols were everywhere and then deprecated, implicit conversions were in and then "best practice" switched to Converters) and there was always at least 2 camps who had very different philosophies. Guice is probably the most popular DI tool in the JVM world so seems to make sense to use it.

The Jackson dependency and Scala Future's shortcomings might be annoying to many, but I don't think they really hindered adoption. Even in your case, what happened? At your company they're ripping out Play and replacing it with Spring, which uses DI very similar to Guice, probably depending on Jackson, and using java Futures (if they're doing async at all).

1 comments

It's true some Scala features or patterns fell out of fashion but I don't recall any time where replacing compile-time logic with annotation based runtime reflection was considered a good idea. And I don't think Guice was ever the most popular JSR-330 implementation, at least not when Play started using it. Spring had been dominating the Java world for several years by then. Funnily enough in the Android world I remember Dagger being very popular exactly around that time as people figured compile-time automatic DI is a lot saner than Guice.

Of course Spring is another can of worms entirely and I find many aspects infuriating. But things like diamond dependencies are less of an issue thanks to Maven BOMs which are common in the ecosystem.

My point is that ~10 years ago people started using Spark at my company, got curious about Scala and thought Play was compelling. Nowadays Spark (in Scala) is less ubiquitous and these teams remember that so many people got burned by Play before.

Funnily enough the peak of Scala's hype which I believe plateaued between 2014 and 2019 before dropping sharply was mainly driven by:

Spark: ground breaking in many ways but has become a huge liability to the ecosystem, holding so many libraries back. Databricks is also the main financial contributor to the Scala Center (I believe) while not giving much of a damn about the community or Scala 3 altogether. Spark is a very frustrating piece of software overall and today 95% of users are in PySpark anyway, avoiding JVM dependency hell being one reason.

Play: good idea, questionable execution, poor governance, and today mostly irrelevant to the future of Scala. Props to community maintainers who managed to secure funding and brought the framework back from the dead, saving many projects from a certain death.

Akka: also ground breaking, pretty much the only game in town if you need stateful cluster sharding, deployed at scale by top-tier companies. But also overkill for most people, and on top of that the relicensing really hurt the community and broke trust.

The boons and banes of Scala.