151–160 of 288 posts
Earlier quoted context omitted.
I’ll bite, is it slack?
In all honesty, there's a whole slew of platforms it could be: - Slack - Keybase - Mattermost - Discord - Microsoft Teams - Facebook Messenger (incl. Work) All of these fine folks apparently use Electron or a similar technology...
Whether intended or not, there's an undercurrent of "you're all so dumb for using Python" (or Ruby, or PHP, or other similarly performant language) here. I want to surface that and question it a bit. It's totally reasonable for a company to choose the Python/Gunicorn option if they already have a bunch of people who know Python and they don't need to serve tons of requests per second. Even if they do need to serve to…
Twitter ran on Rails until 10 million users.
They abandoned their message queue (Starling) written in Ruby early on. That abandonment was often misattributed to them abandoning Rails, I guess because of the shared usage of Ruby. The confusion was compounded to back when someone at Twitter (may have been Odeo at time?) posted a message board rant about how Rails does not scale because ActiveRecord did not allow connecting to multiple databases out of the box. That event seems to be the origins of the "Rails does not scale" mantra that swept the internet for a time. But, humorously, someone replied with a solution a few minutes later.
The premise is that people don't understand their system, or software, and need to be told how it works. So you have an admittedly ignorant person telling other ignorant persons that there are possibilities out there. That's... not really useful. What is useful is to spend 2 days researching massively concurrent network applications, and find the ones that were already written, and see how they evolved over time. For…
Yeah, I know, I'm terrible. I don't know jack about this stuff. I should just stop now while I'm behind. Clearly.
Rachel presumably wrote her server in a reasonable language like C++ (though I don't see a link to her source), but when I wrote httpdito⁰ ¹ ² I wrote it in assembly, and it can handle 2048 concurrent connections on similarly outdated hardware despite spawning an OS process per connection, more than one concurrent connection per byte of executable†. (It could handle more, but I had to set a limit somewhere.) It just…
> I feel like with modern technologies like ... we ought to be able to do a lot of things that we couldn't even imagine doing in 2005... As a self-taught programmer I would say that what all these less efficient bit easier to learn technologies have done is enable people like me who evidently are not geniuses like yourself to write software. Should programming always be an ivory tower thing?
Unfortunately this approach precludes GIL languages like Python. If you're able to use a language/runtime that is amenable to multithreading, then using a thread per connection works fine for most use cases (and it's probably easier than using whatever async/await interface your language has).
> probably easier than using whatever async/await interface your language has Is it? I haven't used threads directly in a while, but I remember dealing with sinchronization issues. Problems that just don't exist in single threaded node with async await. I find the async Promise or Task to be a more useful abstraction than the thread. Although, you need threads or a task dispatcher with a pool of threads if you need t…
Earlier quoted context omitted.
I'm using Waitress in production: https://docs.pylonsproject.org/projects/waitress/en/stable/ It's main thing is that it's really simple, worth a look if you're using Django.
going to look at this in depth tomorrow. Thanks
Its primary use case is that it is pure python, doesn't rely on any specific libraries or compilers to run/build, and is a threaded WSGI implementation so it uses Python threads to run a WSGI app.
It works well for what it needs to do, and hopefully it is fairly robust. I've personally ran waitress directly facing the internet, but will readily admit that in most cases running it behind a load balancer is a good idea, especially since it doesn't support SSL out of the box (yet, I should say, it's on my roadmap).
It won't win any speed contests and it won't win performance contests, but it holds its own.
If you have any issues, please drop by https://github.com/pylons/waitress/issues and I'll see if I can help you out :-)
What WSGI do people recommend for python? I've been using gunicorn but this made me think of alternatives. Quick google search found this benchmark [0], is it really that bjoern is much quicker? It seems all other WSGI are ~ equivalent. [0] - https://www.appdynamics.com/blog/engineering/a-performance-a...
I'm using Waitress in production: https://docs.pylonsproject.org/projects/waitress/en/stable/ It's main thing is that it's really simple, worth a look if you're using Django.
`it kicks off a "serviceworker" thread to handle it.`
It doesn't even tell me how I should do this. I don't know what 'serviceworker' code looks like. I don't know what 'kicking off' means.
This post reads like it was made for maybe 3 or 4 people in the world who truly 'get it' and if you aren't in that elite club you're a terrible engineer, apparently. There's not even a lick of example code to get an idea of what is going on. Engineering is a big word that shouldn't be used in this blog post.
``` First of all, it does not take "that much machine" to serve a fair number of clients. Ever since I wrote about the whole Python/Gunicorn/Gevent mess a couple of months back, people have been asking me "if not that, then what". It got me thinking about alternatives, and finally I just started writing code. ``` Another day, another questionable premise for a blog post. No, @rachelbythebay, the question is not "if n…
> If you have a language you're proficient in and with an ecosystem that supports you developing something rapidly, it's borderline malpractice not to start there. I think the point of this post is that most new programmers do not know things can be faster than their monstrous JS blob. The solution to slow requests is more servers instead of fixing the code.
Earlier quoted context omitted.
You ... are not ... Instagram. Okay. Get over it. Python is fine. Threads are fine. Go is fine. Clojure is fine. Java is fine. PHP is ... okay I won't go that far. :) You fix the problem when the cost required to fix the problem is finally less than the opportunity cost of fixing something else.
PHP is fine too. Check out https://laravel.com/ and tell me that doesn't look like a joy to work with.
It's too stringly-typed for my tastes, seems like a lot of errors you can make will only be caught at runtime.