I don't follow this. My assumption for the repository interface is something like (language, error and domain agnostic):

   interface Repository<T> {
      FetchAll() T[]
      Fetch(id) T
      Persist(T) id
   }

Why would the SQL statements be reflected in the behaviour that the interface is providing?

Such a thing exists: https://github.com/BurntSushi/go-sumtype

  Location: Amsterdam, The Netherlands
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, TypeScript, Rust, Terraform, Kubernetes, Containers, FP
  Résumé/CV: https://www.linkedin.com/in/william-martin-41400517/
  Email: william[dot]la[dot]martin[mailsign]gmail[dot]com

Things I enjoy:

  Mentoring
  Pair Programming
  Test Driven Development
  Systems Engineering
  Team Psychological Safety
  Balanced Teams
  Feedback

Looking for a Senior/Staff level Individual Contributor role. I'd enjoy a job using a language with great domain modelling support (e.g. F#, Rust, Elm) to continue learning how to do that well. I'd enjoy a job where I can continue learning from others directly, as well as mentor others directly.

I find "A Secret Sleeping in the Deep Sea" really takes me back to my childhood.

They don't want to keep the unmapped value in the resulting collection at all. flatMap allows for removal of an element in one traverse, unlike filter+map with eager behaviour.

Then why not just use a fold?

Sure, there's many ways to skin a cat. Given the option, I wouldn't choose either of these, and instead use something like filterMap[1] which I think conveys intent better than a fold or flatMap.

Btw, I'm assuming that the original map questioner wasn't solely using flatMap for side-effectful iteration, which reading again, I'm a bit suspicious about.

1: https://gcanti.github.io/fp-ts/modules/Array.ts.html#filterm...

tRPC is a good choice for TypeScript: https://trpc.io/

> The only thing that's different is that you get a single value you have to check for errors rather than a separate value..

The type system confines you to a set of reasonable cases that allow a caller to reason about the state of the program. This has two benefits for the caller:

1. It is required that the caller check whether a return value is success or failure in order to access the value they want. There is no possibility to mistake one case for another.

2. In the space of valid return values for idiomatic Go function signatures, 50% of them are unidiomatic and end up being ignored. It is far clearer for a caller to understand what is expected of them when valid values exactly overlap with the space. It is far clearer for an author to convey expectations to a caller for the same reason.

Now I must admit, good conventions and tooling in Go account for the vast majority of cases and I don't personally mind that much, but that's a different conversation than API design.

Just some anecdotes from an expat: My landlord is 80+ and cycles everywhere. My parents in law are 75+ and are about to get rid of their car altogether since they either cycle or take public transport. My aunt in law is close to 80 and changed from manual to electric bike a few years ago after a stroke.

yea. plenty of places in the world where people don't have cars in general and afaik old people get by just fine. Japan does not have good bike infra like the netherlands but the majority of people don't use a car much either

Seems like this would be a bit confusing though? `fmap` (flatMap) corresponds to `bind` or `chain` (Monad) rather than `map` (Functor) right?

Nope, `fmap` is indeed short for functor map. It's a historical accident in Haskell as `map` was specialised for lists (ie. `[]`) from the start and later, when mapping would be generalised to all things Functorial, it needed a new name so as to not break everything, hence `fmap`.

Awesome thank you for the clarification. I extra agree with the confusion then since `fmap` sounded exactly like `flatMap` to me!

No, "fmap" is actually the name in Haskell given to the function defined by the Functor typeclass. It was named "fmap" ("f"unctor map) because "map" was already taken by the map specialized to lists.

`flatMap` is actually called `concatMap` in Haskell, or more generically the monadic bind operator `>>=`.

At https://story.ai we're using Shipyard ECS to model the data behind the structured editing experience. Although at first I was suspicious, I've come to realise it's an extremely elegant way to handle our complexity.

Consider for example, a snippet that reads along the lines of:

    when there is a new stripe charge
       send a slack message

It's very nice to attach something like a "ScopeContext" component to each Entity that has a "TokenLine" component, that is a Vec of EntityIds that are sharing values into scope. Very easy to model and add without interfering with other data structures.