Effect CommunityEC
Effect Community•9mo ago
spaethnl

Challenges with Learning Effect: Inconsistencies and API Surface

Hi folks. I've been thinking about a challenge that I have using/learning Effect and thought I'd share my thoughts:

In Dillon Mullroy's talk, he mentions that Effect's large API surface is part of the learning challenge of Effect, but dismisses it because Effect is, after all, the missing standard library. But while the scope is necessarily large like a standard library, I think that the large API surface isn't really the primary problem for learners.

The problem, as I see it, is the Inconsistency in the API. This leads to unpredictability, which then gets magnified by the sheer size of the API surface, and is further complicated by the lack of a clear glossary explaining what common combinators or function suffixes actually mean.

For instance, here are a couple of specific examples that illustrate this friction:

1. API differences/inconsistencies between similar structures:
* Record: Has isEmptyRecord(), toEntries(), fromIterable(), fromIterableBy(), fromIterableWith(). (Is entries() missing?)
* HashMap: Has isEmpty(), entries(), toEntries(), fromIterable(). (Missing fromIterableBy(), fromIterableWith()?)
* The different naming conventions (isEmpty vs isEmptyRecord) and missing counterparts make it hard to guess or reliably remember the correct function.

2. Discovering non-intuitive conversion paths:
An example thought process that came up recently: trying to group an Array into a HashMap
Array.groupBy() // -> Returns a Record<string, A[]>. Okay.

// Is there a direct way?
Array.groupByHashMap()? // No.
HashMap.fromRecord()? // Nope.

// pipe(Array.groupBy(), Record.entries(), HashMap.fromEntries())
// ^^^ Nope... No Record.entries()

// Ah, Record has toEntries(). Let's try that one.
pipe(Array.groupBy(), Record.toEntries(), HashMap.fromEntries())
// Finally
Was this page helpful?