"does NOT constrain user's rate limit" should be "does NOT rate limit incoming requests" or similar.
"We will try out best" should be "our best".
"when our servers are under high traffic pressure" is at least grammatical, but it's awkward. Normally you'd say "when our servers are dealing with high load" or something similar.
"your requests may take some time to receive a response from the server" is again grammatical but also awkward. "Our response times may be slower" would be more natural.
The last sentence is also awkward but the whole thing would need to be restructured, which is too much for an HN comment.
Basically: everything about this screams English as a second language. Which does mean that it's unlikely to have been LLM generated, because from what I've seen DeepSeek itself does a pretty good job with English!
"when our servers are under high traffic pressure" - this is a bit awkward I agree, but only the last three words.
If we rearrange it to "when our servers are under pressure from high traffic", I think it sounds good. It's using a metaphor, and I think that should be encouraged. It's interesting. And the phrase "high traffic" conveys some drama.
"your requests may take some time to receive a response from the server" - I think that's fine, to be honest. I like it.
I think you are conflating "awkwardness" with linguistic flair. Technical documentation English has become standardised to a large degree, which of course is useful, and efficient. But it is also a narrow usage of English, and breaking out of its straitjacket does not make language awkward.
If someone was editing my writing, it would feel a bit patronizing if they said grammar mistakes (many of which come from my mother tongue Portuguese) are “adding flair”, as they are not a stylistic choice.
As for it being patronising, why is telling a non-native speaker their sentence is interesting unacceptable, but telling them it's awkward is ok? (Assuming both are genuinely held opinions).
I'll reiterate my point that common English usage (non-awkward?) has narrowed enormously in the last 50 years. I think that this is a bad thing.
How can the time be slower? Response times may be longer, but not slower
Some examples of my usage in the wild ("response times may be slower" is present verbatim on each page):
https://github.com/aquasecurity/trivy/discussions/8133
https://www.ameristarstaffingny.com/the-negative-effects-of-...
https://oci.wi.gov/Pages/Regulation/Bulletin20200320Regulato...
https://playrix.helpshift.com/hc/en/27-questbound/faq/13930-...
And in English, the word “worse” requires a comparative compliment . Worse than what? Maybe you meant worse than a non-native speaker, but because you didn’t say it, your sentence sounds off.
In English time can have lots of lengths. Any number of English novels have the phrase “a long minute”. People talk about time passing slowly or quickly. We say things like “The last 15 minutes took hours!” Or “Today went by so fast.”
Just because the word “sunrise” is nonsense scientifically doesn’t mean it’s not understood and correct to use in English.
Maybe. However, in my opinion, it’s better to write in such a way that leaves zero chance for misunderstanding.
I often use 'slower' and 'faster' as a native speaker to help reinforce the meaning of the direction.
Higher as opposed to lower? It makes no sense to me.
Consider: "after investigating response times and doing and doing a bunch of work, my PR causes a 30% reduction" - if you're busy doing lots of things and already have a lot of cognitive load, this could sound bad because the important phrase "30% reduction" is in there. You are a detail oriented person who is immune to this effect, but there are people who need help reducing their cognitive load in this type of thing.
You can help people reduce cognitive load by replacing "reduction" with "improvement" so they immediately understand that it moved in the right direction.
"Response times will be higher" sounds very confusing as a way of saying we'll take less time to respond, right? So why should "response times will be lower" mean we'll take more time if the opposite construct is confusing?
Far better to just use the comparative forms that we already have for time specifically to make it perfectly clear.
A lot of English native speakers has such assumptions that:
- any academic topics are universally discussed in English/Latin and so every highly educated person shall speak good English, - language is like a thin wrapper over a to-be-converted-to-YAML common intermediate language(Universal Grammar theory), - anything should translate into fluid English with intent completely intact, - but WWW is >90% English anyway, - etc.
None of these are true, and it's just not realistic for a well educated East Asian - common theme of East Asian languages is it's all custom implementations with minimal sharing with neighbors let alone English - to "just" pick up natural English. I suppose you're looking for something like following:
"At DeepSeek, we strive to serve every request to our customers with best of our effort, and we do not impose a rate limit for our APIs. However, do note that due to finite nature of our computing resources, API responses might become delayed in cases when our backend is experiencing high load. Under such circumstances, the HTTP sessions will be kept alive, and response will be served in following formats..."
... Isn't this a $1m/yr skill on its own? Have you seen a great Far East engineer write like this - I mean, how often do you come across a Far Eastern translator that can casually do this?
The goal is to pretend that DeepSeek doesn't have access to good English translators? Or good English translation capabilities?
Why don't we just not pretend this instead?
A lot of HNers puts blind trust on Universal Grammar Theory and downplay languages as all but obsolete human output packing format that are each no more than header differences and those are just wrong. Languages are at least CODEC. And if you go back to the original topic from there, I don't think it will sound so unreasonable that translating between different CODECs will induce losses and artifacts.
