Thanks for thinking of oapi-codegen (I'm one of the maintainers) but agreed, we only target Go - maybe that'll change in the future, but there are a lot of great companies out there working on this as a problem that I'm happy not trying to compete against

thanks for being a maintainer!

There are open source generators for a ton of languages[1]! We've been reasonably happy with their output for ~5 SDKs over the last few years. We did a massive writeup on our experience at the time[2].

In the end...ongoing maintenance there was still enough of a pain that we made the decision to outsource it. For just one or two SDKs I think we probably would have kept going with it, though.

[1] https://github.com/OpenAPITools/openapi-generator

[2] https://www.mux.com/blog/an-adventure-in-openapi-v3-api-code...

oapi-codegen looks pretty cool (it seems I starred it some time ago) but for starters, it's Go only. Stainless does a bunch of languages with more on the way.

You can see an example of the Go code Stainless produces here: https://github.com/cloudflare/cloudflare-go

(I'm the Stainless founder)

That one only does Go, but it is just one of many OpenAPI generators. I used openapi-generator and was able to produce SDKs for TypeScript (angular and node), Dart (Flutter), Kotlin (andoird), and Swift (iOS). They worked great for our purposes and I really had no complaints or issues.

I guess my question is, what is the key differentiator that Stainless offers above just using OpenAPI and its huge library of existing generators?

https://github.com/OpenAPITools/openapi-generator

If it works great for you, that's great – stick with it!

From what I've seen, a lot of API developers find that openapi-generator flat-out breaks or produces broken code for their OpenAPI spec (varies language-to-language of course).

Beyond hitting the "it just works" mark more often, some other key differentiators:

1. much easier to configure & customize

2. auto-retry with exponential backoff (this is huge for our customers)

3. auto-pagination

4. overall ergonomics of using the SDK

5. internals that look handwritten (some people care, others don't)

6. one-click releases to github & package managers w/ semver, changelogs, etc

7. careful handling of edge cases (eg, will adding a new enum variant cause your Java client to crash?)

8. a long tail of more advanced features, like webhook signature verification, streaming, etc

Thanks for the question – hope this helps :)

Very helpful. Thanks for the details.