If only this was voluntary and automated by an Open Source service provider, so that I only have to pay one monthly fee and all the FOSS that is detected to be in-use on my machine is funded.

If the OSMF takes off, I could definitely see something like this taking off.

Go is a great language because it has distinct types by default, it's not about "making invalid states unrepresentable", it's about recording relationships about a particular type of value and where it can be used ie. it doesn't matter that UserID is just a string, what matters, is that now you can see what string values are UserIDs without making assumptions based on naming conventions.

Can you add support for duplex numbers? (duplexnumbers.com)

I'm unfamiliar. Are duplex numbers specifically used in quantum computing?

This is great! There's way too many arcane text file formats (configs, Dockerfiles, workflow definitions etc) without any sort of fast feedback loop on type-safety, documentation etc.

We need more projects like this and if a system is running SystemD, this needs to be enabled and integrated with any LSP-supported editors.

Thanks for the positive feedback! The documentation needs a bit of revision, but I agree there's a lot of configuration file formats that should be supported with language servers that might not necessarily have rich AST parsing as part of their contents.

> makes it easier for integrators to build a robust integration with you

No, don't say 'easier'. It makes it possible to build a robust integration. We need to stop with this notion that omiting idempotency from an API just makes things "more difficult" to develop. Without idempotency, you garuantee that the resulting system is "difficult" to use and full of nasty issues that are waiting for the right conditions to collapse the entire house of cards you've built.

So many SaaS providers have never even heard of idempotency, let alone design it into their APIs. Many people believe you can just sprinkle it on as a library without having to think about it.

All APIs with multiple distributed servers must support idempotency. Refuse to do business with any organisations who do not design this into their APIs!

Hah, I agree, "easier" is too soft :)

> The second part demonstrates how agents communicate with each other through workflows defined in YAML

oh no

Well thousands of years from now when aliens visit earth investigating how all agents died. The cause will be all agents were buried alive when a giant YAML file fell on them. (Human would be the slaves preparing and carrying yaml files all day and deliver to agents)

YAML makes it easy to version and visualize agent interactions, but I am open to more compact or alternative notations if it becomes unwieldy

You've set the Go code to use int64 but the other faster implementations are using int32.

Schemas that support multiple languages are useful when you actually use more than one language. This is more common in large organizations and between organizations. But it might also happen if you have code on multiple platforms, for example for mobile apps.

Moreover, compiling an IDL to N languages is substantially easier than compiling implementation code across N languages, especially when generating idiomatic code is a requirement. A language purpose-built for this task is going to produce better results while having substantially lower complexity.

(My $0.02 as someone who works on TypeSpec)

Sorry, could you elaborate? If I'm creating an API using, say, ASP.NET Core or Go, I can generate OpenAPI spec out of actual implementation. How this "IDL" fits into the workflow? Is this another output in addition to OpenAPI spec?

TypeSpec is designed primarily as an API first tool as opposed to being an output. In the context of ASP.NET and HTTP/REST APIs, our goal is that you can write your spec and generate much of the service implementation and clients. From this same source of truth you could also emit clients or service implementations in other API definition formats like OpenAPI, schemas like JSON Schema, and other things besides.

In my (limited) experience so far with TypeSpec - it really shines in an API first approach, so you define your API before you implement it, but not so much the other way around.

I would have expected a bit more than type specifications, maybe some behavior specifications also? Something like Daan’s type states. But I get why we are still splitting hairs over data types.

I've been working on an API spec language where state changes can be modeled with linear logic: https://apilog.net/docs/why/ It doesn't have "schemas" yet though. Which may seem odd given they are a crucial part of this type of languages. :-) But it is because I am experimenting with different designs on that front.

Because Go is a bad language, and imposing the requirement to use it on the teams is absurd.

I think the point the author is trying to express here, is that it can be a useful in API representation, to couple the design with other representations designed by other parties.

I don't think "No Abstractions" is a good framing for this, although I would have to admit I dislike use of the term abstraction, as it implies there is a hierarchy of representations.

Alignment, if you add a uint8 tag for example, you'll end up effectively doubling your pointer size.