I think that it owes its success to be first "port" of python requests to support async, that was a strong need.
But otherwise it is bad: API is not that great, performance is not that great, tweaking is not that great, and the maintainer mindset is not that great also.
For the last point, few points were referenced in the article, but it can easily put your production project to suddenly break in a bad way without valid reason.
Without being perfect, I would advise everyone to switch to Aiohttp.
I literally the other week had the choice between using requests and httpx. I chose httpx after deliberating a bit. I don't need async capabilities right now but I figured it'll be more consistent if that changes later.
aiohttp is an excellent library. very stable. I concurs, but!
it's too heavily tied to HTTP/1, and well, I am not a fan of opening thousands of TCP conn just to keep up with HTTP/2 onward. niquests easily beat aiohttp just using 10 conn and crush httpx see https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1...
I don't that their organisation even know how to do things well. It's not in their DNA to not fuckup their users.
But that being said, I have a good laugh at their announcement because you know they will spend money to try to make the thing nice, everything they can at their own cost, to be able to win the users back and lock them, and then they will start to fuck them up again once they feel confident enough.
Doesn't make sense because AI responses are not grounded, still for AI to make sense in this context, and have any relation with Kagi purpose, you need to have the search still, and then the AI process the search results.
I agree with you for a general assistant but even if I'm also not interested to pay for an assistant there are 2 features that I like and bring a lot of value by default in my opinion:
- if you put an interrogation point at the end of the query you have an AI reply based on the search query.
- you can ask a question about that to investigate more.
We're 6 months away from some company's app/infrastructure/whatever going down and staying down, because literally nobody knows how the 500,000 line code base works and Claude is stuck in a loop.
Right, because the same people who vibe coded their applications are the same people who take the time to setup robust infrastructure to allow for easy roll backs.
At least in France and I think in a lot of other countries, you still get a dedicated IP for your connection, so yes you could receive inbound traffic.
Just the IP will most of the time be dynamic, and you might have your IP changing regularly.
If we need to sum up the state of gov now I would pick the following quote:
He told another colleague, who refused to help him upload the data because of legal concerns, that he expected to receive a presidential pardon if his actions were deemed to be illegal, according to the complaint.
I also find it super more complicated and messy than what you can find in another language without proper justification.
Like the Temporal.Instant with the only difference that is now but in nanosecond.
Would have been better to be Now with a suffix to indicate that it is more precise. Or even better, it is just the function you use or parameter that give the precision.
And why Now as the name space? I would expect the opposite, like python, you have something like
Temporal.Date, and from there you get a date of now or a specific time, with or without timezone info, ...
I think that it owes its success to be first "port" of python requests to support async, that was a strong need.
But otherwise it is bad: API is not that great, performance is not that great, tweaking is not that great, and the maintainer mindset is not that great also. For the last point, few points were referenced in the article, but it can easily put your production project to suddenly break in a bad way without valid reason.
Without being perfect, I would advise everyone to switch to Aiohttp.
reply