Hacker News Reader

>> - Finally (and most unfortunately): A lot of the strength of Python is in its ecosystem, and a lot of that ecosystem relies on native code.

I was thinking the same thing... One can wonder how much value there is left if you build an alternative Python interpreter that can e.g. run in the browser, but cannot support C extensions.

I mean I like Python for what it is, but once you stray from the common/intended use cases, e.g. trying to embed the interpreter in a C++ program, skeletons fall out of closets around every corner.

For all it's merits, CPython feels like a house of cards, burdened by a legacy of bad engineering decisions it cannot get rid of anymore. It made me realize it's better to stop fighting it, use CPython as-is (which is great), and use other scripting languages for embedding, live-coding, web, etc. I very much prefer Python over JavaScript for example, but even then it wouldn't cross my mind to use some kind of Python-to-JS implementation for web frontend code, honestly.

> CPython feels like a house of cards, burdened by a legacy of bad engineering decisions it cannot get rid of anymore

At PyBay last year, I ended up with a knot of Python core devs talking about this problem, and talking about building a better, more portable API for native modules. The transition would be nasty (the 2->3 transition was..scarring), but it would solve this problem at a stroke.

> I very much prefer Python over JavaScript for example, but even then it wouldn't cross my mind

I would encourage you to at least check out Anvil (https://anvil.works). It's more than a Python->JS compiler; it's a reimagining of what the web as a platform could look like.

FWIW, I agree with you that it's a bad idea to swap out JS for Python at one layer, while keeping the rest of the stack intact. It's extra complexity, and it doesn't solve the actual problem with the Web, which is the sprawling complexity of the stack and all the weird frameworks that work around it (while themselves making the problem worse).

The Big Idea of Anvil is to replace all those different layers of abstraction with one big, coherent abstraction. That's one reason why we deliberately chose Python rather than JS, so that users wouldn't reflexively reach out and break that abstraction every time they Googled how to do something.

> a better, more portable API for native modules

Pretty sure this exists already: https://github.com/pyhandle/hpy

I really liked Anvil, the thing that made me go back was the requirement for an enterprise account to not host on AWS.

Good news! We open-sourced the runtime, and the standalone App Server, so you can now deploy anywhere you like:

https://anvil.works/open-source

(And yes, it even works with the Free plan)

I'll give it another look, thanks for letting me know!

Anvil looks really interesting, and I appreciate your free forever tier, but I think you're missing a hobbiest tier.

I'd be concerned about investing too much effort in case my project strayed over one of the limits and I have to either pay £39 or kill the project. Whereas I would pay £5 without even thinking about it for access to all the libraries and perhaps a handful of emails etc etc.

Once I'm paying the £5, I can see my requirements potentially growing to reach £39/m but as a hobbiest I'd definitely never get there without stepping stones.

Just as a curious reader, what exactly is it that makes you very much prefer Python to JS? As someone who uses both professionally I rarely if ever miss Python features in JS (or vice versa for that matter, aside from the lack of multi-line anonymous functions or block scoped variables in Python)

Tooling and libraries mostly. In python the ideal is there "should be one, and preferably only one, obvious way to do things". This makes it a lot easier for me to reason about other people's code. The tooling is also an issue, with how much it can take to get started coding.

There's also stuff that surprises me around variable scoping, I imagine I'd get used to it but...

There are also just a bunch of foot guns I have to re-learn, like the comparisons often being bizarre, it's easy to work around all those when you're aware of them but there are a lot of those little eccentricities.

Obviously some of this is subjective, but the main points of frustration are the terrible standard library, the type system requiring you to use things like ===, !== to prevent crazy type conversions, the total lack of advanced built-in data structures, and the fact that you pretty much need to use transpilers to use all the language features, things like coffee script to get a sane type system etc. JavaScript lugs around a lot of legacy and it leaks out in bad way. That, and I absolutely detest the whole npm ecosystem and most of the rest of the typical JavaScript toolchain. That said, I appreciate its ubiquity, and it does have some nice things lik very good support for functional, reactive and/or async programming styles.

But like I said, I may not be entirely objective as I work almost exclusively in C++ and backend Python these days, so JavaScript is pretty far outside my comfort zone anyway.

Starlark is a Python dialect implemented by Google. It is rather liberal with compatibility, but as you observed, none of that matters for "ordinary code". It doesn't even pretend to support existing Python library ecosystem.

In exchange, Starlark is GIL-free. This was the primary motivation to reimplement. It really is that easy if you don't need to be compatible.

I think Starlark is a good approximation of the core of Python. It is easy to implement. It DOES 100% look and feel like Python, and if you use it as Python-as-pseudo-code mode, you will never realize it is not Python. On the other hand, almost no Python library will run. This feels paradoxical, but that's what it is.

https://github.com/bazelbuild/starlark

Wait I didn't realize it wasn't python. Google engineer for 3 years now.

Haha. It is 100% obvious if you are a Python implementer that Starlark IS NOT Python, but it is ALSO 100% obvious if you are a Python user that Starlark IS Python. Strange, isn't it? Such is life.

A lot of Starlark code at Google is still tested using a Python framework. So the code is compatible with Python to a fairly large extent.

A Starlark interpreter can easily be compiled to webassembly and run in a browser. I did it here: http://laurent.le-brun.eu/starlark/

Just to emphasize this:

https://github.com/bazelbuild/bazel-skylib/commit/9948d5538b...

It's possible to `exec` bazel and have it work, with some trickery.

This is quite intriguing since my first thought after reading this is "its too bad we don't have a language thats all the syntax of Python but none of the baggage" and then the #1 child of the #1 comment is almost that. Not quite, but almost.

It’s interesting to me that Python depends so much on native code to have even reasonable performance, but because so much of the ecosystem is native code and because the native code interface is “CPython shaped”, it becomes incredibly difficult to improve CPython’s performance because it would very likely change the shape of CPython. Of course we could have the best of both worlds—a fast Python that allowed you to use native extensions—but the native extension interface would have to be minimized to something that would give Python implementations some ability to look different than CPython today. And when you have a performant Python implementation, much less needs to be implemented natively, which makes things like package management and cross platform development much easier (specifically you don’t have to worry about cross-compiling and testing on your target becomes considerably less important because Python is portable while native extensions likely are not). The latter becomes a lot more pertinent if you’re on x86 targeting ARM or if you’re on a new ARM MacBook targeting x86 or if you’re targeting WASM from either. These cases aren’t common today, but ARM and WASM seem to becoming increasingly likely in the future.

I think that what's even more interesting to me is that people perceive this as such a preoccupying problem.

When I was a young little programmer, the dream was to have a base layer of highly performant native code for handling the heavy lifting, tightly coupled to a very high level scripting language that wasn't really even trying to be performant. The thought being that the scripting language should be more focused on flexibility than performance, because, for the bits of the software that it handled, developer productivity was more important than raw performance.

Fast forward a year or two, and we are living the dream. It's Python, and, while I could nitpick implementation details and language features all day, the big picture is that it's pretty awesome. So awesome that, for the machine learning and data engineering work that I do, the most performant and most productive language I have to work in is Python. (Also R, which is a pretty similar technical story, but I realize that R lost the popularity contest, and I understand why.)

I guess it starts to feel to me like we're making the perfect the enemy of the good, here. We've got a well-established, productive, flexible, and easy-to-learn language where top-tier performance can generally be implemented as a library solution. Despite its many imperfections, that's pretty darned good. In my career to date, I haven't seen much cause to believe that I could realistically expect much better than that. I think that, when I do need better performance, I'd rather write a library than rewrite the language.

Some people have performance requirements to meet, and we’re pretty locked into Python (because some of our engineers foolishly bought into the promise that we could just rewrite the slow parts in C/Pandas/multiprocessing/etc).

If this is “living the dream” then Go and other languages will blow your mind. You can have iteration that is at least as fast (especially when collaborating with other engineers) and performance that is 2-3 orders of magnitude better than Python. Not to mention a better packaging and deployment story.

The sad thing is Python could be much better, but it has to back out of some bad design decisions first.

> Not to mention a better packaging and deployment story.

Go's "packaging and deployment" is enough to rule it out for new projects for me.

This was known at the dawn of python and before, though. For example lisps in various flavors were doing this high-and-low very well decades earlier; arguably nothing has done it radically better since.

So it's worth asking why that never took over the world as a counter to why python exploded.

It's tempting as a technology person to wish a "better python" had been the one to gain that sort of market impact. However, we have to at least ask the question if some of its technical flaws actually contributed to its success....

> So it's worth asking why that never took over the world as a counter to why python exploded.

JavaScript would like a word.

do you mind sharing exactly what problems you've had with Python?

Performance and dependency management are the big ones. Huge binaries are another pain point as well. We would like to run code in lambda functions, but the binaries (which aren’t that complicated) are too big 250MB so we have to run them in ECS tasks which take something like 30s to start up and building the images takes a lot longer as well (we could probably spend time to optimize the docker image builds).

I run lambda functions in Python but I just upload the code. I suppose you are using lambda functions in a way that isn't really promoted for Python.

We also “just upload the code”; however, the issue is that the code size is too large. Lambdas can only be 250mb, and if your dependency tree includes Numpy that’s 70mb alone. Go binaries are about 2 orders of magnitude smaller than Python binaries by my crude estimation. Go compiles source code to native machine code and the linked trims dead code. Neither of these are possible in Python, so you get enormous binaries.

I can see why that's a problem. No tree shaking either in Python. Still it seems like aws can solve the problem by lifting your limits or something.

They said they work on machine learning and data engineering, which means they are very likely using very optimized native code libraries with Python bindings. Go's FFI story has a lot of overhead, so it's actually not inconceivable that Python could be faster for their specific needs.

His first paragraph suggests he was making a general comment, but I agree that if you’re doing very specific things like calling into optimized libraries then its not much of a problem; however, if you have to call into those libraries O(n) or worse, which is often the case, then you’ll very likely lose all or most of the performance you gained due to marshaling costs (not sure how these marshaling costs stack up to Go FFI, but in ago you would just write optimized Go in this situation—e.g., move allocations out of the hot path, make sure critical paths are inlined, etc—which isn’t an option available to Python developers). But yes, if your use case is calling into an optimized C library O(1) (and you have a high degree of confidence that it will never be worse than that) then Python will work fine (or rather, you won’t be fighting with performance, but you’ll still have to deal with package management, poor documentation, huge binaries, etc).

I think though the perceived problem is that as soon as you have to shift between high and low levels, you have a boring friction which gets people dreaming of a different way, hence Go, Julia et al.

It’s that the “shift between high and low levels” costs performance, and if you have to do it O(n) times or worse (as is often the case), then that marshaling cost is a significant portion of (or even more than) the savings that you get from using a lower level language. This isn’t an issue in Go because you can just write faster Go without a marshaling overhead (or you can pay a similar overhead and call into optimized C libraries, but this is rarely necessary or worth the trouble since Go is far more maintainable and generally fast enough.

I think the answer to the "how to support enough of the ecosystem to be useful" question really lies in making it super straightforward for package authors to integrate it into their packaging/testing/ci pipelines. If people test for your implementation, they will very quickly pick up when they're starting to use a feature that may unnecessarily exclude users and hopefully avoid it before it becomes too deeply ingrained in their design.

I love Skulpt! I'm so glad that it's being actively maintained. Thanks for all your hard work!

Lurking here is the main problem, not only of python but of so many langs: Dependency on the C-ABI.

EVERY interfacing with C sucks, even made on C!

Hopefully web assembly become good enough to change that...

> we have often been disappointed by how many [stdlib modules] use native code - even in PyPy!

The CPython interpreter is so slow that it makes sense to implement as much as possible in C. In the past, I've used this as an argument against slow interpreted languages - a faster implementation would not only run code faster, it would allow code to be written faster because more of it could be in a higher-level language.

However, I'm surprised that PyPy uses a lot of native code - not only does it have a fast JIT, but its whole raison d'etre is to be Python-written-in-Python - that's even the project's name!

Our of curiosity, why not just compile cpython to webasm and call it a day by shimming in module loading? I'm sure it's for performance (or extensibility?), but I'm curious where it really falls down.

That totally does work, but in practice it makes the initial bundle download too big to really be workable for the average website.

Would the same be true of javascript? If chrome didn't come with V8 in it, would it be a lot for the average website?

One way to find out would be to compile QuickJS [0] to WebAssembly.

[0] https://bellard.org/quickjs/

Seems to be 945KB in WASM.

http://numcalc.com/

This is exactly what Pyodide (mentioned in the article) does, and it works great for some use cases. The problem is that downloading and wasm-compiling the entirety of CPython and all its native modules is big and slow.

A colleague of mine collected and compared a few Python-in-the-browser implementations - including Skulpt and Pyodide - with code samples and a description of the trade-offs.

You might find the write-up interesting: https://anvil.works/blog/python-in-the-browser-talk

Not to mention any native module you might want to use from Pypi must also be compiled for WASM which is probably not very easy to come by.