tpolecat

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…

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.

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.

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).

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/1tCmphnyP3F5WUtd1iNLub0TWRVyfTJsqhvzYhNS41WY/pub?start=false#slide=id.p 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 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.