@ryansch we'll write a blog post after we publish a product using #Goo, but TL;DR is the following.

1. Why?

Despite #Witchcraft library being an established functional programming "prelude" for #Elixir (#AppSignal even has a blog post about it!) and #Elixir being a 1.x language, they still deprecate key features that make #Witchcraft ergonomic[1] and refuse to accept generalizations that would further improve FP programmers' user experience[2]. We don't want to comment on how we feel about it from the industrial language design best practices standpoint, but here's the pragmatic take. We have chosen #Elixir as the backbone of our stack over #Purerl because it has #Dialyzer and #Witchcraft, otherwise we would've contributed to #Purerl instead. So, practically, for us it's the path of least resistance to fork Elixir and reclaim the functionality we assumed it will have when we were choosing our stack.

# What?

There is no way to tell what #Goo will look like in the long run (think: post #Elixir v2). Practically, #Elixir upstream feature set can be characterised as "unpredictable".

In the immediate future, #Goo shall track #Elixir and maintain an FP-friendly patchset. In the immediate future, we also will be happy to accept more functional programming features both into the language *and* into the set of libraries we support[3].

The only thing we are certain about is that #Goo will forever be a super-set of #Elixir. So if Elixir v2 will diverge from Elixir v1 entirely, most likely we'll freeze Goo in favour of developing new projects in #purerl. Unless Goo will assemble a community, that is.

Not sure this train of thought answers your questions, feel free to follow-up.

[1]: https://elixirforum.com/t/how-difficult-would-it-be-to-add-the-infix-notation-a-la-haskell/19143/26
[2]: https://github.com/elixir-lang/elixir/pull/11588
[3]: https://social.doma.dev/@goo/109940130593807791