The “src/“ directory[0] contains compiled .so files. Is this even open source? [0] https://github.com/cirospaciari/socketify.py/tree/main/src/s...
Hmm... there's Python and CPP. src/socketify ├── __init__.py ├── __main__.py ├── asgi.py ├── cli.py ├── helpers.py ├── libsocketify_darwin_amd64.so ├── libsocketify_darwin_arm64.so ├── libsocketify_linux_amd64.so ├── libsocketify_windows_amd64.dll ├── loop.py ├── native │ ├── Make.bat │ ├── Makefile │ ├── src │ │ ├── libsocketify.cpp │ │ └── libsocketify.h │ └── uv_selector.txt ├── native.py ├── socketify.py ├── ssgi…
Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
101–110 of 192 posts
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#102Good point! However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. Just as a piece of evidenc…
E.g. many languages’ syntax is context-free, yet the languages themselves are almost always Turing-complete.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#103Probably should add that it's faster with PyPy as it might not be obvious on how an interpreted language like Python can beat an AOT compiled language like Go. Interesting results nevertheless.
Yeah, I'm converting to HPy and it probably will be faster in CPython too, but like you said AOT is hard to beet without JIT at least. But with CPython is faster than Golang Gin :D
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#104Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#105Earlier quoted context omitted.
Hmm... there's Python and CPP. src/socketify ├── __init__.py ├── __main__.py ├── asgi.py ├── cli.py ├── helpers.py ├── libsocketify_darwin_amd64.so ├── libsocketify_darwin_arm64.so ├── libsocketify_linux_amd64.so ├── libsocketify_windows_amd64.dll ├── loop.py ├── native │ ├── Make.bat │ ├── Makefile │ ├── src │ │ ├── libsocketify.cpp │ │ └── libsocketify.h │ └── uv_selector.txt ├── native.py ├── socketify.py ├── ssgi…
Ah, thanks! In my defense, the native/ directory contains the portable C++ source and the src/ directory contains a the native executables.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#106This is kind of cool, but it all makes sense if your app is a very simple CRUD that spends 99% of time just passing json around. I have this feeling that when you add some more logic there you’ll start noticing that you’re not in a compiled language any more. Your requests will get slower and your memory usage will explode. Saying that Python is faster than Go with this as a proof looks like overreaching for Me. It o…
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#107Since we're in the useless benchmark, this Go native library completely wreck any C/C++ lib wrapped by Python: https://github.com/panjf2000/gnet It is as fast as the fastest C++ / Rust implementation.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#108The “src/“ directory[0] contains compiled .so files. Is this even open source? [0] https://github.com/cirospaciari/socketify.py/tree/main/src/s...
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#109Earlier quoted context omitted.
Yeah, I'm converting to HPy and it probably will be faster in CPython too, but like you said AOT is hard to beet without JIT at least. But with CPython is faster than Golang Gin :D
Graal JIT often beats Graal AOT in the Java “universe”.
Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3
#110I assume that if this C-extension is faster than Golang Fiber, it is way faster than asyncio! And it would have been the same with Python 2.7. This demonstrates yet again that the main value of Python has always been C-extensions. The efforts of the old boys to add bloat in Python 3 (mostly written by other people of course, the old boys talk and rarely develop) have been misguided.