This message was deleted.

I don't believe so. @big-piano-35669, @incalculable-sundown-82514, and myself are probably your best resources at the moment.

Kotlin on the JVM

Interesting! Particularly as we don't have any JVM-based languages at the moment.

Nice! Definitely eager to help here, as JVM is on our short list. we have light info in our FAQ with a pointer to the Go implementation's PR: https://pulumi.io/reference/faq.html#how-can-i-add-support-for-my-favorite-language

@bitter-oil-46081 may also be a great resource, as he's been actively working on .NET support

Probably worth also comparing notes with @bitter-oil-46081 as he was working on .NET and I bet it will be similar

I don’t know whether I’m going to do it at any point soon (pesky day job getting in the way…), but Hadi might commit someone to looking at it

If it would help, we'd love to hop on a call to discuss and walk through what it might look like

^^ what @big-piano-35669 said

My general plan of attack with .NET has been: - Get the language plugin launching and running your program, but just have your program write Hello World to stdout. This gives you

pulumi-language-<lang-name>

and you deal with the "how do I actually start the user's program" - Get gRPC generation working in your language and in your small program, use the Engine gRPC interface to send explicit log messages. This lets you know the gRPC stuff is working. - Invoke the RegisterResource gRPC call directly, to create an AWS Bucket or some other simple resource. - Build out the ComponentResource and CustomResource base classes, or whatever the analog you have in your programming model is. This forces you to think about how you want to project Pulumi in your language and come up with something like Input<T> and Output<T>. - Write few custom resources "by hand", e.g. write the implementation of the

aws.s3.Bucket

class, so you have a sense for what the code you'll have to produce from tfgen looks like. - Start to compose resources. e.g. a BucketObject that goes in a Bucket. This forces you to build out the dependency tracking in Output<T>, for example, and helps you ensure you marshal custom resources correctly. That's basically where I am at today with .NET. The big gaps left would be do get "ReadResource" and "Invoke" working, but you can actually build non trivial programs with the technology above. I think once you get to that point, the next gap is to tackle getting a tfgen backend for your language. If you're going to do it, it's my personal belief is that you should look at the go language provider to get a sense of the general architecture of a language host but once you have a general sense of things really start reading the nodejs one. I've found the types we defined there super valuable and if you have any real question of "how does Pulumi do X" it's probably the one that's going to have the most satisfying answer.

Thanks for the detailed responses all!

You can also follow my progress here: https://github.com/pulumi/pulumi/commits/ellismg/add-dotnet I've tried to make the commit history somewhat useful, but a lot of it has been: "Well, I'm smarter than I was a few days ago, let's try something new". If anything else, it will make whomever brings up a new language feel better about not getting it right the first time 😉.

That looks like a fairly reasonably scoped amount of bits to at least get going

@bitter-oil-46081 Is there any reasonable way to get involved with .NET provider, but be fed with baby steps? I think it could be fun but I really don't understand whatever you wrote above yet 😂 Not sure if such guidance would be efficient use of your time as compared to just do it yourself. Probably gets easier at later stages.