Hacker News Reader

Comment by the_af | Hacker News Reader

> Scala defines its own set of collection classes [...]

One (arguably) negative consequence of this is that Scala's collections don't play nice with Hibernate and similar ORMs. Due to the way they work, both Scala and Hibernate wanted to "take over" your collections, and obviously they cannot do so at the same time. Of course, it's arguable whether this is a flaw with Scala or with Hibernate, but for the programmers who just wants to get things done that's irrelevant.

It used to be a big deal a few years ago, to the point teams in my company decided to either drop Hibernate or drop Scala.

PS: if I remember correctly, early Scala adopters had reached the consensus that ORMs didn't play nice with Scala's FP style anyway, and so using Hibernate was a mistake. Possibly this attitude changed later.

View on HN

The two major SQL libraries in the Scala ecosystem these days are Doobie (https://tpolecat.github.io/doobie/) and Slick (https://scala-slick.org/).

With Doobie you manually write your queries, and then map the results into the objects in your domain model. Nothing is generated for you. OTOH, nothing is hidden and you are free to write queries as optimized and specialized as you need. The real selling point of Doobie is a typesafe API for manipulating and combining queries, and fragments of queries, into larger wholes. This works very well when your application interfaces with a database it doesn't own.

With Slick you get access to a DSL that lets you layout how your tables look. From there Slick offers an api that let's you treat SQL tables as-if they are basically mutable collections, with Slick handling all the SQL generation itself. You also get DDL, so that you can automate db creation and upgrades. This work very well when your application owns and controls the database it is connecting to.

Both of these have diverged from that traditional ORM model. Slick bills itself as FRM, or Functional Relational Mapping. And Doobie is embedded queries on steroids.

Nobody should be recommending Slick to anyone for new projects. Slick will not be supported in the future.

I've heard that too but I think there are at least efforts to support Scala 3.

Having said that I think Quill looks nicer (https://getquill.io/) if you want a DSL like that.

I haven't used it heavily but one of our newer microservices uses Quill for read-only access to Postgres. I have found it to be great to work with, to combination of "just use case classes" and a DSL that feels like writing SQL is pretty nice.

You can have Quill syntax for Doobie nowadays:

https://tpolecat.github.io/doobie/docs/17-Quill.html

That's by far the best DB access layer I've ever worked with.

I seem to remember Stefan Ziegler asking around the channels about questions relating to how to do certain features to uplift Slick. Don't know if anything came out of it.

Lightbend is planning to end support and development of Slick? This is the first I've heard of this. Can you point me towards what they've said?

they never said that, but it's basically abadonware. look at the commit history: https://github.com/slick/slick/commits/master you can also look at the contributors page: https://github.com/slick/slick/graphs/contributors the guys who primarly contributed to it basically left lightbend, and in 2019 he shifted his priorities. it only had 28 commits since 2020 (including merge commits and changes to the build process) it's basically dead until somebody steps up.

> 28 commits since 2020

wow, the bar for "not dead" is really high these days :-)

well as said 28 commits, NOT ALL were code. MOST of them were basically "fix build"/update dep. so basically the project did not change for over a year.

AND 2019 wasn't really better. 3.3.2 (3.3.3 was mid 2020) was in JUNE 2019 and 3.3.0 was at the beginning of 2019. there won't be a 3.4 anytime soon, if nobody steps up and starts maintaining it, there won't be a 3.4 at all.

slick is heavy on macros it will not survive scala 3

Well, that would streamline nicely the options for DB libs in Scala…

Doobie (optionally with Quill Syntax) would be left and become likely the "Hibernate of Scala-Land".

That's not too bad news imho.

I have had poor experiences with "fancy" SQL libraries in multiple languages. This includes Slick and Quill in Scala.

I don't remember what the problems were with Slick that leave such a bad feeling when I hear its name -- that was 5 years ago -- but I had problems with Quill just last year. I was trying to use it to generate an efficient "in" query against a two column composite primary key, and nothing seemed to work. Since it uses macro magic, one of my attempts triggered an internal compiler error instead of normal compiler feedback.

I ended up dropping Quill for ScalikeJDBC:

http://scalikejdbc.org/

It seems to be less popular/active than other libraries, but it is dead simple to use, even for developers new to Scala. I write exactly the SQL I want just like I would in psql. There is little-to-no magic. I think that the only slightly magical feature I use is variable interpolation into SQL ("SQLInterpolation") that prevents injection attacks. It actually has capabilities to automatically map tables/columns into different structures and generate code for you, but my team doesn't use any of that. We just write SQL.

I didn't have a good experience with scalikejdbc, which was what we ended up using. Possibly we didn't use it well, and I can't remember the details now, but our DB code ended up looking like a mess.

Isn't JOOQ also usable with Scala?

Yes

> PS: if I remember correctly, early Scala adopters had reached the consensus that ORMs didn't play nice with Scala's FP style anyway, and so using Hibernate was a mistake. Possibly this attitude changed later.

Having used Hibernate in a Java project, I would argue using Hibernate is always a mistake. Way too much complexity/brokenness for basically no benefit.

Reply on news.ycombinator.com