[Skunkleton]

Yeah, I did a little test on my system where I wrote a program in C, Python, Perl, and Bash that just prints hello to the console then timed how long it took to fork/exec from bash. C takes ~0.5ms, Perl is ~1.5ms, Bash is ~2.5 ms, and Python 3 is ~35ms.

Kind of sad because there are lots of places where a python script would be a nice way to solve a problem, but I cant use it because it adds an annoying delay.

[aaronbwebber]

I think Python's primary use case has now shifted far enough from scripting to server-side web development that ~35 ms of startup time to deal with Unicode better is a worthwhile tradeoff for the majority of Python users.

It does raise an interesting question about whether there is now an opening for a new scripting language to develop. I don't think any of the well-known languages developed in the last ~10 years have been what you might call "scripting" languages.

[Skunkleton]

I am not knocking python here at all, just pointing out that it doesn't work well for some tasks. I wonder if the startup latency could be fixed though?

[hvidgaard]

In what use case, is a 35ms startup time an issue?

[rtpg]

It's not a dealkiller for most things, but imagine the opposite:

What if startup time for python scripts were 0.1ms? In this case you could imagine writing throwaway scripts and just spawning a new process every time you wanted a result. No need to build a shell to (say) hold onto a DB connection or things like that. Just write the core business logic.

That being said, for the most part, I/O is more than 35ms.

If you have a "serious" Python program, though, you easily enter seconds-long-startup from dependencies. There's some libraries that do not pay a lot of attention to this and mean things like web servers a bit more frustrating. You can no longer spin up a server when the request comes in, but must do it before.

[Skunkleton]

There are plenty of times a tool is called in a tight loop ($PS1, xargs, or a ... | while read). Paying 35 ms over and over again adds up quick.

[majewsky]

In TFA.

[hvidgaard]

I am well aware of the article, but it's nothing but "it feels magical".

Perhaps, since I haven't had any workflow lately which blocks 30-50ms on my input, I'm not the right person to comment on this. That said, the article uses python for a script that will be run multiple times from scratch every time. Perhaps an interpretated language with a known slow start was the wrong tool right from the start?

[majewsky]

Well yeah, that's the point. Plenty of people argue that Python is good enough for any job (except maybe kernel modules, but hey, people even wrote kernel modules in Java, with the obvious consequences). Plenty of people also argue that a runtime of 50ms is not worth optimizing anymore. And I disagree.