There is a bridge to Rust, and nothing at the far end
RFC-0028 wired a path from byld to Rust and back. A .byd file can now call
a controller and receive the answer reactively. What it still cannot do is
anything useful with that, because the framework ships no capabilities:
- No HTTP client. There is no
reqwest/ureq/hyper anywhere in the tree.
A weather app, a feed, anything backed by a remote API, cannot make a request.
- No JSON.
serde_json exists only in byld-lsp. Even an app that brought
its own HTTP client would have nothing to parse the response with, and no way
to get the result into the reactive tree as an RFC-0027 record.
So the two-layer model currently says: write Rust. For a weather app that
means every developer writes the same controller, and gets the timeout wrong,
and forgets gzip, and picks native TLS and finds out on the first machine
without OpenSSL.
What "first-party" has to mean, and what it must not
RFC-0029 O2/O3 make these framework capabilities rather than a suggestion in
the docs, so byard new → weather app works with no Rust at all. That is only
defensible if the capability is genuinely non-privileged: an ordinary
Controller, reached through the same inject, answering through the same
ok/err arms, with nothing an app-written controller could not also do.
It also has to be honest about the choices it makes on the app's behalf, and
there are three that cannot be deferred:
A non-2xx: response or error? Both readings are defensible and the language
has to pick one, because a caller writing ok res => { data = res.json } has
already said what it wants on success, and binding a 404's error page into
data is not that.
A body that lies about its content type. A server sending
application/json with a truncated body must not fail the whole request; the
caller needs to see what actually arrived, or the server is undebuggable.
Key order. RFC-0027 records are ordered and a for over one renders in that
order, so a map-backed JSON parse would make a list of fields come back
shuffled between runs — reproducible only in the sense that it is always wrong
somewhere.
Name collisions
Once Http and Json are provided by default, they occupy names an app might
want. RFC-0029 §7 reserves them. Without that, inject Http as http would mean
different things in different apps, and a .byd file would read correctly
against the documentation while doing something else entirely.
Scope
RFC-0029 O2 (Http, reqwest + rustls) and O3 (serde_json ⇄ HostValue, the
Json capability), their feature gating, registration in both hosts, and the
reserved-name rule.
Timers (O4) and persistence (O5) are separate changes.
There is a bridge to Rust, and nothing at the far end
RFC-0028 wired a path from
byldto Rust and back. A.bydfile can now calla controller and receive the answer reactively. What it still cannot do is
anything useful with that, because the framework ships no capabilities:
reqwest/ureq/hyperanywhere in the tree.A weather app, a feed, anything backed by a remote API, cannot make a request.
serde_jsonexists only inbyld-lsp. Even an app that broughtits own HTTP client would have nothing to parse the response with, and no way
to get the result into the reactive tree as an RFC-0027 record.
So the two-layer model currently says: write Rust. For a weather app that
means every developer writes the same controller, and gets the timeout wrong,
and forgets
gzip, and picks native TLS and finds out on the first machinewithout OpenSSL.
What "first-party" has to mean, and what it must not
RFC-0029 O2/O3 make these framework capabilities rather than a suggestion in
the docs, so
byard new→ weather app works with no Rust at all. That is onlydefensible if the capability is genuinely non-privileged: an ordinary
Controller, reached through the sameinject, answering through the sameok/errarms, with nothing an app-written controller could not also do.It also has to be honest about the choices it makes on the app's behalf, and
there are three that cannot be deferred:
A non-2xx: response or error? Both readings are defensible and the language
has to pick one, because a caller writing
ok res => { data = res.json }hasalready said what it wants on success, and binding a 404's error page into
datais not that.A body that lies about its content type. A server sending
application/jsonwith a truncated body must not fail the whole request; thecaller needs to see what actually arrived, or the server is undebuggable.
Key order. RFC-0027 records are ordered and a
forover one renders in thatorder, so a map-backed JSON parse would make a list of fields come back
shuffled between runs — reproducible only in the sense that it is always wrong
somewhere.
Name collisions
Once
HttpandJsonare provided by default, they occupy names an app mightwant. RFC-0029 §7 reserves them. Without that,
inject Http as httpwould meandifferent things in different apps, and a
.bydfile would read correctlyagainst the documentation while doing something else entirely.
Scope
RFC-0029 O2 (
Http, reqwest + rustls) and O3 (serde_json ⇄ HostValue, theJsoncapability), their feature gating, registration in both hosts, and thereserved-name rule.
Timers (O4) and persistence (O5) are separate changes.