openai-python VS jsii

Check the official migration guide for updates.

Okay, I know Tesla's extremely high P/E ratio is because it's worth is not just tied to cars, and so xAI priced at $20B more than Anthropic does not necessarily mean xAI's AI products are that much better than Anthropic's (e.g. presumably xAI's worth is tied to synergies with Tesla FSD, Optimus, and maybe even Neurolink)...but what products does xAI actually offer, other than Grok being an add-on for premium X subscriptions?

Not only does the Grok API not have access to Grok 3, which was released more than a month ago, it doesn't even have it's own SDK? [0]

> Some of Grok users might have migrated from other LLM providers. xAI API is designed to be compatible with both OpenAI and Anthropic SDKs, except certain capabilities not offered by respective SDK. If you can use either SDKs, we recommend using OpenAI SDK for better stability.

(every code example has a call for `from openai import OpenAI`)

How would using Grok be viable for any enterprise? And if Grok's API is designed to be drop-in replacement for OpenAI's, how are they not able to just use Grok to whip up their own SDK variant based on OpenAI's open-sourced SDK [1] and API spec?

[0] https://docs.x.ai/docs/guides/migration

[1] https://github.com/openai/openai-python

If you want to get an idea for the changes, here's a giant commit where they updated ALL of the Python library examples in one go from the old chat completions to the new resources APIs: https://github.com/openai/openai-python/commit/2954945ecc185...

The API itself is pretty straightforward. You can use it with the OpenAI package on NPM or PIP, or make an HTTP Request. Note for this demo I will be using NodeJS. I will be working in an empty folder with an index.js file, and a package.json file.

To interact with the OpenAI API, you will install the openai package:

Python was chosen for its versatile libraries, particularly linkedin_jobs_scraper and openai. These packages streamlined the scraping and processing of job data.

The essential library for this project is OpenAI, supported by two helper libraries. Install them with the poetry dependency manager a shown:

There is no functional difference between the different languages, so your choice of language does not limit your features. Under the hood, AWS CDK uses a tool named jsii. It allows for class libraries written in JavaScript/TypeScript to be used from other languages, enabling the AWS CDK team to provide many languages with the same functionality.

May also be useful for creating automatic language support from a single codebase. For example, Amazon uses JSII to build a typescript library into Python, Go, dotnet, etc.

Maybe this tooling will help add PHP to that list.

That way you are not maintaining 6 codebases.

https://github.com/aws/jsii

Depending on the type of infrastructure or third party services you’re planning to use, you might not be able to use all available constructs. For instance the constructs maintained by DataDog are only available in Typescript, Python and Go. In my personal experience though, most construct developers are open to support Java. Third party constructs are based on projen and jsii, which means that adding a Java based version is most of the time a matter of configuration in the package.json file of the project.

What about jsii? The technology behind AWS sdks: https://aws.github.io/jsii/

Is Stainless similar, different?

The libraries for other supported languages of CDK are built as wrappers for underlying JS or maybe TS code via https://github.com/aws/jsii

So all the core CDK code is written first in JS/TS and then stubs for the other languages are added

Unfortunately this is often done without consideration for how the other supported langs actually work, and artefacts of e.g. JS lack of support for kwargs leak through

This is why e.g. the typing in CDK Python is completely broken - pretty much uniformly the concrete types like "Resource" don't implement their corresponding interface like "IResource" (to a type checker)

(There are many other typing niggles like this but that's the most egregious and pervasive one)

At the end of the day, having to explicitly cast concrete types as their interface to satisfy type checker is a minor annoyance, albeit a stupid one that could have been avoided with more care in the core library.

I could live with that, but I encountered so many bugs and issues trying to use CDK on current project that it's now much clearer to me why every company I worked at previously was using Terraform.

Pretty sure some of those issues are ultimately CloudFormation ones. The cumbersome CF > CDK JS > CDK Python stack is great for obfuscating errors and making debugging hard or impossible though.

Pulumi do something similar, albeit with Go as the core language and Terraform underneath. From what I've seen with a little use they have a much more successful result though, Pulumi Python was not a complete mess, and deploys faster and more reliable with better error feedback. I guess they just took more care to get it right.

Every version of the CDK uses an interop layer and runs on top of the Typescript version

https://github.com/aws/jsii

And as far as TF supports services before CFT. Guess which is easier for an AWS employee to do - getting the CF service team to support a new service or just contribute to Terraform’s open source project?

I know of at least one service where the service team introduced the needed APIs and then an employee of AWS wrote the TF provider and contributed to the project before AWS’s own internal team added it to CFT.

Source: former AWS ProServe employee

To "meet developers where they are" is a beautiful tenet of AWS, and of the CDK, and inspired us to create awesome technology such as JSII and constructs.

Yeah both CDKTF and Pulumi piggyback on JSII, a class translator that supports the languages you've mentioned, which was used as a building base for CDK.