Hacker News Reader

Comment by keithwhor | Hacker News Reader

This is what we’ve done at StdLib [1] with FaaSlang [2].

FaaSlang uses static analysis and a superset of ESDoc comments to infer types for the API interface to serverless functions on our system. This allows for automatic type coercion from query parameters, automatic error checking, and more - all caked in at the gateway layer before a function is executed.

Zero configuration; just write comments the way you normally would. It’s almost a healthy midpoint between TypeScript and JavaScript, operating above the runtime, but theoretically applicable to any language run within a function container.

[1] https://stdlib.com

[2] https://github.com/faaslang/faaslang/

View on HN

Honestly I stopped reading as soon as I saw the name of your project - really, it's called "stdlib"? What good can possibly come from that name? Either the confusion will prevent your product from ever succeeding; or, less likely but just as annoying, you'll grab meaningful mindshare and everyone here will have to change their vocabulary to accommodate your semantic landgrab.

I've noticed a growing trend of startups trying to do this, and it just annoys me immensely. How hard is it to invest in your own original brand?

We chose the name as a reference or throwback, of course, to <stdlib.h>. We’re <stdlib.com>, and we allow developers to utilize serverless technology to make shipping custom logic (functions) simple and create a Standard Library of APIs within their organization or contribute to a public library.

From the inception of the product we knew we were building a library - well, a publishing and hosting platform combined - but really, a library of APIs. The very first name we came up with was “stdlib” and, through a stroke of fate, “stdlib.com” was available.

We don’t take the name lightly. We understand we stand on the shoulders of giants, and it is our responsibility to create the best “stdlib.com” we can. It motivates and inspires our team members. That is why we chose the name.

It’s unfortunate you have a problem with this, but we’re very thankful to our developer community, team, partners and our investors for their support. :)

> The very first name we came up with was “stdlib” and, through a stroke of fate, “stdlib.com” was available.

maybe everyone who thought of that name before you laughed and said "I'm not that kind of person"

Interesting.

I just went through this a bit and it doesn't appear that the specification allow for polymorphism in the type system. Am I missing something here?

If that's true, it doesn't seem to address the issues highlighted by the paper, although does handle simple type checking across interfaces of primitive types.

To be clear, it seems you have basic coercions (a la C, or ad-hoc polymorphism) but no general support for subtype polymorphism nor parametric polymorphism.

Also, I have to sign up for stdlib? Do I have to pay for it? (Never got that far, and the fact I have to sign up is quite misleading for something called stdlib.)

You have to pay for APIs / Functions that the individual vendor charges for (if the functions are not free) - for example, MessageBird charges $0.005 per SMS sent [1] using their sms.create function.

You also pay a nominal fee per ms of compute used when somebody uses an API you’ve built.

But you can get started for free - $5.00 of credits included that should cover up to 100,000 requests, if you’re really experimenting feel free to message our team (my email is in my profile here, I think).

[1] https://stdlib.com/@messagebird/lib/sms

Not yet! But the specification is still under very active development. We try, as best we can, to solve customer needs ahead of nice-to-haves (though the latter still important!).

But, if you're assuming EsDoc, you're already inherently tied to JavaScript/TypeScript/etc, no?

Part of the point of the paper is assuming non-uniformity between APIs, hence the IDL.

Also, it remains unclear how you expect to support parametric polymorphism if you're assuming JavaScript as a base language for your analysis.

What can I say? We’re a team of hackers. It’s not our goal to solve every problem immediately, just the ones facing us and our developers today. We wanted an abstraction simple enough to ship to our community and customers but robust enough, conceptually, to be built out into a fully expressive language. (Hence FaaSlang.)

ESDoc is JavaScript specific, but the concept of relying on comments to infer types is not, nor is the JSON format we store function execution information in. :)

(Well, I mean, we rely on JavaScript-translatable types — but can create parallels to other runtimes and languages.)

Reply on news.ycombinator.com