Keep in mind you'll be using a different language in the future. All software is maintained for a given amount of time and then sunset. What matters is the lifecycle of the thing you're making now. Pick whatever is maintainable for that application and time frame.

Throwaway script? Use anything. A mobile app? Whatever gets it on the devices you're targeting today, that works for the life of the device/OS/etc. A backend API that will power a large platform? Something maintainable (by people other than yourself) for 3-5 years. Firmware for IoT that will remain in industrial systems for 20 years? Something that is well established and supported with a good number of other people who can fix it in the long haul.

▲

dangoor 3 hours ago | parent | next [-]

Something interesting about your comment is that HN also has a post today (https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...) about TigerBeetle's support for Zig and their reason for using Zig specifically talked about wanting something for a long time horizon:

> Investing in creating a database like TigerBeetle is a long term effort. Databases tend to have a long half life (e.g. Postgres is 30 years old). And so, while Zig being early in 2020 did give me pause, nevertheless Zig’s quality, philosophy and simplicity made sense for a multi-decade horizon.

	▲	0xbadcafebee 14 minutes ago \| parent [-]
		If Zig's core developers decided tomorrow they wanted to do something else, would that result in the rest of the devs slowly leaving, and Zig being unmaintained after a couple years? Might be possible; but it would be impossible with C, C++, Java, etc. If you give me a choice between two products, one in Zig and one in Java, and I need to run it for two decades, I'm picking the Java one (and I dislike Java)

▲

wilkystyle 4 hours ago | parent | prev [-]

I like this take. While I've primarily lived in Python for much of my career (and I don't see that changing soon), I've tried to find reasons to use other languages in at least a hobby capacity so that I can (1) keep my learning muscles warmed up and (2) because they can often shape how I think about software in general.

Like the Alan Perlis (I think) quote goes: "A language that doesn't affect the way you think about programming is not worth knowing."