I am with @mindok on this one.
In a mutable language where variables can be changed under your nose, breakpoints are more useful in my opinion.
If you have such a big elixir/erlang function that you cannot keep track of the values of variables - and a breakpoint is the best(?) way to verify the value/state is what you expect; I think you may want to consider breaking that function up, so it is easier to comprehend.
Tools like :observer are also quite useful for real time debugging - as a breakpoint in the IDE does little to assist in understanding the rest of the state of the runtime at that point in time. This is a result of erlangs actor model, and concurrency characteristics - that traditional imperative languages do not use.
Also the built in :debugger module that opens a window will struggle in certain environments, like VScode + WSL, as there is not a xdisplay for the window. Not sure if this is what the elixir-ls breakpoint stuff relies on, but if developing in an environment that does not have native GUI capabilities, the functionality might not work.
Am also interested to hear compelling use cases for using breakpoints in the beam, as I might be missing something!
