dotty VS Slick

A more limited way to do runtime evaluation is via the jsr-223 support: https://github.com/lampepfl/dotty/blob/main/tests/run-with-compiler/scripting.scala, you can't reflect on types that way but the advantage is that you don't end up depending on compiler-internals APIs that could change in any patch release.

https://github.com/lampepfl/dotty/issues/14262 points to https://github.com/invesdwin/invesdwin-context/blob/master/invesdwin-context-parent/invesdwin-context-scala/src/main/java/de/invesdwin/context/scala/pool/WrappedScalaScriptEngine.java which seems to be doing some caching via https://docs.oracle.com/javase/8/docs/api/javax/script/Compilable.html, but I have zero experience with this stuff.

Note though that our jsr-223 support is currently a bit limited compared to the scala 2 version: https://github.com/lampepfl/dotty/issues/14262

If you could open an issue at https://github.com/lampepfl/dotty/issues detailing your problems with the bash shell on Windows that would be useful (it's likely our scripts have only been tested with the cmd.exe shell).

That seems like a bug. Could you open an issue at https://github.com/lampepfl/dotty/issues?

- If you can't generate a quotation and need any strings, then the next option - add compiler to the classpath and use JSR223 scripting API: (example : https://github.com/lampepfl/dotty/blob/master/tests/run-with-compiler/scripting.scala

The main blocker for such libraries is https://github.com/lampepfl/dotty/issues/11685 now, that also blocks cats-tagless, and hopefully it will be fixed in near future. So if you can wait several months, it would be the easiest choice... so do I :)

See https://github.com/lampepfl/dotty/issues/13985, maybe the graalvm reflection config format could be enriched to support wildcards if it doesn't already?

I purchased the very entertaining book Seven Languages in Seven Weeks. Although I found Haskell fascinating and tempting, I knew it was unrealistic to introduce it in our company. Scala on the other hand looked like it could be the holy grail: All the characteristics I was looking for, no need to abandon the JVM and its cornucopia of tools and libraries, and the possibility for coexistence with Java and therefore incremental adoption. After implementing some simple programs to identify any immediate risks of committing to the language and its ecosystem, I started to introduce Scala in customer projects. Luckily, I was fortunate enough to work with open-minded, curious, and ambitious team members who were also experienced enough to appreciate the benefits of the language. We immediately applied our experience with functional programming, and embraced immutability. Libraries like Slick and Akka HTTP (we actually started out with its predecessor, Spray) made building database-backed REST services a breeze. And the resulting code was robust and highly maintainable. Scala's expressive type system and type inference made it easy to build a restrictive, consistent domain model without bloating the code. There was virtually no overhead. Any boilerplate could be easily abstracted out. In the end, the application code felt natural, concise and elegant. Programming was fun again.

Slick is community-maintained these days. It appears likely this PR adding Scala 3 support will cross the finish line before too much longer: https://github.com/slick/slick/pull/2187

re: Slick, hopefully https://github.com/slick/slick/pull/2187 will land soon-ish. Stefan did much of the work himself a while back; now a volunteer is trying to put the finishing touches on.

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.

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.

Many ORMs introduce a somewhat messy, complicated abstraction layer that doesn't actually get you the desired benefit in statically typed languages - compile time safety. Mainly because most languages do not have sufficiently powerful type systems.

Exceptions are libraries like persist [1] for Haskell, Slick [2] for Scala, and - with caveats - Diesel [3] for Rust.

But: manually mapping between the database domain and your domain objects is also a messy, error prone process that is wasted effort.

My preferred solution is to stick with simple ORMs that just do simple mapping and provide a convenient query builder, without any heavy magic in the objects or any sort of automatic relationship logic (automatic fetching of joins, ...).

[1] https://hackage.haskell.org/package/persistent

[2] http://scala-slick.org/

[3] http://diesel.rs/