Closed ospencer closed 2 years ago
Can we just refer to the Language Support page here? Maybe add an extra "SCN Support" column to the table if the Atmo/SCN support differs?
I actually made a PR for this last week but forgot to link the issue. My bad!
Hmm. I'm not a huge fan of that language support page. I think Reactr should more be talking about what interface the WebAssembly modules should be adhering to / what libraries exist rather than language support, since any language that complies to WebAssembly is technically supported (from a Reactr point of view). Maybe linking out to some Subo documentation for "here's a build tool that makes it easy for certain languages, go check it out."
It's just a different way of thinking vs. the Compute docs, where you don't have access to subo
at all, and I wouldn't want to confuse people by mentioning subo/command line flags. But open to some other opinions here.
Hmm, good points. To be honest initially the language support page I envisioned as talking about the nitty-gritty of the ("Suborbital-flavored") Wasm "support", that is, what languages are able to interact through the Suborbital build tooling with the runtime when used to compile Subo runnables for. I am super open to bikeshedding about where this documentation should live, but I did not know whether there was a marked difference between "what SCN can handle/support" and what Atmo does at any given time.
I think the more parallels we can make between Atmo and SCN ("it's the same thing"), the more we can help the ecosystem grow. Since, well, to my understanding they are pretty much the same (minus release-cadence-related skews).
Here: https://docs.suborbital.dev/compute/integrate-the-function-editor/code-editor#configuration
Looks like we're missing
javascript
andtypescript
as options. I don't think there'stinygo
support just yet.