Here's what I tell people when I mention Erlang and then OTP: "OTP stands for 'Open Telecom Platform', but it's just badly named due to old corporate history at Ericsson. It's more of a general development framework that includes generic versions of design patterns to build pretty much any Erlang application."
I have never received questions after that about the name -- people get more interested by what it contains than what the initials stand for.
For the argument about 'core Erlang devs', the post you mention is:
1. not from a core Erlang dev
2. actually from the main Erlang developer of Cowboy, one of Erlang's most used web server/framework
3. Right that JSON is a pretty inefficient serialization format, full of ambiguities and with many undesirable limitations.
4. It's also right that JSON contains nothing regarding hypertext within its data type (ignoring JSON-schema) and is therefore a weird choice for the web and REST, where hypertext is fundamental.
> It's also right that JSON contains nothing regarding hypertext within its data type (ignoring JSON-schema) and is therefore a weird choice for the web and REST, where hypertext is fundamental.
It's easy to consume with Javascript, which is where most JSON probably ends up.
Ultimately though, something I've learned over the years is that you can either "go with the flow" and do things the way most people are, or you can try and do things your own way. Unless you're Microsoft or Google or something though, mostly, you don't have enough resources to do everything your own way, so you have to strike out on your own only where it really counts. Erlang does that in a number of places already, for sensible reasons - it's part of what makes the language so good at some things. However, fighting JSON is likely one of those Don Quixote battles that's not really going to get you much outside of some very specific contexts.
I don't disagree, but none of the comments given are otherwise false.
I've worked on real-time bidding software where the incoming protocol got changed from JSON to protobuffs. Just doing that made bandwidth costs go down majorly, CPU usage more than halved, and response times got cut.
When the question becomes "easy" vs. "good", always picking "easy" isn't very nice.
You were definitely working in a "very specific context"!
Also, I think that you have to consider how a company grows: JSON is simple to get started with. It's a good default - pretty much anyone can consume it very easily. As you explore your problem space and iterate and improve, you may realize it's not good enough. Fair enough - that's a good time to switch. But many people never reach that point, and will happily continue with JSON for a long time.
Here's what I tell people when I mention Erlang and then OTP: "OTP stands for 'Open Telecom Platform', but it's just badly named due to old corporate history at Ericsson. It's more of a general development framework that includes generic versions of design patterns to build pretty much any Erlang application."
I have never received questions after that about the name -- people get more interested by what it contains than what the initials stand for.
For the argument about 'core Erlang devs', the post you mention is:
1. not from a core Erlang dev
2. actually from the main Erlang developer of Cowboy, one of Erlang's most used web server/framework
3. Right that JSON is a pretty inefficient serialization format, full of ambiguities and with many undesirable limitations.
4. It's also right that JSON contains nothing regarding hypertext within its data type (ignoring JSON-schema) and is therefore a weird choice for the web and REST, where hypertext is fundamental.