I define a language without a runtime as one that can run on bare metal without restricting yourself to a subset of the language. To use C on bare metal, the only thing you can't use is the standard library, which is not a part of the language itself (its not in the grammar, you don't need to make sure to avoid certain keywords). More simply, any program written without using an import needs to work without an operating system under it.
C++ requires runtime support because if you remove the underlying system, it becomes stunted. Keywords like 'new' and 'delete' stop working entirely, and so a program with no imports is not guaranteed to work. Any language with a GC falls under this, obviously. Rust, if I remember right, requires restricting yourself in order to do things like kernel writing.
Sigh. I didn't want to respond, but someone pointed out to me that you work at Amazon (https://news.ycombinator.com/item?id=12181599). I think it's fair to say that in a thread asking about alternatives to AWS, I was both factual and disclosed my non-trivial source of potential bias (so my statements didn't constitute spam).
Again, I don't mean this to be an ad hominem response, but I take the disclosure "expectation" seriously, and it's frustrating to see folks (competitor or not) try to squelch discussion.
If the answer is to this question is no, the answer to whether or not a new format is necessary is not automatically yes. Certainly for at least one of those formats, a reasonably performant JS implementation could be created.
The evolution of technologies goes something like this:
1. Generation 1 is statically typed / schemaful because it's principled and and offers performance benefits.
2. Everyone recoils in horror at how complicated and over-designed generation 1 is. Generation 2 is dynamically typed / schemaless, and conventional wisdom becomes that this is generally more programmer-friendly.
3. The drawbacks of schemaless become more clear (annoying runtime errors, misspelled field names, harder to statically analyze the program/system/etc). Meanwhile the static typing people have figured out how offer the benefits of static typing without making it feel so complicated.
We see this with programming languages:
1. C++
2. Ruby/Python/PHP/etc.
3. Swift, Dart, Go, Rust to some extent, as well as the general trend of inferred types and optional type annotations
Or messaging formats:
1. CORBA, ASN.1, XML Schema, SOAP
2. JSON
3. Protocol Buffers, Cap'n Proto, Avro, Thrift
Or databases:
1. SQL
2. NoSQL
3. well, sort of a return to SQL to some extent, it wasn't that bad to begin with given the right tooling.
If you are allergic to the idea of schemas, I would be curious to ask:
1. isn't most of your data "de facto" schemaful anyway? Like when you send an API call with JSON, isn't there a standard set of keys that the server is expecting? Isn't it nicer to actually write down this set of keys and their expected types in a way that a machine can understand, instead of it just being documentation on a web page?
2. Is it the schema itself that you are opposed to, or the pain that clunky schema-based technologies have imposed on you? If importing your schema types was as simple as importing any other library function in your native language, are you still opposed to it?
C++ requires runtime support because if you remove the underlying system, it becomes stunted. Keywords like 'new' and 'delete' stop working entirely, and so a program with no imports is not guaranteed to work. Any language with a GC falls under this, obviously. Rust, if I remember right, requires restricting yourself in order to do things like kernel writing.