uvloop VS femtolisp

I wound up on a different team with pre-existing Python code so temporarily shelved my use of Go for a bit, and we used Sanic (an async Python framework built on top of the excellent uvloop & libuv that also powers Node.js) to build some APIs for live channel management & operations. We hand-wrote our OpenAPI and used it to generate documentation and a CLI, which was an improvement over what was there (or not) before. Other teams used the OpenAPI document to generate SDKs to interact with our service.

If you're looking for maximum requests per second you can change the asyncio event loop with one like UVLoop.

An optional package uvloop can also be install if working on Linux:

The source code from the project resides in the github, with more than 8.6k stars and 596 forks is a very popular github, but no new releases are made since 2018, looks pure much not maintained anymore, no PR's are accepted no Issues are closed, still without windows or macOS Silicon, or PyPy3 support. Japronto it self uses uvloop with more than 9k stars and 521 forks and different from japronto is seems to be well maintained.

If you are building server-side applications using Python 3 and async API and if you didn't use https://github.com/MagicStack/uvloop, you are missing out on performance big time.

Also, if you happen to build microservices, don't forget to try PyPy, that's another easy performance booster (if it's compatible to your app).

Not that bad actually, with a different event loop implementation (such as https://github.com/MagicStack/uvloop). Not sure how well it will perform in a browser though

And so I did some searching, and found that SearX isn't officially supported on Windows. Not to be deterred, I did another quick search and found that with pip and/or docker, you should be able to install SearX straightforwardly on Windows. After trying this for a bit, I realized that uvloop, a (questionably optional dependency of SearX) is not supported on Windows. I tried a couple things to get it to work, but they didn't end up working for me either through user error, ignorance, or plain old not working.

they also wrote uvloop [0] which is fantastic and advances the cutting edge of what can be done with modern asyncio-based Python. I saw a ~3x improvement in the throughput of a microservice I wrote when I first tried it out years ago. currently at $dayjob we just use it by default in every Python service, whether or not we expect that service to be performance-critical.

0: https://github.com/MagicStack/uvloop

If you manage to grok how uvloop works as well as Python's default asyncio loop scheduler, you'll understand this style. It is not by itself a parallelism enabler, but network I/O the coroutines triggered would run in parallel nevertheless, though CPU bound computations would not by default.

> In short, Julia is very similar to Common Lisp, but brings a lot of extra niceties to the table

This probably because Jeff Bezanson, the creator of Julia, created a Lisp prior to Julia, which I think still exists inside Julia in some fashion

https://github.com/JeffBezanson/femtolisp

Well let's flip this around: do you think you could write a performant minimal Python in a weekend? Scheme is a very simple and elegant idea. Its power derives from the fact that smart people went to considerable pains to distill computation to limited set of things. "Complete" (i.e. rXrs) schemes build quite a lot of themselves... in scheme, from a pretty tiny core. I suspect Jeff Bezanson spent more than a weekend writing femtolisp, but that isn't really important. He's one guy who wrote a pretty darned performant lisp that does useful computation as a passion project. Check out his readme; it's fascinating: https://github.com/JeffBezanson/femtolisp

You simply can't say these things about Python (and I generally like Python!). It's truer for PyPy, but PyPy is pretty big and complex itself. Take a look at the source for the scheme or scheme-derived language of your choice sometime. I can't claim to be an expert in any of what's going on in there, but I think you'll be surprised how far down those parens go.

The claim I was responding to asserted that lisps and smalltalks can only be fast because of complex JIT compiling. That is trueish in practice for Smalltalk and certainly modern Javascript... but it simply isn't true for every lisp. Certainly JIT-ed lisps can be extremely fast, but it's not the only path to a performant lisp. In these benchmarks you'll see a diversity of approaches even among the top performers: https://ecraven.github.io/r7rs-benchmarks/

Given how many performant implementations of Scheme there are, I just don't think you can claim it's because of complex implementations by well-resourced groups. To me, I think the logical conclusion is that Scheme (and other lisps for the most part) are intrinsically pretty optimizable compared to Python. If we look at Common Lisp, there are also multiple performant implementations, some approximately competitive with Java which has had enormous resources poured into making it performant.

While it uses an Algol inspired syntax, it has the same approach to OOP programing as CLOS(Common Lisp Object System), with multi-methods and protocols, it has a quite powerfull macro system like Lisp, similar REPL experience, and underneath it is powerered by femtolisp.

For a real answer, other replies have already mentioned KiloLisp, but there's also femtolisp. Also, not exactly what you're asking for, but Maru is a very compact and elegant self-hosting lisp (compiles to x86).

Take a look at femtolisp It has some low level features and is quite small. There is also a maintenance fork at lambdaconservatory

A fun Julia easter egg I recently discovered.

Running 'julia --lisp' launches a femtolisp (https://github.com/JeffBezanson/femtolisp) interpreter.

Reminds me of the femtolisp README :)

Almost everybody has their own lisp implementation. Some programmers' dogs and cats probably have their own lisp implementations as well. This is great, but too often I see people omit some of the obscure but critical features that make lisp uniquely wonderful. These include read macros like #. and backreferences, gensyms, and properly escaped symbol names. If you're going to waste everybody's time with yet another lisp, at least do it right damnit.

https://github.com/JeffBezanson/femtolisp