tpolecat

I can’t speak for others, but scala’s has two of the best sql db libs I ever used, namely doobie and quill. https://github.com/getquill/quill https://tpolecat.github.io/doobie/

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.

Their are linters available for scala (e.g. wartremover). Also, the Scala compiler supports a number of flags to warn you if your code is using some of Scala's 'more questionable' features. You can even tell the compiler to fail if any of these warnings occur. A list of useful flags can be found at https://tpolecat.github.io/2014/04/11/scalac-flags.html. You might also want to look at this excellent talk titled 'Toward a Safer Scala' at https://docs.google.com/presentation/d/1tCmphnyP3F5WUtd1iNLub0TWRVyfTJ… that recommends a number of best practices that can be followed using Scala. If you're using sbt, I put together a giter8 template for scala/sbt projects that follows these best practice recommendations at https://github.com/hohonuuli/basicscala.g8

You write Scala? (https://tpolecat.github.io)

You capture the root issue quite well. Now every tool has to adapt to Scala 3. And you guess it? It will take time. Even IntelliJ still doesn't correctly highlight syntax on some parts that also exist in Scala 2. And this has been years after Scala 3 was launched. It's mind-boggling. They could have improved upon Scala 2 and incrementally add more capabilities. It's obvious they don't care about Scala's industry success. They care mostly about the academic success. Nothing wrong with that, but that should be made very clear. In Scala, they have a huge debate with zealots arguing against, for example, early return; they would describe how bad it will be blah blah blah e.g. https://tpolecat.github.io/2014/05/09/return.html, meanwhile Kotlin supports early return with absolutely no issue.

> Don't use explicit returns this is not just a style issue, its also a functional one https://tpolecat.github.io/2014/05/09/return.html

So the particular example here isn’t too different from exceptions. You’re unwinding the stack up to a predefined point— here, the callsite of foo, where with exceptions it would be up to the surrounding try/catch. Scala actually implements non-local returns (the only practical use I’ve had for call/cc) using exceptions: https://tpolecat.github.io/2014/05/09/return.html

> I simply also feel that having 100% type safety in your results (which you really can't do with SQL queries) is a huge bonus. It is possible to get type safety with SQL queries. Eg doobie[0], a purely functional JDBC layer for Scala. [0]: https://tpolecat.github.io/doobie/

I would use it at work because I know it. There are a LOT of libraries in Scala for HTTP up to database stuff, and it really depends on what kind of ecosystem you're walking into: * Scala as Python: https://github.com/com-lihaoyi/cask, maybe https://github.com/getquill/quill * Scala as Haskell: HTTP4s, https://tpolecat.github.io/doobie/ * Scala as Rails: Play Play is the closest thing to Rails-like CRUD productivity IMO, and honestly for CRUD most times I would like to write as little code as possible and just get it done, even using low/no-code solutions (postgrest, hasura, htmx), but that wasn't the question :)

I've had bad luck with ORMs in general, mainly because they fall apart whenever I need to do something complicated. The abstraction is just too leaky. However, I've had really good luck with Doobie, a purely functional SQL library in Scala. The big difference is that queries can be manipulated as ordinary pure values, which really lets you do some cool stuff. I actually used these features to significantly speed up a schema change in a large database I was working on. https://tpolecat.github.io/doobie/docs/01-Introduction.html

f-bounded types (such as in the article) still leave properties to be desired, however: http://tpolecat.github.io/2015/04/29/f-bounds.html

2. There are places where this is true, but a lot of people seem to get hung up on the syntactic differences between e.g. "a.foo(b)" and "a foo b", which really are superficial and you learn to read past very quickly. 3. Some of these are backwards compatibility. You can get a more helpful typesystem by setting a few flags: https://tpolecat.github.io/2014/04/11/scalac-flags.html

I'm using it mostly for full-stack web development with ScalaJS (https://www.scala-js.org) in the frontend (https://outwatch.github.io/docs/readme.html) and in the backend with AWS lambdas. The ecosystem is currently in the process of porting all the libraries to Scala 3. So if you're new to Scala, I'd recommend to start with Scala 2, which is rock-solid and already very powerful. I never worked with SQLAlchemy. But on the scala database side, popular libraries are Doobie (https://tpolecat.github.io/doobie) and Quill (https://getquill.io). Keep in mind that these are for Scala on the JVM. On the ScalaJS side I'm using the javascript library pg. But I'd like to try if it works well with Prisma soon. The nice thing about ScalaJS is, that you can use Javascript libraries. And if there are typescript facades, then you can transpile these to Scala and use them in a type safe way (https://scalablytyped.org).

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.

Here is one that I run into frequently. You're building a CRUD app, but want some semblance of sane FP interaction with your database. So you use Doobie [1] because free monads and all. So you type your query using a Doobie SQL string interpolator... sql"SELECT ItemId from dbo.Item WHERE IsOnSale = TRUE" ...but then you forget all of the ".query[Int].vector.transact(tx).unsafePerformSync" crap that you are supposed to tack onto the end of the string to actually run your query. What are your options? 1. Type a '.' character in your IDE and watch it crash while the presentation compiler thrashes around, sifting through a combinatorial explosion of implicit values (or whatever it is that makes it so slow). You quickly learn to stop using autocomplete. In a sane world, this should take milliseconds and you should quickly get a list of methods to guide you down the right path. 2. Type a '.' and try to recompile. Wait 30 seconds. While you're waiting, what work can you possibly do??? None. 3. Stop what you're doing, open up The Book Of Doobie [2], try to remember which page has the syntax that you need for doing this one simple thing, go to that page, navigate to the right part of the webpage, read the crap, think a bit, copy/paste it into your code. This FEELS more productive than (2), but is it really? This is just one example, maybe not terribly compelling, but it happens. People (well at least me) have a limited amount of memory for administrivial crap to…

So, I've been a Scala programmer for the last 3 years, and have been effectively writing Haskell in Scala reasonably effectively. The pure FP Scala community understands your complaints more than the Haskell community. https://typelevel.org/ is chock full of a) useful utilities for actually writing applications b) decent documentation. Not just pages of type signatures, but demonstrations of the libs usage. Everything you need is here: JSON, config, units of measure, streams, testing, validation, a really nice JDBC wrapper (https://tpolecat.github.io/doobie/) Throw in https://http4s.org/ and you've got yourself a rock-solid, purely functional stack with sensible, documented APIs, a more readable syntax and better tooling support. I urge anyone who learnt some Haskell, thought "man this shit sucks, I'm never going to write something useful in this" to at least give FP Scala a chance. Here's a useful service template to start hacking with: https://github.com/http4s/http4s.g8.