I saw your question about AWS/Lambda and you are partially right, but it’s more nuanced.
The impetus for creating FunctionScript is simple: it stems from the initial vision of Standard Library. We believe the modern web is missing a base primitive - the API. Daily, computer systems and developers around the planet make trillions of requests to perform specific tasks: process credit card payments with Stripe, send team messages via Slack, create SMS messages with Twilio. These requests are made primarily over HTTP: Hypertext Transfer Protocol. However, little to no “hypertext” is actually sent or received, these use cases have emerged in an ad hoc fashion as a testament to the power of the world wide web. Oftentimes, API standardization attempts have been presented as band-aids instead of solutions: requiring developers to jury rig a language, framework, markup language and hosting provider together just to get a simple “hello world” out the door.
By creating API development standards as part of a language specification instead of a framework, FunctionScript truly treats the web API as a base primitive of software development instead of an afterthought. This allows teams to be able to deliver high-quality APIs with the same fidelity as organizations like Stripe in a fraction of the time without requiring any additional tooling.
FunctionScript has been developed by the team at Polybit Inc., responsible for Standard Library. Ongoing development is, in part, funded by both Stripe and Slack as venture investments in the parent organization.
If you dig deep into the heritage of Standard Library you can see how (and why) autocode emerged as it did. It’s a long but somewhat interesting story of why the interweb has become one of the cornerstones of the API economy.
FunctionScript truly treats the web API as a base primitive of software development instead of an afterthought.
This is the key issue - the argument (for FunctionScript and autocode) is that HTTP(s) is an inadequate and antiquated protocol for building application interchange processes. No one can debate this. However, we can all debate how to modernize the web to accommodate and hypercharge the API economy.