Forem: Zelenya

Types and Compilers are our friends

Zelenya — Mon, 30 Mar 2026 03:19:47 +0000

The (natural) language we use is influenced by how we feel and what we think, but it also works the other way: just by the way we approach things, we can make our experience better or worse.

So, when we say "compiler is in the way" or "I have to fight the compiler", we are setting ourselves up for failure. And I don't mean some gigantic failures ‒ I mean small shitty every-day frustrations. There is no need to live like this.

And it's normal to be frustrated, not trying to put pink glasses on everyone, just trying to share different perspectives on some things.

Good and Bad

Disclaimer: I don't want to go too deep into details or muddy the definitions. Let's establish an abstraction level: we'll focus on moving more work out of runtime to build/compilation time.

We don't have to search too long to get to the most common arguments on this topic:

"Good"

catching bugs
enforcing correctness
improving performance (optimizations)

"Bad"

introducing "to-live" latency (slow)
introducing cryptic error messages
introducing unnecessary work (bad for prototyping)

It's somewhat common to treat those as trade-offs. Some people say that those "bads"/"frustrations" are there because the compilers are doing solid work for us. Others say it's not worth it. And we keep going in circles for years.

There is some truth to that. However, I don't think of those as "frustrations" nor as balanced trade-offs. And here's why.

Bad? Introducing latency

Things are relative. Slowness is relative. When we want to run a program and check our changes, there is a difference between waiting for javascript, purescript, and scala to run. Okay.

However, when we account for the time it takes bugs (or programming errors) to surface, we see a more noticeable difference.

For example, imagine we added a new status to a reporting job: "dismissed", ran the program (or even deployed it), opened the dashboard, updated the state, checked that it's there, and were done. Pretty sure this could be accomplished with javascript xTimes faster than with scala. Ok, but. If this status is used somewhere else, we didn't notice, javascript didn't care, and as a result, our users faced the bug. Not ok.

We traded off waiting seconds for the compiler to verify that all enum usages are exhaustive for a runtime error hours later. Was it worth it? Still valid to ask and question that.

And yes, compilation times can be really slow, but there is often room for improvement. And I don't mean just waiting for the compiler team to do the improvements ‒ I mean rolling up our sleeves. I know it's nice to have things out of the box, but if you want faster builds, you might need to do something yourself: reorganize modules for incremental-friendly compilation, figure out the optimal build configurations, tweak the CI caches, and so on.

Bad? Introducing error messages

Similar situation with error messages.

There is elm with friendly compilation error messages, haskell with infamous messages, and then there are null pointer exceptions at runtime. I don't know about you, but I'd take an unknown to me haskell compilation error message over a vague null pointer runtime exception any time.

And let's face it: If I see a compilation error, it means I made an error. It's not the compiler's fault (at least most of the time). And it's okay to make mistakes during development, it's a great time to make mistakes – we can learn from those! Look at this beautiful error: E0507. We can read it like a book.

Not all errors are the same. Not sure we can learn much from the compiler telling us that we forgot a semicolon. If you are so smart, Java, why don't you put a semicolon there yourself?!

And of course, individual error messages can and should be improved.

Good. Catching bugs

Remember how we talked about adding a new status to a reporting job?

enum Status {
    InProgress,
    Done,
    Failed,
    Dismissed,
}

Show pattern matching error

match Status::InProgress {
  Status::Done => println!("Done"),
  Status::InProgress => println!("Not done"),
}

// error[E0004]: non-exhaustive patterns: `Status::Failed` and `Status::Dismissed` not covered

Those are incredibly useful when we need to express constraints on the values. But we need support from a compiler (to properly create, pass, and consume those).

Also, I'm not saying the compiler is good; no compiler is bad. I want to paint a picture around expectations and intentions. For instance, the go compiler has a weak offering for the status. We can fake enums / sum types, but it's still quite error-prone; for example, nobody warns us if a case in a switch is missing.

type Status int

const (
    InProgress Status = iota
    Done
    Failed
    Dismissed
)

s := InProgress

switch s {
    case Done:
        fmt.Println("Done")
    case InProgress:
        fmt.Println("Not done")
}

// No complaints

Let's look at another example.

Rust has a single-threaded-only primitive Rc (in other words, it's not thread-safe). If we try to use it concurrently, the compiler won't let us:

let value = std::rc::Rc::new(42);

// ERROR: `Rc<i32>` cannot be sent between threads safely
let handle = std::thread::spawn(move || {
    println!("value = {value}");
});

The compiler refuses to let the value cross a thread boundary before the program ever runs (through the Send trait). Nothing is stopping us from making those sorts of mistakes in java. For instance, we can forget to use volatile on a variable (and the changes won't be noticed by other threads), or we can use a non-atomic operation on concurrent collections – we always need to be aware and use the right combination of keywords and primitives.

import java.util.concurrent.ConcurrentHashMap;

public class Main {
    public static void main(String[] args) throws InterruptedException {
        ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<>();
        map.put("count", 0);

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) {
                map.put("count", map.get("count") + 1); // not atomic!
            }
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) {
                map.put("count", map.get("count") + 1); // not atomic!
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();

        System.out.println("Expected: 2000, Got: " + map.get("count"));
        // The result is going to be different on each run, not 2000
    }
}

Note that you can use a thread-safe Arc there:

let value = std::sync::Arc::new(42);

let handle = thread::spawn(move || {
    println!("value = {value}");
});

handle.join();

One can argue for a skill issue or whatever, but we won't go there.

The rust compiler or type system is quite expressive, allowing us to be quite expressive. We can eliminate classes of bugs, as well as classes of thoughts. We don't have to think about using the wrong collection because it's not even possible. With more thinking capacity, we can prioritize mastering things that actually matter – in writing or review, we can focus on the core intent of the code.

And it's not about thinking less; sometimes we have to think more. In general, it's about thinking about different things (and at different times).

I am a big fan of the "parse don't validate" approach. For example, using an explicit non-empty list instead of normal arrays or lists with comments, runtime errors, or whatever. A non-empty collection isn't always better or a possible alternative to a collection. So, we have to think and decide upfront if enforcing a non-empty requirement is actually the right thing to do (depends on what and for whom we are optimizing). But if we do decide, someone can't mess it up.

-- Please pass a non-empty array, please!
foo :: Array Int -> _ Unit
foo items = case head items of
  Nothing -> throwException (error "Unexpected empty array")
  Just x  -> ...

bar :: NonEmptyArray Int -> _ Unit

Now, imagine:

We have a giant list (or text) that we need to carry around and render in multiple places in our system.
In some places, we want to show it raw, in others – sorted.
Showing the wrong thing in the wrong place is bad, and sorting is expensive.

We can express this with types.

sort :: RawText -> SortedText

foo :: RawText -> ActionA

bar :: SortedText -> ActionB 

baz :: RawText -> SortedText -> ActionC

This way, we can never mess it up (never mix things up, never forget to sort, and never sort twice). In languages like haskell and rust, those safety nets are zero-cost abstractions. Compilers take care of those – they don't appear at runtime.

Good. Improving performance

When it comes to optimizations, it's rarely as simple as Y times slower compilation = Z times faster runtime. Regardless, compilers are often aware of things that we're not thinking about or are too lazy to think about. So, why not let them assist us?

Take, for instance, react compiler. Probably not the first association that comes to mind when we talk about compilers, but it's a good illustration. This build-time tool automatically optimizes the application by handling memoization (adding useCallback, useMemo, useRef, and other tweaks and optimizations in the right places), so we don't need to worry about them.

"...freeing you from this mental burden so you can focus on building features."

Once again, back to freeing our thinking. And, just to be clear, I'm not advocating for thoughtless development – we need to be realistic about management of our thinking resources. Of course, we lose some control. What if we add a minute to the build for a 100ms rendering improvement for the users? Is this a fair tradeoff?

Bad for prototyping?

Out of all of these, the meme about prototypes gets on my nerves the most.

First, short term vs long term effects of prototypes. Why does nobody talk about the long term? Why can't we admit that most prototypes stay in production?

Prototypes are products.
The impact of failure is high.

I know why, because it requires introspection and admitting mistakes, nobody wants to do that...

After seeing dozens or hundreds of prototypes, I'm pretty confident that languages with fearless refactoring shine here. Haskell, PureScript, etc. are really good when it comes to delivering with rapidly changing requirements while staying reasonably correct and maintainable.

Rust is not famous for its refactoring – the meme is that if you choose the wrong abstraction, you have to rewire everything. However, even then, I'd still take refactoring a project in rust over javascript 9 times out of 10.

Ok, let's take a step back and simplify to the short term. Let's imagine an extreme example: 1 out of 10 experiments actually stays. Or even, 1 out of 10 one-off scripts doesn't get thrown away the next day. In this case, ok, I agree, we don't need anything maintainable. The impact of failure is low.

However, it's still a myth that something like python is the best for this. It still 100% depends on the individual or team experience. I think throw-away scripts are the best proof. I've seen people do those in bash, python, scala, rust, typescript... I can keep going.

If a person is good at something, they will be good at it when they need something fast.

Sure, we can kickstart a blog on rails xTimes faster than in haskell (from scratch). But we are not making hello worlds. What is this metric? If I'm in a company that has 20 production projects in haskell, and 0 in ruby, I bet it would be much faster to start the 21st one in haskell.

Hold on, what about tests and linters?

The initial abstraction is a bit leaky. We included the "react compiler" build tool, but I want to push back on some other build tools. A bit. It's somewhat common to hear:

"We don't need proper type systems, we write tests and catch things with linters."

Both are the wrong tools for that job. Simple as that. Those also add latency, vague errors, and unnecessary work. And, on top of that, they are more error-prone, add flakiness, increase the size of the codebase, and are easy to neglect (or forget).

I use linters and tests a lot, and they are important. But as supplemental tools. It's like real supplements. Compare eating junk food along with taking a bunch of multivitamins vs. eating nutritious food and a couple of vitamins you personally need.

Is this our last chance to use fun programming languages at work?

Zelenya — Sun, 15 Feb 2026 19:44:22 +0000

Do you care what programming language to use?

I often think about reddit discussions, where someone genuinely asks how they can find a Haskell job, for example, and there are always people who advise against looking for a job based on the language (instead of answering the original question). I get it. I understand arguments for both sides, but I won't argue for either. Some care 80% of the time, some don't care 80% of the time.

A different way to look at this is from the perspective of mainstream vs niche programming languages. Because if you are obsessed with a programming language, you are likely obsessed with some niche, esoteric language. And if you are not obsessed, you are probably using something more or less standard; the good old "nobody ever got fired for choosing Oracle".

Those aren't the same, but bear with me. I'll repeat myself, not arguing for any side, I want to establish that there is a conflict: within a team, a company, a wider industry, wherever. There are people with different values and interests.

Another very new conflict is about the use of LLMs. Once again, some people are all about it, some refuse to use it, and all sorts of in-between.

If we overlap those, we get conflicting quadrants. It’s a simple illustration ‒ conflicts are rarely two-dimensional. But conflicts are not fun. Sure, some people love conflicts and thrive in conflicts, but for normal people, constant conflicts are not fun. If most people on my team are in one quadrant and I'm in another, I have to deal with it: either suppress my needs, argue, change companies, or whatever.

I've been thinking about this, and while I was looking at a project at work, it clicked: we can have our cake and eat it too (one group can have it and another can eat it). We can have successful and less-conflict teams over multiple quadrants.

So, I'll tell you the story about this little project, and maybe it can give you hope or inspiration in some dark, turbulent times.

A story about a little project

About 2 years ago, I wanted to migrate an existing internal dashboard to PureScript. The existing one was part of the legacy system that nobody wanted to touch, let alone extend. So the bar was quite low.

My goals were to 1) quickly migrate basic functionality to unblock the migration of a larger legacy system, which was driving me crazy, 2) make it composable and extendable with the lowest possible friction: have copy-pasteable components and allow people to integrate TypeScript and JavaScript components easily, 3) showcase PureScript and get people curious (spoiler, this didn't bear fruit).

It was never a goal to spread the PureScript usage; the arrangement with a team and tech leadership was to give it a try for a few of weeks, and then consider or plan a rewrite to TypeScript. I did an mvp (including the migration of core functionality) in my free time because there was no time for that during work hours. As a plus, I got a video about PureScript+shadcn/ui and a template out of it.

I believe one of the worst, unprofessional stunts that one can do is to introduce something that nobody can maintain. It can soil the reputation of the thing forever. I had an experience where someone used Haskell for a project, which had terrible management and plans from the beginning ‒ it was doomed to fail. Because it sucked, people quit. Eventually, nobody could or wanted to maintain it. Guess who was a scapegoat? Years later, people who don't even know what Haskell looks like were blaming it (and the dev team) for everything.

After I deployed the first version, it was just the two of us contributing. My accomplice had no prior PureScript experience and first hated it: mostly because of the tooling and compilation errors. But, he still contributed more code and functionality than me. And, in a couple of weeks, we got it to a pretty big state. And it wasn't even on our team's priority list; we were doing it in the evenings and between things.

Things were going pretty well, the project was growing, and then we went from copilot to the llm-assisted coding era. It's really big now. A lot of annoying things that used to be managed manually are now behind this nice ui: a bunch of customer support tools, dev tools, a bunch of product configurations, some analytics, and exploration tools. A huge portion of that code isn't human-written. Quite successful.

Why it works well and what we can learn from this

Why it works in a specific case

One of the main reasons it works (and scales) so well is that it's a stateless app (ofc we persist users' dark/light mode preference), and consists of simple flows. Also, when we let the llms loose, we had a solid project with a bunch of code, a lot of good copy-pasteable code (for what it's worth).

Each tool doesn't affect the rest. The only problem is organizing everything and not cluttering the ui, but that's more of a fun puzzle than an actual problem. In this context, I'm not afraid of any potentially bad or slow or whatever changes affecting the rest of the tools; there is no need for wild smoke tests or QAs.

For example, one person wanted to add a new fraud-prevention tool. They aren't part of our team and have never touched PureScript before. We had a five-minute chat, I shared the repository and told them, "Look, as long as there are secure endpoints, there isn't anything else to worry about, really". The project's readme is just npm install and npm start, so don't think that we have something sophisticated going on. They opened a pull request the next day, the code looks pretty good and consistent, and ui looks nice and friendly.

Which is fun and brings us to the most exciting part.

Why it works despite being functional

There were always concerns with steep learning curves. People bring this up most times someone mentions Haskell, Scala, Rust, or any other non-mainstream language.

This is no longer a serious argument.

The contribution entrance level is pretty low now. I definitely don't want to generalize and pretend like every contribution is equal, that this applies to acquiring proper skills, or anything like that, and I'm also not talking about open source.

But, in work environments, there are opportunities now to have good human code (I would go as far as to say, good functional code) and open the gates to various contributors. And if you have a higher bar then llms can deliver, you can always refactor and polish the code as needed.

As a bonus, we can lower the fear of maintainability and bus-factor. Microsoft says they are going to use llms to rewrite everything to Rust, so if somebody out there was brave enough to claim that, surely, we can be brave enough to introduce new technologies at smaller scale.

If somebody hates your Haskell tool at work, what stops them from rewriting it over the weekend? It has never been easier. I only had experience with migrating Ruby, JavaScript, and Python code to functional languages, but I'm pretty sure it works the other way around.

And it also extrapolates to making libraries. If someone says: "Oh, no! There is no Haskell SDK for a new hyped technology!" We can just laugh at them and send them back to 2025! Sorry. This is one of my favorite internal jokes.

In the case of PureScript, we don't even need to rewrite libraries ‒ we can just generate FFIs (PS-friendly bindings) to existing JS/TS libraries. We can also generate TypeScript code that uses those libraries and then generate PS bindings to this code instead...

For instance, we use shadcn/ui and have a couple of graphs integrated already, but not all of them. A couple of months ago, I wanted to investigate how the data looked somewhere (to work on improving caches), just once. Llms are pretty good at making quick charts ‒ it doesn't want to use shadcn/ui and prefers using radix charts directly. But I don't have to maintain it, so who cares?

(There is a chance I'd need it again next time, and I still haven't learned, but that's a different problem)

I don't want to go through a bunch of complaints and myths; the last two things I want to mention are tooling and errors.

I don't have an exact venn diagram, but plenty of people who complained about Haskell tooling, for instance, are now using chat as an interface to their code. So... yeah... Make your own conclusions.

But the situation with compilation errors is even more interesting. These errors ‒ in Haskell, PureScript, and so on ‒ are a huge pain point for many inexperienced and experienced developers. Talking about this has been in my backlog for a long time. Long story short, 90% of the time, if not more, the compilation errors are actually really good and precise. The problem is that they are often too precise. The compiler tells them exactly what the problem is, but in the words and concepts they don't understand. Because if they did, they wouldn't make the mistake in the first place.

firstLetter :: String -> String
firstLetter xs = head xs

• Couldn't match type ‘Char’ with ‘[Char]’
  Expected: [String]
    Actual: String
• In the first argument of ‘head’, namely ‘xs’
  In the expression: head xs
  In an equation for ‘firstLetter’: firstLetter xs = head xs

0 || True

• No instance for ‘Num Bool’ arising from the literal ‘0’

I'm not defending those errors, by the way. They still suck. For humans. But guess what, they are really good for the machines. Feed those suckers to llms. No need to be scared of compilation errors.

Why it works by virtue of being functional

On this project, we used to be cautious with llm-generated code, but at some point, we ended up with a couple of modules that only Claudius reads and edits. Once, I was curious and wanted to check what we had there. There were 10 states for different in-flight statuses ‒ a common thing, when one action is happening, we don't want to allow others. So, each action/button had its own flag/state and checked all the others (9 checks) to determine if it should be disabled. It's terrible.

So, if you look at one change or PR at a time, it's fine ‒ each one is just adding a normal state, nothing special. But if you take a step back and look at the bigger picture ‒ hell. It was a quick and easy fix to go from 10 states to 1.

Refactoring and dealing with tech debt are quite important, but could be scary.

This is a point for languages with fearless refactoring, like PureScript. I can't imagine how JavaScript developers, for instance, can survive this long term.

But that is me, right now, on a specific project. This is not an argument for an FP future.

Who cares what programming language to use?

I just want to know. Do you care what programming language to use? What are you doing about it?

Do LLMs care what programming language to use? How does it affect things you care about? How will it affect?

*This is February 2026; regardless of your opinion and experience, there is a chance, not a 0% chance, that programming languages will matter less because of the new abstraction level. But they might matter more.

Could it be our last chance to choose and care about programming languages?

I would love to ramble, speculate, and expand on this more, but probably some other time.

Also for that project, my side quest was to get people excited about PureScript, maybe teach a couple of people. This failed. Nobody really wanted to, and there is not much incentive at this point.

Functional takes on GoF design patterns

Zelenya — Tue, 30 Dec 2025 04:17:48 +0000

There is a meme that every (OOP) GoF design pattern can just be replaced with a function.

If you think about it, it’s not that funny. Sure, there is some truth to that, and some patterns are already obsolete. But we also don’t just use functions in a vacuum — we write, compose, and manipulate them.

Plus, jumping to those kinds of extremes is not helping anyone. We can build connections and grow on top of existing knowledge.

So, let’s go through each of the 23 GoF patterns and see which one I actually see being used and what the functional alternatives are (if any). Most techniques and concepts will be language agnostic, with a few specific examples. We’ll see snippets in Haskell, Scala, PureScript, and Unison.

Creational Patterns

Abstract Factory
Builder
Factory Method
Prototype
Singleton

Disclaimer: There are no OOP classes outside of OOP, so making instances of classes doesn’t make sense — but we still can talk and abstract over creating instances of things. Instead of classes, we'll be thinking in terms of modules, bundles of functionality, encapsulated APIs, or something along those lines...

Abstract Factory

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

I remember it as a toy factory that, for example, can make bears, airplanes, and cars out of different materials (e.g., wood or plastic).

In the oop world, we can use this to abstract over things like database connections and commands while generalizing over the database. So, we can write code that creates a database connection, executes some queries, and runs it with one database. Later, if we want to, we can swap the database by swapping the factory (and configuration).

In FP, we don’t use abstract factories — we utilize functions and polymorphism (polymorphic types, and, in some cases, type classes). Let’s take a look at two Haskell libraries and how they address this.

In beam, we write abstract (backend/database-agnostic) code in terms of MonadBeam with polymorphic backend and generic functions (e.g, select).

query1 :: (MonadBeam be m) => m [Product]
query1 = do
  let allProducts = all_ (warehouseDb.product)
  runSelectReturningList (select allProducts)

Don't worry about the function signature for now. The important part is that it's abstract in terms of the database.

We can then execute for a specific database using one of the backends; for example, runBeamPostgres for postgres.

executeQuery :: Connection -> IO ()
executeQuery connection = runBeamPostgres connection do
  result1 <- query1
  liftIO $ putStrLn ("Query 1: " <> show result1)

Note: We can also use the specific backend directly to access the full power of the database.

See usage example and docs.

In persistent, it’s somewhat similar; we use functions that are abstract over the backend type. (for sql databases, it’s SqlBackend). The library uses type classes (such as PersistStoreRead, and PersistStoreWrite) to define database operations.

insertStuff :: (MonadIO m) => ReaderT SqlBackend m ()
insertStuff = do
  newId <- insert (Product "Wood Screw Kit 1" 245)
  liftIO $ putStrLn ("Insert 1: " <> show newId)

ReaderT SqlBackend m () means we can access database configuration (e.g., database connection), can perform arbitrary IO operations, and don’t return anything meaningful (void).

And once again, we tie everything together with a specific backend, for example, using runSqlite or withPostgresqlPool.

See usage example and docs.

Factory Method

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

In the simplest form, we want to hide the concrete implementation, so it can be created, returned, and used behind an abstraction/interface. A somewhat simple and common use case.

Imagine we have some payment processing system and need to support multiple providers — for now, stripe and paypal.

trait PaymentProcessor[F[_]] {
  def processPayment(payment: Payment): F[PaymentResult]

  def refund(transactionId: String): F[PaymentResult]
}

class PayPalProcessor[F[_]: Sync] extends PaymentProcessor[F] {
  def processPayment(payment: Payment): F[PaymentResult] = ???

  def refund(transactionId: String): F[PaymentResult] = ???
}

class StripeProcessor[F[_]: Sync] extends PaymentProcessor[F] {
  def processPayment(payment: Payment): F[PaymentResult] = ???

  def refund(transactionId: String): F[PaymentResult] = ???
}

This is an example of tagless final — a popular approach to structuring code in Scala. We have an abstract interface PaymentProcessor (some generic F) and somewhat abstract implementations (F with Sync) that still don't commit to the final implementation, it could be IO, IO with explicit error handling, IO with tracing, etc.

If we delegate the creation of the specific implementation to the PaymentProcessorFactory — for example, based on the config — we get ourselves a simple factory.

case class PaymentConfig(paymentProvider: String)

object PaymentProcessorFactory {
    def createProcessor(config: PaymentConfig): F[PaymentProcessor[F]] = {
      config.paymentProvider.toLowerCase match {
        case "paypal" => PayPalProcessor[F].pure[F]
        case "stripe" => StripeProcessor[F].pure[F]
        case unknown  => IllegalArgumentException("Unknown provider: $unknown").raiseError[F]
      }
    }
}

Note that we can always go a level deeper and abstract the abstractions:

trait PaymentProcessorFactory[F[_]] {
  def createProcessor(provider: String): F[PaymentProcessor[F]]
}

class DefaultPaymentProcessorFactory[F[_]: Sync](config: PaymentConfig) 
  extends PaymentProcessorFactory[F] {

  def createProcessor(): F[PaymentProcessor[F]] = {
    config.paymentProvider.toLowerCase match {
      ???
    }
  }
}

class ExperimentBasedPaymentProcessorFactory[F[_]] 
  extends PaymentProcessorFactory[F] { ... }

class CountryBasedPaymentProcessorFactory[F[_]] 
  extends PaymentProcessorFactory[F] { ... }

But let's not get wild here. Instead, let's look at a primitive usage example (note that there is nothing about specific implementations):

class PaymentService[F[_]: Sync](factory: PaymentProcessorFactory[F]) {
  def makePayment(provider: String, payment: Payment): F[PaymentResult] = {
    for {
      processor <- factory.createProcessor(provider)
      result    <- processor.processPayment(payment)
    } yield result
  }

  def refundPayment(provider: String, transactionId: String): F[PaymentResult] = {
    for {
      processor <- factory.createProcessor(provider)
      result    <- processor.refund(transactionId)
    } yield result
  }
}

Factory methods are still used in different shapes and forms, especially in the scala world. As soon as you have a tagless final, mtl, service pattern, or whatever, factories sprout out naturally when we actually have multiple implementations.

Singleton

Ensure a class only has one instance, and provide a global point of access to it.

In the presence of immutability and other things, singletons aren’t really needed. Most of the time, we create something once and then pass it around, knowing that nobody can modify it. For example, a db connection:

Simple.withConnect connectionInfo $ \connection -> do
    cleanUp connection
    insertStuff connection
    queryData connection
    insertWithTransaction connection
    queryWithJoins connection
    errors connection

If we need to modify something and access it concurrently, we use appropriate concurrency primitives; for example, Ref (aka Ref, IORef, …, you can find ref’s siblings all over).

If we are in scala land and do need the simplest form of singleton (one instance of a class, not the double-thread-safe protected version, there are also singleton objects modules.

Builder

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Now that we talk about scala, Builders are also quite common. It is one of the patterns that the community inherited and carried over from java.

For example, here is a request definition using the sttp library:

val request = basicRequest
  .cookie("login", "me")
  .body("This is a test")
  .post(uri"http://endpoint.com/secret")

It’s typical for fp libraries (and apis) to provide a basic/initial/default way to create data and build on top of.

Here is a unison example

We see something similar in Haskell libraries and apis: defaultRecord that can be updated via setters or via record update syntax. For example, to create Options for json codecs using

defaultOptions { omitNothingFields = True }

💡 Note: Sometimes it comes in the form of a default record and monoid instance.

Wait. Is this Prototype, not Builder? Hm. Let’s revisit it in a second.

To conclude with builders, I’d say that they are somewhat common. Maybe not the way GoF envisioned, but whatever, builders are builders.

Otherwise, in the fp world, we talk more about smart constructors and not builders. The focus is on making functions and APIs for creating only valid or validated values that can be safely passed around afterwards. For example, if we have a smart builder for an album, it should make sure that we can't create an album with an invalid year or an empty artist name.

Prototype

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

It’s quite a functional pattern. Even if I can’t draw a clear line between builders and prototypes.

We saw this example of creating Options for json codecs:

defaultOptions { omitNothingFields = True }

There is some record with defaults, we copy it, and update only what's needed.

Copying data is bread and butter in FP. Some have it baked in. The above is the Haskell syntax for record updates. Scala case classes have a copy method:

case class Foo(from: String, amount: Long)
val foo = Foo("foo", 20)
val bar = foo.copy(from = "bar")

Structural Patterns

Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Structural design patterns are about organizing (structuring and re-structuring) objects and classes. And once again, a disclaimer. Because we don't have those outside of OOP, we’ll have to be more abstract and think in slightly different terms. I think we should focus on APIs and gluing code together. And to keep it interesting, we'll mix in various approaches.

If you can recall, when we started with Abstract Factory, we already saw a couple of interesting-looking functions (function signatures):

query :: (MonadBeam be m) => m [Product]
query :: (MonadIO m) => ReaderT SqlBackend m ()

In Haskell, there is plain IO, mtl and transformers, custom monads (on top of those), IO + Reader(T), RIO, unliftio, services and handle patterns, free monads, freer-simple, extensible-effects, fused-effects, eff, effectful, cleff, polysemy, bluefin, and other effect libraries (that I forgot to mention).

“Remember this when someone says that it’s just functions in FP.”

Adapter

Convert the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

In the simplest case, an interface could imply the data we move around. Imagine you have a module responsible for payments, you need to update to the latest stripe API (with breaking changes), but you don't want (or are not allowed) to change the sdk module. You can make an adapter.

If you have a module with V1 data with a function like this:

getInvoices :: UserId -> InvoiceStatus -> IO [InvoiceDataV1]

You can adapt it to V2 data like this:

adaptInvoice :: InvoiceDataV1 -> InvoiceDataV2

-- adapt from v1 to v2
getInvoicesV2 :: UserId -> InvoiceStatus -> IO [InvoiceDataV2]
getInvoicesV2 user status = do 
  v1Response <- getInvoicesV1 user status
  v2Response = map adaptInvoice v1Response 
  pure v2Response

I'd say this is an adapter, alas, a boring one. A more interesting interpretation of interfaces is the library and internal APIs ‒ APIs that we use to code with. It's a perfect opportunity to demonstrate what I meant in the introduction.

There is no one way to write Haskell code. Even in the same code base, it's quite common to have a mix of approaches. For example, you just started a new service with a new fancy framework, and you need to integrate a library (internal or external) that uses something different.

Let's start simple. You have a library that uses plain IO:

getInvoices :: UserId -> InvoiceStatus -> IO [InvoiceData]

And you need to integrate it with your service that uses monad transformers, for example, ResourceT. We need an adapter!

getInvoicesLifted :: UserId -> InvoiceStatus -> ResourceT Env [InvoiceData]

💡 ResourceT provides the ability to pass and read env. There are no global variables.

You can do the transformation manually (not going to show it), but you can also use a function just for this! In this case, liftIO:

getInvoicesLifted :: UserId -> InvoiceStatus -> ResourceT Env [InvoiceData]
getInvoicesLifted user status = liftIO (getInvoices user status)

This is simplified. Depending on the context, complexity, and your team, this could be handled differently and kept more abstract. For instance, some people would prefer not to use an intermediate function like getInvoicesLifted and use liftIO at the call site.

Some prefer to use alternative abstractions and utilities, such as unliftio. But it all depends... Remember to check the documentation, recommendations, or your instincts for each particular case.

For example, if you look at the docs of the Effectufl library, you can see a whole section on integration with various cases.

Bridge

Decouple an abstraction from its implementation so that the two can vary independently

I think the idea is to use composition instead of inheritance to decouple the high-level interface that clients interact with from the concrete implementation details. The inheritance is not a problem outside of OOP, and you can decouple the public interface from the private in many different ways.

For example, if we talk about libraries and apis, one common approach in Haskell and PureScript library design is using the Internal module.

For example, let's look at the bytestring library: the public API is Data.ByteString, but the lower-level API is in Data.ByteString.Internal. The Internal API is not stable and not meant for casual everyday usage; it's meant to provide flexibility for advanced users. For instance, see the disclaimer in the containers internals

Not everyone's favorite approach, and it doesn't solve all the problems, just one example.

Composite

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Trees and recursions are native to FP. For instance, there are design patterns for traversing and recursing over nested data structures, called recursion schemes. But I think it might be too specific to "represent" Composite; we can get away with something simpler. We can use type classes to model Composite.

Let's ignore the parts where we need to add and remove components, and focus on having a uniform interface for components and compositions of components. Imagine we need to have a Printable interface.

(Don't think about oop classes, think about rust traits)

class Printable a where 
  print :: a -> String

We can implement a Printable instance for anything that needs to be printed. Let's rely on the default PureScript show for a number and return a string in quotes:

instance Printable Number where 
  print = show

instance Printable String where
  print s = "\"" <> s <> "\""

If we have an array of printable things, we can print them all:

instance Printable a => Printable (Array a) where
  print arr = "[" <> intercalate ", " (map print arr) <> "]"

Note that we rely on a Functor instance of Array, a map function. Another type class. Just imagine that we apply a function to every element of the list.

To wrap up this example, let's look at printable json (with a mix of printable and not yet printable types):

data JSON 
  = JNull 
  | JBool Boolean 
  | JNumber Number 
  | JString String 
  | JArray (Array JSON) 
  | JObject (Array (Tuple String JSON))

instance Printable JSON where 
  print JNull = "null" 
  print (JBool true) = "true" 
  print (JBool false) = "false" 
  print (JNumber n) = print n
  print (JString s) = print s
  print (JArray arr) = print arr
  print (JObject pairs) = "{" <> intercalate ", " (map printPair pairs) <> "}" 

printPair (Tuple k v) = print k <> ": " <> print v

There might be too many quotes, and I'm too lazy to test it. However, see how the json arrays and objects are handled. Composite!

Decorator

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

My favorite use of decorator is to separate business logic from production-needed bells and whistles (things that help observability and performance, but can swallow the core logic if not tamed well).

Let's revisit the tagless-final processor that we used a while back.

trait PaymentProcessor[F[_]] {
  def processPayment(payment: Payment): F[PaymentResult]
  def refund(transactionId: String): F[PaymentResult]
}

class PayPalProcessor[F[_]: Sync] extends PaymentProcessor[F] {
  def processPayment(payment: Payment): F[PaymentResult] = ???
  def refund(transactionId: String): F[PaymentResult] = ???
}

class StripeProcessor[F[_]: Sync] extends PaymentProcessor[F] {
  def processPayment(payment: Payment): F[PaymentResult] = ???
  def refund(transactionId: String): F[PaymentResult] = ???
}

If we want to add metrics without duplication and polluting the implementation, we can add a new implementation of the payment processor to enhance the functionality:

class MeteredProcessor[F[_]](underlying: PaymentProcessor, metrics: Metrics) 
  extends PaymentProcessor[F] {

  def processPayment(payment: Payment): F[PaymentResult] = 
    metrics.measure(underlying.processPayment(payment))

  def refund(transactionId: String): F[PaymentResult] = 
    metrics.measure(underlying.refund(transactionId))
}

// Checks the cache first, before calling the api
class CachedProcessor[F[_]](underlying: PaymentProcessor, cache: Cache) 
  extends PaymentProcessor[F] {

  def processPayment(payment: Payment): F[PaymentResult] = ???

  def refund(transactionId: String): F[PaymentResult] = ???
}

And then decorate the original processors:

val payPalProcessor = MeteredProcessor(PayPalProcessor(...)) // no cache

val stripeProcessor = MeteredProcessor(CachedProcessor(StripeProcessor(...)))

Facade

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

I don’t think it’s a real design pattern; it’s just good design (good manners). I don’t think it’s worth talking about here.

Flyweight

Use sharing to support large numbers of fine-grained objects efficiently.

This one is also a normal phenomenon. In my naive and optimistic view, in the presence of immutability, we often get this for free.

data Expense = Expense Int 
  deriving (Eq, Show, Num)

makeExpensiveValue :: Int -> Expense 
makeExpensiveValue n = 
  trace ("Creating an expensive value: " ++ show n) (ExpensiveValue n)

If we create an instance of something expensive, it makes sense that it's created once:

main = do 
  let x = makeExpensiveValue 3
  print x

-- Creating an expensive value: 3
-- Expense 3

And if we want to create a whole list of those, it will still create one instance of Expense 3:

main = do   
  let xs = replicate 5000 (makeExpensiveValue 3)
  let res = sum xs
  print res

-- Creating an expensive value: 3
-- Expense 15000

This still prints Creating an expensive value once. The initialization happens once.

Proxy

Provide a surrogate or placeholder for another object to control access to it.

I think using Proxy is structurally similar to Decorator ‒ instead of providing an additional functionality, it restricts access, sometimes adds lazy initialization, and so on. Maybe the way the clients use it is different, doesn't make a huge difference. Let's just move on.

Behavioral Patterns

Finally, a set of patterns that have nothing to do with classes and objects, right?

Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor

Chain of Responsibility

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

When I think about chains and fallbacks, I think of Options:

val first: Option[Payment] = stripePayments.headOption
val second: Option[Payment] = payPalPayments.headOption

first.orElse(second).getOrElse(fallback)

We chain a few things until we get some payment. This isn't much of a chain of handlers, so let's look at something more interesting. Imagine we need to extract a version out of the string, but we are dealing with questionable vendors (some return "v1.1", others "1.1.0", "2025-10-10", and so on):

We can go through the list of parser functions until one of them returns some result, or we reach the end:

val parseSemVer : String => Option[Version] = ???
val parseCalVer : String => Option[Version] = ???
val parseSoloVer: String => Option[Version] = ???

val parseChained: String => Option[Version] = { str =>
  List(parseSemVer, parseCalVer, parseSoloVer).collectFirstSome(_(str))
}

parseChained("2025-10-10")  // Some (CalVer ...)
parseChained("non-sense")   // None

Alternatively, we can use an explicit chain:

val parseChained: String => Option[Version] = { str =>
  parseSemVer(str) <+> parseCalVer(str) <+> parseSoloVer(str)
}

The <+> operator comes from the SemigroupK type class. Doesn't matter where it comes from. It's common. We won't go too deep into parser combinators, but this would be a fitting detour. They don't use Options (because we need meaningful errors), but do use plenty of typeclasses and operators to chain parsers together. If you are interested, consider exploring any Haskell library (such as megaparsec) or tutorial (e.g., Learn Haskell by building a blog generator). Note the use of the <|> operator (it's related to the other one).

parseTest (try (string "let") <|> string "lexical") "lexical"`

If we return to our examples and want more than "just" parsing -- if we want arbitrary handlers of requests -- we can use IO along with Option:

val fetchStripePayment: IO[Option[Payment]] = ???
val fetchPayPalPayment: IO[Option[Payment]] = ???
val createFallback: IO[Option[Payment]] = ???

fetchStripePayment.orElseF(fetchPayPalPayment).orElseF(createFallback)

That is syntactic sugar. Those chains are more commonly seen as an OptionT monad transformer:

(OptionT(fetchStripePayment) <+> OptionT(fetchPayPalPayment) <+> OptionT(createFallback)).value

The syntactic sugar in the previous snippet is to hide OptionT from innocent eyes.

And to nail the point. One of the Scala HTTP libraries uses something similar to chain services (actual request handlers) together:

val services = tweetService <+> helloWorldService

Command

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

This is IO, or Task, or Effect, or whatever your language or library calls it — some data type to describe and pass around (effectful) computations. Let's use Effect and PureScript for examples, and start simple.

Let's start with a function that takes an arbitrary command and repeats it N times. We can log and differentiate the stages via the console.

repeat :: forall a. Int -> Effect a -> Effect a
repeat n task = 
  -- todo: errors
  if (n == 1) then do
    log "done"
    task
  else do 
    log ("doing " <> show n)
    _ <- task
    repeat (n-1) task

Even though we can pass any kind of action, I couldn't come up with anything better than passing another log repeat 3 (log "- Action"). We can still see the repetition in action:

doing 3
- Action
doing 2
- Action
done
- Action

If we return to the payments domain and sketch out a more complex client, we can see the pattern more clearly:

type Request = 
 { fetchPayments :: UserId -> Effect Payments
 , prepareInvoice :: Payments -> DateTime ->  Effect Invoice
 }

client :: UserId -> Request -> Effect (Array Invoice)
client user { fetchPayments, prepareInvoice } = do
  payments <- fetchPayments user
  let dates = [yesterday, today, tomorrow]
  invoices <- for dates (prepareInvoice payments)
  pure invoices

In this example, there is no exception handling or retries, but this could be the next logical step. This is not really Command, but it covers 80% use cases (if not more). We can pass different implementations of tasks/actions to the client, and the client decides in what order to execute those, how many times, and whatever else.

This is a service pattern -- it's not very documented but not very restrictive. If you are coming from oop world, it's just an interface bundled together. And concrete implementations are also bundles of concrete functions.

Anyway. If IO and friends are not enough to express the Command, it could be integrated with the techniques used to replace the Interpreter.

Interpreter

Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

I'm pretty sure this is the most beloved design pattern among fp devs. For instance, EDSLs (embedded domain-specific languages) are very popular and one of the go-to examples for selling fp; the overlap between the patterns and the worlds is significant.

We've already seen a few interpreters in the previous examples. But let's start with an alphabet: expressions.

// operations
sealed trait Expr
case class Add(l: Expr, r: Expr) extends Expr 
case class Lit(i: Int) extends Expr

// evaluators/interpreters
def eval(e: Expr): Int = e match {
  case Lit(i) => i
  case Add (l, r) => eval(l) + eval(r)
}

def pprint(e: Expr): String = e match {
  case Lit(i) => i.toString
  case Add (l, r) => print(l) + "+" + print(r)
}

Which allows us to represent and interpret sentences like this one:

eval(Add(Lit(1), Add(Lit(2), Lit(3))))

It's not a production-ready example; there are plenty of issues (it's hard to extend and add new operators, to support other types of literals, and so on), but this should be a good starting point.

Now, let's hop a few learning steps ahead and look at real-world examples. When we are talking about free monads or tagless final, we are talking about interpreters. It's especially common in scala.

One of the popular Scala libraries -- doobie (for sql/persistence) uses free monads and "provides a functional way to construct programs (and higher-level libraries) that use JDBC"

For example, we can construct a program using a primitive sql statement that returns an int:

val program: doobie.ConnectionIO[Int] = sql"select 42".query[Int].unique

But it won't do anything unless we run or interpret it:

val xa: Transactor[IO] = Transactor.fromDriverManager[IO](???)

program
  .transact(xa)    // Interpret the doobie program into IO
  .unsafeRunSync() // Execute IO

Technically, doobie provides an interpreter from its free monads to something more generic than IO, but ... I hope the point about interpreters is clear.

While we're here, let's look at a visitor.

Visitor

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

It's quite common to compare the Visitor pattern to pattern matching.

// Visitor interface 
trait PaymentVisitor { 
  def visitPayPal(payment: PayPalPayment): Unit 
  def visitStripe(payment: StripePayment): Unit 
  def visitBankTransfer(payment: BankTransferPayment): Unit 
}

vs.

def process(payment: Payment) = payment match { 
  case PayPalPayment(email, amount) => ???
  case StripePayment(token, amount) => ???
  case BankTransferPayment(iban, amount) => ??? 
}

And then you are supposed to laugh because a design pattern was invented to compensate for a lack of a language feature. But the thing is, life is not that simple. Not every functional language supports sum types and pattern matching. It's not a requirement for being functional.

Those languages can get away with Church encoding / Böhm-Berarducci encoding (depending on whether they are typed or not).

For example, instead of pattern matching on an optional value, it's enough to have a function that allows dealing with both cases when you have and do not have a value:

// with pattern matching
Option(3) match {
  case Some(int) => print("You have an int")
  case None => print("You have none")
}

// with Böhm-Berarducci encoding:
Option(3).fold(ifEmpty = print("You have none") // None case
  )(f = (int: Int) => print("You have an int")) // Some case

Also, even though Scala has pattern matching, sometimes it can be more efficient to use a Visitor. See doobie internals:

// Interface ... encoded via the visitor pattern.
// This approach is much more efficient than pattern-matching for large algebras.
trait Visitor[F[_]] ...

Also, Java 21 comes with pattern matching. So, we'll see if it's time for Visitor to retire or not.

Speaking of folds

Iterator

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Multiple things here. Depends on what kind of aggregation we're talking about.

First, we have Foldable and Traversable type classes. Let's start with Foldable :

let numbers = [1, 2, 3, 4, 5]

length numbers -- 5
elem 3 numbers -- True
foldl (-) 0 numbers -- -10
sum numbers -- 15

Usage isn't limited to just lists; we can find Foldable instances for all sorts of things; we can even derive those for free:

data Tree a 
  = Empty
  | Leaf a
  | Node (Tree a) a (Tree a)
deriving Foldable

Traversable extends Foldable and abstracts away even more work for us:

let strings = ["1", "2", "3", "4"] 
traverse readMaybe strings :: Maybe [Int] -- Just [1,2,3,4] 

let badStrings = ["1", "2", "bad", "4"] 
traverse readMaybe badStrings :: Maybe [Int] -- Nothing

fetchUserData :: Int -> IO String 

apiExample :: IO () 
apiExample = do 
  let userIds = [1, 2, 3] 
  -- Fetch all users (sequential) 
  traverse fetchUserData userIds

Those two play a vital role in iterating over things. But I wouldn't stop there, because we also have Optics. They allow us to deal with pretty much any sort of aggregation and complexity. A lot to cover here. But here is my favorite example.

Imagine we have warehouses with stocks, and our task is to update all existing shoe stocks.

[
  {
    "inventory": {
      "shoes": [
        {
          "name": "CHUCK TAYLOR ALL STAR LIFT",
          "brand": "Converse",
          "stock": 4
        },
        {
          "brand": "Morrison"
        }
      ]
    },
    "location": "London"
  },
  {
    "location": "Berlin"
  }
]

Something that we have to keep in mind: inventory is optional, name and stock are also optional.

newtype Response = Response {_warehouses :: [Warehouse]}

data Warehouse = Warehouse
  { _location :: Text
  , _inventory :: Maybe Inventory
  }

newtype Inventory = Inventory {_shoes :: [Shoes]}

data Shoes = Shoes
  { _name :: Maybe ShoesName
  , _brand :: Brand
  , _stock :: Maybe Stock
  }

-- We omit optic derivation/generation for simplicity (see else where)

We start with composing optics to access what we need (existing stocks across warehouses and inventories):

_allShoes = warehouses . traverse . inventory . _Just . shoes . traverse
_existingStock = _allShoes . stock . _Just

And then we use it to update existing stocks:

over _existingStock (subtract 1) warehouseResponse

Technically, in this example, we are working with "underlying representation", but if we think of those snippets as library internals that expose only _allShoes or _existingStock, then we do provide a way to access the elements per pattern definition.

And then if the internal representation changes (for instance, there are multiple inventories per warehouse, inventory becomes inventories), nothing changes from the user's perspective.

_allShoes = warehouses . traverse . inventories . traverse . shoes . traverse
_existingStock = _allShoes . stock . _Just

-- No changes
over _existingStock (subtract 1) warehouseResponse

Mediator

Define an object that encapsulates how a set of objects interacts. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Similar to Facade; for me, not a real design pattern. We shouldn't write spaghetti code.

Memento

Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.

In the presence of immutability, the state can't be modified, so there is no encapsulation to violate. History can be a list of (previous) states.

I used to work on a graph editor with PureScript, and we needed to keep a history of states to support undo. It was pretty much this:

type Editor = 
  { current :: EditorState
  , history :: Array EditorState -- "Memento"
  }

undo :: Editor -> Editor

Well, it was more complicated but more ergonomic. We also wanted to support undo and redo (go back and forth in history), so we used Zipper. I don't remember if we used a library or wrote something custom, but it provides an api like this:

current :: forall a. ZipperArray a -> a
prev :: forall a. ZipperArray a -> Maybe a
next :: forall a. ZipperArray a -> Maybe a

Observer

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

This makes me think of functional reactive programming. I don't have much experience with it, so I'm unable to come up with an interesting illustration.

But I do have experience with simpler functional streams, like fs2, that provide primitives like Topic and Signal to implement the publish-subscribe pattern, and other ways to define dependencies between objects:

Topic[IO, String].flatMap { topic =>
  val publisher = fooStream.through(topic.publish)
  val subscriber = topic.subscribe(10).take(1)

  subscriber.concurrently(publisher)
}

The next thing that comes to mind is event handling with api like this:

onEvent :: (a -> Effect Unit) -> Effect Unit

event :: a -> Effect Unit

Consider web events, such as button clicks, form updates, and key presses.

For example, this is an event handler from purescript-react-basic:

handler :: forall a. EventFn SyntheticEvent a -> (a -> Effect Unit) -> EventHandler

-- for simplicity, can be read as 
handler :: SyntheticEvent -> (SyntheticEvent -> Effect Unit) -> EventHandler

Let's use it to update the credentials when someone types into the password form:

input
  { id: "password"
  , type: "password"
  , placeholder: "P4$$W0RD"
  , required: true
  , value: credentials.password
  , onChange: handler targetValue (\value -> setPassword value)
  }

And if you don't think that either fits as Observer, wait till you see what I have for the next one.

State

Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

Probably, the closest kinda-functional kinda-backend kinda-version of this is (Finite) State Machines.

┌─────────┐
│  Draft  │
└────┬────┘
     │ Send
     ▼
┌─────────┐
│  Sent   │──────┐
└────┬────┘      │
     │ Pay       │ Cancel
     ▼           ▼
┌─────────┐ ┌───────────┐
│  Paid   │ │ Cancelled │
└─────────┘ └───────────┘

sealed trait State
case object Draft, Sent, Paid, Cancelled extends State

sealed trait Event  
case object Send, Pay, Cancel extends Event

(state, event) match {
  case (Draft, Send)   => ???
  case (Sent, Pay)     => ???
  case (Sent, Cancel)  => ???
  case (Draft, Cancel)  => error("Invalid state")
  ...
}

This is a very straightforward example, and there are many ways to implement a state machine, depending on the language, use case, and the rest of the code. There are libraries for this as well. For instance, there was a time when it was popular to use Akka FSM.

Let's take a step back and think of the State more abstractly. There are no objects in fp, so if we are talking about altering an object's behavior, we should be talking about altering the behavior of functions. In theory, we can make the behavior dependent on input parameters. Different parameters -- different behavior. However, as we discussed in the context of Structural patterns, at some point, we have to start using higher-level concepts and ways to organize code.

This is where the concept (or ability or whatever you want to call it) of State comes in. There are different implementations and approaches, but they all have the same interface:

-- Return the state (from internals of `m`)
get :: m s

-- Replace the state (inside the `m`)
put :: s -> m ()

There is the State data type in the standard library. There are various States in each effect library (for example, State in bluefin). Let's look at MonadState from the mtl library. I think it is the simplest one to use as an example, but the ideas apply to other libraries and implementations.

pay :: MonadState Invoice m => m ()
pay = do
  invoiceState <- get
  -- behavior depends on the internal state
  if invoiceState.status == Sent 
  then put (invoiceState { status = Paid })
  else pure () -- noop

We have a pay function that uses get and put state functions. This function is quite abstract -- we say that we don't care who or how is going to call it, as long as they implement the MonadState type class (get and put). They can store state in a single-threaded mutable variable, an atomic reference, or even on a disk; we don't care.

And note that we can also chain those operations:

-- modify is get + put in one operations
send :: MonadState Invoice m => m ()
send = modify (\(Invoice _) -> Invoice Sent)

cancel :: MonadState Invoice m => m ()
cancel = modify (\(Invoice Sent) -> Invoice Cancelled)

program = do
  send
  if someCondition 
  then pay
  else cancel

I also want to look at the State from the frontend perspective. We might be getting even more off track, but this State makes me think of Elm architecture:

Model — the state of your application

View — a way to turn your state into HTML

Update — a way to update your state based on messages

If you squint, it does alter its behavior when its internal state changes. And even though the basic description of the pattern doesn't mention how the state changes, here the state is changed via messages, which is very oop.

You can see something similar in lustre, a framework for building web apps in Gleam:

... the state of the application is stored in a single, immutable data structure called the model, and updated as messages are dispatched to the runtime.

I've mostly used it via useAffReducer hook purescript-react-basic-hooks :

useAffReducer ::
  forall state action.
  state ->
  AffReducer state action ->
  Hook (UseAffReducer state action) (state /\ (action -> Effect Unit))

The most interesting part is at the end: state + (action -> Effect Unit)

Provide an initial state and a reducer function

Strategy

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Finally, a design pattern that can be replaced by plain functions.

val processPaymentStripe = (payment: Payment) => { ??? }

val processPaymentPayPal = (payment: Payment) => { ??? }

If we need to pass a payment processor, we can pass a function. That's it.

Template Method

Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

Either I'm getting tired, or this could be similarly replaced by plain functions. We can pass "steps" via functions. And if we need something more complicated, we can use one of the many approaches we discussed before.

val processPaymentStripe = (payment: Payment) => { ??? }

val processPaymentPayPal = (payment: Payment) => { ??? }

Friction in programming and why FP isn’t mainstream

Zelenya — Fri, 11 Jul 2025 15:10:58 +0000

The other day, I was working on a dashboard: I wrote the core of it in purescript in a couple of hours, and then I got stuck fiddling with css for half an hour. I gave up. I switched to the BE, added all the endpoints, logic, and queries; then I got stuck for another half an hour fiddling with schema derivation (for the api docs).

After that, I needed a break and finished the day. I had this bitter feeling — I’ve done a lot but haven’t finished the task, even though I was so close. I chewed on these annoying issues the rest of the day. I hate friction in coding. With all the meetings and firefighting, it’s already a challenge to find time to code and get into the flow. I don’t want to be interrupted by stupid little things.

Let’s talk about friction.

What does friction have to do with functional programming?

Disclaimer: Not saying that this is THE explanation for everything.

While I was chewing on this, I realized that functional programming is very guilty when it comes to friction. Regardless of the precise definition of FP, it’s intended to reinforce safer code and eliminate numerous bugs through types, abstractions, and functional design patterns. All of these come at a cost!

It’s the same as when you want to secure your app — you add auth, mfa, vpn, and so on. All of these add friction but have a purpose. At the same time, not all security frictions are created equal — some are extremely tedious. You know that feeling when you have to go FROM ssh’ing to production TO layers of vpns and tools?

Same with FP: some points of friction are intentional and others are not.

Types of friction

While outside of FP, it’s acceptable to focus only on the happy path and overlook the rest, it’s unacceptable in FP.

Imagine a function that fetches a role by user id (from postgres, for example). Somewhere in java land, you can say this function takes a user id and returns a role. Done. 1 input and 1 output. But it’s a lie. What about a database connection? It’s also an input. What if the user doesn’t exist or doesn’t have a role? There won’t be a role output.

In functional land, you have to be explicit about all the inputs (even a database connection), optional outputs, and even the fact that the function needs to access a database. All of this adds friction (for everyone who writes this function and uses it). But it also has a purpose. We want this. We don’t want bugs and errors at runtime.

Let’s label this “intentional friction”. It covers types (making them stronger and static), type classes, effects, and all the other things that make a programmer’s life better (but take time to master).

By inverse, this leaves us with “unintentional friction”. Vague error messages, flawed tooling, missing functionality or libraries, and everything that makes your blood boil.

Regardless of whether you agree with those categories, the line between the two is blurry. Many things that are not-100-percent-intentionally introduce the friction that eventually smoothes away. It could be small things or other ways of doing “familiar” things. Let’s take “looking for the right function” as an example. It’s a simple thing. However, if you are new to a language ecosystem and don’t know how to utilize dot-completion or tools like hoogle, it can break your flow: you stop coding, switch to browser to search for a function, get distracted, switch to check your email or slack notifications, and then you have to invest substantial effort to get back into coding (flow).

Friction breaks flow

I used to think that it’s just about steep learning curves or normal hurdles for beginners, but the problem is bigger — for me, it’s about all the things that can break the flow. And it sucks the most when various frictions interfere.

Let’s take an average java developer trying to pick up a new language. I think rust and haskell offer similar learning curves: a bunch of unfamiliar concepts, new things to worry about, different syntax, whatever.

But rust allows you to polish down the rough corners. For instance, unnecessary cloning, dynamic dispatch, and global state are generally discouraged; however, you can quickly use these and revisit your code later (in a second pass, for example).

Haskell doesn’t let you cut corners — it’s either a haskell way (one of many haskell ways) or the highway…

But it doesn’t mean that haskell is rigid or inflexible. Haskell is great for prototyping… When you know what you are doing. Because if you aren’t or return from a big break, it’s tough, not gonna lie. Even after all these years, when I return to haskell (or other fp language), I’m quite lost: how to glue the code? how to deal with errors? what to do about records? So many decisions and friction areas… I can hardly imagine how tough it must be for beginners.

That’s one of the reasons why people don't want to try new languages and technologies — they keep using what they know, even if it's not good, because they are already used to that friction. It's less scary than the new unknown frictions.

We talk about this a lot with one friend and occasionally wonder if it wasn’t a mistake for us to give up on spring. The framework isn’t perfect, but it eliminates most of the decision- and discovery-related friction, which is great.

In either case, there are still plenty of other frictions left, so…

What can we do?

Obviously, we all want someone to work on tooling, improve errors, write books, and reduce all sorts of friction. Usually, by “we”, we mean “someone else”. This won’t do! We should all take responsibility. I won’t ask you to contribute to open source or write books — I’ll ask you to start thinking and be more conscientious.

We should be more diligent with decision-making; for example, choose the right level of abstractions and fitting techniques. We shouldn’t always choose based on what we want to play with at the moment, but consider the longer-term consequences and the bigger picture. I can think of many examples from various communities of technical decisions that added unnecessary friction and had negative consequences for maintenance, adaptation, and the larger community. But those weren’t my decisions, and it’s not for me to criticize them right now.

I have a good and common example, which I am occasionally guilty of: strength of types.

Imagine we have an api that returns data for a role management dashboard. We need to add how many admins we have. How should we model it? It could be a string, an integer, an integer newtype, a refined type (for a natural number or something more precise — we might want to include or exclude 0). We can even bring it to the type level, so we can restrict some functions from compiling when the number is 0. What type is the best?

It might be tempting to have the strongest guarantees. But consider the volume of friction it will add for using the api, extending it, and onboarding new developers. Is it worth it?

Let’s say we chose the refinement type. What do we do if we start using a new storage library that doesn’t have the required instances for refinement types? What do we do if we need to add other numbers, for example, for super-admins and members? What if we want to ask a junior developer to update something small, and they have never heard of refinement types? Friction, friction, friction…

End

Coding in a state of flow is great, safe approachable code is great, and unintentional friction sucks.

Friction can be valuable. However, reducing unintentional friction enhances the flow and increases the likelihood that people will do the right thing. This requires a lot of work and awareness, and is easier said than done.

Looking at problems from a friction point of view can be fruitful, but remember it’s not a hammer that fits all.

With that being said, let’s extend the metaphor and look at two other things before wrapping up.

Appendix

Why haskell is not more popular?

A discussion about making haskell more popular arises multiple times a year. Every time with the same suggestions: better build tools, more learning resources and libraries, friendlier error messages and community, … and other things that reduce friction!pie chart

If you asked me what the haskell community should do to make haskell more popular, I could say focus on whichever of these reduces the most friction, and it would probably help. However, I believe the biggest friction is in people’s heads — haskell’s image. The perception of haskell magnifies its friction points.

For instance, most languages have mediocre tooling full of friction. Tooling is hard. But somehow, haskell tooling is perceived to be one of the worst. So, someone tries haskell, struggles with the tooling, and instead of persevering (as they would with other things), they give up because that was their expectations from the start. The meme lives and spreads.

So, unless haskell goes through a major rebranding, I don’t think it’s going to be popular. Bite-sized evolution isn’t enough.

And should haskell be popular? A whole other question…

What about llms?

On the contrary, I’m fascinated by how blunt llms deal with friction (so far). Changed some code and broke tests? Fuck it. Delete the tests. Need a slightly different function from what a library provides? Fuck it. Reinvent the wheel.

Remove or ignore anything that’s in the way. Zero friction tolerance.

One of the reasons some love llms and others hate them.

It is what it is.

Programming: Between industry and craft

Zelenya — Thu, 13 Mar 2025 03:48:00 +0000

Begin

I grew up around people drawing, sewing, building, gardening, etc. I admired crafts and trades — it’s cool when people create and design things by hand. And not just by hand, they put skills into it, attitude, sometimes pride or love. In a way, they go beyond “just doing something” and tap into art territory.

Years ago, when I stepped onto the IT path, I expected software engineers to be like craftsmen (like watchmakers or woodworkers, for instance). But recently, I realised I’m in the world of fast fashion.

Between industry and craft

I understand we’re a few industrial revolutions away from the original crafts. We’re in a start-up world with a low germination rate. We MUST be fast or someone else will eat our part of the cake.

I understand that modern watches and wooden furniture are rarely made by hand. Most apartments I’ve been to in Berlin looked like IKEA catalogues.

But I’ve seen beautifully crafted furniture and watches. My question is: Where is beautifully crafted code?

I’m guilty of this myself. Just look at the recent Gleam video: on multiple occasions, I leave shitty code and a promise to fix later. I wasn’t always like this. I used to be a better engineer just a couple of years ago. These days, I’m a “better engineer” but only for the business — I deliver faster and know what to focus on (as far as business is concerned). But why don’t I focus on the craft anymore? And it’s not just me — I notice this in others more and more.

Some of it is industry’s fault, but some is our own.

Not built to last

Memes about rewriting stuff to Rust are funny, but it’s not funny that we normalized rewrites for no major reason.

A watchmaker can service a pocket watch from 1887, a woodworker can service a mid-century modern chair, both are likely to enjoy the process, and the results will last for years. There is admiration for well made older (vintage) stuff.

And what do we do in our industry? We label code “legacy” the moment it leaves our local machine. What else do we do? We make “quick prototypes” that are never planned well but always end up in production… stay there for years… until we “rewrite it”. Of course, it rarely goes well and we never learn from our mistakes.

🖼️ 1st system with cut-corners that’s hard to extend barely scales vs. bloated and over-engineered second-system

There is hope: “Software you can love”

Not picking the right tool for the job

One might say: “But what if the language we picked for prototyping 5 years ago doesn’t scale any more?!” Is it? Is it the language’s fault? Maybe it’s a couple of small design decisions’ fault? Or your whole architecture’s? Or maybe, by Conway’s law, your entire organization is to blame?

Sure, there are right tools for the job.

For some jobs — for example, to cut some simple dowels — one can use a hand saw or a circular saw. It doesn’t matter much.

For some jobs — for example, to make a short straight cut — a skilled worker can do a better job with a hand saw than a junior with a jig saw.

For some jobs — for example, to make a long straight cut — using a hand saw is a stupid (or an impossible idea).

In other words, why are we wasting time brawling ****with go/java/haskell/whatever experts who pick their language of choice to do another web service? And when will we stop pretending there is no difference between writing a script to use once and maintainable code for years to come?

Not studying masters

If history books are true, apprenticeship with a master was a common practice. These days, it’s more of a luxury or exception, so some artisans defer to master studies. For example, when you want to improve drawing and painting skills, you can study Michelangelo drawings, Stepan Kolesnikoff’s use of color, Dean Cornwell’s compositions, and so on.

I don’t think bootcamps or seniors teaching juniors come anywhere close to that. The main goal of these is not to hone in software-engineering skills, it’s to get newbies to contribute good-enough code as soon as possible.

Also, every time I onboarded someone or was onboarded by someone, the senior person had to do a walk of shame either around architecture decisions, developer experience, or code practices. I've never seen a code base someone was proud of.

In good news, we have open source. It’s not easy to navigate and distinguish good from bad. But there are still some enthusiastic people who share good code and some are even happy to tutor others. Recently I’ve learned about The Architecture of Open Source Applications, which is pretty good. So, overall, a pretty hopeful area.

💡 Also, see Software Carpentry nonprofit

Not mastering tools

It takes time (sometimes a lifetime) to become great at anything. It’s an obvious fact to anyone who tried to learn and perfect something.

I don’t care about overpaid and over-self-confident juniors and middles. What worries me is that we promote the best, most valuable engineers out of their craft. Instead of using their hard-learned skills, they waste time sitting in meetings, writing documents nobody reads, or running after people trying to persuade other already-overloaded teams to do more things and improvements.

illusion of free choice: manager path and principal path

FP part

At this point, I was going to bring it back to functional programming, but whatever I wanted to say I already did in the video on values (Do your Values align with FP Values?) and on labels (On “superiority” of (functional) programming and other labels). So, let’s wrap it up.

End

You can say that it’s a bit unfair, because our industry is still young and immature, while people have been building furniture for thousands of years and watches for centuries…

But. We’re in the LLM age now. Regardless of what you think of llms, and if you think that they're going to replace all, some, or none of the jobs, they are here and they are part of the industry. So, how much more “new” code and values can we even contribute? In this month, year, or maybe two? Will we fly high into the craft of engineering or dive deeper into the fast-fashion industry?

If all of this sounds unfamiliar, you’re in the minority. If you are a part of the community or a company of craft-engineers, please share. I’ve heard of https://softwareyoucan.love/ and a few other exciting things. But would love to learn about more. This question is not for youtube engagement or anything like that, you can DM me anywhere else.

PureScript for Scala developers

Zelenya — Sat, 30 Nov 2024 04:29:38 +0000

This is mostly based on Haskell for Scala developers. If you’ve seen that one already, your most interesting sections are Row Polymorphism, Aff and Effect, and Tooling.

Once again, we’ll cover the main differences, similarities, major gotchas, and most useful resources. Consider this a rough map.

Basic syntax and attitude

Driving on the wrong side of the road

You have to get used to reading chains of operations “in the opposite direction”. Take this Scala code:

def foo(err: Error) = err.extractErrorMessage().asLeft.some

There are multiple ways to translate it to PureScript; the most straightforward:

-- read from right to left
foo err = Just (Left (message err))

Notice the order of functions and how we call functions (e.g., no parentheses after message). We can avoid even more parentheses by using the function application operator (f $ x is the same as f x):

-- read from right to left
foo err = Just $ Left $ message err

And we can avoid the rest of the plumbing by using function composition:

-- read from right to left
foo = Just <<< Left <<< message

Good news: You can reverse all of it and read from left to right if you want:

-- read from left to right to right
foo = message >>> Left >>> Just

-- read from left to right to right
foo err = message err # Left # Just

Bad news: more syntax to get used to. In the wild, you will see all of these styles and their mix.

Function signatures

Did you notice that functions had no type signatures?

💡 PureScript is pretty good at inferring types. But some error messages aren’t newcomer-friendly; the more explicit types you add — the better the error messages.

foo :: forall a. Error -> Maybe (Either String a)
foo err = Just $ Left $ message err

Note the explicit universal quantifier, forall (we’ll talk about this later).

The type signature goes above the function definition. It might feel awkward to connect a name to a type, but on the other hand, it allows you to focus on types (while ignoring the names).

bar :: User -> Maybe Password -> Either Error Credentials
bar user password = unsafeCrashWith "Not implemented"

💡 The unsafeCrashWith function is a cousin of ???.

Common error. Could not match type

Because in PureScript, we use parentheses differently from the way we do in Scala, the most common newcomer error is forgetting or misusing them. For example:

good = bar user (Just password)

oops = bar user Just password
                ^^^^

  Could not match type
    Function t0
  with type
    Maybe
  while trying to match type t0 -> Maybe t0
    with type Maybe Password
  while checking that expression Just
    has type Maybe Password
  in value declaration x
  where t0 is an unknown type

Technically, the compilation error is good: the foo takes a value with type Maybe Password, but we passed Just (which is a constructor, aka a function that takes a value of any type and returns Maybe of that type). However, in practice, it’s not that good — the actual error is that the programmer forgot parentheses and now passes Just and password separately (three arguments instead of two).

Names don’t matter?

Another slightly different but related thing is about common function names and operators.

There is map, but it’s more common to use operators: <$> and <#>.

x ∷ Array Int
x = (_ + 1) <$> [ 1, 2, 3 ]

x ∷ Array Int
x = [ 1, 2, 3 ] <#> (_ + 1)

There’s no flatMap, there bind and >>= (bind operator), and in general PureScript codebases (and developers) are more tolerable towards operators:

fetchUser someUserId >>= case _ of
  Right user -> withDiscount <$> findSubscription user.subscriptionId
  Left _ -> pure defaultSubscription

traverse is still traverse, and everything else you can pick up as you go.

Indentation

Unless you embraced Scala 3 and brace-less syntax, after years of curly brackets, it’s going to be hard to adjust to the indentation-based syntax, and it’s going to feel unnatural.

example ∷ UserId → Array SubscriptionId → Effect JSX
example userId subscriptions = do
  user <- fetchUser userId
  userInfo <- case user of
    Right u -> pure $ renderUser u
    Left e -> showError e *> mempty
  let
    hasActive _ = true
    subscriptionInfo =
      if hasActive subscriptions then renderSubscriptions subscriptions
      else mempty
  pure $ renderBox [ userInfo, subscriptionInfo ]

⌛ Effect is like IO, we’ll cover it later.

The minimal thing I can recommend here is to use a formatter, split things into smaller chunks, and when you are not sure, just push things left and right 😅

Basic concepts and fp

Function composition and Currying

In PureScript (like in Haskell), function composition and currying are first-class citizens. Both are powerful enough to make the code tidier and more elegant, as well as the opposite. You certainly have to practice to get better at writing and reading.

If you find some code confusing (or you wrote some code that the compiler doesn’t accept), try rewriting it: make it more verbose, introduce intermediate variables, add explicit types, and so on. It’s ok. It’s not a one-liner competition.

fetchUser someUserId >>= subscription
  where
  subscription (Right user) = userSubscription user
  subscription (Left _) = pure defaultSubscription

  userSubscription :: User -> Effect Subscription
  userSubscription user = withDiscount <$> findSubscription user.subscriptionId

💡 where declarations are a convenient way to scope things within a function.

Also, if it feels like the number of arguments is getting out of control (or you miss having values and types right next to each other), try introducing records.

userInfo :: UserId -> SubscriptionId -> BundleServiceUrl -> Cache -> IO UserInfo
userInfo u s b c = unsafeCrashWith "Not implemented"

type Config = { api :: BundleServiceUrl, cache :: Cache }
type RequestIds = { userId :: UserId, subscriptionId :: SubscriptionId }

userInfo2 :: Config -> RequestIds -> Effect User
userInfo2 c { userId, subscriptionId } = unsafeCrashWith "Not implemented"

Note how we pattern match in the case of RequestIds, we’ll touch on records later.

Purity

When writing PureScript, you cannot just use a quick var or a temporary println. Depending on your experience and workflows, it can be or not be a big deal.

You can start by getting familiar with Debug (spy):

userSubscription user = 
    withDiscount <$> findSubscription (spy "test" user.subscriptionId)

💡 See Debugging without a “real” debugger.

Modules, Imports, and Exports

There are no classes and objects.

You might quickly run into a problem with naming conflicts:

import Data.String
import Data.List 

foo :: Int
foo = length "abc"
--    ^^^^^^
-- Conflicting definitions are in scope for value length from the following modules:
--   Data.List
--   Data.String

You have to get into a habit of using qualified imports:

import Data.String as S -- stylistic choice
import Data.List as List

foo :: Int
foo = S.length "abc"

Some libraries suggest the users to qualify their imports; some people prefer to qualify all their imports, but, at the end of the day, it’s a personal/team choice. Start using qualified imports for collections (containers) and strings, and see how it goes.

There are no access modifiers (no private or public keywords). You can either export everything from the module (in the module declaration on the top):

module Test where

Or export (aka make public) only specific functions, data types, type classes, etc.:

module Test
  ( publicMethod
  , PublicConstructor
  , class Example
  ) where

Types

Product Types

PureScript records correspond to JavaScript objects. Here is a function that takes some user model and bumps their score:

bumpCounter
  :: { userId :: String, counter :: Int }
  -> { userId :: String, counter :: Int }
bumpCounter user = user { counter = user.counter + 1 }

bumpCounter { userId: "test", counter: 10 }
-- { counter: 11, userId: "test" }

We can make it tidier by introducing a type alias:

type UserScore = { userId :: String, counter :: Int }

bumpCounter :: UserScore -> UserScore
bumpCounter user = user { counter = user.counter + 1 }

We can also use various combinators to work with records:

bumpCounter :: UserScore -> UserScore
bumpCounter = Record.modify (Proxy :: _ "counter") (_ + 1)

In this case, the code is a bit longer, but imagine chaining and using multiple operations like unions, deleting and renaming fields, etc.

🍪 There is an upcoming alternative syntax for this — using @ (Visible type applications) instead of Proxy …

Sum types

Sum types (aka Tagged Unions) shouldn't be too surprising. Those are declared via data and can be deconstructed through pattern matching:

data Role = Member UserId | Admin

hasRights :: Role -> Boolean
hasRights role = case role of
  Member (UserId "special") -> true
  Admin -> true
  Member _ -> false

Newtypes

Newtypes are introduced with the newtype keyword:

newtype UserId = UserId String

Row Types

It’s one of the coolest PS features but also one of the main sources of confusion and errors for newcomers.

UserScore is a record and we can make a value of the type UserScore.

type UserScore = { userId :: String, counter :: Int }

value :: UserScore
value = { userId: "test", counter: 10 }

It has two fields: userId of type String and counter of type Int.

On the other hand, those are rows (note the parentheses):

type ClosedRow = ( userId :: String, counter :: Int )

type OpenRow r = ( userId :: String, counter :: Int | r )

Let’s not worry about the difference right now. A row of types represents an unordered collection of named types. Rows are not of kind Type. Rows cannot exist as a value.

🌯 Kinds are types of types. It’s what distinguishes List from List[Int] (among other things). You can’t create a value of just List of just Option, but you can create values of List[Int], Option[String], and so on.

Row types unlock many typelevel operations. We won’t go into details here.

The simplest application of rows:

type UserScore = (userId :: String, counter :: Int)

type UserDTO = { createdAt :: DateTime | UserScore }

type UserResponse = 
  { age :: Int, subscriptions :: Array SubscriptionId | UserScore }

enrichUser :: UserDTO -> Effect UserResponse
enrichUser { userId, counter, createdAt } = unsafeCrashWith "???"

Common error. Could not match kind Type with kind Row Type

We can add rows to get a row, pass row types, return them, whatever. Because it’s new for many, there is this one typelevel error that needs attention:

Could not match kind

  Type

with kind

  Row Type

It means, you passed a type (usually, representing a record) where the row type was expected.

For example, there is this type alias for declaring components that that takes a row:

type FFIComponent props = ...

We pass it props we care about as a row type:

type ButtonProps =
  ( asChild :: Boolean
  )

buttonExample :: FFIComponent ButtonProps

But if we pass a record by accident, we get that error:

type ButtonPropsOops =
  { asChild :: Boolean
  }

buttonExample :: FFIComponent ButtonPropsOops

Could not match kind

  Type

with kind

  Row Type

🌯 Records and rows are related but different concepts. Once again remind yourself about kinds. If you’ve conquered F[_], you can conquer row types.

Polymorphism

What in the Java world is called generics, in the PureScript world is called parametric polymorphism.

-- a is a type parameter
filter :: forall a . (a -> Boolean) -> Array a -> Array a

In PS, polymorphic functions require an explicit forall (to declare type variables before using them). Other than that, in general practice, it’s not that different.

Row Polymorphism

We can rewrite the bumpCounter function to make it more polymorphic (more generic):

bumpCounter
  :: forall r
   . { userId :: String, counter :: Int | r }
  -> { userId :: String, counter :: Int | r }
bumpCounter user = user { counter = user.counter + 1 }

For simplicity, the userId isn't used in the function body.

r is a row of types (zero or more of some other rows that we don't care about). In other words, the function takes (and returns) any record that has a field userId with type String, a counter with type Int, and whatever else.

To make it more interesting, we can change the type of the counter

processCounter
  :: forall r
   . { userId :: String, counter :: Int | r }
  -> { userId :: String, counter :: String | r }
processCounter user = user { counter = show (user.counter + 1) }

In either case, we can pass any record that fits the shape, including existing UserScore:

processCounter { userId: "x", counter: 10 }
-- { counter: "11", userId: "y" }

processCounter { userId: "y", counter: 10, payments: [ 1, 2, 3 ], whatever: 2 }
-- { counter: "11", payments: [1,2,3], userId: "y", whatever: 2 }

Type classes

Unlike Scala, PureScript has built-in type classes — there's (guaranteed to be) at most one instance of a type class per type.

Good news: No need to worry about imports!

There are other things you’ll have to worry about at some point, but don’t worry about them right now. You can start by declaring the type class instances next to the type class (in the same module) or next to the data.

Sometimes, when you need a new (custom) instance, you can introduce a newtype:

-- User is declared in some other module

newtype InvalidUser = InvalidUser User 

instance Arbitrary InvalidUser where
  arbitrary = do
    userId <- UserId <$> arbitrary
    subscriptionId <- SubscriptionId <$> arbitrary
    pure $ InvalidUser { userId, subscriptionId }

And remember that you can get a lot for free with deriving.

Deriving

In PureScript, you can derive quite a lot.

newtype JwtAccessToken = JwtAccessToken String

derive instance Newtype JwtAccessToken _
derive newtype instance Eq JwtAccessToken
derive newtype instance Show JwtAccessToken
derive newtype instance ReadForeign JwtAccessToken
derive newtype instance WriteForeign JwtAccessToken

Meta Programming

The most common way to generate boilerplate in PureScript is generic programming. Not java generics. Even more generic generics!

💡 That’s one of the reasons not to refer to parametric polymorphism as just (java) generic types.

Generic programming

Generic programming comes in different shapes and forms. PureScript has a built-in Generic class is the purescript-prelude library. The most common usage is deriving show instance for sum types:

import Data.Generic.Rep (class Generic)
import Data.Show.Generic (genericShow)

data Role = Member UserId | Admin

derive instance Generic Role _
instance Show Role where
  show x = genericShow x

🌯 Generics are kinda like shapeless.

Best practices (and concepts)

Abstractions and type classes

It’s important to know your type classes. Those are a must: Functor, Applicative, Monad, Semigroup, Monoid, Foldable, Traversable, and Alternative. If the library has a functionality that can be provided by one of those (e.g., smooshing or mapping things), it’s likely that it’s going to be provided and won’t be very documented.

Addition and multiplication come via Semirings; boolean operation come via HeytingAlgebra.

Aff and Effect

Instead of one IO data type, there are two, Aff and Effect.

💡 Both can be used with the do notation (for comprehension).

Aff is for asynchronous computations, Effect is for synchronous, and they can’t be mixed. If you know of function coloring, you should know why; and if not — let’s look at examples.

💡 A reminder: JavaScript is single-threaded and achieves concurrency via asynchronous operations and event loop.

So, for example, api call has to be asynchronous. We don’t want to block everything waiting for response:

getUserProducts :: Config -> UserId -> Aff Product
getUserProducts { apiUrl } (UserId id) = do
  -- returns Aff Response
  { status, json } <- fetch (apiUrl <> "/users/" <> id) { method: GET }
  case status of
    -- fromJSON :: forall json. ReadForeign json => Aff Foreign -> Aff json
    200 -> fromJSON json
    -- throwError :: forall e m a. MonadThrow e m => e -> m a
    other -> throwError $ error $ "Unexpected response status: " <> show other

Button click, on the other hand, should respond (have an effect) right away:

{ variant :: String
, size :: String
, onClick :: SyntheticEvent -> Effect Unit 
}

We can’t mix the two, but we can convert one to another. It’s easy to make a synchronous computation (Effect) asynchronous (Aff). For example, we can use liftEffect to add something to our async call:

-- This is for illustration purposess only
syncLog :: String → Effect Unit
syncLog = log

getUserProducts :: Config -> UserId -> Aff Product
getUserProducts { apiUrl } (UserId id) = do
  { status, json } <- fetch (apiUrl <> "/users/" <> id) { method: GET }
  -- This is where we transform Effect to Aff
  liftEffect $ syncLog "This is sync"
  case status of
    200 -> fromJSON json
    other -> throwError $ error $ "Unexpected response status: " <> show other

And what if we want to make an api call on a button click? Make an asynchronous computation (Aff) synchronous (Effect)? The easiest thing to do is to fork the computation:

setUserProfile :: Aff Unit
setUserProfile = do
  result <- try $ apiClient.getUserProducts userId -- Aff
  liftEffect case result of
    Right user -> setUserProfile user -- Effect
    Left error -> showError error     -- Effect

button
  { variant: "ghost"
  , size: "md"
  , onClick: handler preventDefault $ launchAff_ setUserProfile *> log "Clicked"
  }

On click, it’s going to asynchronously make an api call (which then depending on result either sets some user info or shows an error) but also (concurrently) log a message to the console. No blocking.

Note that we throw away the fiber handle. This isn't always desirable. In this case, we don’t care about the result, only side effects, so it's ok.

The other option is to use something like the useAff hook or useAffReducer to deal with async stuff. For example, button sync updates some state/model, and then that triggers some async action.

setUserId :: UserId -> Effect

useAff userId do
  result <- try $ apiClient.getUserProducts userId
  liftEffect case result of
    Right sub -> setUserProfile user
    Left error -> showError error
  pure unit

button
  { variant: "ghost"
  , size: "md"
  , onClick: handler preventDefault $ setUserId someUserId *> log "Clicked"
  }

Failure handling

The situation is not much better than in Scala.

Option is called Maybe.
Error is the the type of JavaScript errors that lives in Effect.Exception (cousins of Throwable). You can throws those via throwException into ~~IO~~, I mean Effect
There is also MonadThrow and MonadError that, for example, have throwError to throw and try to catch errors (for instance, in Effect and Aff).

Organizing code

There are options for all:

It’s common and convenient to use plain data types and pass things around via records.
There are mtl classes (see the transformers library).
There is yoga-om — Om data type (Om ctx errs a) has a context, potential errors, and the value of the computation.

Tooling

You know how you have Scala and Java code, than use sbt (or some other build tool), and it all becomes one bytecode mess that you run or deploy?

In PureScript world, we can’t get away with using just one tool.

We use spago (a PureScript package manager and a build tool) to run and test pure PureScript projects, as well as turn PS code into JS code. For example, we can run spago test to run our PS tests.

⚠️ Note that, there is legacy spago and spago@next.

But we can’t get far with PureScript alone in the modern web. So.

We use dependency/package managers, such as npm or yarn, to install JS packages (both globally and locally). For example, we can install and use react in our PS project.

We also need a bundler — another build tool that let’s us bundle everything together (into a single executable file or few files), optimize JavaScript, and produce production files when we are ready to ship. There are multiple options here; the most popular are esbuilt, webpack, and parcel (see spago tutorial).

💡 Note that spago has a bundle command to bundle the project. Maybe that’s enough for your use case.

Bad news: this is just a tip of the iceberg of tools.

Good news: no need to worry, usually all of it is going to be hidden from you behind npm or yarn scripts. Often, you can get away with limiting your vocabulary to npm install, npm start, npm deploy, or something along those lines.

Editor

You can use Intellij with PureScript plugin or any other editor via purs ide (an IDE server that comes with compiler) or PureScript language server (built on top of IDE server).

💡 For details, see the dedicated documentation section on Editor support.

Don’t expect java-level IDE support.

Libraries

Searching for functions

If you’re looking for some function or some data type, you can still use dot completion on a module, but if you don’t know where to look, try pursuit.

You can also use typed holes, to get compiler suggestions (it also works in the editor).

foo = ?custom someUserId >>= subscription

Hole 'custom' has the inferred type

  UserId
  -> Effect
       (Either t0
          { subscriptionId :: SubscriptionId
          , userId :: UserId
          }
       )

You could substitute the hole with one of these values:

  TestTypes.fetchUser         :: UserId
                                 -> Effect
                                      (Either Error
                                         { subscriptionId :: SubscriptionId
                                         , userId :: UserId
                                         }
                                      )

You can get help with types as well:

userSubscription (user :: ?What)

Hole 'What' has the inferred type

    { subscriptionId :: SubscriptionId
    , userId :: UserId
    }

  in the following context:

    subscription :: Either Error
                      { subscriptionId :: SubscriptionId
                      , userId :: UserId
                      }
                    -> Effect Subscription
    user :: { subscriptionId :: SubscriptionId
            , userId :: UserId
            }
    userSubscription :: { subscriptionId :: SubscriptionId
                        , userId :: UserId
                        }
                        -> Effect Subscription

Standard library

Standard library (std module) is called Prelude (the Prelude module comes via the purescript-prelude library). It has to be explicitly imported.

import Prelude

This, for example, imports common type class methods, such as <$> and pure.

Searching for libraries and FFI

If you’re looking for a library (a package), you can still poke around pursuit. But if you can’t find anything, there is always a see of JS libraries that can be used from PS. We do this via The Foreign Function Interface (or FFI, for short).

We’ve demonstrated this in the PureScript + Shadcn video.

Searching and managing dependency versions

You don’t have to search for specific library versions compatible with other libraries. There are lists of package versions that build together, called a package set.

Reproducible builds are one of the core principles of spago.

Books and other resources

PureScript website and Getting Started Guide.
Free PureScript By Example Book.
Blog posts: Thomas Honeyman Articles, PureScript: Jordan’s Reference, Mark’s alethic.art.
Community: PureScript Discord or PureScript Discourse.
Playground: try.purescript.org

On “superiority” of (functional) programming and other labels

Zelenya — Wed, 30 Oct 2024 03:32:26 +0000

I'm not going to lie. There was a time when I used to believe that. I was convinced I only wanted to work with functional programmers because functional programmers are better programmers.

And I know others still think that way. Likewise, some believe that C programmers are better than Rust programmers, devs that use AI tools are better than others, and vice versa.

Reaching that kind of conclusion takes only a few logical (mis)steps. In my case, it was like this:

fp and good code

I care a lot about writing good, reliable software

I consider coding a craft. I want to be productive and write maintainable code that delivers value. I don’t want to do a sloppy job, introduce preventable bugs or tech debt, and get woken up in the middle of the night.

I know that functional programming is a great tool for that

I have years of experience with functional and non-functional languages and suck at the latter. The other day, it took me 3 pull requests (3 deployments to production) to ship a trivial change to a Ruby codebase. Maybe that’s a special case. However, I’m sure I write and read Scala code better and faster than Ruby, PureScript than TypeScript/JavaScript, and so on.

This misdirected me to a naive conclusion: A programmer who cares about writing good, reliable software should use functional programming.

In other words, if someone doesn’t use FP, they don’t care. Right? Cause, why someone interested in writing good code chooses not to? Why are they choosing to use inferior tools and do a sloppy job?

not-fp and good code

Turns out “I” am not the “programmers”. And there are other programmers (and other people).

Just because a tool helps me — doesn’t mean it helps others. People are different, environments are different, abilities are different, and so on.

For instance, some people are good at holding many things in their working memory and switching between tasks, but I’m not. When working on something, I easily get distracted by slack messages, switch contexts, and — poof — completely forget what I was doing. I need functional programming — I need small independent blocks that I can quickly joggle and work with.

Also, people have different values and preferences. Take, for example, abstraction and expressiveness (those are different concepts but related enough). There is plenty of room for choice here. I believe that a typical functional dev is leaning to a greater extent on both. Extracting abstractions, reusing functionality, and refactoring data types, among other things, are completely different experiences in Rust and Haskell. Similarly, handling optionality, errors, lists, and async programming in Scala and Java…

If you aren’t familiar with those or don’t care for them, the ordinary opinionated programming thing is generics. There are Go, Java generics, and Zig comptime, and there are plenty of programmers who prefer and are productive with each one.

fp and bad code

So, there are functional programmers who write good, reliable software, and there are other programmers who write good, reliable software. Which is one thing.

The other thing is that if we deceive ourselves with generic statements (like I did), it’s easy to forget that there are functional programmers who don’t write good, reliable software.

The reason I’m chewing on this topic is this other extreme. I haven’t noticed this in my earlier days, but it turns out that quite a number of FP devs just offload their thinking (or not thinking) onto functional programming, tangential theory, and other standards.

It’s easy to fall into this kind of attitude: FP is so formal and mathematical and whatever, so let’s just over-rely on it and don’t reason ourselves. You know? The people who seriously believe that “if it compiles, it works” or “if it’s according to the specification, it’s perfect”.

Totally shattered my devotion to functional programmers.

In other words, if someone is doing X, it doesn’t mean they have values associated with X, or X can imply any values in the first place.

How to make a quick and pretty PureScript web app

Zelenya — Tue, 01 Oct 2024 00:10:54 +0000

In theory, I’m a full stack developer, but in the last year or two, I’m on the backend, staring at the code, terminal, and google docs — not tinkering much with UIs (or anything like that).

But some weeks ago, I built a prototype for a PureScript web app and want to showcase what I did in a couple of hours… I’ve pretty much copy-pasted all of this and spent most of the time scaffolding all the configs and dependencies.

The idea is to demo how quick it is to have something nice running with PureScript (not single-handedly) and share a minimal interesting project that can be used to play around with PureScript (as well as save myself and other time in the future)

Overview

For this project, I used PureScript + React + Tailwind css + shadcn/ui components. I assume you’ve heard of the first two (if not, see PureScript overview). The other two are blessings for the copy-paste-driven development.

Tailwind is a CSS framework that provides classes for styling components:

<div class="font-medium">
  <div class="text-sky-500 dark:text-sky-400">
    Some text
  </div>
  <div class="text-slate-700 dark:text-slate-500">
    More text
  </div>
</div>

Honestly, this extra noise in the markdown was scaring me away before. I decided to try it (for the first time) because I heard it’s supposed to be quite composable and also that’s what shadcn uses.

From the shadcn website: “Beautifully designed components that you can copy and paste into your apps”. That’s all I ever wanted.

Let’s see the code

The purescript-shadcn-tailwind-copypaste repository also demos a few other things:

routing with routing-duplex and web-router
ergonomic FFI with undefined-is-not-a-problem
copy-paste with web-clipboard
basic usage of fetch, fetch-yoga-json, yoga-json
primitive authentication with local storage (web-storage)
service/handler pattern

Scala is one of the best ways to learn Haskell

Zelenya — Tue, 17 Sep 2024 04:52:34 +0000

First, a reminder: You DON’T NEED TO learn Haskell — that’s not what I want to talk about. I genuinely want to talk about learning Haskell, and Haskell specifically — not functional programming.

The following might interest you if you want to get into Haskell for personal reasons (if you think it’s cool, well-paid, or whatever). If not — idk…

📹 Hate reading articles? Check out the complementary video, which covers the same content.

Haskell is tough to learn

People constantly report about their frustration with learning Haskell. Working professionals already have some experience and expectations from using a language. For example, a Java developer can pick up Go and carry over most of their knowledge, while Haskell can crash all their assumptions about programming.

How is it that I know how to connect to databases, serve http, make decent uis, or all the other cool stuff — but then I can’t simply print a variable in Haskell or get the value out of some box?!

We can blame it on education, learning resources, skills, or whatever… but the thing is: there are too many things to joggle in Haskell. Imagine a Java developer. If they want to learn Go, they need to learn new concurrency mechanisms, pay some attention to syntax (still C family), unlearn inheritance, resist using abstract factories, get used to a couple of other things, and that’s pretty much it (I know, it’s a bit oversimplified).

But then imagine them learning Haskell — now there are more unfamiliar faces: laziness, purity, IO, type classes, immutable collections, entirely different syntax, etc. — and see them getting crashed by the balls.

One step at a time

Scala is a multi-paradigm language that allows you to tame this gap and learn one ball at a time.

The most stereotypical example is starting with Scala as a better Java (a bit of new syntax and constructs) and then building on top of that: introducing immutable collections, other immutability, purity, type classes, IO, and so on.

If you don’t know how to do something in a “functional” way, do what you know until you learn how: write a for loop, print in the middle whatever you want, throw an exception — it’s your life, don’t let anyone tell you what to do. You’ll eventually figure it all out.

And then, at some point, you “just” get familiar with Haskell’s syntax and laziness, and you're good to go. It’s quite enough to contribute at a middle or even senior level. Yeah, there is still plenty to learn to be proficient. There is always going to be something to learn with Haskell.

The best part about this flow is it can be done at a personal pace. For instance, you can be productive for years with basic Scala + immutability + ADTs without fully grokking type classes and using IO, then grok type classes and be productive with that, and so on… And if you want to deeply understand the concept before moving to the next one, you can do it too. Good luck doing that with Haskell directly.

There is a reason that Scala’s logos is a ladder. (It’s a joke; please don’t quote me on that).

No silver bullet

This way of learning Haskell is not a silver bullet — it’s just one path, which I think is worth considering. It comes naturally to some, judging by dozens of people I know who learned Haskell this way. But might seem unintuitive or even stupid to others.

Sure, if you’re taking your time studying Haskell in school, it’s a whole different thing. But if you’re already working in the industry, want to invest your free time into learning Haskell and Haskell books and courses don’t work for you (because they’re either too long and tedious or jump over the concepts, hand-wave, and tell you to wait for explanation in later chapters), consider the Scala path.

Also, Scala is just an example I’m confident with. I guess learning via OCaml might be close enough. I can’t vouch for it — I don’t know anyone who learned Haskell via OCaml (not because they don’t exist, but because they are out of my bubbles). Something like Gleam or Roc could be good as well…

Also, if you have Rust experience, you can jump to Haskell right away because the gap is smaller. But I wouldn’t recommend learning Rust just to learn Haskell, though…

And if you come with a JavaScript background, PureScript or Elm is a good pitstop before trying Haskell.

You have to decide for yourself.

A metaphor

Look at it this way. Imagine you want to learn to be an artist.

You can start painting (with whatever medium), where you must joggle shapes, values, colors, light, and shadow. I’m not even talking about other fundamentals (like subject, composition, or perspective). This is just the minimum, and it could already be overwhelming.

That’s why lots of people start with something like drawing with charcoal and restrict to basic shapes and values. For starters, you don’t have to worry about colors or try to understand shadows — just treat everything as shapes. And later, add perspective, light, complex shapes, or whatever you like.

And, of course, some people directly pick up painting without drawing experience (and don’t get overwhelmed).

Scala for Haskell developers

Zelenya — Tue, 27 Aug 2024 03:18:50 +0000

So, you have some Haskell experience and want (or need to) write Scala code. The following is a rough map with the main differences, similarities, major gotchas, and most useful resources.

📹 Context: subjective-production-backend experience, web apps, microservices, shuffling jsons, and all that stuff.

🥈 Scala 2 and Scala 3. In 2024, some projects still haven’t upgraded to Scala 3. Unless it includes the company you’re working for, you don’t need to worry about Scala 2.

Most of the stuff here applies to both; we lean towards Scala 3 and explicitly describe both if there is a big difference.

📹 Hate reading articles? Check out the complementary video, which covers the same content.

Basic syntax and attitude

You should pick up syntax by yourself, but here are the things you should conquer first:

Driving on the wrong side of the road

Forget about reading code from right to left. You’re not in Haskell land.

-- read from right to left
foo err = pure $ Left $ errorMessage err

Scala, similar to Java, often chains from left to right:

// read from left to right
def foo(err: Error) = err.errorMessage().asLeft.pure[IO]

At the same time, you will often encounter code like this:

def fee(err: Error) = (Left(err.errorMessage())).pure[IO]

def faa(err: Error) = IO.delay(Left(err.errorMessage()))

The order and syntax are different due to using methods and not functions.

Methods

def fee(err: Error) = (Left(err.errorMessage())).pure[IO]

def faa(err: Error) = IO.delay(Left(err.errorMessage()))

errorMessage is a normal method on a class (Error) — typical OOP.
Left is a constructor (Either).
delay is a static method on a singleton object (IO).
pure is an extension method (for anything with an Applicative).

The first variant particularly relies on extension methods to get this consistent syntax:

def foo(err: Error) = err.errorMessage().asLeft.pure[IO]

It’s not as complicated as it might appear.

Just one more thing.

Functions and methods

In Scala, there are Functions:

val function1: String => Int = _.length()

And we can convert methods to functions:

class Tmp:
  def method(s: String): Int = s.length()

val function2: String => Int = Tmp().method

Tmp().method("test") // 4
function1("test")    // 4
function2("test")    // 4

🥈 In Scala 2, it’s slightly more verbose: new Tmp().method _

Even if you miss functions, get used to declaring methods (and when needed use them as functions). The transitions are so seamless that I usually don’t think about them. And if you are new to OOP, good luck. See the official docs, write/read code, and give it some time.

Function and method signatures

Functions are expressions and their types can be (often) inferred:

val function2 = Tmp().method

val nope = _.length()

When you declare a non-zero-arity methods, you can’t omit the types of parameters:

def method(s: String): Int = s.length()

While the return type is optional (it’s usually a bad practice):

def method(s: String) = s.length()

The unit return type (doesn’t return any value):

def helloWorld(): Unit = {
  println("Hello, World!")
}

⚠️ It’s not functional but something you might encounter.

In Scala, we can use default parameter values, named arguments…

def helloWorld(greet: String = "Hello", name: String = "World"): Unit = {
  println(s"$greet, $name!")
}

helloWorld(name = "User")

and multiple paramater lists:

def helloWorld(greet: String)(name: String, alias: String): Unit = ???

💡 The ??? is almost like undefined (only it’s not lazy and not type-inference friendly).

Names don’t matter?

Scala community has less tolerance for operators.

def foo(userId: UserId): IO[Result] = for 
  user <- fetchUser(userId)
  subscription <- findSubscription(user.subscriptionId)
yield subscription.fold(_ => defaultSubscription, withDiscount)

There’re some in DSLs, but there no <$>, there is map; there is no >>= or <*> , but there are flatMap and mapN:

"1".some.flatMap(_.toIntOption) // Some(1)

(2.some, 1.some).mapN(_ + _)    // Some(3)

There is traverse but no mapM, see either traverse or foreach. This depends on the library and we’ll talk about this later.

💡 Friendly advice: also get familiar with flatTap, tap, and alike.

Basic concepts and fp

Function composition

Function composition isn’t common. There are ways to do it (e.g., there is compose and andThen), but nobody does it (e.g., currying and type inference aren’t helping).

Currying

Similar here. You can curry a function but rarely want to or need to.

def helloWorld(greet: String, name: String): String =
  s"$greet, $name!"

val one = helloWorld.curried // : String => String => String
val two = one("Hello")       // : String => String
val res = two("World")       // Hello, World!

Because, for instance, you can partially apply “normal” scala functions/methods:

val two = helloWorld("Hello", _) // : String => String
val res = two("World")           // Hello, World!

On a relevant note, get familiar with tuples and function parameters (and how they play and don’t play together).

val cache = Map.empty[String, Int]

def foo(t: (String, Int)): Int = ???
// This works in Scala 2 and Scala 3
cache.map(foo)

def bar(s: String, i: Int): Int = ???
// This works only in Scala 3
cache.map(bar)

🥈 In Scala 2, there are cases when you need to be explicit (see tupled) and use more explicit parenthesis.

Purity

Scala is not Haskell. For example, you can add a println ✨ anywhere ✨.

You should use a linter or an alternative way to enable recommended compiler options for fp scala. For example, sbt-tpolecat.

Laziness

If you want a lazy variable, see lazy val. If you want a lazy list, see standard library LazyList or alternatives in other libraries (for example, fs2).

However, if you want another kind of laziness: make some thunks, write recursion, or whatever, it’s not that straightforward — beware of stack (safety).

See cats-effect IO and ZIO (we cover IO later).
See cats Eval data type (or other alternatives).
See @tailrec.
See tailRecM and other ways to trampoline.

⚠️ Beware of the standard library Futures.

Modules and Imports

Good news: Scala has first-class modules and you don’t need to qualify imports or prefix fields. And you can nest them!

class One:
  class Two:
    val three = 3

Bad news: you have to get familiar with classes, objects, companion objects, and how to choose where to put your functions.

Terrible news: you still have to worry about imports because they can affect the program’s behavior (we talk about this (implicits) later).

Standard library

Scala comes with a bundle of immutable collections (List, Vector, Map, Set, etc.). In the beginning, pay attention, ensure that you are using immutable versions, and stay away from overgeneralized classes, like Seq.

Also, be open-minded — in many cases, Scala has better methods/combinators than you might expect.

Equality

In Scala 2, multiversal equality was hell for me:

4 == Some(4)

In Scala 3, it’s not allowed:

3 == Some(3)
^^^^^^^^^^^
Values of types Int and Option[Int] cannot be compared

But out of the box, you can still shoot yourself:

case class A(i: Int)
case class B(s: String)

A(1) == B("1") // false

You can disable it with the strictEquality compiler flag:

import scala.language.strictEquality

case class A(i: Int) derives CanEqual
case class B(s: String) derives CanEqual

A(1) == A(2) // false

A(1) == B("1")
// ^^^^^^^^^^^
// Values of types A and B cannot be compared

Types

Type inference

When I was thinking about this guide a couple of years ago, I thought it was going to be the beefiest chapter. Luckily, Scala 3 is pretty good at type inference.

And yeah, it’s still not Haskell and sometimes you need to help the compiler:

val id = a => a
// error:
// Missing parameter type
// I could not infer the type of the parameter a

val id: [A] => A => A = 
  [A] => a => a

val idInt = (a: Int) => a

It could come up during refactoring. For example, this is fine

case class Foo(s: Set[Int])

val f1 = Foo(Set.empty)

And this doesn’t compile (empty should be helped):

case class Foo(s: Set[Int])

val s1 = Set.empty
val f1 = Foo(s1)

But once again, don’t worry, it’s mostly good. For instance, using monad transformers used to be type-inference hell — in Scala 3, it’s fine:

def foo(userId: UserId): IO[Result] = (for 
  user <- EitherT.right(fetchUser(userId))
  subscription <- EitherT(findSubscription(user.subscriptionId))
  _ <- EitherT.right(IO.println("Log message"))
yield withDiscount(subscription)).valueOr(_ => defaultSubscription)

🥈 If you’re on Scala 2, you might need to get in the habit of annotating intermediate values. And just be gentler to the compiler!

Union types

Union types are great.

But even union types need an occasional help:

def foo(userId: UserId): EitherT[IO, MyError, String] = for 
  x <- thisThrowsA() // At least one needs to be explicitly casted
  y <- thisThrowsB().leftWiden[MyError]
yield "result"

case class NotFound()
case class BadRequest()

type MyError = NotFound | BadRequest

def thisThrowsA(): EitherT[IO, NotFound, String] = ???
def thisThrowsB(): EitherT[IO, BadRequest, String] = ???

Product types

Product types aren’t bad either. You use case classes:

case class User(name: String, subscriptionId: SubscriptionId)

val user = User("Kat", SubscriptionId("paypal-7"))

user.name // Kat

Which come with a copy method to modify fields:

val resu = user.copy(subscriptionId = SubscriptionId("apple-12"))

And 95% of the time it’s enough. When you need to, you can use optics (for example, via monocle) or data transformations via libraries like chimney.

Sum types

Sum types are a bit more awkward.

In Scala 2, we used to model sum types with sealed trait hierarchies:

sealed trait Role
case class Customer(userId: UserId) extends Role
case class Admin(userId: UserId) extends Role
case object Anon extends Role

We used to do the same for enums (with some boilerplate) or use the enumeratum library.

sealed trait Role
case object Customer extends Role
case object Admin extends Role
case object Anon extends Role

🤔 enumeratum was made as an alternative to Scala-2-built-in Enumeration.

In Scala 3, we have nicer enums:

enum Role:
  case Customer, Admin, Anon

Which are general enough to support ADTs:

enum Role:
  case Customer(userId: UserId)
  case Admin
  case Anon

Note: Some still use enumeratum with Scala 3.

Newtypes

Newtypes are even more awkward.

In Scala 2, we used Value Classes:

class SubscriptionId(val value: String) extends AnyVal

Scala 3 has Opaque Types:

opaque type UserId = String

But the thing is, by themselves, both aren’t ergonomic and require boilerplate. So, you need either embrace manual wrapping, unwrapping, and other boilerplate OR use one of the many newtype libraries.

Pattern matching

There shouldn’t be anything too surprising about pattern matching (just watch out for parenthesis):

def getName(user: Option[User]): String = 
  user match {
    case Some(User(name, _)) if name.nonEmpty => name
    case _ => "anon"
  }

However, you should know where pattern matching comes from. Scala allows pattern matching on objects with an unapply method. Case classes (like User) and enums (like Role) possess it out of the box. But if we need to, we can provide additional unapply methods or implement unapply for other classes.

class SubscriptionId(val value: String) extends AnyVal

object SubscriptionId:
  def unapply(id: SubscriptionId): Option[String] =
    id.value.split("-").lastOption

SubscriptionId("paypal-12") match {
  case SubscriptionId(id) => id
  case _ => "oops"
}

💡 See extractor objects.

Polymorphism

Type parameters are confined in square brackets:

def filter[A](list: List[A], p: A => Boolean): List[A] = 
  list.filter(p)

Square brackets are also used for type applications:

val x = List.empty[Int]

Type classes, implicits and givens

I don’t think it makes sense for me to go into too much detail here, especially, given the differences between Scala 2 and Scala 3. Just a few things you should put into your hippocampus:

In Scala 2, instance declarations are implicits:

implicit val example: Monad[Option] = new Monad[Option] {
  def pure[A](a: A): Option[A] = Some(a)

  def flatMap[A, B](ma: Option[A])(f: A => Option[B]): Option[B] = 
    ma match {
      case Some(x) => f(x)
      case None => None
    }
}

In Scala 3, type classes are more integrated; you write given instances:

given Monad[Option] with {
  def pure[A](a: A): Option[A] = Some(a)

  def flatMap[A, B](ma: Option[A])(f: A => Option[B]): Option[B] = 
    ma match {
      case Some(x) => f(x)
      case None => None
    }
}

In Scala 2 and Scala 3, context looks something like this:

//     ................
def foo[F[_]: Monad, A](fa: F[A]): F[(A, A)] = 
  for 
    a1 <- fa
    a2 <- fa
  yield (a1, a2)

💡 F[_] and F[A] in Scala is as conventional as m a in Haskell.

Sometimes, in Scala 2, they look like this:

def foo[F[_], A](fa: F[A])(implicit Monad: Monad[F]): F[(A, A)] = ???

Instances

It’s common to put instances into companion objects:

case class User(name: String, subscriptionId: SubscriptionId)

object User:
  implicit val codec: Codec[User] = deriveCodec[User]

Another place to look for instances is objects named implicits, for example.

import my.something.implicits._

This means that you have to remember what to import, and imports technically affect the logic of the program. In application code, it used to be somewhat common but seems to be less popular. It’s still the way to get instances for libraries that integrate with other libraries. For example, iron + circe.

Also, in Scala 3, there is a special form of import for given instances:

import my.something.given // Scala 3

💡 Don’t forget to read more about implicits or givens on your own.

Deriving (from library user perspective)

In Scala 2, the most popular ways to get instances are automatic and semi-automatic derivations.

Automatic derivation is when you import something and “magically” get all the instances and functionality; for example, circe json decoders:

import io.circe.generic.auto._

Semi-automatic derivation is a bit more explicit, for example:

import io.circe.generic.semiauto._

implicit val codec: Codec[User] = deriveCodec[User]

Scala 3 has type class derivation:

case class User(name: String, subscriptionId: SubscriptionId) 
  derives ConfiguredCodec

Note that you can still use semi-auto derivations with Scala 3 (when needed):

object User:
  given Codec[User] = deriveCodec[User]

Consult with the docs of concrete libraries.

Meta Programming

There are “experimental” macros in Scala 2 and multiple features in Scala 3.
There is shapeless (for scrap-your-boilerplate-like generic programming) for Scala 2 and built-in “shapeless” mechanism in Scala 3

Deriving (from library author perspective)

In Scala 2, it’s common to use shapeless and magnolia for typeclass derivation.

Scala 3 has built-in low level derivation. It’s still common to use shapeless and magnolia.

Best practices

Failure handling

Idiomatic Scala code does not use null. Don’t worry.
Either is Either, Maybe is called Option.
You might see Try here and there.
See Throwable (cousin of Exception and SomeExceptions)

For everything else, see what your stack/libraries of choice have in terms of failure handling.

Styles and flavors

There existed a lot of different scalas throughout the years. In 2024, fp-leaning industry-leaning scala converges into two: typelevel and zio stacks. Roughly speaking, both come with their own standard library (prelude), IO runtime, concurrency, libraries, and best practices.

🤔 Scala’s standard library is quite functional, but not functional enough. That’s why we have these auxiliary ecosystems.

Even more roughly speaking:

If you’re leaning towards using mtl/transformers, see typelevel.
If you’re leaning towards using app monads with “baked-in” EitherT and ResourceT, see zio.

There was a moment when people used free and effect system in production Scala code, but it sucked. So, I don’t think anyone uses either in prod these days. Some library authors still use free.

🤔 There is a hype train forming around “direct-style” Scala. Actually, there are multiple trains — because the term is so ambiguous — multiple styles packaged and sold under the same name. If you’re curious, look into it yourself.

If you get an “fp” scala job (around 2024), the newer services are going to be written using typelevel or zio (and there probably going to be legacy code in other styles).

Typelevel / cats

cats and cats-effect are the core of the typelevel stack
the other two pillars are fs2, and http4s
the other gotos are circe for json and doobie for databases
and many others: kittens, cats-mtl, etc.

🤔 Note that nothing stops you from using alternative libraries; especially, if they provide required instances or interoperability/conversions. For example, it seems common to use tapir instead (on top of) http4s for writing http servers in the last years. Tapir integrates with all major Scala stacks.

It’s common to organize code via “tagless final”:

trait Subscription[F[_]] {
  def fetchSubscription(subscriptionId: SubscriptionId): F[Subscription]
  def revokeSubscription(subscriptionId: SubscriptionId): F[Unit]
  def findSubscription(userId: UserId): F[Option[UserId]]
}

It’s common to tie your app together via Resource:

def server: Resource[IO, Resource[IO, Server]] =
  for
    config <- Config.resource
    logger <- Tracing.makeLogger[IO](config.logLevel)
    client <- HttpClientBuilder.build
    redis  <- Redis.resource(config.redis)
    kafka  <- KafkaConsumer.resource(config.kafka)
    db     <- Postgres.withConnectionPool(config.db).resource
    httpApp = Business.make(config, client, redis, kafka, db)
  yield HttpServer.make(config.port, config.host, httpApp)

It’s common to write business logic and organize control flows via fs2 streams:

fs2.Stream
  .eval(fetchSubscriptions(baseUri))
  .evalTap(_ => log.debug("Fetched subscriptions..."))
  .map(parseSubscriptions).unNone
  .filter(isValid)
  .parEvalMapUnordered(4)(withMoreData(baseUri))
  ...

ZIO

ZIO ecosystem comes with a lot of batteries. ZIO[R, E, A] is a core data type. See usage (it’s the way to organize the code, deal with resources/scopes, and control flows).

Tooling

You can use coursier to install Scala tooling ghcup-style.

Build tools

I’ve never used anything but sbt with Scala. If it doesn’t work for you for some reason, I can’t be much of a help here.

See mill
See other java build tools (like maven) or multi-language build tools (like pants or bazel)

Miscellaneous

Libraries

Searching for functions

There’s nothing like hoogle. The dot-completion and the go-to-definition for libraries often work. But, honestly, I regularly search through the github looking for functions (and instances). I don’t know what normal people do.

Searching for libraries

Search in the organization/project lists. Example 1 and Example 2.
Search on scaladex.
Search on github.
Ask a friend.
Just use a java library.

Managing dependency versions

There is no stackage.

Some people use sbt-lock, sbt-dependency-lock to get lock (freeze) files.
Some people use scala steward. A bot that helps keep dependencies up-to-date.

And you can always fall back to checking the maven repository to see what are the dependencies. An example.

Books and other resources

If you want to learn more, see docs.scala-lang.org, rockthejvm.com, and Foundations of Functional Programming in Scala.

To Haskell devs, I used to recommend underscore’s books: Essential Scala (to learn Scala) and Scala With Cats (to learn the FP side of Scala), but those are for Scala 2. The classic Functional Programming in Scala has a second edition updated for Scala 3 — it’s great if you want a deep dive into the FP side of Scala.

If you want to get weekly Scala content, see:

Scala Times newsletter.
This week in Scala.

If you want to chat, see scala-lang.org/community.

OOP and variance

When it comes to the OOP side of Scala, I think the most important one to get familiar with is variance. You might think you won’t need it if you don’t use inheritance to mix lists of cats and dogs. However, you’ll still see those + and - around and encounter related compilation errors.

More and more libraries deal with this to make your life easier, so you might not even need to worry about it…

💡 If you are familiar with functors, depending on how well you’re familiar, it might help or hurt you to apply the knowledge of variance here.

Few things you’ll need sooner or later

You might encounter different sub-typing-related type relationships. See (upper and lower) type bounds.

trait List[+A]:
  def prepend[B >: A](elem: B): NonEmptyList[B] = ???

If you encounter something that looks like associated type, see abstract type members:

trait Buffer:
  type T
  val element: T

If you encounter *, see varargs (for example, Array.apply())

val from = Array(0, 1, 2, 3) // in parameters

val newL = List(from*)        // splices in Scala 3  

val oldL = List(from: _*)     // splices in Scala 2

End

Congrats, you’re one step closer to mastering Scala. Just a few hundred more to go.

Haskell for Scala developers

Zelenya — Mon, 15 Jul 2024 02:53:18 +0000

Imagine you’re my colleague: you have functional Scala experience and must start contributing to the Haskell code. These are the things I would share with you (over some period of time).

⚠️ Context: subjective-production-backend experience, web apps, microservices, shuffling jsons, and all that stuff.

We will cover the main differences, similarities, major gotchas, and most useful resources. Consider this a rough map — just looking at this won’t make you a professional Haskell developer, but it should certainly save you (and the rest of the team) plenty of time.

⚠️ I’ll use Haskell and GHC interchangeably, which is “technically” incorrect. But it’s 2024. Who cares.

📹 Hate reading articles? Check out the complementary video, which covers the same content.

Basic syntax and attitude

You can (and should) pick up syntax by yourself, but here are the things you should conquer first:

Driving on the wrong side of the road

You have to get used to reading chains of operations “in the opposite direction”. Take this Scala code:

def foo(err: Error) = err.extractErrorMessage().asLeft.pure[F]

There are multiple ways to translate it into Haskell; the most straightforward:

-- read from right to left
foo err = pure (Left (extractErrorMessage err))

Notice the order of functions and the way we call functions (e.g., no parentheses after extractErrorMessage). We can avoid even more parentheses by the using function application operator (f $ x is the same as f x):

-- read from right to left
foo err = pure $ Left $ extractErrorMessage err

And we can avoid the rest of the plumbing by using function composition:

-- read from right to left
foo = pure . Left . extractErrorMessage

In the wild, you will see all of these styles as well as their mix.

Function signatures

Did you notice that Haskell’s functions had no type signatures?

💡 Haskell is pretty good at inferring types. We can omit type signatures even in the top-level definitions. We can, but it doesn’t mean that we should!

foo :: Error -> IO (Either Text a)
foo err = pure $ Left $ extractErrorMessage err

The type signature goes above the function definition. It might feel awkward to connect a name to a type, but among other things, it allows you to focus on types (while ignoring the names).

foo :: User -> Password -> Token -> IO (Either Error Credentials)
foo user password token = undefined

💡 The undefined value is like a type-inference-friendlier cousin of ???.

Names don’t matter?

The last thing I want to cover before we move on to more interesting things is about common function names and operators.

For reasons, Haskell has a map function that only works on lists. Functor has fmap.

There’s no flatMap, there is >>= (bind operator), and in general Haskell codebases (and developers) are usually more operator tolerable (some are too tolerable):

fetchUser someUserId >>= \case 
  Right user -> withDiscount <$> findSubscription user.subscriptionId
  Left _ -> pure defaultSubscription

traverse is still traverse, and everything else you can pick up as you go.

Basic concepts and fp

Function composition and Currying

As I’ve mentioned in the first Haskell vs. Scala video, in Haskell, function composition and currying are first-class citizens. Both are powerful enough to make the code tidier and more elegant, as well as the opposite. You certainly have to practice to get better at writing and reading.

If you find some code confusing (or yourself wrote some code that the compiler doesn’t accept), try rewriting it: make it more verbose, introduce intermediate variables, and so on. It’s ok. It’s not a one-liner competition.

fetchUser someUserId >>= subscription
  where 
    subscription (Right user) = userSubscription user
    subscription (Left _ )    = pure defaultSubscription

    userSubscription :: User -> IO Subscription
    userSubscription user = withDiscount <$> findSubscription user.subscriptionId

Also, if it feels like number of arguments is getting out of control, try introducing records.

userInfo :: UserId -> SubscriptionId -> BundleServiceUrl -> Cache -> IO UserInfo
userInfo u s b c  = undefined

userInfo' :: Config -> UserIds -> IO UserInfo
userInfo' c (UserIds userId subscriptionId) = undefined

Purity

When writing Haskell, you can not just use a quick var or a temporary prinltn. Depending on your experience and workflows, it can be or not be a big deal.

You might need to get used to it. You can start by getting familiar with Debug.Trace:

userSubscription user = 
  withDiscount <$> findSubscription (traceShowId user.subscriptionId)

Note: because of laziness, it might not be as trivial (a value might never be evaluated).

💡 See Debugging without a “real” debugger.

Laziness

Otherwise, I think you shouldn’t worry about laziness at the beginning of your journey. Trust the compiler. If you’re too worried about performance and resources, keep an eye on the metrics.

When needed, use existing code as a reference; for example, if you see exclamation points (BangPatterns) or a StrictData extension where the data is defined, copy-paste first and ask questions later!

Two great series on laziness in Haskell (you can find even more online):

Modules and Imports

There are no classes and objects.

You might quickly run into a problem with naming conflicts:

import Data.Text -- (Text, strip)
import Data.List 

foo :: Text
foo = filter (/= 'a') "abc"
--    ^^^^^^
-- Ambiguous occurrence ‘filter’
-- It could refer to
--   either ‘Data.List.filter’
--       or ‘Data.Text.filter’

You have to get into a habit of using qualified imports:

import Data.Text (Text)
import qualified Data.Text as Text
import qualified Data.List as L -- stylistic choice

foo :: Text
foo = Text.filter (/= 'a') "abc"

Some libraries suggest the users to qualify their imports, some people prefer to qualify all their imports, but, at the end of the day, it’s a personal/team choice.

📹 bytestrings

import Data.HashMap.Strict (HashMap)
import qualified Data.HashMap.Strict as HashMap
-- import qualified Data.HashMap.Strict as HM

foo :: HashMap Int Char
foo = HashMap.fromList [(1, 'a'), (2, 'b')]
--         HM.fromList [(1, 'a'), (2, 'b')]

I’d say, start using qualified imports for collections (containers) and strings (texts, bytestrings), and see how it goes.

Standard library

💡 Standard library (std module) is called Prelude. It’s imported by default into all Haskell modules unless explicitly imported or disabled by the NoImplicitPrelude extension.

You should pay attention when using Haskell’s standard library, (at least) for two reasons.

It provides things that you shouldn’t use in production; for example, head (that crashes a program on an empty list), String (see text / bytestring), and lazy IO operations (see streaming libraries).

💡 Also see the OverloadedStrings extension.

It doesn’t provide things you might expect or provides them in unexpected ways. For example, there is no distinct to ignore duplicate elements from a list, but there is nub:

List(1, 2, 1, 3).distinct // List(1,2,3)

List.nub [1, 2, 1, 3] -- [1,2,3]

There is no contains, there is elem:

elem 1 [1, 2, 1, 3] // True

Which is commonly written using infix form:

1 `elem` [1, 2, 1, 3] -- True

💡 elem is not prefixed with List, cause it comes from Foldable.

And stuff like that. Be more open-minded (and careful).

🥈 Some companies use alternative preludes (existing or custom) not to deal with the standard prelude.

Types

Product Types

No easy way to put this. Records in Haskell can be irritating. You’ll find out really fast.

It’s annoying when you use records with the same field names:

data User = User {name :: Text, subscriptionId :: SubscriptionId}
data UserIds = UserIds {userId :: UserId, subscriptionId :: SubscriptionId}
--                                        ^^^^^^^^^^^^^^
-- Multiple declarations of ‘subscriptionId’

And it’s annoying when you need to access or update nested records.

*I’m not even going to illustrate this in vanilla Haskell.*

I wouldn’t recommend using vanilla records. You have to get familiar with a couple of extensions. You can start with OverloadedRecordDot (since: GHC 9.2.0) and DuplicateRecordFields. Additionally: NoFieldSelectors (incl. in GHC2021), NamedFieldPuns (incl. in GHC2021), and maybe…maybe RecordWildCards. Don’t expect a smooth ride.

💡 We cover GHC2021 in the extension section.

It’s also common to use lenses via some optic library. There are quite a few options. Pick you poison: lens, optics, generic-lens, lens-simple, microlens, profunctor-optics, prolens.

💡 If you can’t afford GHC 9.2.0 (or higher) or lenses, you can also checkout getField.

Sum types

It can be a bit unexpected, but Haskell allows partial field accessors (with a warning).

data Role = Role {internalId :: UserId} | Admin

dont :: Role -> IO ()
dont user = print user.internalId

dont Admin
-- *** Exception: No match in record selector internalId

I’m mentioning this just in case. I’ve never cared or worried about this. Just use pattern matching like you would in Scala.

Polymorphism

What in the Java world is called generics, in the Haskell world is called parametric polymorphism.

-- a is a type parameter
filter :: (a -> Bool) -> [a] -> [a]

Don’t want to go into details here, you shouldn’t see this that often, eventually, see Explicit universal quantification (forall).

-- this version is explicitly quantified
filter :: forall a . (a -> Bool) -> [a] -> [a]

Other than that, in general practice, it’s not that different, so let’s talk about ad-hoc polymorphism.

Type classes

Unlike Scala, Haskell has built-in type classes — there's (guaranteed to be) at most one instance of a type class per type.

Good news: No need to worry about imports!

Sometimes, when you need a new (custom) instance, you can introduce a newtype:

-- User is declared in some other module

newtype InvalidUser = InvalidUser User 

instance Arbitrary InvalidUser where
  arbitrary = do
     Positive x <- arbitrary
     pure $ InvalidUser $ User undefined x undefined

Sometimes, you can add an orphan instance and not use a newtype (it’s not encouraged, but still legal and sometimes unavoidable):

{-# OPTIONS_GHC -fno-warn-orphans #-}

instance Arbitrary User where

And remember that you can get a lot for free with deriving.

Deriving

In Haskell, you can derive a lot (starting with Show, all the way to Traversable and beyond).

{-# LANGUAGE GeneralizedNewtypeDeriving #-}

newtype MyApp a = MyApp { unApp :: ReaderT Config IO a }
  deriving (Show, Functor, Applicative, Monad, MonadReader Config)

Usually, a library will have some examples of how to derive required type class instances, including imports and extensions. And if it doesn’t include the extensions (or you copied a code from somewhere else), the compiler will give you a hint.

For example, aeson:

{-# LANGUAGE DeriveGeneric #-}

import Data.Aeson (FromJSON, ToJSON)
import GHC.Generics (Generic)

data Product = Product { name :: Text, tier :: Int } deriving (Generic, Show)

instance ToJSON Product
instance FromJSON Product

To expand your vocabulary, start with GeneralizedNewtypeDeriving(incl. in GHC2021). Then checkout strategies, DerivingStrategies (incl. in GHC2021), DerivingVia, and maybe DeriveAnyClass.

-- DerivingStrategies is implied by DerivingVia
-- {-# LANGUAGE DerivingStrategies #-}

{-# LANGUAGE DerivingVia #-}

import Data.Aeson (FromJSON, ToJSON)

newtype Quota = Quota {getQuota :: Int}
  deriving (Eq, Ord)
  deriving (Show, ToJSON, FromJSON) via Int

💡 The GHC docs are good. There are a couple of other guides online.

Meta Programming

The two most common ways to generate boilerplate in Haskell are Template Haskell (TH) and generic programming. Not java generics. Even more generic generics!

💡 That’s one of the reasons not to refer to parametric polymorphism as just (java) generic types.

Template Haskell

Let’s start with Template Haskell, cause it’s easier to explain (as an overview, I would claim that about the actual explanation).

You use the TemplateHaskell language extension and write template haskell or you use code that generates boilerplate via TH.

Libraries often provide a specific TH module (or even a package) with functions to derive necessary instances. For example, Data.Aeson.TH:

{-# LANGUAGE TemplateHaskell #-}

import Data.Aeson.TH (defaultOptions, deriveJSON) 

data Product = Product { name :: Text, tier :: Int } deriving (Show)

$(deriveJSON defaultOptions ''Product)

Generic programming

Generic programming comes in different shapes and forms. I’d say the most relevant is GHC.Generics with the DeriveGeneric extension (incl. in GHC2021), because it’s the one that libraries usually use. Once again, let’s look at aeson:

{-# LANGUAGE DeriveGeneric #-}

import Data.Aeson (FromJSON, ToJSON)
import GHC.Generics (Generic)

data Product = Product { name :: Text, tier :: Int } 
  deriving (Generic, Show)

instance ToJSON Product
instance FromJSON Product

There is also generics-sop, which is seemingly more accessible than GHC.Generics if you want to generate your own boilerplate (maybe in the future; probably, if you’re watching this, you should not be writing generic code like that).

There is also generic programming via Data.Typeable and Data.Data (see Scrap Your Boilerplate). It came before GHC.Generics, uses a different approach, and feels more straightforward. However, it’s usually not recommended any more because it’s less efficient. That’s what they say on the internets. I’ve never compared any of those.

🌯 So, Template Haskell is like macros, generics are like shapeless.

Best practices

As I’ve mentioned in the overview, there is no consensus on writing Haskell. Whatsoever. On any topic.

Abstractions and type classes

However, it’s essential to know your type classes. Those are a must: Functor, Applicative, Monad, Semigroup, Monoid, Foldable, Traversable, and Alternative. If the library has a functionality that can be provided by one of those (e.g., smooshing or mapping things), it’s likely that it’s going to be provided and won’t be very documented.

Failure handling

The situation is not much better than in Scala. I can’t help you here, you’re on your own.

Option is called Maybe.
See Exception and SomeExceptions (cousins of Throwable).
See synchronous exceptions (throwing exceptions in IO).
See safe-exceptions package (throwing exceptions in ~~F[_]~~, I mean MonadThrow m => m a).
Maybe see UnliftIO.Exception as a safe-exceptions surrogate.
See asynchronous exceptions.

You might be tempted to use error "this should never happen" in “pure” code — just a friendly reminder it eventually does happen. Don’t be lazy, don’t trust other teams to respect your contracts, and be cautious. Think about your future self.

Styles and flavors

From time to time, people bring up Simple Haskell, Boring Haskell, and stuff like that. But there are no actual rules, communities, or many guidelines for those.

The one way that Haskell (GHC) varies between companies and projects is via the language extensions. You need to start recognising extensions and what they change: notice which extensions are enabled per module and which for the whole project (or package). Also get familiar with language editions — such as GHC2021 and GHC2024 — how to enable those and what’s included.

Organizing code

There is plain IO, mtl and transformers, custom monads (on top of those), IO + Reader(T), RIO, unliftio, services and handle patterns, free monads, freer-simple, extensible-effects, fused-effects, eff, effectful, cleff, polysemy, bluefin, and other effect libraries (that I forgot to mention).

I could oversimplify and say, if you used cats-effect and tagless final use THIS, or if you used ZIO use THAT, but what’s the fun in that?

💡 A quick note: if you’re looking for something like Resource (for your library of choice) and can’t find it or make it work, try starting or searching from bracket and functions prefixed with with (e.g., withPool). Also, see resourcet and managed.

Runtime and concurrency

Green threads (provided by Haskell runtime system).
MVar is MVar, Ref is IORef.
See async package.
See STM.
See bracket.

📕 Bonus: See Parallel and Concurrent Programming in Haskell by Simon Marlow.

Tooling

📹 Okay, okay, let’s go back to stuff I can actually be a bit of help.

There’s no universal answer when it comes to tooling. If you’re using nix, do what you're doing. If not — install ghcup and install everything else through it (it’s kind of like cs setup).

There are two main build tools in Haskell: Cabal and Stack.

If the team or project that you’re using uses one — choose that one.
If you’re starting a new project for yourself — you can choose by throwing a coin (or partially depending on the preferred dependency workflow; see below).

Editor

You can use ghcup to install HLS (Haskell Language Server) – Haskell LSP support, so you can use whatever supports LSP.

I use vs code. Using Haskell with it is not that different from using Scala. You can also use IntelliJ via the LSP plugin — obviously don’t expect java-level IDE support.

REPL / GHCI

Try integrating ghci into your development workflow. It’s more than just a repl — it’s closer to Scala worksheets with abilities to debug and inspect; for example, get a type or a kind of expression and get available (type-class) instances for a data type.

🤷 In other words, if there is some Scala/IntelliJ functionality/workflow that is missing in the Haskell editor, you might substitute it by using GHCi.

Libraries

Searching for functions

If you’re looking for some function or some data type, you can still use dot completion on a module, but if you don’t know where to look, try hoogle (or local alternative).

You can also use typed holes, to get compiler suggestions (it also works in the editor).

foo = _ someUserId >>= subscription

• Found hole: _ :: UserId -> IO (Either a0 User)
  Where: ‘a0’ is an ambiguous type variable
• In the first argument of ‘(>>=)’, namely ‘_ someUserId’
  In the expression ...
• Relevant bindings include
    ...
  Valid hole fits include fetchUser
  Valid refinement hole fits include
    ...

Searching for libraries

If you’re looking for a library (a package), you can still poke around hoogle or search hackage (central package archive) by tags.

But here is the first catch: there could be too many options. For example, see my video on Haskell and Postgres. I don’t have a rule of thumb here. You can try asking around, but the more people you ask — the more answers you get.

🤔 Maybe the solution is to ask only one person or two, not more.

The opposite is also common, sometimes there are no options. Sometimes there are bindings on top of a C library. For example. So, if you can’t find anything, there is always C FFI.

Searching for dependency versions

You don’t have to search for (or use) specific library versions compatible with other libraries.

There are a few other ways to deal with dependency versions.

Managing dependency versions

You can use stackage snapshots (snapshot is a set of compatible Haskell libraries).
You can use loose version bounds or no bounds at all for your dependencies (if you don’t care about reproducibility or like living on the edge).
You can use cabal freeze to pin down the dependencies, which ensures (more) reproducible builds. Something like sbt-lock, sbt-dependency-lock, or locks in other language ecosystems.

Books and other resources

If you want to learn more, haskell.org has a list of all sorts of learning resources.

If you want to get weekly Haskell content, see

https://haskellweekly.news/ (newsletter)
https://haskell.libhunt.com/ (newsletter)
https://haskell.pl-a.net/ (aggregator)

If you want to chat, see https://discourse.haskell.org/. Or find your own echo chamber.

Few things you’ll need sooner or later

The last thing we cover. If you aren’t proactive enough with catching up with less-beginner Haskell, you might bump into unknown syntax. A few more pointers:

If you encounter @ followed by a type, see TypeApplications.

If you encounter | in a type class declaration, see functional dependencies.

class (Monad m) => MonadState s m | m -> s where
  ...

If you encounter type family, data family, or an associated type (or data), see type families.

-- something like this
type family IsChar (a :: Type) :: Bool where
  ...

class Foo a where
  -- or something like this
  type Bar a :: Type
  f :: a -> Bar a

If you encounter too many foralls or suspiciously nested foralls, see RankNTypes (or maybe ExistentialQuantification).

If you feel like there is too much happening on the type level, see DataKinds, Type-Level Literals, or something along those lines.

If you see where in a data declaration, see GADTs (or GADTSyntax)

data Option a where
  ...

End

Congrats, you’re one step closer to mastering Haskell. Just a few hundred more to go.

🌱 Hopefully this is useful as a standalone resource (even if you can’t ask follow-up questions).

What Scala does better than Haskell and vice versa

Zelenya — Tue, 25 Jun 2024 04:04:00 +0000

📹 Hate reading articles? Check out the complementary video, which covers the same content.

There is this meme that Haskell is better than Scala or that Scala is just a gateway drug to Haskell. A long time ago, I used to believe this.

I saw how 4 different companies use Scala.
I saw how 4 different companies use Haskell

After years of using both in multiple companies and meeting people who “went back to Scala”, it’s kind of sad to see people bring up these stereotypes repeatedly. Sure, the Haskell language influenced and inspired Scala, but there are so many things that I miss from Scala when I use Haskell… as well as vice versa.

⚠️ Disclaimer

When talking about Scala or Haskell here — it’s not just about the languages themselves, but also about standard libraries and overall ecosystems.

“All happy families are alike; each production is unhappy in its own way.”

We’ll be talking from subjective-production-backend experience — from somebody dealing with web apps, microservices, shuffling jsons, and all that stuff. The emphasis is on the production setting (not academic, theoretical, or blog post).

For example, Scala is built on top of Java and has nulls, oh no! While in a day-to-day code, I rarely encounter it. The last time I saw a NullPointerException was more than 8 months ago. Not even in the Scala code. It was in the http response body — the vendor’s API returned internal errors in case of malformed input 🤷 (they used Spring).

With this in mind…

FP dial

One of the biggest things that separates Scala from Haskell is the ability to choose the level of FP or level of purity.

I know how to use trace (and friends) to debug in Haskell, but it’s pretty convenient to sneak in an occasional println anywhere I want.

And I’m happy to admit, that I used a couple of mutable variables a few of months ago and it was great. I was migrating some convoluted functionality from legacy Ruby to Scala, and it was simpler to translate the core almost as is (in a non-fp way), add tests, remove unnecessary code, fix some edge cases, and only after rewrite in a functional style with a little State.

Sure, it wouldn’t be the end of the world to rewrite that in Haskell as well — instead of intermediate representation, I would have to plan on paper or something…

Fp-dial is also great for learning/teaching, occasional straightforward performance tweaks, and so on…

Laziness

Another big difference is laziness.

When writing Haskell, laziness allows us not to think or worry about stuff like stack safety; for example, we don’t have to worry about *> vs >>, we can look at the code of any Monad and it’s going to be just two functions — no tailRecM or other tricks… (it still doesn’t mean it’s going to be easy to read though)

And laziness gives more room for the compiler to be free and optimize whatever it wants.

On the other hand, when writing Scala, it’s pretty nice not to worry about laziness. Like I’ve mentioned before, I can println (or see in the debugger) pretty much any variable and know that I will see it (and it will be evaluated). On top of that, no worrying about accumulating the thunks…

😉 Don’t worry, there are other ways to leak memory on JVM.

Function Composition and Currying

Probably the biggest stylistic thing I miss from Haskell is function composition.

Starting with a concise composition operator (.):



pure . Left . extractErrorMessage -- Note: read from right to left

Sure, it requires getting used to, some people abuse it, and so on. But function composition can be so elegant!



map (UserId . strip) optionalRawString

What also helps Haskell’s elegance is currying — Haskell functions are curried, which makes function composition and reuse even more seamless:



traverse (enrichUserInfo paymentInfo . extractUser) listOfEntities

enrichUserInfo :: PaymentInfo -> User -> IO UserInfo

extractUser :: Entry -> User

At the same time, not having currying by default is to Scala’s advantage — it can notably improve error messages (which is also more beginner-friendly). When you miss an argument, the compiler tells you if you passed a wrong number of parameters or which exact parameter is wrong:



def enrichUserInfo(paymentInfo: PaymentInfo, user: User): IO[UserInfo] = ???



enrichUserInfo(user)
// Found: User
// Required: PaymentInfo



enrichUserInfo(paymentInfo)
// missing argument for parameter user ...

Where clause

Another style- or formatting-related thing that I really miss in Scala is having the ability to write things in the where clauses.



foo = do
  putStrLn "Some other logic"
  traverse (enrichUserInfo paymentInfo . extractUser) listOfEntities
  where
    enrichUserInfo :: PaymentInfo -> User -> IO UserInfo
    enrichUserInfo = undefined

    extractUser :: Entry -> User
    extractUser = undefined

It’s not the same as declaring variables (before using them) and not the same as using private or nested functions. I like to have primary logic first and secondary — after (below) and be explicit that functions aren’t used anywhere else.

Types

Let’s talk types.

Newtypes and Sum types

It feels like Haskell encourages us to make custom types, because of how uncluttered it is:



data Role = User | Admin deriving (Eq, Show)



newtype Quota = Quota Int deriving Num

remainingQuota :: Quota -> Quota -> Quota
remainingQuota balance cost = balance - cost

It’s just so neat and ergonomic! When I’m writing Scala, I might think about making a custom type but then give up and keep using Strings and Booleans…

🙏 Sure. One can use a library. Sure. It’s better with Scala 3. Still…

Product Types

Funnily enough, Scala is way better at product types (records/case classes):



case class User(name: String)

User("Peach").name

We don’t need to go into more details. If you have used Haskell, you know.

🙏 Sure. One can use lenses. Sure. It’s better with the latest extensions. Still…

Union Types

On a related note, Scala 3 introduced union types:



val customer: Either[NotFound | MissingScope | DBisDead, CustomerId] = ???

customer match
  case Right(customerId)        => as200(customerId)
  case Left(NotFound(message))  => notFound(message)
  case Left(MissingScope(_))    => unauthorized
  case Left(DBisDead(internal)) => 
    Logger.error("Some useful information, {}", internal.getErrorMessage()) >>
    internalServerError("Some nice message")

Finally, introducing new error types doesn’t feel like a chore — we don’t need to build hierarchies or convert between different ones. I miss those in Haskell and Scala 2.

🤔 The type could be even CustomerId | NotFound | MissingScope | DBisDead

Type inference

Let’s keep it short: Haskell has great type inference. It works when you need it — I never feel like I have to help the compiler to do its job

🙏 Not talking about more complicated type-level stuff — just normal fp code.

For example, we can compose monad transformers without annotating a single one (or even the last one):



program :: IO (Either Error Result)
program = runExceptT do
  user <- ExceptT $ fetchUser userId
  subscription <- liftIO $ findSubscription user
  pure $ Result{user, subscription}

fetchUser :: UserId -> IO (Either Error User)

findSubscription :: User -> IO Subscription

And when we use the wrong thing, the compiler has our back:



program = runExceptT do
  user <- _ $ fetchUser userId
  subscription <- liftIO $ findSubscription user
  pure $ Result{user, subscription}



• Found hole: _ :: IO (Either Error User) -> ExceptT Error IO User
• ...
  Valid hole fits include
    ExceptT :: forall e (m :: * -> *) a. m (Either e a) -> ExceptT e m a
      with ExceptT @Error @IO @User
      (imported from ‘Control.Monad.Except’ ...
        (and originally defined in transformers

Modules and dot completion

On the other side of the coin, Scala has a great module system — we can design composable programs, don’t worry about things like naming conflicts, and also… look what we can do:

dot completion…

Hoogle

To be fair, the dot-completion is good and all, and occasionally I miss it in Haskell. It’s, however, only useful when I already have a specific object or already know where to look. When we just start using the library, have a generic problem, or don’t even know what library to use yet; then the dot-completion won’t help us — but Haskell’s hoogle is.

We can search for generic things:



(a -> Bool) -> [a] -> [a]

And for more specific things, for example, we have an ExceptT, how can we use it?



IO (Either e a) -> ExceptT e IO a

Libraries

If we look at the bigger picture, Scala has a better library situation — when I need to pick a library to solve some things, it’s usually easier to do in Scala.

🙏 Keep in mind the context. I know, for instance, Scala has nothing that comes close to Haskell’s parser libraries, but this is not what we’re talking about right now.

It's most notable in companies where many other teams use different stacks; we have to keep up with them (new serialization formats, new monitoring systems, new aws services, and so on).
We rarely have to start from scratch in Scala because, at least, we can access the sea of java libraries.

The opposite issue — when there are too many libraries for the same use-case — is just a bit less common in Scala. Mostly, when there are multiple libraries, it’s because each exists for a different Scala flavor (we’ll talk about this soon), but it’s often fine because it’s easy to pick one based on your style (maybe not as easy for beginners 🤷)

And then Scala libraries themselves are usually more production-ready and polished. Essentially, there are more Scala developers and more Scala in production, so the libraries go through more iterations and testing.

Library versions / Stackage

However, when it comes to picking versions of the libraries I prefer Haskell because it has Stackage — a community project, which maintains sets or snapshots of compatible Haskell libraries.

We don’t need to brute-force which library versions are compatible or go through bunch of github readmes or release notes. The tools can pick the versions for us: either explicitly, if we choose a specific resolver/snapshot (for example, lts-22.25); or implicitly, by using loose version bounds (base >= 4.7 && < 5) and relying on the fact that Stackage incentivizes libraries to stay up-to-date and be compatible with others (or something like that).

Best practices

As I mentioned, there are various flavors of Scala (some say different stacks): java-like Scala, python-like Scala, actor-based Scala, … many others, and two fp Scalas: typelevel/cats-based and zio-based. Most of the time, they come with their core set of libraries and best practices.

It’s easy to get onboarded at a new code base or a company — no need to bike-shade every time about basic things like resource management or error handling. Of course, there are hype cycles and new whistles every few years, but Scala communities usually settle on a few things and move on.

On the other hand, there is no consensus on writing Haskell. Whatsoever. On any topic. And I’m going to contradict what I’ve just said, but I like it too — it can be really fun and rewarding as well. I have seen 4 production usages of Haskell: each company used a different effect system or ways to structure programs (actually, half of them used even multiple different ones inside the same company), and it was enjoyable to learn, experiment, and compare.

Abstractions

In a nutshell, all those (Scala/Haskell) effect systems are just monads with different boilerplate — if you used one, you used them all. It’s not a big deal to switch between them.

And it’s another great thing about Haskell — the use or reuse of abstractions and type classes.

It’s typical for libraries to provide instances for common type classes. For example, if there is something to “combine”, there are probably semigroup and/or monoid instances. So, when Haskell developers pick up a new library, they already have some intuition on how to use it even without much documentation (maybe not as easy for beginners 🤷).

Take, for instance, the Megaparsec parser library — most of the combinators are based on type classes; for example, we can use applicative’s pure to make a parser that succeeds without consuming input, alternative’s <|> that implements choice, and so on.

Blitz round

Let’s quickly cover a few other topics. We won’t give them too much time, because they are even more nuanced or niched (or I was too lazy to come up with good examples).

Documentation, books, and other resources

Speaking of documentation, originally, when I sketched out this guide, I was going to say that Scala is better at teaching (documentation, books, courses, and whatever), but after sleeping on it (more than a couple nights), I don’t think it’s the case — I don’t think one is doing strictly better than the other on this front (as of 2024).

Type classes

Probably the first and the most common topic people bring up when comparing Scala to Haskell is type classes: in Haskell, there's (guaranteed to be) one instance of a type class per type (Scala allows multiple implicit instances of a type).

There are a lot of good properties as a consequence, but honestly, the best one is that there is no need to remember what to import to get instances.

Type-level programming

If you like it when your language allows you to do “a lot” of type-level programming, it’s an extra point for Haskell.

If you don’t like it when your colleagues spend too much time playing on the type-level or don’t like complex error messages, it’s an extra point for Scala.

Build times

Scala compiles faster.

Runtime and concurrency

I think, in theory, Haskell has a strong position here: green thread, STM, and other great concurrency primitives.

However, in practice, I prefer writing concurrent code in Scala. Maybe it’s because I’m scared of Haskell’s interruptions and async exceptions, maybe it’s because occasionally I can just replace maps with “pragmatic” parMap, mapAsync, or even parTraverse and call it a day, or maybe it’s because Scala library authors, among other things, built on top of Haskell’s findings.

Take-aways

So, is there a lesson here? On one hand, I wish people would stop dumping on other languages and recite the same things.

On the other hand, I, for instance, hate Ruby so much that if someone told me to learn something from Ruby, I’d tell them to…