I'd finished up a heavy bit of work. I wanted to process it. It's good work, and I'm proud of what I've shipped. I wanted to walk over to Lafayette Park, sit, and give myself a quiet "mission accomplished."
But I couldn't. The park's blocked off. There are high barricades (walls), guards, and it is now entirely inaccessible.
I work for the United States and even Oppenheimer couldn't enjoy *our* "commons."
gonna have claude code prototype atproto account integration? it's friday and i haven't hit my weekly usage cap yet. (for sale: my time and some claude code usage credits, get at me.)
Roughly the nail on the head of why I can't use Scala at work:
[W]hat killed Haskell is the parochialism, the inability to address the needs of the Enterprise... If we’re going to survive in the end, we have to address problems that everybody has. Otherwise someone else will address those problems. - Alexander Granin, memeing Robert C. Martin
I'd disagree with the characterization as parochialism, though. I've met enough talented functional programmers to know that it isn't really an ego thing. It's more about what excites a certain kind of person paid to code when they wake up in the morning.
Early in my career I got caught up in languages and frameworks, like lots of developers. But something happened that may not happen to every programmer, but certainly changed my mind about my work: I started working with non-profits, educational institutions, and the federal government, on software adjacent to problems whose outcomes I cared about. I've been fortunate enough to find work where the mission matters, and to keep drawing from the well of important problems.
But this colors my experience, as a developer, and as an open source user and contributor.
My customers don't care about Cats Effect, or ZIO, or Kyo. Heck, I don't think they know the difference between Java and JavaScript, let alone http4s and Spring Boot. Three effect libraries, but it takes weeks to get auth running on http4s because nothing like Devise exists (well, until I'd shipped Apollo).
And so I agree that what's killing functional programming is its abstractness from concrete problems. Certainly there are snobs in FP, but I don't think the majority of FP programmers are snobs, merely that functional languages scratch a very specific itch for certain kinds of programmers. Especially programmers who hate bugs, and spaghetti.
The Rust vs. Scala Native conversation too appears similarly: talented folks doing crazy cool stuff, then no ecosystem is built around it, so nobody uses except a group of people you could probably fit around a conference table.
I've been using Scala off and on for around eight years or so. I like the language, and I hope it succeeds. But I'm also a realist, and I'm not sure the people who make Scala great are the same kind of people who can ever make Scala popular.
There's a whole universe of great things happening in the Scala ecosystem I just don't see often, or really even think about, because I live so far up the stack, right alongside my customers. This window into Cats Effect on Scala Metals is pretty inspiring. I can't easily cross-compile Tertulia due to Doobie (though JDBC should be replaceable with Skunk), plus some of my other fun features, like processing Anki stats and rendering genuinely good social media previews.
distinguishing 許可 (permission), 依頼 (favor-requests), and instruction-seeking in Japanese — てもいい vs ばいい vs てもらえる and the whole benefactive ladder: combining/parsing at speed is tough, needs work
Caught up on flashcards, did some grammar, did some listening. Current pain point is discrimination between types of requests — e.g. asking permission, vs. asking how to do something, vs. asking for a favor — and request direction/actors — e.g. asking to borrow something, vs. asking someone else to lend you something. All the forms are familiar. How they're combined, and in which context, is new.
The first is invitation-gated registration à la DeviseInvitable, which exists because while toying with the multi-user branch I decided that an invitation system would be the right way to limit who's allowed to register. It's now part of Apollo, not Tertulia. Flip it on and registration requires a code — members can mint invitations (or anyone can, if you want a waitlist), the invitee gets an invite link to their e-mail, and following it allows you to register via the existing registration form. No template changes, invite codes ride their own short-lived cookie, and the user-facing messages travel through the existing flash middleware. Codes default to expiring after a week, but this is adjustable.
The second is more humbling. I announced 0.1.0 in the http4s Discord. Justin Reardon looked at my API and gently pointed out that since every service returns EitherT[F, Throwable, _] , over IO results in two error channels (IO has its own error channel, plus Either's Left) carrying the same type (Throwable). In my ignorance of this, and because the type checker didn't suggest to me this was an issue, when I wrote the original code I ended up splitting failures between them by the happy accident of liftFing my service code into the shape of an EitherT in some places, where in other places I'd simply wrap an Either-returning block of code in an EitherT . Depending on the lift, some errors are catchable, and some sail past every case Left in the codebase and hit the server-level error handler. (liftF lifts the success path only. The one that includes errors is .attemptT. Oops.)
0.2.0 fixes this. There's now a proper AuthError enum — EmailTaken, ResetNotFound, and friends — on the typed left, and infrastructure failures stay in F's own channel. I figure, essentially, that some errors are recoverable, and some aren't: the ones that are I want to match on, so they can be handled correctly in the UI, and the unrecoverable errors; e.g. the database is unavailable; just need to log correctly. The HTTP routes also no longer import java.sql to sniff SQLStates for error handling, which should have been a smell, but I'm a n00b.
It's a breaking release — every service trait changed — but that's what 0.x is for, and better now than after anyone besides me depends on it. Thank you for your code review, Justin. I know LLMs will one day probably be able to one-shot a lot of this code, and maybe it's silly to think the Scala/Http4s community needs this module, but it's useful to me!