My deepest conflict with Python as someone who works with it professionally is balancing "keep it simple and clean" with an acknowledgement that reality is often is complex and messy.
Synchronous, mostly functional python scripts written with the standard library and perhaps a few dependencies generally feel like the best the language has to offer, and they frequently make great prototypes (and I have put a few in production).
But I have also dealt with a lot of important stuff that felt like the wrong tool for the job:
- Airflow tasks, and durable workflows as a whole on top of a database
- async stuff, and generally the fact that you need `aiofile` to interact with the filesystem asynchronously
- "Productionized" stuff around NumPy and DataFrame APIs. I think there are genuinely fascinating uses for this stuff and its still great! JAX stood out as the the API that truly "clicked" for achieving "simplicity" despite the difficult challenges that it solves.
Typing woes appear the most when I am handed a prototype to productionize. Good static analysis of types carries you so far, it makes me frequently wonder if something even more aggressive than what TypeScript does would have been ideal. There is a great scripting language trapped underneath a mountain of adjustments that have been made to Python so it can "be used for writing large scalable software systems" and it makes me question whether that ever should have been the point of Python in the first place.
P.S. INB4 Stroustrup quote about languages people complain about vs ones they don't use and all that. You can tell Go was designed for very specific use cases and hasn't catered too much to use cases outside of that.
My deepest conflict with Python as someone who works with it professionally is balancing "keep it simple and clean" with an acknowledgement that reality is often is complex and messy.
Synchronous, mostly functional python scripts written with the standard library and perhaps a few dependencies generally feel like the best the language has to offer, and they frequently make great prototypes (and I have put a few in production).
But I have also dealt with a lot of important stuff that felt like the wrong tool for the job:
- Airflow tasks, and durable workflows as a whole on top of a database
- async stuff, and generally the fact that you need `aiofile` to interact with the filesystem asynchronously
- "Productionized" stuff around NumPy and DataFrame APIs. I think there are genuinely fascinating uses for this stuff and its still great! JAX stood out as the the API that truly "clicked" for achieving "simplicity" despite the difficult challenges that it solves.
Typing woes appear the most when I am handed a prototype to productionize. Good static analysis of types carries you so far, it makes me frequently wonder if something even more aggressive than what TypeScript does would have been ideal. There is a great scripting language trapped underneath a mountain of adjustments that have been made to Python so it can "be used for writing large scalable software systems" and it makes me question whether that ever should have been the point of Python in the first place.
P.S. INB4 Stroustrup quote about languages people complain about vs ones they don't use and all that. You can tell Go was designed for very specific use cases and hasn't catered too much to use cases outside of that.