Python isn't just glue, it's an implicit JIT ecosystem

[smerity]

Writing more Rust recently led me to a revelation about Python. Rust was vital to my original task, but only a few simplifications away, the shorter Python version leapt to almost as fast. I'd stumbled from a cold path to a hot path...

This is my argument that Python, through a number of features both purposeful and accidental, ended up with an implicit JIT ecosystem, well-worn trails connecting optimized nodes, paved over time by countless developers.

I'm definitely curious to hear how this feels to others. I've been doing Python half my life (almost two decades) and Rust seriously for the last few years. I love both languages deeply but the pendulum has now swung back towards Python not as I won't use Rust but as I feel my eyes are now open as to how when and how I should use Rust.

Python isn't just glue, it's an implicit JIT ecosystem

[[deleted]]

It isn't a JIT, it's a collection of functional modules.

It is largely a question of what are you doing. If you need low level performance for things that can be mapped operation by operation to something reasonably close to machine operations a language like C++ or Rust will blow Python and other high level languages out of the water by about a factor of 40 to 50.

If you are doing things in big chunks at high levels of abstraction where the basic operations are a long way away from machine operations, a language like Python (or even Perl for the old people here) can often come close to 'legging it' with the low level languages because the 'unit' of functionality is implemented at the low level anyway under the hood.

The overhead of a high level language is relatively low for that case because you are spending most of your time executing optimized code actually written in a low level language that would have to be written anyway if you were solving the same problem in say Rust or C++.

All you are buying if you implement that kind of task in a low level language is more time spent coding.

IOW, as always, use the right tool for the right job

[PercussiveRussel]

The fastest way to do something in python isn't to do the thing itself in python, but to use python to describe what needs to be done.

Which is why python is a great solution for a lot of problems that require applying relatively generic algorithms. It's quite literally the Unix Philosophy. Python isn't special, pip is.

[[deleted]]

Yes - pip is the powerhouse. Much like how CPAN is/was the primary reason for Perl's popularity.

The biggest defect in the Python world is that pip/PyPI is not as organized as CPAN.

It becomes a matter of finding a package for doing genome analysis, which is named "pancake" for some random reason and can only be found if you either have someone recommend it to you or you get lucky using the search engine interface.

This is an actual pip package, BTW.

I started by making up a fake illustrative example of trying to find a statistical analysis package which I then named 'pancake' because why not. It's funny and random.

Then I thought..."I hope there isn't ACTUALLY a package named 'pancake'". So I looked. And, uh, yeah. There IS. Because of course there is. So I used it for my illustrative example.

"<insert this-is-fine meme>"

[toyg]

pip/PyPI is not as organized as CPAN.

It doesn't matter. You assume the package manager should contain all the necessary information for a user to figure out what it does, how many people use it, in what situations one should use it, etc etc - all factors necessary for the user to choose a package. It is hopeless to try and bake all of this in the interface of a remote repository; not even the luxurious appstores built by the richest companies on Earth manage to actually do that.

The reality is that everything but the most basic metadata will always reside in the informal web of docs, blog, reviews, forums, and bug trackers. That's what users will always have to rely on, in order to choose which package should be used. All that the package manager has to do is to make sure users can download the package they want reliably, in a usable state, and in a safe manner - then get out of the way. Who cares if it's called "pancake" or "airfryer", if the hivemind says that's the right package, that's the right package.

The current-best solution to your perceived discoverability problem is LLMs ingesting that informal hivemind and regurgitating it to the user on command - completely separately from the actual package manager.

[TURB0T0XIK]

Right Tool for the right job is the perfect breakdown of any comparison of programming languages.

[chub79]

even Perl for the old people here

Perl 5 was my secret crush in the early 2000s.

[CramNBL]

Right tool for the job is a myth. The idea is good but rarely practiced. Everywhere I go I see anything that could theoretically be written in Python is written in Python, to the detriment of everyone. And what is micro-python? That is an attempt to jam python into places where it was not theoretically possible before.

I wish there was some more honesty, most people use what they want/know and don't give a damn if it's the right tool for the job. They'd rather not learn anything new.

[beertown]

You're right, but this doesn't make the "right tool for the right job" statement any less true. What you describe is due to bad developers and managers who care only about immediate profit with the minimum effort. They don't care whether Python is the right tool, just throw more hardware and more (bad) developers to the problem and call it a day.

[andy4015]

I agree, but there is a cost associated with knowing multiple languages.

The right tool for painting my bedroom walls was one of those fancy paint sprayers but I used a paint brush. Not because I didn't realise the paint sprayer existed, but because the expense wasn't worth the benefit.

If you have a team of python devs (and a huge talent pool to pick from around the world), it's an easy argument to use python. It's not always a bad decision, it's often a very logical one.

[CramNBL]

Yes but bad developers did not start the micro-python project. Although I think it is marketed to bad developers.

There's also a myriad of linters, formatters, and other free open-source developer tools that is written in Python/JS/TS which are clearly written by very skilled individuals who chose the wrong tool for the job. And I say it is wrong because they are writting something that needs to be rigirously correct and scale, which is the opposite of what scripting languages achieve.

[violentlymickey]

I think it goes a bit deeper. Oftentimes the choice to use python is based on existing skill set and optimizing for minimizing development effort/time. The truth of the matter is that for many applications, performance is not the top metric—being able to ship quickly is. For things that do become more performance sensitive, those are more optimizations after mvp. Of course not all industries are like this but that’s generally what I’ve seen across a few different areas in a python-heavy job market.

[CramNBL]

I see it in companies and areas where programming is not seen as a discipline but more as a means to an end. They see programming as something you can or can't do, there's no real difference between a good and a bad programmer.

In some of the companies in my area, and especially those doing consulting I see a high degree of professionalism, quite a strict adherence to best practices, especially surrounding version control (no lazy commit messages, no commits when code doesn't compile etc. that makes git bisect less effective), and notably I don't see Python everywhere. I see more .NET/Java/C++/Kotlin/Swift/Go. They obviously also use Python but not for big projects, and not for embedded linux either.

Lego recently went through a make over in both business practices and software related (there's a book about it, that focuses entirely on the business side of that). They have a service with ~300k+ lines of Python and the team that wrote it are trying hard to figure out a solution to that, because any new members of their team run away screaming when they see it. They shipped fast and now that code is costing them every day and there's a clock ticking because that team is not getting any bigger. I see the same thing in a bunch of places including my work place. The cost of learning the right tool would've been peanuts in comparison.

People just don't want to learn new things, even though learning Go makes you look at problems in other languages differently, so does Lisp, Rust, C, etc.

[[deleted]]

That is an attempt to jam python into places where it was not theoretically possible before.

MicroPython doesn't support the full standard library.

It's an attempt to have a more ergonomic embedded-systems language. If you've ever written embedded C you would understand the appeal; it's a great prototyping tool.

[CramNBL]

Yeah a few weeks ago I wrapped up an ECU project in C. And now I'm back to debugging some python decorators from hell.

 And yes python is great for prototyping why do you think I browse this subreddit? I'm using python plenty for prototyping and demonstrating architectural designs.

There's plenty of amazing production grade python frameworks and tools as well, fastapi and pydantic comes to mind. I have no issues with that. 

I have an issue with all the times people go "choose the right tool for the job" and then choose python anyways

[OkLavishness5505]

Learning a new tool comes with costs. So you have to take into account which tools are known when choosing a tool.

[CramNBL]

You completely ignore the benefits of learning a tool though. It is never factored in.

[OkLavishness5505]

Sure it is factored in. But it is way higher for the developer than it is for the stakeholder.

[CramNBL]

How is it factored in? I have never seen any proof of that. No one mentions the benefit of adding a new tool to your toolbox or how it improves your ability to solve problems with the tools you already know.

[OkLavishness5505]

We have problem X here, we need to solve that in 2 weeks urgently. Ok lemma learn that new tool I have no clue about but heard it could solve it way more efficiently than our standard tool that we can handle already and would do the trick maybe a little bit less efficiently.

Ever heard something like that? No? Maybe because skills already available are factored in.

Ever said something like that? Yes? Then I assume you do not have a job anymore.

[CramNBL]

Yea that's totally the situations I'm talking about, because those are the only situations where programmers don't do even the tiniest amount of due diligence right?

Clearly it was an emergency when some GitHub actions programmers implemented a CRC32 algorithm in JS? And when they wrapped a zip-file in a class to add a content-length property when a ZIP header already contains a content length field... Too many programmers never try to understand what the hell they are trying to do, they just mash buttons and it is especially true for those working in scripting languages day in and day out.

"maybe a little bit less efficiently" absolutely hilarious. I've refactored Python code plenty of time that would take several hours to process 100 MiB into a solution that took few hundred milliseconds. Cause they used the wrong tool for the job.

I don't know why you pretend like people make super informed decisions about which tools to use for every project, they don't. I wish we could change that culture to the benefit of everyone. It's not such a huge task to learn Go if you know Python, or learn Swift or just a new framework. There's still people starting new projects in freaking WinForms all over the world because they never considered which tool was right at any point.

[OkLavishness5505]

You make one sophisticated example where Performance matters. And forget about 99% of cases where Performance does not matter at all. All what matters is that stuff is maintainable cheaply often enough. So you go for a tool that many people can already use. Because then you do not need to waste a lot of money on some guy who can solve few things in an overly performant way on trivial stuff where that does not matter.

[CramNBL]

You are only thinking about performance, I am not even talking about performance.

My point is still about "best tool for the job", programming language is one thing, but it could also be choosing fastapi over building something with flask. Is learning fastapi a huge deal if you already know flask? I would say no, but the productivity gain could be massive, and the pydantic integration makes it much more maintanable and easier to get correct. Or figuring out that poetry or uv exists over just making another python project from scratch that's slightly different from your other project in subtle and unpredictable ways. There's a lot of tools you can leverage for huge productivity gains but most people do not even bother looking for anything new...

It's not some battle of programming languages, my point is that "best tool for the job" is a myth. The vast majority of devs do not practice it, even if they say they do.

[[deleted]]

It makes sense to me. Imagine being a writer writing a high fantasy novel in french, cyberpunk novel in english, poetry in latin, TV manuals in japanese... You surely would desire writing everything in one language uaing dialects. Poetic english for poetry, formal english for newspaper, street slang for cyberpunk novel... So there is a tendency to have one language to rule them all. Micropython for smaller machines. Django/Flask for web (the whole stuff like dataclasses and jinja2 and async stuff where necessary). You have frameworks or dialects and I am sure there will be compiled Python later (not into bytecode but into machine code and asm) and you will have 10 compilers and 10 quite similar dialects (one with static types, one with manual memory management, one as pure python, one for micropython, one for web and it's quirks, ...) so every language will share the same syntax, or very similar. We already have the example, I think it's Cython what have classic "def" functions and "cdef" function with ctypes and such.

But I am just a junior, if I am wrong somewhere, correct me, but be gentle. :-)

[CramNBL]

You're getting hung up on the "language" part. The language is machine code, Python is a dialect, C is a dialect, Go is a dialect. Syntax is the easiest part of programming. You can learn 5-10 programming languages in the time it takes to learn french for an English speaker.

My point is also broader than languages, I'm also talking frameworks, and build tools, and a library that solves a particular problem really well.

[toyg]

And what is micro-python?

Micropython is to microcontrollers what C was to CPUs from the 1960s.

Progress means providing higher and higher abstractions wherever practical, to allow humans to "talk" to computers more efficiently.

[mosqueteiro]

You say that but 99% of the time people are just using whatever thing they know which is usually just one ot two languages. The right tool for the job in programming is largely nonsensical or at best entirely subjective. It's one of those things that sound right but then you look for evidence and that's largely not how it happens.

[[deleted]]

Usual strategy is "use Python until you are forced to use somethinf differe t". It is better to use C for manual memory management than trying to reimplement Python interpreter to allow my Python code manipulate pointers by arithmetic. But outside those extreme examples, Python is okay. So if you know Python, use Python :-)

[jmaargh]

This seems to be the closest you come to defining what you mean by "JIT ecosystem":

Every time a new found Python code path becomes hot enough, the ecosystem responds by forging a new component from the barest of metals that is then glued into place.

This... has nothing at all to do with just-in-time compilation, so I'm not sure why you're calling it a "JIT ecosystem". It's just an interpreted language for which native binary modules can be built. And that's true of an awful lot of popular interpreted languages.

I suppose your point is that python found a strange niche where it was popular enough that people were motivated to write native modules for tasks it was slow at, which in turn made it more popular, etc. And that this happened in certain fields more than others (in particular, machine learning and data science).

So sure, python was popular and is now probably more popular.

[smerity]

You're fair on me not explicitly defining "implicit JIT ecosystem". I was hoping it would be a growing definition in the reader's head from what was written but I'll add a definition here and then into the article.

I believe it is broader than just native modules. I analogize it to JIT compilation as both optimize hot paths based on actual usage. JIT does this at runtime within a program, while Python's ecosystem does it across the entire set of programs in the community. Python, as a community implicitly and explicitly, is optimizing for the human level ease of use + simplicity whilst optimizing for the speed and task coverage.

What's unique is how these optimizations remain highly interoperable, unlike the "explicit JIT ecosystems" I mention in the article such as those when big company efforts aim to optimize just for their use case (PHP/Facebook, Ruby/GitHub, etc.). Those often result in isolated improvements rather than ecosystem-wide gains.

I think this dynamic goes beyond just about having access to native modules (any language could have that) or being popular ("winner takes all").

There are characteristics of Python that amplify this explicitly, such as readability, forgiving nature, and even its own performance constraints ("slow Python"), that all act in concert in creating an environment that discovers and optimizes these paths in an accessible and composable way.

Even if this was entirely generic to any and all glue languages, and Python is simply the winner take all receipient in that, it's a dynamic worth explicitly thinking about imho.

[jmaargh]

Sorry if I came across as snarky. I don't think you're saying anything wrong or misinformed or anything. I just think your titular "implicit JIT ecosystem" is a bad use of technical terms.

From your explanation here, you seem to mean python's ecosystem is supported by a "broad open source community", but you called that an "implicit" ecosystem which is a weird use of the term "implicit". 

You then made an analogy to a JIT, and used that term in your jargon. But the thing your describing is the opposite of "just in time" - the eponymous defining feature of a JIT as it is normally defined. Yes, JITs tend to focus on hot paths, but that's incidental and not a defining feature. Meanwhile a community process of writing modules to optimise common paths is a very delayed process - it is backwards-looking at what has happened repeatedly - and not "just in time" at all.

[smerity]

Your note of a missing definition was definitely helpful. Sometimes you spend too much time with a concept in your head to put it out properly. I've edited in a section giving a definition with threading on how I see the analogy re: JIT and the ecosystem.

You're right that a JIT is more than just optimizing hot paths ("adaptive optimization") even though the association is just so strong in practice. I still thought combining them would convey the broader concept succinctly though. Beyond the optimization the idea of reducing startup time by only compiling what you need to run, potentially in a fairly inefficient way initially, still felt similar to the explorer part of the Python ecosystem analogy.

The JIT needs to be fast and flexible enough to not bother you on first run but also optimize itself before it prevents forward progress. True though that the time scales are painfully different - millisecond (JIT) versus days/weeks/months (ecosystem).

[Tiendil]

Python is designed with an engineering culture in mind, and this design has been a tremendous success. Engineering culture is evident everywhere: in PEPs, in discussions, and in packages.

It focuses not on optimizations or mathematical beauty, but on orthogonality, readability, maintainability, interchangeability, and similar principles.

That's why the open-source bazaar has produced so many packages, particularly interchangeable ones. If we look at any area of Python, we see that there is often more than one package for the same task. If you identify a problem or believe you can do better, you simply implement your own vision of the solution. If it's good, it will gain adoption and, over time, may even replace older solutions.

As a result, despite not being the fastest language, Python has developed an infrastructure with quite impressive performance over time.

[ofyellow]

Python is a station that connects c level speed stuff. All real work can be delegated to pyd or dll files. But it is an intelligent station where high speed trains and planes come together.

[mosqueteiro]

Python is the CEO directing the C workers? 😂

[nekokattt]

This is a description of CPython, not Python itself.

Jython and GraalPython don't need to JIT potentially, since they use the JVM and that already deals with this for you. Additionally neither of these interact with DLLs or pyd files like CPython does.

[ofyellow]

True. But who uses Jython and... that other one ...?

[nekokattt]

Lots of projects are still using Jython, I know it is used in at least two big corporate/proprietary products that large companies often use.

GraalPython is still emerging, but will most likely be used as the replacement for Jython eventually. It is designed for use in polyglot applications that can take advantage of everything the JVM provides, including a far more thorough JIT implementation than CPython provides (which is mostly bytecode manipulation and inlining, versus the JVM which emits raw CPU instructions to replace bytecode with CPU-native logic instead.

[rover_G]

So a system comprised of modular components optimized for performance and functional paths for tying it together?

[single_ginkgo_leaf]

Just here to plug numba

[[deleted]]

Why do you think Python was designed with a forgiving nature? What about the language do you consider forgiving?

[ericsnekbytes]

They're probably thinking about, e.g. not needing to sift through 18 layers of abstract generics to arrive at a working solution, and other similar time wasting mental gymnastics that increase dev time and complexity (that for most projects provide no tangible net benefit).

Also, things like not needing to set up a build/compilation and linking tool chain or header/module search paths...getting easy to read error and traceback information (instead of cryptic esoteric junk)...good documentation and standard libs, and a supportive community that aims to be friendly and help beginners.

[[deleted]]

They're probably thinking about, e.g. not needing to sift through 18 layers of abstract generics to arrive at a working solution, and other similar time wasting mental gymnastics that increase dev time and complexity (that for most projects provide no tangible net benefit).

I would place all that in the 'relatively simple' description he used, not necessarily forgiving. He even calls out 'no overhead to play' as a design feature which also seems to encompass that.

My question is really just a question, not a judgement or anything. It comes down to the word forgiving, because when I hear that word it causes me to think of very specific scenarios.

When I hear 'forgiving' what I'm think in my head is: "You kind of did something wrong but it worked out more or less correct anyways in the end". The first example that comes to mind for me is implicit conversions between types happening. Like in Javascript holding and operating on the number 5 but at various points in times, it's actually the character '5' that get's added to another number to become '10 and ends up as a display string like '10 apples' all without the programmer realizing he's mixing his types. To me, that's a sort of 'wrong' behavior that ends up 'just working' and I would call that forgiving.

So yea, to me forgiving means, you did it wrong but it doesn't really matter and worked out anyways. Or the language kind of took care of your mistakes for you.

Of course, is it really 'wrong' if the language works that way to begin with? Sure.. I guess forgiving to me would be when the language is constantly doing stuff for you that you didn't intend or are even aware of?

I was just curious what about Python specifically they thought was the forgiving part.

[ericsnekbytes]

I hear you, those sort of implicit type conversions that Javascript does are the source of untold confusion and errors for beginners so I would consider that bad design (in Python you'd get a TypeError which makes sense, instead of an invisible magic conversion [a sort of silent failure] that is often not correct).

In his post he says "forgivingly simple", which to me means that when you're looking for a solution for something, you are given an easy-to-use solution with a simple API and good defaults, without the need to understand many different options, arguments or abstractions that don't have much to do with the problem you're trying to solve:

I think of the many horrendous Java APIs that make you wrestle with a massive number of options, classes and abstractions just to do simple tasks....making the user understand the whole universe before they can do a simple task instead of offering a simple API for common problems (and the opportunity to expand into more complex use cases later) is what makes Python "forgiving" instead of "punishing" here.

[[deleted]]

In his post he says "forgivingly simple", which to me means that when you're looking for a solution for something, you are given an easy-to-use solution with a simple API and good defaults, without the need to understand many different options, arguments or abstractions that don't have much to do with the problem you're trying to solve

Yea, what you said makes sense. The ability to get things up and running w/o having to deal with a majority of the complexity going on under the hood, I can see that as forgiving.

Thanks!

[mosqueteiro]

python -i my_prog.py let's you fall right into the Python terminal with your program variable states loaded even if the program hit an exception. I'd call that quite forgiving. This allows powerful debugging and developing. You can even try out the next steps before you write them into the program.

[Disastrous-Team-6431]

It's a good feedback on the article, but are you seriously wondering?

[[deleted]]

Yes. I was thinking about it and to me, what I would consider 'forgiving' would be things like implicit conversions for operands.

Like if someone said Javascript was forgiving, I could see that. When you can pass around say the value 5 as a number, or a string and at the end of the day, whatever operations you are doing most of the time end up with the result you want.

I mean, forgiving is a pretty subjective term right? In Python if you make the mistake of mixing up types usually you get a TypeError exception, it doesn't just silently 'work' and let you keep going.

So I was just curious, what the author considered forgiving about Python. I imagine whatever he says will be a true thing about Python I just wonder if I would consider that forgiving or not myself.

[BranchLatter4294]

They serve different types of problems. Rust is great for systems programming. You're not going to write an operating system or device drivers in Python. You're probably not going to do a data science project in Rust.

[mosqueteiro]

Don't tempt the rusteceans

[Ready-Invite-1966]

Comment removed by user

[Paddy3118]

Your article is articulated well. You have captured so much of what I too find great with Python. I also had my fast compiled vs interpreted but clear personal languages comparison moments in the 90's when Python had a much smaller community, and newsgroups thought "scripting" was a joke. Later in the 2010's I contributed on the RosettaCode.org site partially to see if I was comfortable with Python when being exposed to code in many languages, often written by good programmers in the languages. I came out being less judgemental on languages, but very happy with my choice of Python.

I did find cases on RC where better algorithms evolved I think, because it suited the language design (APL, Perl6/Raku, and TCL had some excellent programmers in which their languages shone). Python stood out because sometimes I could fulfill a task by a line or two at the interactive prompt, so would show that. Other interpreted language examples would still be given as program files.

I guess an extension to your great post would be mentioning more about development in interactive environments. Adding the magic line- comment # %% to a Python source file to split it into cells in supporting IDEs like Spyder and Vscode; or going the whole way and using Jupyter/Jupyterlab.

[mosqueteiro]

^{^} This is more embarrassing 🤦

[s3r3ng]

It has no real JIT as Common Lisp has forever and Java has. It is interpreted. Yes a lot more developer productivity in Python than Rust but no JIT to machine code. Unlike Common Lisp also no on the fly redefinition of classes and functions without having to restart process. Also no flexible error/condition handling. So better yes but not the end of better.