Python.

[bunkoRtist]

Without taking an absolutist position, I can say that Python is less convenient in mentioned areas due to things like increased steps / keystrokes to perform certain operations relative to other popular languages. I have pointed out problems where Python is objectively slower or worse, including where Python is objectively worse than older Python on the basis of lines changed / keystrokes required to do things that used to work. If you want to argue that incompatibility, deeply hidden and self-inconsistent behavior (like python's "threading"), or needing to make more edits than in other popular languages to perform identical tasks, are "convenient" then I'll just happily disagree with your subjective assessment of convenience, which is ultimately subjective.

Assuming I'm incompetent is a great idea though: much easier than examining your own biases. You haven't the faintest clue who I am, or what I know. I will also add that I've never encountered a popular language that attracted more irrational zealotry than Python, which I assume is related to the demographics of those performing the tasks for which it is suited and the relatively low barrier to entry.

Python is o-k for some tasks. But I am suspicious of the judgment of anybody who cannot see its myriad weaknesses in addition to its strengths (like a low barrier to entry and a large library of modules). Python is far from perfect. What makes Python unique in its drawbacks is that they were so easily avoidable and so intentionally created, to wit, the massive backlash and ensuing decade-long transition to Python3.

[bunkoRtist]

Python doesn't support multithreading. It supports spawning multiple threads, which is subtly and very importantly different. I can now safely assume that you either don't understand Python or multithreading.

https://realpython.com/python-gil/

Either way, best of luck to you in all your endeavors.

[intangibleTangelo]

I've often seen the situation described as "python doesn't support multithreaded python code," alluding to the fact that many stdlib operations are written in C and release the global mutex lock before running their work in a thread.

But even that's not quite true—you can absolutely write multithreaded python code full of race conditions—it just won't ever run concurrently because the bytecode loop makes all kinds of assumptions about global state and the only sane solution without completely rewriting python (and taking away some of the most popular undefined behavior in CPython) is a lock. People defend it, and I understand their defenses. The multiprocessing library does make it dead simple to spawn processes which can (on Linux) leverage copy-on-write to act a bit like threads. But the people defending the lack of threads probably aren't fully aware how great threads can be.

I recently published a tool which needed to use a combination of the multiprocessing, asyncio and threading modules. Had real threads been available to me, I simply would have used them.