 
       def init(_init_arg) do
         children = [
-          {Stack, [:hello]}
+          {Counter, 0}
         ]
 
         Supervisor.init(children, strategy: :one_for_one)

  restart each of its children:

      %{
        id: Stack,
        start: {Stack, :start_link, [[:hello]]}
      }

  The map above defines a child with `:id` of `Stack` that is started
  by calling `Stack.start_link([:hello])`.

  However, specifying the child specification for each child as a map can be
  quite error prone, as we may change the Stack implementation and forget to
  update its specification. That's why Elixir allows you to pass a tuple with
  the module name and the `start_link` argument instead of the specification:

      children = [
        {Stack, [:hello]}
      ]

  The supervisor will then invoke `Stack.child_spec([:hello])` to retrieve a
  child specification. Now the `Stack` module is responsible for building its
  own specification, for example, we could write:

      def child_spec(arg) do
        %{
          id: Stack,
          start: {Stack, :start_link, [arg]}
        }
      end

  Luckily for us, `use GenServer` already defines a `Stack.child_spec/1`
  exactly like above. If you need to customize the `GenServer`, you can
  pass the options directly to `use GenServer`:

      use GenServer, restart: :transient

  Finally, note it is also possible to simply pass the `Stack` module as
  a child:

      children = [
        Stack
      ]

  When only the module name is given, it is equivalent to `{Stack, []}`.
  By replacing the map specification by `{Stack, [:hello]}` or `Stack`, we keep
  the child specification encapsulated in the `Stack` module, using the default
  implementation defined by `use GenServer`. We can now share our `Stack` worker
  with other developers and they can add it directly to their supervision tree
  without worrying about the low-level details of the worker.

  Overall, the child specification can be one of the following:

    * a map representing the child specification itself - as outlined in the
      "Child specification" section
    * a tuple with a module as first element and the start argument as second -
      such as `{Stack, [:hello]}`. In this case, `Stack.child_spec([:hello])`
      is called to retrieve the child specification
    * a module - such as `Stack`. In this case, `Stack.child_spec([])`
      is called to retrieve the child specification

  If you need to convert a tuple or a module child specification to a map or
  modify a child specification, you can use the `Supervisor.child_spec/2` function.
  For example, to run the stack with a different `:id` and a `:shutdown` value of
  10 seconds (10_000 milliseconds):

      children = [
        Supervisor.child_spec({Stack, [:hello]}, id: MyStack, shutdown: 10_000)
      ]

  ## Module-based supervisors

  In the example above, a supervisor was started by passing the supervision
  structure to `start_link/2`. However, supervisors can also be created by
  explicitly defining a supervision module:


      #=> %{active: 1, specs: 1, supervisors: 0, workers: 1}

  Note that when starting the GenServer, we are registering it
  with name `Counter` via the `name: __MODULE__` option. This allows
  us to call it directly and get its value:

      GenServer.call(Counter, :get)
      #=> 0

      GenServer.cast(Counter, {:bump, 3})
      #=> 0

      GenServer.call(Counter, :get)
      #=> 3

  However, there is a bug in our counter server. If we call `:bump` with
  a non-numeric value, it is going to crash:

      GenServer.call(Counter, {:bump, "oops"})
      ** (exit) exited in: GenServer.call(Counter, {:bump, "oops"}, 5000)

  Luckily, since the server is being supervised by a supervisor, the
  supervisor will automatically start a new one, reset back to its initial
  value of `0`:

      GenServer.call(Counter, :get)
      #=> 0

  Supervisors support different strategies; in the example above, we
  have chosen `:one_for_one`. Furthermore, each supervisor can have many
