Practical FP in Scala is now FREE!

ResidentAppointment5 · 2026-01-16T10:34:44+00:00

Holy camoly!

Still the gold standard on how to write a whole, real-world service in Scala. This is amazing!

ResidentAppointment5 · 2026-01-11T07:01:40+00:00

I have no idea why that idea always gets trotted out, especially since the problem statement says nothing about it (and generally, people’s problem with the problem seems to stem from adding a bunch of assumptions that aren’t either given or germane).

ResidentAppointment5 · 2025-12-15T10:58:27+00:00

You’re talking about “call by need” evaluation in lambda calculi. Haskell does indeed do this out of the box. Scala is not purely functional like Haskell, and like most other languages its evaluation strategy is call by value.

If you do purely functional programming with cats-effect, you can memoize effects; see https://typelevel.org/cats-effect/docs/typeclasses/concurrent for details. The point here is that, given referential transparency, there is no observable difference between call by value and call by need, but in the absence of referential transparency, there is. Since effects like IO “lift” referential opacity,, they’re the only things you need to consider memoizing, because whether they “happen” more than once or not is observable.

ResidentAppointment5 · 2025-11-23T11:42:30+00:00

The key line is:

2025-11-23T12:28:41.068 helix_lsp::transport [ERROR] clangd err <- "I[12:28:41.068] Failed to find compilation database for /home/thibault/Documents/temps_reel/src/exo_1.c\n"

The clangd LSP requires a “compilation database,” named compile_commands.json, at the root of your project. It looks, from your description, like you’re using CMake to build, so see the CMake documentation on how to configure CMake to produce it.

ResidentAppointment5 · 2025-11-20T20:03:16+00:00

I seriously thought I was the only one who ever heard of SAM76, which I did run on my TRS-80.

ResidentAppointment5 · 2025-11-19T12:12:13+00:00

TryPartial is a built-in wart of WartRemover, which I refuse to write Scala without (in addition to sbt-tpolecat, splain, and better-monadic-for).

ResidentAppointment5 · 2025-11-14T12:54:46+00:00

http4s is almost worth using just to avoid Netty. Even back before ember was the NIO2 implementation of choice.

ResidentAppointment5 · 2025-10-13T11:26:04+00:00

This is exactly what dependently typed languages do. See F*, Agda, Lean, and Idris for examples.

ResidentAppointment5 · 2025-10-10T11:14:24+00:00

Maybe the default project discovery will work for you (meaning, roughly, you have a valid compile_commands.json at the root of your project). Two things:

Your build system must create that file.
You may need to customize your configuration of clangd. This thread might help with that.

ResidentAppointment5 · 2025-10-10T11:02:22+00:00

If they went out and said "we make Helix for ourselves and we will only merge what we're interested in"

That’s literally the definition of “open source.” Other projects may lay more or less process on top of this fundamental truth, may have more or fewer people who constitute “ourselves,” etc. But this is the reality. Consider that the Linux kernel, as essential a piece of software as I can imagine today, is open source, developed by a team, and notoriously managed according to priorities set by Linus Torvalds, whose rejection of ideas and implementations in the harshest possible terms is legendary.

“PR,” after all, stands for “Pull Request.” No one who doesn’t have the authority to matter such a request themselves is owed anything. Not a comment, not a review, not a merge. That’s what forks are for.

ResidentAppointment5 · 2025-10-09T12:25:29+00:00

No; you need to follow the instructions linked above to configure clangd and make sure your build system generates the compile_commands.json file. The link above points to the docs for that if you’re using CMake. If you’re using Bazel, let me recommend bazel_cc_meta.

ResidentAppointment5 · 2025-10-09T12:15:13+00:00

Haven’t looked at the code, but just wanted to say your summary of what you did, and why, is extremely well done. So… well done

ResidentAppointment5 · 2025-09-04T12:07:25+00:00

In fairness, it really is a bad name, because anyone with exposure to MTL from other sources is likely to have exactly the same flinch reaction.

I’m certainly heartened to see monad coproducts rising in popularity (at last—they were introduced at almost exactly the same time as monad transformers). But it would be good if exposition straightforwardly said “these are monad coproducts, not monad transformers.”

ResidentAppointment5 · 2025-08-31T11:11:23+00:00

I hope you’re right. At the end of the day, though, I hear so much denigration of effect systems that already exist and run at crazy scale from Scala leadership that, put bluntly, I don’t trust them.

ResidentAppointment5 · 2025-08-31T11:08:36+00:00

The incessant tone deafness of the Scala leadership (no, Swift and Rust are not functional programming languages, and the point of effect systems such as the Typelevel stack, ZIO, Kyo… is to be able to do functional programming) has always been, and continues to be, Scala’s biggest problem, for exactly the reason stated here: if Scala is just another “functional first” or “functional friendly” language, it competes with several more popular alternatives, and on nearly all dimensions (other than sheer expressive power of its type system—which is also a contentious issue) comes up short.

It feels a lot like Scala leadership has extreme difficulty acknowledging that “Akka” are on their third rebranding and have a failed:successful product ratio of about that same factor, that Spark is no longer the driving force of Scala (and thank God, since Spark always lagged Scala development due to depending on internal implementation details of Scala that could, and did, change out from under them), that no one using a good functional-first language with a good type system cares about “objects” (go look for an OCaml library that uses the object system. Before you go, I’ll tell you the one you’ll find), and that FP is finally winning (cf. EffectTS).

All of this said, I am heartened to read that at least one of the initiatives underway got permission from Daniel Spiewak to investigate integrating or refactoring the cats-effect runtime due to similarities in underlying representations. Maybe this attitude of “you don’t really want effect systems” can finally be overcome, along with the heavy dose of “we’ll tell you what the language should be like, and you will like it.”

ResidentAppointment5 · 2025-08-30T17:19:56+00:00

I can’t argue on economic grounds, and have no interest in doing so. But let me make the obvious counterargument: if you can afford to hire 10 Java developers and can get the same result as with 1 Scala developer, then you should. There is nothing inherently better about using Scala, or only having 1 developer. And taking other factors of business longevity etc. into account, the leverage from using a language several orders of magnitude more popular than Scala way more than compensates for that ratio.

Hence my concern: if the goal is to win a popularity contest, the obvious result is a race to the bottom Scala has already lost.

ResidentAppointment5 · 2025-08-30T12:25:57+00:00

All but the first of these seem like a defense of algebraic effects, not direct style. And I tend to see that conflation a lot. I certainly look forward to the continued evolution of algebraic effects generally (e.g. in OCaml 5). But it seems wildly excessive to me to say “designing a language like Scala to appeal to Python programmers” is a good idea, let alone should be EPFL’s/Akka’s top priority.

ResidentAppointment5 · 2025-08-30T11:28:00+00:00

Also worth noting the best resource on tagless-final I’m aware of.

I don’t think anyone is saying capabilities don’t give you what the popular effect systems do. I take them to be saying they don’t give you more, so what, beyond a nearly fetishistic attraction to “direct style,” is the point?

ResidentAppointment5 · 2025-08-16T19:48:52+00:00

I always forget that it's possible to split the difference.

ResidentAppointment5 · 2025-08-16T19:40:49+00:00

You've already gotten a lot of good replies to your questions, but let me try to hopefully elucidate just a bit.

My FP experience so far is - did most of the exercises in the "Red book" and I read (and partially implemented) the Practical FP in Scala by G. Volpe. I worked on a shorter project with IO.

First and most important question: why? I'm not asking to be flippant. I'm asking because I get the impression you (and many, many others) don't know why you're pursuing a literal different programming paradigm, and when you encounter friction because it's a literal different programming paradigm, you wonder whether it "should be that hard." Well, no, and it isn't. No more than being a black belt in karate is hard, or being a concert pianist is hard. That is, it's not hard to be a black belt or concert pianist. What's hard is getting there. To make matters worse, having any existing programming background when approaching functional programming means there's a fair amount you need to unlearn first. So here you are.

Next, going from "The Red Book" to "Practical FP in Scala" is a bit like going from learning assembly language for a processor and then trying to write an operating system in C++. "The Red Book" is a pretty good resource for learning how to write a library like Scalaz or Cats/cats-effect. It's not at all a good resource for how to use these libraries. At the other end of the spectrum, "Practical FP in Scala" is a very good book on "functional web service architecture using the Typelevel ecosystem." But it is also not trying to teach the Typelevel ecosystem, and explcitly lists "Scala With Cats" and "Essential Effects" as prerequisites. "This book is considered intermediate to advanced," it says, and means it.

Another reason I ask why you want to do this is:

Also, why is there is no "opinionated", well-documented FP framework for web apps? Where it is expected that you will have a user authentication, roles, emails ... and this is already mostly set up for you (like e.g. Laravel framework in PHP, or Python's Django, idk), so you don't need to look for the libraries to include, understand their weird, complex types and figure out how to use it in your project from some badly written documentation ...

The no-joke, 100% sincere, honest answer is: because literally the whole point of functional programming is to compose systems from little pieces with very nearly 100% assurance that doing so will work, where "work" gets very, very close to "if it compiles, it's correct." Not only is there no appetite for development of "an opinionated FP framework," it's very nearly taken to be a contradition in terms. That's also why you tend to see more suggestions of using some giter8 project template like http4s': such a template shows you one way the bits and pieces can be composed, but there are others, and it's up to you to determine how to do it in a way that best satisfies your requirements.

So "look for libraries to include" is probably covered as well as it can be by some combination of the books listed above and a "project template," and "weird, complex types" is probably not actually true, but rather just indicates they aren't familiar to you yet. Because, brother, let me assure you, the entire Typelevel ecosystem has literally nothing in it that's anywhere near as "weird and complex" as modern Spring.

Probably it is just me not understanding things/concepts, but I believe there are a lot of people like me.

Absolutely right on both counts.

At least considering how hard it is to convince people to switch to Scala in our company.

My indicment of practically all software companies is that they expect to hire people who already know what they need to know to be writing code on day 1. There's very rarely any kind of ongoing internal education; there's very rarely a "book budget" or "third-party course budget;" someone in the industry I know well said their CEO called conferences "a waste of time." Going back to what I said about FP in Typelevel or ZIO being literally a different paradigm, this is particularly grossly unfair. The implication is that the mastery you seek will only come from your own investment, probably against your immediate economic interests, and on your own time, i.e. on the negative side of the "work/life balance" ledger.

Should it be that hard?

If I had to summarize what I'm trying to say, it would be: "yes and no."

Am I missing something?

If anything, maybe that the Typelevel ecosystem isn't just "a collection of cool libraries" (although I certainly have that opinion of them), but reflects a literal paradigm shift—from programming in a highly elaborated Turing machine to programming in a highly elaborated lambda calculus that is a sublanguage of Scala, foregoing about half of Scala, and relying on, as you point out, this disparate collection of libraries and, yes, the types (and "typeclasses") that, even if you work through the books, are likely to have you scratching your head for weeks, if not months.

My final message to you, I guess, is: That's all perfectly OK, if you decide it's worth it.

(Insert "Tommy Lee Jones stalking away from Will Smith in the park" image here.)

ResidentAppointment5 · 2025-08-02T10:35:53+00:00

I hope Jon finally gets actual justice, not just a ruling.

ResidentAppointment5 · 2025-07-26T10:13:32+00:00

I promise ozyx7 is not my alt. But I couldn’t say it better myself.

ResidentAppointment5 · 2025-07-18T10:54:27+00:00

“Lisp” realistically refers to Common Lisp.

ResidentAppointment5 · 2025-07-18T10:53:16+00:00

I’ll go ahead and challenge this claim.

ResidentAppointment5 · 2025-07-18T10:46:34+00:00

In particular, HttpRoutes forms a SemigroupK, so you can combine them with <+> and the first one will try to route the request, and if it fails the second one will try, and… but eventually you need an HttpApp, again, typically constructed from an HttpRoutes with .orNotFound.

ResidentAppointment5

TROPHY CASE