I would start from top to bottom as this is a stack trace - look at what the exact error is and then check what data is being passing to library calls.

Error at this line (most likely as I don’t know your library versions) - matches your stack trace:

It has something to do with Payload length or indirectly Payload itself?

Little more context about the app would help - is this phoenix app or elixir app with cowboy web sockets ? What versions of libraries you are using?

Start from the top - this is the root cause of the error - :erlang.iolist_size/1 is raising :badarg. The most common cause of this is passing something in that’s not the right shape.

The next two frames for :cow_ws.payload_length and :cow_ws.frame aren’t particularly interesting.

The frame for :cow_ws.websocket_send gives us another piece of information: we’re trying to send whatever the badly-shaped data is down a websocket

But the really important one is the frame after that: :cow_ws.handler_call. This is the “brains” of the websocket handler:

This is why the stack doesn’t have any application code in it - the application code is called in the first part of handler_call, and then the result of that is what’s being handled when the crash happens.

Check your code that’s sending data via websockets; has a stray {:ok, "data that should be sent"} snuck in someplace where you’re expecting just "data that should be sent"?

cowboy_websocket expects frames to match the cow_ws:frame type:

frame() :: {text, iodata()}
    | {binary, iodata()}
    | ping | {ping, iodata()}
    | pong | {pong, iodata()}
    | close | {close, iodata()} | {close, close_code(), iodata()}

close_code() :: 1000..1003 | 1006..1011 | 3000..4999

{:ok, "{\"some\":\"json data\"}"} is none of those, and it’s not an iodata either - so an error occurs.

I can’t offer you any shortcut - if you’re going to write code that interfaces with Erlang libraries (like cowboy_websocket) you’re going to need to learn some Erlang.

The comparison is a bit off. It‘s more like Scala and Java. Both run on the JVM and can interop with each other. If you depend from a Scala project on a Java library you’re better off knowing Java as well.

I also found that erlang becomes easier and easier to read with getting to know elixir.

I mean learn to love it for your own satisfaction in life. It’s not going to split from Erlang and life is too sweet to worry about things out of your control.

And yes your analogy is off. You are largely freed from writing C by the Erlang team, who are writing it for you.