This message was deleted.

hey @purple-coat-73595! we have #C01PF3E1B8V but here is just fine! You cannot define infrastructure in the same stack in multiple languages and I don’t think we’ll ever support that. Regarding this:

I know that there are multi-language Components but my use case is a little bit different: My main code is written in Golang and I wanted to allow other developers to write parts of the infrastructure in a different language (for example TypeScript).

I believe multi language components meets this use case. Is there something you can see doesn’t meet your needs?

It is probably doable with multi-language Components, I would have to do some experiments. I think that using them is too much overhead in my use-case as I know exactly that the main code is written in Golang. I would love something like sending Pulumi context over the wire to another process and using hashicorp/go-plugin to communicate between my main code and other languages.

that is basically what MLCs do… 😅 are you wanting to define two resources in different languages in the same stack?

Exactly - one stack, more than one language. For example, the app is being deployed to AWS ECS in the main Golang code, but the database would be created in the TypeScript code. My problem with MLCs is that you have to write the schema, generate all the code for different languages, etc. It is perfect when you want to have a universal component and use it in multiple languages but I feel like it is too complicated in my use-case and it is designed for something opposite than I want to achieve.

you can define different projects and use stack references for that sort of thing export the required outputs from the AWS ECS project, and then have a different project with the database that imports those outputs

I know that and it is partially what I am doing now (using the automation API). But having it in a single stack/project would be great. You said "that is basically what MLCs do…". So maybe it is possible to serialize the pulumi context using protobuf or something like that?

not without some serious legwork. Ultimately, we’ll probably need support multiple languages in the same project

Thank you @billowy-army-68599! For now, I just wanted to know my options. But when I really need it, I would be glad to help in implementing it.

Ultimately, we’ll probably need support multiple languages in the same project

I'm not sure if we'd support this exactly, but we are going to make it a lot easier to write MLCs and to link local copies of MLCs to projects. Which would have a very similar end result in that you could have one folder of typescript code to write a component, and another main folder of go code that uses it.

If you need beta testers for this evolution count me in