Live data from Hacker News

Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

github.com

151–160 of 192 posts

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#151

Earlier quoted context omitted.

> Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. This is the case for basically every programming language or performant library that exists. Yet, I never see this when discussions exists about node libraries or other languages for that matter. I mean you could argue that node itself is just a thin wrapper around fast C++ libraries. Who the fuck cares if th…

> Yet, I never see this when discussions exists about node libraries or other languages for that matter. Huh? It's the first comment for pretty much any of these stupid performance comparisons. Does someone really think node performance is great, or pick node because of its performance? > I still write my logic in Python and get this benefit anyway. That's part of the point. Writing your logic in Python is fine, but…

I think the issue is that there is three different types of people when it comes to performance.

There is the 1% that are in a need of hard realtime performance, that thinks about GC performance as an issue that needs to be adressed. Sure I can get that for these people, these kind of discussions seems stupid and confusing since they have to develop in C/C++, Rust etc to get the pure performance they need. These people probably aren't in this thread because they know that Python is not a language for them and will never be.

Then there is the 99% crowd, which I am a part of, that could use slow-as-shit frameworks like Rails or Laravel because the performance is just a nice-to-have. These people, like myself, compares Python perf to perhaps PHP or Node because they are fast enough languages and in this kind of league a framework like OPs can make a huge difference. No matter what language you pick here you are basically always using something "beneth" it. Node has been picked by many because it's faster than for example Python and Ruby.

Then there is the people who are part of the 99% crowd but are just have to comment and point the needs of the 1% out because they are negative people who probably produce little themselves and have to hate on what other people create and distribute for free. This group is where most haters on HN belong in. :)

I started in PHP, when I went to Node in the early beginning I was deeply impressed by the great performance and nice features it had. Sure it was built upon C++ libraries but I am never gonna use C++ to write my web api. Still, I could use Node and get 2-3x AT LEAST the performance in all of my endpoints because of this and all my code was in javascript.

What I am trying to say is that I don't care if you pack my code and run it on a computer in Minecraft or your calculator, if it runs faster for very little to no pain on my side that is pure joy to me.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#154

Good 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…

Language is used to communicate. And not needing to be absurdly verbose in everything that one says, is a virtue and a need for efficient transmission of concepts and idea.

So when someone says "Python is an interpreted language" they are pleading to an implicit preexisting shared knowledge about the nature of the most commonly found usage of the concept.

Granted, when this shared knowledge doesn't match, that's where misunderstandings can happen, but that's the nature of human language. In this case I'd be hard pressed to think that any misunderstanding could have been possible for the immense majority of people reading this.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#155

Good 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…

>> However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. My advice to you: Stop fighting that "misconception". See the other responses to back up the idea that Python is interpreted. The existence of a Python compiler is also not relevant here, as the linked project does not list that as a supported Python variant. Let's assume that by…

Common nomenclature is a hard thing to rally against, and probably not worth the fight.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#156
post #57

sure it's faster.. but go gin and fiber are really slow. they are literally 90% slower than the fast go frameworks. Not that im a go fanboy, but to put things into context here, the actual context here is: python framework 5% faster than fiber and 85% slower than gnet/silverlining/gearbox.

How is fiber slow? Can you please provide some source? According to the techempower fortune branchmark, it's the 3rd (prefork) and 6th (normal) fastest go framework and even in the all-language list it's 24th and 34th.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#157

Earlier quoted context omitted.

For all practical purposes, a programming language is defined by it's general real world implementation, and not it's specification. Maybe not so much for computer scientists, but for programmers, Python is interpreted with some JIT alternatives and C++ is compiled.

I literally posted the links to the AOT Python compiler and to the C++ interpreter.

I literally posted the links to the AOT Python compiler and to the C++ interpreter.

That would be important in high-school debate club. In the real world, most people don't care about obscure edge cases and pedantry. In the industry vernacular, Python is an "interpreted language" and C++ is a "compiled language". Arguing against that in anything other than a highly (highly!) specialized context is just lighting candles in the wind.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#158

Good 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…

>> However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. My advice to you: Stop fighting that "misconception". See the other responses to back up the idea that Python is interpreted. The existence of a Python compiler is also not relevant here, as the linked project does not list that as a supported Python variant. Let's assume that by…

Like asking an engineer not to argue a detail!!!

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#160

Good 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…

>> However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. My advice to you: Stop fighting that "misconception". See the other responses to back up the idea that Python is interpreted. The existence of a Python compiler is also not relevant here, as the linked project does not list that as a supported Python variant. Let's assume that by…

While I also find arguing for the sake of arguing tiresome, the comment your responding to makes a good point. The linked project beats Go fibers using PyPy, which is JIT compiled, where hot codepaths are not interpreted. A language is a set of rules (hopefully described in a specification...) - you can have interpreted C++, or compiled Python. The popular implementations are just that: implementations, of which others exist.

> Rather than convince them, you are destroying your own credibility and probably making a fool of yourself in their eyes.

I'd understand where you were coming from had the parent comment not explained what they meant and given examples.

Post reply on HN