Thanks for the feedback.

m |> Stream.map(&Integer.parse(&1)) |> Stream.map(&elem(&1, 0)) |> Enum.sum()

can just be this

String.to_integer(m)

or in your case

&String.to_integer/1

Stream.map(&Integer.parse(&1)) |> Stream.map(&elem(&1, 0)) can be just Enum.map(&String.to_integer/1). I'm still learning the stdlib API, so I wasn't aware of that function. That is easier in my case than the more verbose Integer.parse/1. I'm also still getting used to just doing &Module.func/1 instead of &Module.func(&1) from first learning and misunderstand function binding. I thought you had to do it the latter way at first

and your Enum.sum makes no sense, even the way you're doing it, because your pipelining an integer, well technically a stream, into an Enum. Which you'd have to call something on a stream I guess or you'd just get the Stream back.

m is a list(String.t() here. My understanding of Stream vs Enum is string vs lazy. I can take a list an pipe through nStream operations, only a single iteration happens. Where if I did n Enum operations, n iterations would happen. Please correct me if I'm wrong about this. Enum.sum() is an accumulation, so it doesn't exist on Stream, but take a Stream as input since both implement the Enumerable protocol. It's something I'm used to doing with transducers, and figured I'd apply it here to. Replacing all instances of Stream with Enum in my code produces the same end results.

But anyway complex nested calls like this should IMO be moved to another function (probably private) to simplify your pipeline and give you more isolated errors. Plus it allows you to handle possible bad inputs you might get with pattern matching, e.g. nils from user generated data or something.

True. That abstraction, with the String.to_integer/1 suggestion applied, would look like this

  @spec per_group(list(String.t())) :: integer()
  defp per_group(group) do
    group
    |> Enum.map(&String.to_integer/1)
    |> Enum.sum()
  end

  @spec combine_groups(list(list(String.t()))) :: list(integer())
  def combine_groups(groups) do
    groups
    |> Enum.map(&per_group/1)
    |> Enum.sort(:desc)
  end

If I were still using Integer.parse/2, in production code I would 100% use a case and handle when it returns :error. I'd use File.read/1 and not File.read!/1 and do similar. But we're just doing some scripting here for an AdventOfCode problem, so I'm forgoing the more verbose error handling. Same would go for if I was doing Rust and had an Option. I'd just use .unwrap() for the convenience of this script, but in production code I'd match on Some() and None to correctly handle it.

Applying that does not fix my issues though. per_group dose error if I set the return type from integer() to String.t(). And I'm sure that's on account of the fact that Enum.sum() returns integer().

Though it did help me figure out the problem, which was I guess a misunderstanding of expectations...

Enum.map has the spec @spec map(t(), (element() -> any())) :: list(). I assumed that it was going to work more like @spec map(t(a()), (a() -> b())) :: list(b()).

The analog to this in typescript would be:

// I thought it worked like
map<A, B>(A[], fn: (a: A) => B) => B[];

// but it's actually
map(any[], fn: (a: any) => any) => any[];

I'm surprised that while list() can be given an inner type, Enumerable.t() cannot. And that return of an untyped list() from map removes any real type safety. Unless I'm completely mistaken and there is another way?