
On 28 January 2017 at 02:11, C Anthony Risinger <anthony@xtfx.me> wrote:
I can't articulate it we'll, or even fully isolate the reasons for it. All I really know is how I feel when peers ask me about Python or the reading I get when others speak about their experience using it. Python is absolutely one of my favorite languages to write, yet I find myself recommending against it, and watching others do the same. Python comes with caveats and detailed explanations out the gate and people simply perceive higher barriers and more chores.
Picking up on this and the comment you made in the original post
With a still difficult distribution/compatibility story, I've watched dozens of instances where people choose something else, usually Node or Golang.
Can you explain why you recommend against Python, in a bit more detail? If you are an enthusiastic Python user, but you are steering people away from Python, then it would be worth understanding why. As you mention end user applications and distribution, one of my first questions would be what platform you work on. Following on from that, what sort of end user applications are you looking at? If we're talking here about games for iOS, then that's a much different situation than GUI apps for Windows or command line tools for Linux. My personal feeling is that Python happily works in the "Command line tools for Linux" area (except possibly with regard to C extensions where the plethora of Linux ABIs makes things hard). But other areas less so. I've been having good experiences making standalone applications with the new Windows "embedded" distributions, but that is relatively new, and still has a lot of rough edges. I'm working on a project to bundle a working zipapp with the embedded distribution to make a standalone exe - would having something like that make any difference in your environment? So I think it would be good to understand precisely where and why you feel that you need to recommend Go or Node over Python. It's possible that we have to accept that your situation is simply not a use case that Python is well suited for, but equally it may be that there's something we can do. Paul