1
  |> Stream.iterate(fn n -> n * 1.01 end)
  |> Stream.drop(1)
  |> Stream.take(70)
  |> Enum.at(-1)

Just a simpler way to do this 1.01 ** 70

And for the more useful comment, I can say that counting dependencies as lines in mix.lock is a very naive way to count dependencies. Let’s start that your Elixir app depends on OTP runtime, which depends on features provided by operating systems, which depend on drivers, which depend on hardware, which depends on electricity and specific temperatures and supplementary hardware, etc.

So the discussion about dependencies as the burden you-as-the-engineer have to carry is wrong, because we can support only a very little subset of software we use, and software is very little part of what products depend on. You don’t choose operating system by looking at the millions lines of code and thinking “Hmm, if a bug occurs here, I think I can find and fix it”.

I tried to come up with question which would reflect this idea, but I couldn’t, because not all ideas fit into questions which fit into article titles. But I can advice to do these things

1. Check if the maintainer of the dependency is going to fix your problems. If it’s open source, do they actively maintain it?
2. Do maintainers provide workarounds or fixes for their own dependencies?
3. Can you pay someone to fix your problems with this dependency when they occur? Maybe bug-bounty or some external consulting specializing in these kinds of problems?
4. Can you fix the problems yourself?
5. Can you replace the dependency?

It sounds similar to the original question, but the key difference here is that most of the time you don’t have to carry or think about replacing anything