191–200 of 288 posts
Earlier quoted context omitted.
I've mainly used gunicorn and uwsgi, without seeing any large differences. But my apps have fairly light network requirements. It seems like the new trend for Python servers is ASGI ( https://asgi.readthedocs.io/en/latest/ ), e.g. as in uvicorn ( https://www.uvicorn.org/ ).
But from what I understand this replaces gevent, you still use gunicorn to manage workers?
Now in order to make it slow you must know enough stuff to introduce complexity to the program. To make a slow program you probably have to learn about frameworks, php, micro services, cloud databases, etc.
- Web-anything is fetched off of a DB nowadays. That's another crapton of latency, because a) it's just easier to understand its characteristics if it runs on a separate system and b) most companies IME have either no DBAs at all or the DBAs have no time to look in depth at every system being built. So the DB resources are vastly underutilized, and the DB itself is badly understood.
- Cache invalidation is still the hardest problem, and every caching framework I've looked at seems to gloss over that part. Just cache all the things and hope people retry enough times to get the latest update. I would love someday to work on a system where things are aggressively cached at every level and invalidated at every level and with perfect granularity.
- Building for web scale from the beginning is premature optimization for the vast majority of companies. In the vanishingly unlikely scenario that the company actually grows 100-fold or more it makes sense to start investing heavily in performance. Of course, this also has the knock-on effect that the vast majority of software developers never get anywhere near a web scale system. OTOH it creates jobs for millions of developers, some of whom might end up building at scale someday.
Another elephant in the room is that building anything at web scale is just not something anybody straight into the workforce is anywhere near qualified for. We desperately need more focused learning (mentoring, pairing, etc.) across the board to bring everybody up to speed faster.
Earlier quoted context omitted.
1) .NET APIs change very frequently. 2) C# is a very verbose language, that requires a lot of typing. 3) F#, the best language in .NET, is largely ignored by the .NET community.
> 1) .NET APIs change very frequently. ASP.NET Core 2.1 was released in 2018 and will be supported until late 2021. ASP.NET Core 3.1 was released a few months ago and there is no end of support in sight. Moreover, the changes between 2.1 and 3.1 were not that many. I've migrated a whole ASP.NET Core 2.1 web service to 3.1 in less than 1 hour. > 2) C# is a very verbose language, that requires a lot of typing. Nonsense…
Which is way too unstable, especially for the kind of corporate environment c# has typically been used in. Getting those places to upgrade to stable supported versions of the framework has always been a battle even when backwards compatibility was great, if they have to deal with breaking changes every few years they will never upgrade.
This is why so many companies stick with their ancient COBOL systems, most modern alternatives don't offer the stability they need.
Earlier quoted context omitted.
> Even if they do need to serve tons of requests per second, it's totally reasonable for them to still choose Python/Gunicorn if the cost of the additional servers is less than the cost of having to support multiple languages. How hard is it to get up to speed on any other tech stack? ASP.NET Core is extremely fast and the learning curve is close to none, for example. If someone was able to wrap his head around backe…
Learning curve close to none? I like that many times there's "the way" of doing things, but when I have to do something slightly outside the recommended way, I feel that the effort required outweights all the benefits.
Earlier quoted context omitted.
Saw an interesting talk just about this topic [1] The gist of it was: Other engineering disciplines use the techniques you've mentioned because of the the costs, both time and money, associated with getting it wrong. Software engineering lends itself to different methods of development and construction, as the costs associated with getting it wrong or making changes after the fact are much lower. (For most applicatio…
*Assumed to be lower. What is actually happening we don't know. IT is dramatically changing everything. It's not all bad but it isn't all good either. I hate to give examples since it is really vague what goes in and what comes out and people tend to mistake an example for full coverage but... for example, we have no idea what drives suicide rates.
This is a good point but I wanted to make it a bit more clear.
Across a population we have a good idea of the risk factors and of the things that increase rates of suicide: deprivation, abuse, substance misuse[1], previous self harm.
The bit we have no idea about is how to apply these to an individual person to see if they're high or low risk of suicide.
There are a load of different tools that input lots of different information and put out a risk rating, and none of them are as good as just asking the person "what do you think your risk is?"
It's about 30% slower than the fastest golang equivalent.
For multiple-queries benchmark, its about 40% slower. https://www.techempower.com/benchmarks/#section=data-r18&hw=...
Once I start bringing Numba for accelerating computational usecases... I guess the difference will be even smaller.
Does she even see the size of the batteries included in a framework like Django? Here is some brand new information. Everyone knows Python/Django is slow and inefficient (same for rails) but they still use it for those batteries.
It is easy to write some web service in a low level language that just crunches some numbers for your benchmark. It quickly gets complicated when you start thinking about accounts, security, passwords, databases, orders, carts etc.
> 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. I actually want to know: then what? As a web developer who usually reaches for Django or Flask with Gunicorn because I just don't know any better, is there a better stack that doesn't face these pr…
> is there a better stack Apparently, it's C, or ...assembly? According to the comment above yours. Because developer time is apparently cheaper than CPU cycles. Weird.