Many of these have C-bindings for their libraries, which means that slowness is caused by bad code (such as making a for loop with a C-call for each iteration instead of once for the whole loop).

I am no coder, but it is my experience that bad code can be slow regardless of language used.

There are a few reasons for this, some of the most important being:

• The languages were not designed with speed primarily in mind and as such made some design decisions that fundamentally cannot be optimized around
• Authors of programs in these languages prioritize things other than performance when writing the programs.

Speed is not just about processors becoming faster - this is a large part of why DSA is important to learn as a programmer.

That's because it's not relevant. Speed can be compensated for either by caching or outsourcing your load, if there's such a huge need to process large amount of data quickly. In day to day work I can't say I have ever ran into issues because code was executing slow. Normal operation Python is more than capable of keeping up.

On the other side of the coin you have memory management, buff and stack overflows and general issues almost exclusive to C, which is something you don't have to worry about as much with higher level languages. Development with Python is simply faster and safer. We as developers have different tools, and we should use them for their appropriate purpose. You can drive nails with a rock as well, but you generally don't see carpenters doing this all day.

True, plus the bloated websites I see are using hundreds of thousands of lines of JavaScript. Why would you possibly need that much code? My full fledged web games use under 10,000.

It is always a question of chosing the right tool for the right task. My core code is in C (but probably better structured than most C++ programs), and it needs to be this way. But I also do a lot of stuff in PERL. When I have to generate a source code or smart-edit a file, it is faster and easier to do this in PERL, especially if the execution time is so short that one would not notice a difference anyway.

Or the code that generates files for the production: Yes, a single run may take a minute (in the background), but it produces the files necessary for the production of goods of over 100k worth. And the run is still faster than the surrounding processes like getting the request from production, calculating the necessary parameters, then wrapping all the necessary files with the results of the run into a reply to the production department.

"Slow"

They aren't as fast as a native language but they aren't all that slow if you aren't trying to use them for performance sensitive applications. Modern machines run all those very quickly as CPUs are crazy fast.

Also it seems weird to put Java/OpenJDK in the list as it is in its own category from my experience

This is because they are meant to be simpler for complex logic. They don't want to be faster by ditching the simplicity

Link is to classic xkcd comic, not furry porn

Damn, you got my hopes up for a second there.

(Link is to classic xkcd comic, not furry porn)

I am both disappointed and pleased.

Well if it's linear the cheeta is going somewhere around 100 million miles per hour. Air resistance would quickly make it a no-ass cheeta.

Log scaling?

Did you notice how it also mentions the speed of light?

That's just the FreePascal Compiler

• Relevant xkcd #1
• Relevant xkcd #2

Anyway, this is only relevant if you're writing only for yourself. It's your poor users who suffer for your expediency.

I used to write extensively with C++, but it has been a long time since speed mattered that much to one of my applications. I still marvel at the cache-level optimizations some people come up with, but I'm in the same mindset as you now.

My workload split of Data Movement vs Data Transformation is like 95:5 these days, which means almost all the optimizations I do are changing batch/cache/page/filter settings. I can do that in any language with http bindings, so I choose those that are faster to write.

I use c++ whenever possible because I like classes and objects and having more versatility to make more dynamic programs. I made an entire kernel that way one time because fuck the police.

I was a huge C++ fan back when I was doing a bunch of competitive programming. If I need a performant project nowadays, I look to golang first. It gives me the speed of a compiled language with the usability of high-level language. I still solve the occasional Advent of Code in C++, though :)

yeah and it allows for queering up the distro logo, which I absolutely love.

It's fitting for this image too since CachyOS kernel + packages + defaults go zoom.

Laughs in -O3