7 ms·

I just don’t get why they absolutely had to come up with new syntax. All of this would have been possible with standard Typescript, unlocking heaps of existing

by 9dev 2y ago

I just don’t get why they absolutely had to come up with new syntax. All of this would have been possible with standard Typescript, unlocking heaps of existing tooling, editor support, and prior knowledge. But no! Let’s come up with a new language, bespoke compiler, new LSP and IDE integrations, and make developers learn yet a new DSL. It’s creating changes for the sake of creating changes.

wg0 2y ago
"Looks good on my CV" syndrome.
- dham 2y ago
  I'm not sure why you're getting downvoted. It might be hitting too close to home for some. But yeah, 95% of developers choose things to do to boost them for the next job.
  - wg0 2y ago
    I believe that 99% of the time, a reuse of older technologies results in greater innovation that is more stable and a return is multiple of the underlying foundations. This applies here as well. Typescript could go a long way. But admittedly, writing a grammar, parser and then a whole compiler along with its tooling of a new DSL is fun for sure but does look good on CV as well. I didn't say anything more than that.
  - jitl 2y ago
    I downvoted both of your comments because I think it's rude and insulting to assume the motivation of someone's work is self-aggrandizing, and to dismiss out of hand the work might be motivated by technical needs because you can't immediately recognize those needs. I find the attitude frustrating, similar to the other common HN dismissal of "I could build it in a weekend".
- mardifoufs 2y ago
  Is that why a lot of teams inside azure use it for their API? Do all of them just do it for their CV? Or maybe it is that you're missing something ?
sixhobbits 2y ago
https://www.speakeasy.com/guides/api-frameworks/typespec https://www.speakeasy.com/guides/api-frameworks/typespec This post has a bit more detail about why "we don't need more standards" might not be the correct take here (Disclaimer speakeasy is a client but I wasn't directly involved in writing this and just figured it's pretty relevant here)
- lostmsu 2y ago
  Nah, it doesn't really say why they didn't just use TypeScript.
- startupsfail 2y ago
  Pydantic/FastAPI - it is well designed, industry proven. Doesn’t need custom DSLs.
  - samier-trellis 2y ago
    Came here to post this. We use Django Ninja at work (basically FastAPI style endpoints for Django), and it automatically does OpenAPI and Swagger docs for us. Whatever web framework one chooses in whichver language should def have this built-in by now, IMO, seems like tablestakes for anything larger than a "micro-framework"
  - lknuth 2y ago
    Having your Framework generate the Docs is nice, but doesn't always fit. At work, I build backends for mobile applications. When designing new APIs to be consumed by apps, we want input from the mobile developers. We facilitate this by having an api-specs repo with TSP and using Pull Requests to discuss, track and finally commit on new APIs. It also allows mobile developers to open PRs with changes they want. The contracts are basically an interface that both sides can discuss and agree on.
crowdyriver 2y ago
It's even worse, you still need node to run this thing, so you don't avoid the node dependency.
bterlson 2y ago
We first tried a TypeScript DSL and I really wish it would have worked for our use cases (e.g. describing complex REST APIs in Azure), but unfortunately it didn't. I explained a bit more here last time TypeSpec was on here: https://news.ycombinator.com/item?id=39843184 https://news.ycombinator.com/item?id=39843184
pc86 2y ago
You don't get a bonus and promotion for just using TypeScript.
- ActionHank 2y ago
  Facts, bonus-driven "innovation". Also why Google has so many dead products.
  - ivanjermakov 2y ago
    "3 years of experience with TypeSpec"
- drewcoo 2y ago
  Corollary: Not even a patent cube.
thrance 2y ago
Off the top of my head, I don't think you can perfectly describe the type (string format) of an UUID in typescript types, which you can do with OpenAPI. That may be a reason.
- bterlson 2y ago
  You can get by, e.g. you can use JSDoc comments describing format or pattern, generic types taking a parameter of either format or pattern along with a base type, or create a custom well-known type you define as having the properties of a UUID. But aside from comments, this is not reflected well in the tooling, and none of these options compose particularly well.
- n2d4 2y ago
  You can do it with template string types: https://ybogomolov.me/type-level-uuid https://ybogomolov.me/type-level-uuid
  - throwitaway1123 2y ago
    The built in DOM types for the browser's `crypto.randomUUID` function actually already use this technique to a lesser extent: https://github.com/microsoft/TypeScript/blob/121c5dd36bd87e47a065ff7d6b220ce6d079075c/src/lib/dom.generated.d.ts#L5971 https://github.com/microsoft/TypeScript/blob/121c5dd36bd87e4...
- erikerikson 2y ago
  See n2d4's comment but also AJV's JSONSchemaType import { JSONSchemaType } from 'ajv' It will bridge the JSON Schema and TypeScript types We've found this useful too: import { OpenAPIV3_1 as oa } from 'openapi-types' export type Schema<T> = JSONSchemaType<T> & oa.SchemaObject We validate that the type aligns with the schema and load the schema to validate all incoming requests

by 9dev 2y ago

wg0 2y ago

"Looks good on my CV" syndrome.

dham 2y ago
I'm not sure why you're getting downvoted. It might be hitting too close to home for some. But yeah, 95% of developers choose things to do to boost them for the next job.
- wg0 2y ago
  I believe that 99% of the time, a reuse of older technologies results in greater innovation that is more stable and a return is multiple of the underlying foundations. This applies here as well. Typescript could go a long way. But admittedly, writing a grammar, parser and then a whole compiler along with its tooling of a new DSL is fun for sure but does look good on CV as well. I didn't say anything more than that.
- jitl 2y ago
  I downvoted both of your comments because I think it's rude and insulting to assume the motivation of someone's work is self-aggrandizing, and to dismiss out of hand the work might be motivated by technical needs because you can't immediately recognize those needs. I find the attitude frustrating, similar to the other common HN dismissal of "I could build it in a weekend".
mardifoufs 2y ago
Is that why a lot of teams inside azure use it for their API? Do all of them just do it for their CV? Or maybe it is that you're missing something ?

sixhobbits 2y ago

https://www.speakeasy.com/guides/api-frameworks/typespec https://www.speakeasy.com/guides/api-frameworks/typespec This post has a bit more detail about why "we don't need more standards" might not be the correct take here (Disclaimer speakeasy is a client but I wasn't directly involved in writing this and just figured it's pretty relevant here)

lostmsu 2y ago
Nah, it doesn't really say why they didn't just use TypeScript.
startupsfail 2y ago
Pydantic/FastAPI - it is well designed, industry proven. Doesn’t need custom DSLs.
- samier-trellis 2y ago
  Came here to post this. We use Django Ninja at work (basically FastAPI style endpoints for Django), and it automatically does OpenAPI and Swagger docs for us. Whatever web framework one chooses in whichver language should def have this built-in by now, IMO, seems like tablestakes for anything larger than a "micro-framework"
- lknuth 2y ago
  Having your Framework generate the Docs is nice, but doesn't always fit. At work, I build backends for mobile applications. When designing new APIs to be consumed by apps, we want input from the mobile developers. We facilitate this by having an api-specs repo with TSP and using Pull Requests to discuss, track and finally commit on new APIs. It also allows mobile developers to open PRs with changes they want. The contracts are basically an interface that both sides can discuss and agree on.

crowdyriver 2y ago

It's even worse, you still need node to run this thing, so you don't avoid the node dependency.

bterlson 2y ago

We first tried a TypeScript DSL and I really wish it would have worked for our use cases (e.g. describing complex REST APIs in Azure), but unfortunately it didn't. I explained a bit more here last time TypeSpec was on here: https://news.ycombinator.com/item?id=39843184 https://news.ycombinator.com/item?id=39843184

pc86 2y ago

You don't get a bonus and promotion for just using TypeScript.

ActionHank 2y ago
Facts, bonus-driven "innovation". Also why Google has so many dead products.
- ivanjermakov 2y ago
  "3 years of experience with TypeSpec"
drewcoo 2y ago
Corollary: Not even a patent cube.

thrance 2y ago

Off the top of my head, I don't think you can perfectly describe the type (string format) of an UUID in typescript types, which you can do with OpenAPI. That may be a reason.

bterlson 2y ago
You can get by, e.g. you can use JSDoc comments describing format or pattern, generic types taking a parameter of either format or pattern along with a base type, or create a custom well-known type you define as having the properties of a UUID. But aside from comments, this is not reflected well in the tooling, and none of these options compose particularly well.
n2d4 2y ago
You can do it with template string types: https://ybogomolov.me/type-level-uuid https://ybogomolov.me/type-level-uuid
- throwitaway1123 2y ago
  The built in DOM types for the browser's `crypto.randomUUID` function actually already use this technique to a lesser extent: https://github.com/microsoft/TypeScript/blob/121c5dd36bd87e47a065ff7d6b220ce6d079075c/src/lib/dom.generated.d.ts#L5971 https://github.com/microsoft/TypeScript/blob/121c5dd36bd87e4...
erikerikson 2y ago
See n2d4's comment but also AJV's JSONSchemaType import { JSONSchemaType } from 'ajv' It will bridge the JSON Schema and TypeScript types We've found this useful too: import { OpenAPIV3_1 as oa } from 'openapi-types' export type Schema<T> = JSONSchemaType<T> & oa.SchemaObject We validate that the type aligns with the schema and load the schema to validate all incoming requests