Greenfield Project: What SDK would you choose?

We have a very-nextgen, prototype, no-forseeable-path to production project going to explore new directions of a product. It is virtually greenfield and we have the luxury of being completely unopinionated about language of workflow or client.

What SDK would you choose if you wanted an SDK where the least amount of “gotchas” existed. For example, I know in the upcoming TS SDK there is a wonderful vision for not needing to use custom time or random libs as all these have been or will be hooked out in the V8 layer or similar, so it will theoretically be quite “transparent” to the workflow code with minimal impact or special-awareness in writing workflow code (correct me if I am wrong, @maxim )

How do the Go and Java SDKs compare here?

Again, we do not care at this point what the production status of a given SDK is, we’re considering how we start playing with things here and want to understand if there’s a substantive difference between SDKs in such things like the upcoming TS SDK may provide a more transparent DX, etc.

Being feature-complete up-front isn’t necessarily a requirement, either, of course.

I ask, because as I staff this project I need to choose which engineers I assign, and if the Go SDK is appreciably better DX I choose different people :).

What SDK would you choose if you wanted an SDK where the least amount of “gotchas” existed.

I would say that TS SDK is the one we believe will be the most user-friendly. And your understanding of its model is correct.

How do the Go and Java SDKs compare here?

In the near future, they will continue to have feature parity with other SDKs. But they will not provide the type of isolation that V8-based SDKs would be able to.

1 Like