Python Like Rust

Resently this meme post got top spots on both HN and Lobsers.

https://kobzol.github.io/rust/python/2023/05/20/writing-python-like-its-rust.html

Of course, HN is a dumbster fire for narcissits and imposers, and Lobser is gated community of unique snowflakes, but nevertheless…

First of all, it should be …Write _ like Scala 3 and the end of the story. Lets, however, elaborate a bit.

Both Python 3 and Scala 3 are way more refined languages (on its own, respectively) than Rust. Rust is still a PHPscure community effort, while Scala 3 and to some extent Python 3 incorporated a lot of good research and best practices (from the non-bullshit theoretical point of view).

In particular, both sturcural dynamic typing of Python 3 and advancesd static typing of Scala 3 are both a state of the art in their realms. The type-decorations of Python and type-inference of Scala are the technologies to give to the programmer a choice for balancing expressiveness with clutter.

It is already well-understood that dynamically (but strongly - this is absolutetly necessary) typed laguages are good for quick prototying and exploration of small projects (since “On Lisp”) and terrible for large ones which require constant updates (changes) and mainteneace. This nowadays is an undisputable fact.

Another fact (does not matter how much you like it or not), is that (since CLU) it is well-understood that a properly designed language must be mostly-functional (must have a pure subset and related immutable collections) and must have better defaults and a minimalist (less verbose) syntax for it.

This is what CLU pioneered and then Scala 3 has been done right.

One could look at how clever are the rewrites of some basic Pythonic libraries done by http://www.lihaoyi.com/, which shows that the current Scala 3 is almost as expressive (uncluttered) as Python 3.

The other way around is also the case.

One has to realize that Cython is still and will be an iterpreter, and that even the overhyped meme-lang Mojo will run /Cython “to ensure compatibility”. Yes, it will call and use this very runtime. There is no other way.

A serious (less meme-infested) academic discussion could begin with the realization that Python’s rutime is an enterpreter, and the typing is structural (whatever hangs out from an object). Most of the library code rely impliitly on these two facts.

This, in turn, implies that type-decorations of Python 3 will never become a fully-featured static typing system, and that this is a non-goal. The dynamic (and strucural) nature of Python is its strenght. Being an intepreter is the price to be paid for this dynamic nature.

And no, no bullshit arguments about the theoretial Turing-equivalence of languages will apply. Languages can be vastly different (like, lets say, Smalltalk or Python 3) and have their own unique, definitive features. The fact that Python 3 can run basic CS 101 code is, of course, not the whole story.

So, yes, it is absolutely good (and even necessary) to have ADTs, Algebraic Types, “data-classes” and pattern-matching. We (those who uderstands) have all this since Standard ML/ and Scala got it all by desing since 1.0. There is literally nothing to talk abot.

The whole memepost could be reduced to just “look, the modern python 3.11 finally got the support of all the nice things, which has been researched and well-understood in 80s (Standard ML), and ”finalized“ in late 90s (by the time of the Haskell-98 Report and emergence of Ocaml.

So, Python 3.11 got rudimentary pattern-mathing expressions and necessary type-decoratioins (and data-classes) for it. YAY!

Notice, again, that the types are still strctural, and are checked by an ordinary python code and runtime/. There is no (and never will be) a classic static typing discipline, where the type of every value (or expression) is known (and checked) before the code runs. For that you have to give up what makes Python 3 unique and nice.

And, yes, the trade-offs are well-understood by Racket guys (on the dynamic side) and other “applied theorists”. Haskell and ML guys on the other hand, know (and well-understand) the limitations of having every branch of a conditional expression to be of the same type and of what follows from this (includuing homogeneous lists).

In short, you will become Haskell – Algebraic Abstract Data Types and Type-classes only – nothing dynamic or structural (examined at runtime). The Haskell guys are way ahead in undetrstanding of the limitations of a proper static typing.

ML modules are (and has to be!) proper ADTs. With Scala 3 it is more complicated, but Scala 3 is by desing an OO language, so it has to have some dynamic nature (an object introspection) “under the hood” (at runtime).