Hacker News Reader

Comment by cmeiklejohn | Hacker News Reader

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.

View on HN

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