Comment by w0utert | Hacker News Reader

Comment by w0utert | Hacker News Reader

Parent Full thread

>> - 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.

Reply on news.ycombinator.com