Pure Gleam will get you really far without having to touch any Erlang, I've done Gleam for almost a year now and there were very little cases where I needed to write Erlang code myself, usually there's already a library that deals with it for most common needs :)
> Could you say something about the cases where you did need to write Erlang code?
Sure! For one of my most used packages (https://github.com/giacomocavalieri/birdie) I needed to get the terminal width to display a nice output, that has to be implemented using FFI based on the specific runtime (erlang or js) so I had to write it in Erlang, that was just a couple of lines of code.
But now there's a Gleam package to do it, so if I were to rewrite it today I wouldn't even need to write Erlang for that and could just use that!
> What kind of cases?
Usually it is when you need some functionality that has to rely on specific things from the runtime (like IO operations, actors on the BEAM, async on the JS target, ...) and there's no package to do it already.
Most of the common things (like file system operations and such) are already covered
> Were you already proficient in Erlang and its ecosystem?
Not at all :) I knew very little about Erlang (basically nothing behind the syntax), Gleam was my introduction to the BEAM ecosystem and it has worked out great so far!
Hope this is helpful, happy to share my experience here
If you error from Erlang or Elixir you will get the error as those languages construct them, even if you call that code from Gleam. The Gleam build tool attempts to print them more nicely than Erlang does by default, but it cannot add additional information to them. Gleam runtime errors have more information attached to them.
In practice runtime errors in Gleam are rare. The one place you'll likely have to deal with poor Erlang errors is if you are writing Erlang code to create Gleam bindings to an existing Erlang library.
