I was thinking to do some testing with Pulumi and ...
# general
w
I was thinking to do some testing with Pulumi and would like to know what is "recommended" language or is there any?
f
After playing around with different languages I found the Typescript implementation robust enough and well documented. Will have to look into the new C# part more deeply though. Python does also seem to make to job rather well but as most members of our team are more familiar with Javascript, Typescript and C# we rather prefer Typescript
w
ok thanks for information
I am not so familiar with Typescript but that does not look too complicated
f
it isn't šŸ˜‰
w
started with python but I may take a look typescript as well
g
Generally speaking TypeScript and Python are the best supported and popular language options for Pulumi. Out of the two TypeScript is imho objectively the better language because of its very strong type system. That means you're getting better code completion and have to lookup less often the docs on what properties are valid in a given context.
o
I donā€™t know anything about TypeScript, but saying that Python is objectively worse just because the type system is better in TypeScript sounds like itā€™s ignoring a lot about a very popular language that has been in active development for many years. Is it really?
I mean, if I were to switch to a different language from Python Iā€™d go with Go, not Typescript.
w
Python make sense for me because I have done a lot of lambda things with it and it is commonly used in data analytic side as well
o
And there are type checkers for Python, too. Including one built by Microsoft. Might even be part of some future official release, who knows. If thatā€™s the only advantage Typescript over Python, itā€™s something, but doesnā€™t sound like that much.
w
didn't wanted to start any language war šŸ™‚
and kind of get response from geekflyer that TypeScript and Python are best supported
I am just doing some small POC testing so language is not so big issue at this moment
o
TypeScript is definitely better supported, especially in the documentation department. Itā€™s simply easier to navigate. They are working on the Python docs.
w
I mainly work with AWS and GCP at this moment but have plans so study Azure as well
if basic things are working with those then it is enough
o
If you know both, go with Typescript. But if you know one of them, go with whatever you know. Pythonā€™s docs are harder to work with, but you can get away with it with multiple tabs open. If you understand a bit of Typescript, that also helps, you can peak at ā€œthe other sideā€ if you get stuck.
w
I have done a lot of Python so it is more easy for me at this moment. I do not have any Typescript experience
o
Then Iā€™d say go with Python. Thereā€™s much to unpack, adding language syntax in the mix doesnā€™t help IMO.
w
ok thanks for info
g
ok, I guess I should reduce the scope of my statement a bit. I think TypeScript is the better language for writing Pulumi programs. That is, if you and your team have the same level of experience in Python and TypeScript, I think it is wiser to choose TypeScript, mainly because of it's stronger type system. I totally understand that Python has introduced a type annotation syntax with Python 3.6 and there's mypy as a static type checker, but the whole ecosystem and checker capabilities (and integration of mypy with pulumi) and type system capabilities are just not yet on the level of TypeScript. I would say the maturity and adoption of the Python type system are roughly at the level TypeScript was 3 years ago. Re Go: I'm actually spending most of my work day writing Go backend code, but it's type system is objectively a lot worse than both Python's 3.6 type annotations and TypeScript's type system and you have to write a lot more code to get things done. For something like Pulumi, where you write a short-lived program that simply expresses / constructs a target-state (and the facto is just programmatically constructing some config that you would otherwise have written in YAML / JSON / TF) all the performance and concurrency features of Go are practically irrelevant (i.e TypeScript, Python is fast enough for this) and Go's verbosity and type system will just make it harder and more time consuming for you to express a valid target state. A simple example is that in Go functions or structs you cannot easily denote a property as mandatory or optional. All my statements of course ignore the level of familiarity you and your team has with a particular language, which is of course also important when choosing one language for a project / task.
šŸ‘ 1