This is great! Let me start by saying that we are planning to send Erlang Term Format from channels in Phoenix v1.5, as that will use less CPU and save bandwidth. So work on this is definitely welcome as well as an efficient decoder in JS (the client will continue sending JSON though).

With that said and since you are planning to drop RPC anyway, I would call it SETF - Sequential Erlang Term Format. It is sequential because it does not include PIDs and others.

With that said, my take is:

• Should we support atoms?

Yes.

• Should we support byte lists (aka Erlang strings)?

They should just be a list of integers. I.e. they should not have a special treatment. (btw, Erlang strings are a list of chars)

• Should we allow defining improper lists?

I am personally indifferent.

BERT-ng is now Ernie (not an acronym, at least for now).

Also I have prepared implementation of encoder and decoder in Rust:

I have started work on implementations in Go and JS, but contributions from more experienced developers are more than welcome. Other languages are welcome as well.

That is why I disallowed improper lists and force all lists to be proper.

Maybe loudly disallowing them in the spec yet making the encoder smart enough to rewrite as proper lists would make sense (possibly only with a relevant flag/option, so it’s not completely hidden)?

Solid implementations in other languages would rock!

That’s awesome news!

Do you plan to optionally support Erlang Term Format? Some projects does not care about how much client needs to do, but bandwidth is still a big problem for people which does not have fiber cable. I’m in small city in Poland and I could use fiber internet only after relocation. In my old flat there is still no fiber connection.

Yes, but developer in other languages could be confused as its name is sometimes different like symbols, so I think that atoms/symbols should be mentioned there.

I think like @josevalim, because I don’t like overcomplicated solutions.

I’m not sure, because I did not read about similar things when I learned about basics of other languages (which not surprised me as for some reason I mostly take a look at OOP languages). If it have value even for 1% of them then I would add it, but if not then again we do not need extra complication.

I’m sure that Erlang has support for it - if other languages based on Erlang also supports it then I would definitely say yes.

As long as you document that unknown atoms may be refused, I think you should be fine? And no atoms cache, for simplicity.

Ah, I see. Then yes, we need to handle it if you want to leverage term_to_binary out of the box.

Not sure. But note that all of this can already be achieved today too with custom serializers.