Hacker News Reader

> I was active in the Python community in the 200x timeframe, and I daresay the common consensus is that language didn't matter and a sufficiently smart compiler/JIT/whatever would eventually make dynamic scripting languages as fast as C, so there was no reason to learn static languages rather than just waiting for this to happen.

To be very pedantic, the problem is not that these are dynamic languages _per se_, but that they were designed with semantics unconcerned with performance. As such, retrofitting performance can be extremely challenging.

As a counterexample of fast and dynamic: https://julialang.org/ (of course, you pay the prize in other places)

I agree with your comment overall, though.

What are examples of those semantics? I'm guessing rebindable functions (and a single function/variable namespace), eval(), and object members available as a dict.

Some examples that come to mind: You can inspect the call stack, and get a list of local variables of your callers. You can assign to object.__class__ to dynamically change an existing object's class at runtime. You can overwrite every operator, including obj.field access, dynamically at runtime (including changing an existing class)

a long time ago, there was Parrot and a bet with Guido https://justatheory.com/2004/08/oscon-notes/

I'm sort of surprised I'm not seeing any modernized dynamic scripting languages coming out lately, despite the general trend towards static languages. A fast dynamic language, with a day-one concurrency story, and some other key feature that pushes it ahead seems possible to me. (I dunno, maybe a nice story for binding to Rust instead of binding to C at this point could be enough to lift a language off?) I don't see any reason why dynamic scripting languages as a category couldn't do that. The ones we have now don't, not because the category makes it impossible, but because by the time that was desirable they just had too much baggage, and are all still struggling with it even a decade after they started.

> fast dynamic language, with a day-one concurrency story

simple dynamic scripting languages target people without serious CS background

concurrency is a footgun best hidden from such people, they are not ready for it

> A fast dynamic language, with a day-one concurrency story

That's pretty much what Erlang claims to be. Of course people will always quibble with "fast".

I do quibble with fast, and I also quibble with "dynamic language". Its variables are untyped, but that about ends the "dynamicness" of the language. It's not what people mean.

Elixir is closer, though BEAM in general still leaves a lot of performance on the table. I'm somewhat surprised that tracing JITs and stuff have not managed to make more progress than they have, but it could be lack of developer time. Unfortunately JITs eat that voraciously.

I'd expect this to be a mutable language, though part of that "day one concurrency story" could be an inability to transmit references between something like Erlang "processes".

Welcome to Elixir. A concurrency story baked into its architecture, Rustler for trivial Rust bindings, a full set of project tooling (package management, deployment handling, etc). And a killer combo of database bindings in the form of Ecto and a best-in-class web framework from Phoenix.

And it's got an unusually broad base of existing libraries for how young it is, both because writing bindings is really easy, and because you can import Erlang libraries which have been around since the 80's.

This is all true, but there's another angle that often gets missed:

JITs are really only ideal for request-processing systems, in which a) memory is abundant b) the same code paths run over and over and over again, and c) good p99 latency is usually the bar.

In contrast, in user facing apps, you usually find that a) memory is constrained b) lots of code runs rarely or in some cases once (e.g. the whole start-up path) c) what would be considered good p99 latency for a server can translate to pretty bad levels of jank.

JITs can't do anything if the code you care about runs rarely and causes a frame skip every time you hit it, either because the JIT hasn't triggered yet due to too-few samples, or the generated code has been evicted from the JIT cache because you don't have memory to spare. And if you have code that needs to run fast _every_ time it runs, the easiest way to do that is to start with fast code already compiled and ready to execute.

We saw this play out when android moved from Dalvik (JIT) to ART (AoT compilation). Apple figured this out years earlier.

Of course it's not that there are no highly performant apps built on JIT runtimes. But it's a significant headwind.

(Most of the above applies equally to tracing GC, btw)

You missed the part where Android moved into caching JIT code with a mix AOT mode compilation, since Android 7 thus avoiding those issues. Latest version is Android 16, many other optimization happened since then.

Also that Android followed up on Windows Phone model, their mistake was making the AOT compilation on the phone instead of on the store like Windows Phone was doing.

JITs are very capable, provided people also design with them in mind.

The clever Apple with AOT failed against this now famous benchmark, against tracing GC languages, using a JIT.

https://github.com/ixy-languages/ixy-languages

While what you say is true, there is still a huge gap between the performance of javascript (and even Ruby) and that of Python. The efforts to optimize Python are lagging behind, so there is a lot of things that still can be made faster.

Python is also choosing to play with one hand behind its back; e.g., the “no extension API changes” rule which means any hope of a faster value representation (one of the most important factors in making a dynamic language fast!) goes out the window, refusing to change the iterator API (which means that throwing and handling exceptions is something that needs to be handled by the fast path of basically everything), and so on.

Those changes are big enough that they’d need to be a Python 4, don’t you think? Community is still gun why after the 2-3 transition pain.

yeah. Python is somewhat trapped here. because Python is slow, real work gets moved to C, and the C api makes it almost impossible to speed Python up. If Python had made the API changes needed for speed 20 years ago, there would be way less C code, so further changes would be easier, but that ship has now basically sailed

It could have made the changes in the 2->3 transition.

Instead we got parentheses around print.

The biggest problem of the Python 3 release was that it broke a bunch of _Python_ code. That's pretty different from changing the C API. But sure, it has ups and it has downs. One of the downs is that Python, despite a lot of announcements over the years, still is struggling to become significantly faster.

Google has been pouring huge amounts of effort into making their JS interpreter fast for many years at this point. They have a lot more resources than the Python foundation.

Microsoft had the Faster CPython team for several years, and then recently laid off some of the core devs and the team lead.

At one point, Google was also interested in pouring lots of money into making Python faster, and they shifted those resources away.

I think what always ends up failing here is that, as others have stated, they won't make breaking API changes, in particular those in charge of driving Python forward are extremely hesitant to break the C API for fear of losing packages that have make Python so popular.

I would imagine, if the leadership was willing to put in the elbow grease to help those key packages along the changes when they happen, they could do it, but I understand that its not always that simple

Meta does some work for this with Cinder, but Meta has a history of language forks, and it's far enough off the beaten track that I wouldn't use it.

cinder team member here - we are putting a lot of work into having cinder converge with rather than diverge from mainline cpython. the main idea is to get support for pluggable JITs into cpython, and then have cinder use those APIs to work as a regular extension module.

I remember this from the early 2010s "compilation of a dynamic language is a superset of compilation of static languages ergo we should be able to achieve both optimizations static languages can do and more because there are opportunities that only become apparent at runtime". When really its all about the constraints you can put on the user that set you up for better optimization.

And profile-guided optimization (PGO) for static languages turned out to be pretty good at revealing those “only apparent at runtime” optimizations.

That's like the joke that dynamic languages are static languages, but with only one type: hash table.

That's not a joke. It's a perspective that is seriously held: https://existentialtype.wordpress.com/2011/03/19/dynamic-lan...

(Not everyone agrees, for sure, but that's different from it being a joke.)

Javascript and Common Lisp aren't as fast as C but they are faster than Python.

Javascript and common lisp don't have object models that are as anathema to optimization as python does. Well, CLOS is pretty bad, but at least the badness is typically isolated.

Python is definitely slower for programs that do the same thing. What I see is that the users of fast languages often write programs that do the wrong thing, 30x faster than Python. No free lunch either way

I don’t understand the sentiment of not wanting to learn a language. LLMs make learning and understanding trivial if the user wants that. I think many of those complaining about strongly typed languages (etc) are lazy. In this new world of AI generated code, strongly typed languages are king