bterlson

9 ms·

31.
by bterlson 3y ago
Codegen is coming online as we speak. We do codegen from TypeSpec in Azure across multiple languages, and the results are pretty great. We're moving that over to the TypeSpec project so everyone can generate code. Obviously my opinion
32.
by bterlson 3y ago
Extensive experience inside Azure. In general, supporting existing APIs is harder, predominantly because it might not sufficient to produce a semantically identical OpenAPI when downstream tools are sensitive to e.g. whether something is a
33.
by bterlson 3y ago
Hey, nice work on openapi-code-generator, its output is very nice. I think you could probably package it up as a TypeSpec emitter without too much difficulty, by emitting OpenAPI and feeding it to your generator. I am doing a similar thing
34.
by bterlson 3y ago
I answered in more detail in another comment, but we actually tried this first, and couldn't make it work for the kinds of complex APIs we deal with in Azure. But, it worked great for simple APIs, and I hope someone releases such a too
35.
by bterlson 3y ago
It's LSP, and we also have a VS extension in the marketplace.
36.
by bterlson 3y ago
Our first attempt at a TypeSpec-like thing was in fact a TypeScript dialect! It works great for simple cases, but at the limit it falls over for a number of reasons. HTTP needs a lot of metadata that isn't found in TypeScript, things l
37.
by bterlson 3y ago
Hey, author here. Right now we don't have any streaming or eventing support, but I am working on it as we speak. My first goal is to support describing SSE and JSONL HTTP streaming endpoints, but I want to work toward an AsyncAPI emitt
38.
Write OpenAPI with TypeSpec(blog.trl.sn)
118 points by bterlson 3y ago|72 comments
39.
by bterlson 3y ago
If you use the fetch API you can get a readable stream and party on without too much difficulty. You can also implement a transform stream in ~10SLOC that will make the reader vend parsed JSON objects and can be reused easily.
40.
by bterlson 3y ago
I agree, but SSE is a more complex protocol that requires additional handling on both client and server, with capabilities that may not be relevant for your use case (multiple event types, event id). For JS clients and JS servers it is not
41.
by bterlson 3y ago
Great comparison. Would love to see http response streaming added to the mix. I think a lot of use cases involving finite streams sent from server to client can be handled by the server streaming JSONL in the response. I tend to prefer this
42.
by bterlson 3y ago
This is a great question. We think OpenAPI is great and TypeSpec is a great way to write OpenAPI, but OpenAPI has some challenges generating high quality, language ideomatic code for complex services. Generating code straight from TypeSpec
43.
by bterlson 3y ago
Thank you! We take most of our inspiration from TypeScript and sometimes C#, but I agree that gql demonstrates the value of terse, highly readable specs quite nicely.
44.
by bterlson 3y ago
Since there's a lot of show and tell going on, I'll jump in too I suppose. I work on a tool in this space called TypeSpec (aka.ms/typespec) that aims to address some of the authoring concerns folks have with OpenAPI. We'
45.
by bterlson 8y ago
The current speed of iteration means you get updates in smaller batches rather than more throughput. Still important, but it's not like we're letting proposals bake less. Note how so far we've only gotten two big new features
46.
by bterlson 8y ago
Babel has a lot of plugins, and hopefully people don't have to learn all of them. How many people use stage-0 plugins for bind operator or do expressions? You're right that Babel (and TypeScript!) implement features earlier than t
47.
by bterlson 8y ago
I think it's good to note that this proposal is not far along the process. Pattern matching, if it clears TC39 (a tall order, to be honest), won't land in a spec for half a decade at least I would bet. So, keep the feedback coming
48.
by bterlson 9y ago
Yes, this is by no means normative! Nothing will happen without a long discussion and consensus among dozens of people. TC39 has a meeting later this month where I imagine this will discussed in more detail. Also, assuming we can't use
49.
by bterlson 9y ago
More strongly, the draft is incomplete by its very nature. If you care about having only complete and ratified standards, do not use the GitHub snapshot. Use the official versions hosted on ECMA's website ( https://www.ecma-i
50.
by bterlson 9y ago
If anyone has any data on this topic I would love to hear and understand it!
51.
by bterlson 9y ago
Official standards are moved to ECMA's website. E.g. ES2017 is here: https://www.ecma-international.org/publications/files/ECMA-S... . The GitHub site is mostly targeted toward implementers who are always work
52.
by bterlson 9y ago
I hear ya. Once the spec is finalized for the year I produce a change log. I have done so in between versions before but things tend to be menial and/or change a lot and it was a lot of work for not too much gain. Willing to go back on
53.
by bterlson 9y ago
There are many proposals sitting at the cusp of the stage 3 to stage 4 transition. There will be a couple more meaty things to make it. I suspect we'll end up with more proposals ready than I have time to integrate into the main spec :
54.
by bterlson 9y ago
Probably not ES2018, but 2019 is looking likelier now thanks in part to excellent work by Daniel Ehrenberg (@littledan).
55.
by bterlson 9y ago
I will be writing the ES2018 intro prose around when we send ES2018 draft to ECMA for ratification (few months away yet).
56.
by bterlson 9y ago
Wow, oddly relevant - I've been working on a RegExp implementation in JavaScript using similar techniques (minus vectorization of course, RIP SIMD.js). There is no efficient way in JavaScript to replace many patterns (e.g. a list of se
57.
by bterlson 9y ago
I'm sorry I missed your comment earlier, but hopefully replying later is better than never :) ChakraCore is cross-platform now so we no longer get the benefit of a single platform. However back when we were only Windows there were adva
58.
by bterlson 9y ago
Agreed, Octane was good as far as benchmarks go but you have to balance with a much larger set of benchmarks and always ground your work in real-world scenarios (something we focused heavily on from day one e.g. when we realized having an i
59.
by bterlson 11y ago
Thanks for your thoughts :) We've updated the roadmap[1] to call out that JIT and more platforms are coming in future iterations. 1: https://github.com/Microsoft/ChakraCore/wiki/Roadmap
60.
by bterlson 11y ago
The goal is for all of ChakraCore to be broadly cross-platform eventually, including the JIT, and including many more platforms than just Ubuntu x64. The roadmap reflects our next steps for the next 6 months but is not the entire journey. D

More ›