
Yes, Python is Slow, and I Don’t Care - mithunmanohar1
https://hackernoon.com/yes-python-is-slow-and-i-dont-care-13763980b5a1
======
scarface74
I was all ready to savage his opinion after reading the headline but I agree
looking at my architecture that I designed for the company I work for, CPU
isn't the bottleneck. Every time I try to increase performance by multi
threading as much as possible, the databases start screaming.

On the other hand, the idea that dynamic languages are more productive than
static languages are laughable. Statically type languages prevent a lot of
bugs and allow for a lot of automated provably correct refactorings that
simple cannot be done with a statically typed languages. You can't even
reliably do a "find usages" of classes using a dynamically typed language.

~~~
carlmr
>On the other hand, the idea that dynamic languages are more productive than
static languages are laughable. Statically type languages prevent a lot of
bugs and allow for a lot of automated provably correct refactorings that
simple cannot be done with a statically typed languages. You can't even
reliably do a "find usages" of classes using a dynamically typed languag

Exactly, I get quick and precise code completion, I catch plenty of errors
beforehand etc. I'd say I'm about 10x as productive in C# as in Python, with
similar amount of experience. Python only shines when there is a library that
does something really well that you need. For me any productivity advantage in
Python is from lots and lots of libraries.

Also in terms of maintainability, I find my C# code easy to read and modify a
year later when I've forgotten completely about it. In Python I need to rescan
all of the types into my head until I can understand what the program does.

I mean with var and dynamic, C# offers everything you need for duck typing
efficiency, while preserving the very important statically typed interfaces.

~~~
bluntfang
>In Python I need to rescan all of the types into my head until I can
understand what the program does.

Couldn't that be solved with sane variable naming conventions and
docstrings/documentation?

~~~
scarface74
Maybe. But it can be more easily solved on a strongly typed language where you
can right click on a method and do "find usages" and it can. E done
algorithmically.

------
freetime2
I pretty much agree with everything in the article - except for the bit where
he tries to quantify why python is better from a developer efficiency
perspective than other languages.

The main example he cites is a study that compares the amount of time writing
string processing routines in different languages - which is quite a bit
different from the work I do every day. I develop web apps which means I
generally work in very large code bases, and spend most of my time modifying
existing code rather than writing fresh code from scratch. I have found that
statically typed languages (java + typescript) and the fantastic IDE support
that comes along with them make it really easy to navigate around the code and
refactor things. Also - the compiler tends to catch and prevent a whole class
of bugs that you might otherwise only catch at runtime in a dynamically typed
language.

Of course there are other situations where I prefer to use Ruby as my
scripting language of choice - it all comes down to using the right tool for
the job at hand. Unfortunately I don't think the author gives enough
consideration to the trade-offs between static vs. dynamically typed
languages, and I think he would have been better just leaving that section out
as it isn't really necessary to prove his point that CPU efficiency isn't
important in a lot of applications.

Ultimately though I completely agree with his main point: "Optimize for your
most expensive resource. That’s YOU, not the computer."

------
mangecoeur
Python is also heavily used in science, where performance really does matter.
It's successful because of how highly ergonomic python apis can be built on
top of optimised C/C++/Fortran libraries.

That said, there is clearly a desire to write 'fast' code in python itself
without swapping to C. Cython helps, but to get really fast Cython code you
actually have to write with C-semantics (so you are basically writing C with
Python syntax).

Projects like numba JIT are interesting in that they can optimise domain-
specific code (i.e. numerical/array code) that's written in normal python
style. It also means jumping through a few hoops (although with the latest
version in many cases all you need is a single decorator on your hot
function). You can even do GIL-less multithreading in some cases.

Overall things are looking promising, with the addition of the frame
evaluation API and possible improvements to the python C-api that could make
JIT and similar extentions easier.

------
boomlinde
The author argues from his professional experience as a Python developer that
it's fast enough, that you'll spend most time waiting for I/O anyway, that you
can just throw more servers at the problem etc.

The problem is that his experience as a Python developer doesn't accurately
reflect the prevalence of problems where runtime CPU performance actually is
an issue. Of course not, because who in their right mind would make an
informed decision to solve such a problem in Python? Python has worked for him
because it is only useless for a category of problems that he hasn't had the
opportunity to solve because he's a Python developer. Outside this
professional experience, not everything is a trivially parallel web service
that you can just throw more servers at if CPU time exceeds I/O waiting.

It all really boils down to what your requirements are, whether you have all
the time and memory of a whole server park at your hands, or a fraction of the
time available in a smaller embedded system, how timely the delivery of the
software has to be and how timely it needs to deliver runtime results once
it's up and running. There are times where Python just isn't fast enough, or
where getting it fast enough is possible, but more convoluted and tricky than
implementing the solution in a more performant language. Developer time may be
more expensive than the platform that my solution is for, but that doesn't get
around the fact that it eventually will need to run with the available
resources.

------
agentgt
Unless we are talking like circa 1999 I don't think I have heard a complaint
yet that Python is slow. I'm curious who or where the author heard that from
(not specifically the people themselves but the domain they are in).

What I have heard complaints about Python are (and I don't agree with all
these points):

* Its not statically typed

* The python 2/3 compatibility

* It has some design flaws: GIL, variable assigning, mutable variables, lambdas, indentation (I don't agree with all these but this is complaints I have heard).

* The plethora of packaging (ie its not unified)

I guess one could argue its slow because it can't do concurrency well but that
really isn't raw speed.

Then the author started comparing string processing of programmer time from a
study which... doesn't help the authors point at all.

* Python has and will always be fast at string processing and most people know this

* The people that complain about python speed are almost certainly not doing string processing

* I have serious questions about the study in general (many languages have changed quite a bit since then)

~~~
pg314
> I'm curious who or where the author heard that from (not specifically the
> people themselves but the domain they are in).

In the telecom domain, I've dealt with data big enough that Python wasn't
really feasible. Think 100 of millions of records in CSV format that need to
be parsed and processed. Doing that in Python is going to be painful.

~~~
classybull
Python is insanely fast at data processing and analysis because it has very
fast libraries.

As a matter of fact, don't know if you've heard, but data processing it kind
of like.. Python's thing...

~~~
mattkrause
You're violently agreeing with each other.

Python _itself_ can be pretty slow. Doing image processing on data stored as
list-of-lists-of-integers would be brutally slow.

On the other hand, numpy is an import away, and it can be quite fast,
especially if it's been built with an optimized BLAS/ATLAS, etc.

~~~
AstralStorm
By blazingly fast you mean 100x slower than C++ equivalent and only 20x slower
is you're very careful to avoid accidental copies.

For reference, MATLAB is about 30x slower with no special care. Pure Java on
Hotspot was 5x slower except it dies on big data input due to very slow GC and
goes to 50x slow.

Source: handled big audio data from hdf5 database, gigabytes sized. C++
equivalent had no vectorization or magic BLAS or anything.

~~~
joshuamorton
As I'll often say to these comments, then you're doing things wrong. Numpy
code can be written to never leave the numpy sandbox, and at that point it
should be as fast or faster than naive c++ (because you'll be getting SSE and
stuff for free).

There's a reason almost all deep learning is done in python.

~~~
pg314
Not all data is a good fit for Numpy: some data is non-numeric or not a
homogenous array.

> There's a reason almost all deep learning is done in python.

The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make
sense because it is one of the few sanctioned languages inside Google, and it
is widely used outside of Google and easy to pick up.

~~~
joshuamorton
>The heavy-lifting in e.g. TensorFlow is done in C++. Bindings to Python make
sense because it is one of the few sanctioned languages inside Google, and it
is widely used outside of Google and easy to pick up.

That's exactly the same as with numpy. I'm not sure what your point is. C++ is
also one of the few sanctioned languages inside google, as is Java.

>Not all data is a good fit for Numpy: some data is non-numeric or not a
homogenous array.

I'm curious what kind of data you're working with that can't be represented
and effectively transformed in a tensor (numpy array).

~~~
pg314
> That's exactly the same as with numpy. I'm not sure what your point is.

I was replying to "there's a reason why...". You didn't specify that reason,
so from the rest of your comment I took it to mean that Python (with numpy)
was fast and good enough to write deep learning stuff. That doesn't seem to be
the case for TensorFlow.

> I'm curious what kind of data you're working with that can't be represented
> and effectively transformed in a tensor (numpy array).

I'm not intimately familiar with the internals of numpy, but my understanding
is that the basic data structure is a (multi-dimensional) array of values (not
pointers). That leads to a number of questions.

If you have an array of records (dtype objects), and one of the fields is a
string, am I correct that each element needs to allocate memory to hold the
longest possible value that can occur for that field? What if that is not
known beforehand?

How do you deal with optional fields (e.g. int or null)? Do you need to add a
separate boolean to indicate null?

How do you deal with union types, e.g. each record can be one of x types, do
you make a record that has a field for each of the fields of those x types? Do
those fields take up space?

~~~
joshuamorton
>You didn't specify that reason, so from the rest of your comment I took it to
mean that Python (with numpy) was fast and good enough to write deep learning
stuff. That doesn't seem to be the case for TensorFlow.

Tensorflow tensors are numpy arrays, or are transparently viewable as such.

>If you have an array of records (dtype objects), and one of the fields is a
string, am I correct that each element needs to allocate memory to hold the
longest possible value that can occur for that field? What if that is not
known beforehand?

Yes, although you can also store numpy arrays of pyobjects, which are arrays
of pointers. You'll be able to vectorize the code, but you won't get the same
performance improvements as with a normal numpy array, because that same level
of performance isn't possible with an array of pointers.

Note that for most machine learning applications, you'd preprocess your string
into a vector of some kind.

>How do you deal with optional fields (e.g. int or null)? Do you need to add a
separate boolean to indicate null?

Yes, but I'm not sure when you'd do that. That is, again in most machine
learning applications you'd be representing things as one-hot arrays or as
some kind of compressed high dimensional position vector, where 0 would
represent a lack of presence of some thing.

>How do you deal with union types

dt = np.dtype((np.int32,{'real':(np.int16, 0),'imag':(np.int16, 2)})

is a 32 bit int that can also be accessed as a 16 bit complex number via .real
and .imag.

------
icebraining
"It doesn't matter than Python is slow, besides we can use compiled libraries
to speed it up"

"People saying it doesn't matter that Python is slow are deluding themselves
and preventing Python from getting faster like JS did"

"Python is inherently harder to optimize than JS since it has <very dynamic
features>"

"Smalltalk/Lisp/etc are also very dynamic yet are much faster"

"The slowness of Python is harming the planet by being inefficient and
therefore wasting more energy/producing more pollution"

Did I miss any arguments? I know certain topics are bound to attract some
repetitive discussion, but "Python is slow" has been one of the worst.

~~~
dom0
> "Python is inherently harder to optimize than JS since it has <very dynamic
> features>"

Python is not a very dynamic language in the sense that you actually _can 't_
change a lot of stuff (and a number of the things you _can_ change just
segfault CPython). I think JS is more dynamic, for example. Or Ruby.

~~~
icebraining
These are not my arguments, mind you; I don't know enough to make them.

You've piqued my interest, though: can you give me an example of those things
that you can't change or that break CPython?

~~~
dom0
Things like the Carlo Verre hack (also a thing you can't change —any more— in
Python: builtins), editing objects during their construction (via e.g. gc)...
generally, the gc module allows other ways as well to crash your interpreter.

    
    
        >>> import gc
        >>> 'foo'.lower()
        >>> gc.get_referents(str.__dict__)[0]['lower'] = str.upper
        >>> 'foo'.lower()
        segmentation fault (core dumped)  python
    

(That's the method lookup cache)

A talk in this direction is
[https://www.youtube.com/watch?v=qCGofLIzX6g](https://www.youtube.com/watch?v=qCGofLIzX6g)

------
Waterluvian
Python is my Swiss army knife. I love it because it is a single tool that can
aid in almost every project I do. But if I'm doing one specific thing a lot, I
want that thing to be done well and done efficiently, so I'll reach for the
specific screwdriver I need.

Also most of my problems are IO bound so single threaded concurrency is fine.

But I represent a very small portion of the global problem space.

------
dom96
The fact that Python is slow isn't its only problem. What I care more about
nowadays is wasting my time hunting bugs that could have been avoided by a
static type system.

~~~
blumomo
Please tell me, do you write tests? I've learned that it's necessary. I do
100% code coverage and I'm enjoying TDD a lot.

~~~
virmundi
The whole point of static type systems is that they give you the "type tests".
100% code coverage just to get what the compiler would give you is a waste of
time. If python is supposed make developers more productive, this is just
dragging them down.

------
dahart
Python's value to me has always been that it's easier to get things done, not
it's speed. One time when I was interviewing a candidate for a coding job, the
candidate said she loved Python the most "because you can just yell at it and
it'll work."

It's both the breadth of the standard library and ecosystem, and the simple
language design, that make developing things in Python faster for me.

Doing problems on Project Euler has been an education for me in how algorithm
matters more than speed. Lots and lots of people spend hours writing long C++
codes that are easily beaten by a few lines of Python. It certainly goes the
other way too, and the wrong algorithm in Python is even that much slower and
more painful than the right algorithm in C++. But when the right algorithm is
used and the problem is solved in a few milliseconds, it really doesn't matter
which language uses more CPU cycles, all that matters is whether you saw the
insight that let you skip 99% of the search space, and how much time you spend
writing code.

------
_pmf_
Somewhat ironically, Python is used a lot for things that would benefit from
raw speed (data processing pipelines) and do not benefit at all from dynamic
typing (since the kind of property bags / data frame views over data are
easily replicated in statically typed languages). But Python's C extension API
is quite a bit easier than p.e. Matlab's MEX API (to me at least); can typical
Python IDEs compile and relink extension modules without an external build
step?

> Your bottleneck is most likely not CPU or Python itself.

With applications that are dominated by raw data processing, it's very, very
easy to be CPU dominated. Hell, I had one quite trivial data converter for
logfiles where the "parsing the printf string" part of Java's printf dominated
processing and writing a custom formatter halved processing time (while
regexes can be compiled, the format string cannot be precompiled and will be
interpreted each time); it's one of those things where I would intuitively say
"why did this moron write his custom formatter" if I stumbled upon it in a
code review. Intuitively, you'd expect this to be a simple case of an IO
dominated task (which it is now once the bottleneck has been removed).

If it's fire-and-forget batch jobs, you can get away with it, but if the
converter is part of a user facing fat client application that runs on a old
office laptop, you don't have that luxury.

------
kodablah
The article could be titled: "Yes, Python is Slow To Refactor and Maintain,
and I Still Don't Care".

I never understand why dynamic language enthusiasts primarily focus on new
code only. You have to discuss all sides of increased or decreased
productivity to make a rational argument.

~~~
hasenj
Python is optimized for getting interesting things done in a few lines of
code. Small scripts you write once and then forget.

For serious projects? IMO python is a disaster.

------
wyldfire
> Your bottleneck is most likely not CPU or Python itself.

I've found that this is often the case. Nearly always disk or network. But
it's sometimes surprising how little work you need to do to become CPU-bound.
This is the price we pay for such a tremendously dynamic language.

Indeed, the article's suggestions of C/Cython/PyPy are good ones to remedy the
problem when it occurs.

------
jayflux
I get the point this guy is making, but if you need something parallel for a
cpu bound task, throwing more hardware at the problem isn't the most efficient
solution if you can just use more cores. For example adding another quad core
when the first cpu is only using one core anyway is inefficient and expensive.

Right tool for the right job I suppose.

~~~
nhumrich
Python does multiprocess very well. You can easily use all cores on your
machine. Pythons main "disadvantage" is threading because of the GIL. But each
process gets its own GIL. So when you multi process, your not limited to one
core.

~~~
classybull
This. I had a problem where I needed to scrape roughly 20,000 html documents
daily, which is normally a pretty slow task. You have to open the file, load
it into memory, parse the DOM, and then run all of your selection methods.
Sequentially, it took about 60 minutes daily. Multithreading slowed it down
because it was CPU bound. Multiprocessing allowed me to run 12 processes
across 8 cores. That took the total processing time down to about 4 minutes or
so. And I was able to write the code in a day. Writing something similar in
Java or C++ would have taken me a week.

------
nadam
"It used to be the case that programs took a really long time to run. CPU’s
were expensive, memory was expensive. Running time of a program used to be an
important metric."

As hardware gets faster we give it new tasks that could not be achieved
before. Like rendering high resolution stereoscopic images using physically
based shading at 90 FPS on relatively cheap consumer hadware (VR). There are
still quite a lot of code that we call 'performance critical'. Most of that
code is written in C/C++ (and CUDA and glsl, and hlsl, etc...) today.

~~~
ivm
It's still expensive on client machines because most of the persons in the
world are NOT software engineers with 6-digit salaries.

They run cheap computers with HDDs and Windows polluted by a ton of 3rd party
crap. They don't know how to fix it and silently suffer.

I was cleaning a local vet clinic's devices recently – they were literally
switching between two computers to not wait 5 minutes of non-responsiveness
because some bloated software was occasionally consuming 100% of CPU.

~~~
mark-r
A lot of businesses these days prefer web apps. It's not hard to understand
why - all the hassle of system maintenance falls to the people who host the
app and can afford to know their stuff. If your Windows PC is suffering from
rot just replace it with a Chromebook.

~~~
ivm
"Just get money for a new device out of thin air and just replace all your
paid or even cracked Windows software with subscription-based alternatives
that will not work without Internet. Ah, also just relearn all your
workflows."

Sorry, but that's how being in a bubble looks like.

~~~
mark-r
I wasn't suggesting that businesses were anxious to replace things that
already work, I'm suggesting that as they acquire new software it's more
likely to be web-based.

Devices are often replaced on a schedule anyway, especially if they're leased.

~~~
ivm
I wasn't talking only about businesses in my previous reply. But most
businesses on the planet aren't bathing in money either.

You are speaking as a citizen of a rich country where devices are relatively
cheap and stable Internet is available everywhere.

------
VHRanger
The problem is not so much that python is slow. It's that in some scenarios
python can't be made fast.

Fast prototyping is great but being stuck with a prototype for deployment
isn't.

~~~
traverseda
>It's that in some scenarios python can't be made fast.

Can you give some examples of this? I mean, obviously with enough effort you
can "make python fast" since it has good C bindings, and can just be a thin
wrapper around fast stuff. Similar to how command line tools can be
ridiculously fast[^1] despite, ostensibly, running in bash.

So I'm a bit confused about what you're claiming. Organizational issues, it's
difficult to get management on board with an optimization pass?

[^1]: [https://aadrake.com/command-line-tools-can-be-235x-faster-
th...](https://aadrake.com/command-line-tools-can-be-235x-faster-than-your-
hadoop-cluster.html)

~~~
VHRanger
My point is do you have competent C programmers on your team?

That said, there is a point in some python prototypes where you "hit the
performance wall". For whatever reason, you'll need to look at one of the
options to make python faster and none of them are painless unless you're
already a serious C programmer.

------
traverseda
There's are still some big gains python could make, if python implementations
were better.

Micropython is equivalent to a real-time cooperative-multitasking OS. If it
had ~~better~~ support for things like cffi, you could implement posix on top
of it. I can imagine a laptop that runs gnu+python in the next few years.

That's a whole new usecase, simply because that implementation uses a lot less
ram. What usecases would we discover for a faster python?

Shared objects and proper sandboxing would also be huge.

~~~
jerf
"There's are still some big gains python could make, if python implementations
were better."

At this point, I would find it far easier to believe that you are
underestimating the difficulty involved in what it takes to speed up Python
than that there are enormous gains yet to be had in speeding up Python. I
suspect JS has had more optimization effort expended overall, but Python has
still had a ton of work by lots of smart people, and generally got an earlier
head start on optimization. (They didn't start trying to make JS "fast" right
away; they spent rather a lot of time getting JS's hookup to the DOM in the
face of things like .innerHTML working first, before anyone even cared to do
what we today do routinely without thought in plain ol' Javascript, let alone
with our glorious frameworks.)

There are enormous gains to be had in speeding up "a language that is like
Python except certain things are banned", but people have already done _that_
analysis too and discovered that broadly speaking, if you do that, too much
existing Python breaks. If you want to see something like that, check out the
RPython aspect of the PyPy project, which successfully implements a fast
subset of Python. But it is a noticeably restricted subset of Python; AIUI
it's not even close to something you can just drop in to your code and get
faster speeds.

One of the things that I've learned from Python and the other attempts to
speed up the scripting languages is that despite the mantra, yes, there _is_
in practice such a thing as an intrinsically slow language. (The theoretical
existence of a Python interpreter that can run all existing Python code at C
speeds doesn't do us much good if we have no idea after decades of very smart
people banging on the problem how to manifest it. Personally I'd suspect that
while such a beast theoretically exists it has an exponential complexity
startup cost or, if you prefer, exponential compilation costs. And probably a
pretty decent code and/or RAM bloat cost, too.) And Python is one of them.
Some of the reasons why it is so much fun to use are part of that intrinsic
slowness. Some of them really aren't.

I personally think there's a lot of up-and-coming languages that are exploring
the space of how to get those nicer programming abstractions and programmer-
convenient code without paying anywhere near the runtime cost that the dynamic
scripting languages of today do; it's one of the more exciting developments I
see coming up. People complain a lot about code bloat and poor performance of
our code since right now we have to choose between "fairly inconvenient but
fast" and "convenient but slow and bloated". Patience! Better choices are
developing, but they're still young.

~~~
monkmartinez
Will you please share the languages you thunk are up and coming?

~~~
jerf
Go is an early entrant into this space, but I think part of the reason it is
early is also that it is less ambitious. But to answer the ever-present
question on HN about "why would anyone ever use this language?", something
modern, almost as easy to use as a scripting language [1], and almost as fast
as a compiled language, doesn't actually have a lot of contenders. (Old
fogeys... like me!... like to observe that if you drop modern you have some
things like Delphi that fit that slot, but they're all pretty much dead now,
and Go has good support for concurrency in the modern processor environment.)

In the "you probably can't convince your boss yet" category I'd recommend
Crystal ([https://crystal-lang.org/](https://crystal-lang.org/)) and Nim
([https://nim-lang.org/](https://nim-lang.org/)).

Given the programming landscape and the general direction of things lately, I
also bet there's a couple of serious contenders developing out there that
haven't even hit HN yet.

[1]: For at least a broad class of problems. Put Go head-to-head with a
problem someone would use NumPy for and Go will go down in flames in the ease-
of-use and line count department. However I use Go for a lot of networks
servers (not even necessarily Web servers, but network servers) and the line
count for these comes out maybe 20% larger than Python, and it doesn't take
much developer cognitive energy for those extra lines. I've also used Go for
some command-line type apps where the line count is probably 50% over Python,
but I also got some significant wins from the type system and concurrency, so,
all in all there's a lot of things I can prototype with about the same mental
effort in Go as I could in Python. Being able to declare interfaces that
existing types conform to turns out to cover a surprising amount of those
"duck-type" scripting-type cases.

------
booshi
This keeps getting posted, and while it makes some valid points, it's a lot of
handwaving.

Arguably, other languages can get code out faster depending on the dev,
language, etc.

~~~
0xcde4c3db
Agreed. Things that are handwaved include:

1) Performance can be a genuine requirement of the product, i.e. if it's not
fast enough, it doesn't ship. You can't ship faster and cheaper by sacrificing
the thing you need to ship (well, you _can_ , but then you're shipping a
different product, not meeting the same requirements sooner; it's no different
than cutting a feature).

2) Many processes can't be horizontally scaled in an efficient way, period.
Not because the programmer is ignorant of some cool algorithm, but because the
problem is fundamentally expensive to parallelize. Maybe you end up getting
something like a 20% boost by having twice as many nodes, even after applying
all the cool algorithms. And you don't necessarily get that scalability in
your code base for free, either.

3) "Speed" in the mobile and embedded spaces is often as much about energy
efficiency and thermal management as getting done sooner.

4) The metrics for deciding that Python is faster to develop in only measure
small problems. People tend to shy away from Python for bigger projects, and
the reasons for this are pretty hotly debated.

------
bluedino
Many times when Python is blamed for being slow, it's the programmers fault.
Python is great that you can 'regular' people writing code in it quickly. The
problem is, these regular people don't always understand algorithms or things
like caches, threads, databases...

A lot of these users can just say "My department needs a $40,000 24 CPU server
with maximum RAM from MicroWay/SuperMicro, we need to run our codes faster",
when they are just trying to brute force things.

They understand the problem domain but don't have the programming skills to
use a computer to efficiently solve it.

But, these guys are all a step ahead of the ones who are stuck in the mindset
of "C is the only language fast enough for my work", while not even
understanding pointers and basic syntax and getting stuck on silly things like
text processing, which could be done in minutes in Python.

------
nhumrich
Author here. Surprised to see this toping HN. Appreciate all the feedback. Let
me know if you have any questions.

------
progman
Yes, time to market is important. However, you don't need to compromise
convenience of development for the sake of performance. If you twist your
Python code to get performance it takes time. If you need performance, and
like the syntax of Python then you should take a look at Nim [1]. With Nim I
develop as quickly as in Python while I get the performance of C.

[1] [https://nim-lang.org](https://nim-lang.org)

I believe application performance _is_ important on servers. It makes a
difference if your Shop software written in Python is able to handle 50
requests per second, or if the same software written in Nim can handle 500
rps. And by the way, Nim provides static typing which helps a lot to catch
errors at compile time.

~~~
cup-of-tea
Nim seems really good, but does it have a decent REPL these days? I'm not sure
if it would be as convenient with a statically typed language, but I like the
incremental development approach so much that I only use C if I absolutely
have to.

~~~
dom96
It doesn't. But you can grab Aporia (or some other tool) to quickly compile
and run some code, it replaces a REPL very well in my experience.

------
deadsy
Premise: It's more important to be productive than to have fast code.
Conclusion: Use Python. Is the premise true? For many cases- yes, but it
depends. If you are running an application on the cloud and your metric is
$/user/year and you have many users then saving some compute resources for
each user gets attractive and you don't want to just throw another VM at it.

Is the conclusion true? Garbage collection gives big productivity gains. Other
languages have GC. It's not nice to see your Python code die after a few days
because you messed up the type passed to a function. Other languages fix that
at compile time. Multicore is now. Other languages are built with better
multicore awareness.

------
__s
> without getting stuck in the weeds of the small things such as whether you
> should use a vector or an array

Yes, instead get into the weeds of tuple vs list

Not included in the graph of time-to-solve-problem static languages:
statically typed languages with type inference

~~~
scbrg
Given that they have exactly the same interface, that choice is really easy.
You go with one until it turns out to be insufficient, and then you switch to
the other and _not a single line of code_ has to change, except at the point
where you create the thing.

Incidentally, the same is true in many situations in Python, and that is (IMO)
one of its strengths.

------
agnivade
> However, this is no longer true, as silicon is now cheap. Like really cheap.
> Run time is no longer your most expensive resource.

Our client won't spend more money than a t2.medium instance on aws. Nothing we
can do about it. In that case, run time does become an expensive resource.

But I get the point that OP is trying to make. Just wanted to mention that not
all of us have the comfort of having enough resources on which our app runs.

------
fiatjaf
> It’s more important to get stuff done than to make it go fast.

This is not a real absolute. It is only valid when what you have to run will
not benefit a lot from performance or suffer a lot from lack of it.

The real guidance you can have in these matters is: how many times is my code
going to run per second?

Some programs are written to be run once a day, others 10000000 times in a
second. The first ones should be written in the language you're most
productive in, the second ones in the fastest possible language.

------
karmakaze
Putting aside the discussion regarding productivity, there is a case where I
have found execution time to matter. Scaling an application which uses an
unsharded database. The long transaction durations and number of connctions
were bottlenecking db throughput. The particular app was a Ruby/Rails
monolith.

------
nervous123
This sentiment is the reason for almost all software (especially on the web)
beeing a load of crap. It's slow, it's buggy and developers always give the
same excuse: CPUs and memory are cheap, therefore we can waste our customers
time.

Imagine what we could do with the amazing hardware we have, if people started
to do the sane thing and actually use the hardware to do things efficiently.

------
Thaxll
Giving EvE Online as an example is bad because that game artificially slow the
game loop to keep up with the number of players, would this happen with C++ on
a recent architecture? Probably not.

------
sedlich
In "What if CPU time is an issue?" we could also mention the nim language (and
not only cython) because it compiles (not only) to C and feels like python.

------
donatj
I know it's not trendy, but I would argue PHP is as productive for developers
as Python and has a MUCH faster runtime, particularly after 7.

------
snarfy
Slow doesn't matter when you scale horizontally.

------
hellofunk
Yeah? Well, Jimmy Crack Corn and _I_ don't care.

