# hackernews.search_comments **stable** **Advanced** Search Hacker News comments. `GET /v1/hackernews/search_comments` ## What you get A list of Hacker News results in Onekey's unified shape, in `data` (an array). An empty array is a normal, successful answer and is charged like any other; a source that reports "nothing found" as an error returns a free `404 not_found` instead. **Pagination:** 20 results per page. The response carries a `pagination` block; send its `next_cursor` back as the `cursor` parameter to get the next page. Every page is one call at the price below. See [Pagination](https://onekey.dev/docs/pagination.md). ## What it costs - **Advanced · 5 credits** for a fresh fetch, charged only when it succeeds. - **Free when served from cache (0.2 credit for a cached response over 100 KB).** - **Free** if the request is invalid (never charged) or the source fails or reports not found (refunded). ## Parameters | Name | Type | Required | Default | What it is | Constraints | | --- | --- | --- | --- | --- | --- | | `q` | string | yes | (required) | Search query | max 200 chars; trimmed, repeated spaces collapsed | | `cursor` | string | no | - | Opaque cursor from a previous response's `pagination.next_cursor`. Omit for the first page. | - | ## Request ```bash curl "https://api.onekey.dev/v1/hackernews/search_comments?q=rust" \ -H "x-api-key: YOUR_API_KEY" ``` ```python import requests res = requests.get( "https://api.onekey.dev/v1/hackernews/search_comments", params={"q": "rust"}, headers={"x-api-key": "YOUR_API_KEY"}, ) body = res.json() if body["success"]: print(body["data"]) else: print(body["error"]["code"], body["error"]["message"]) ``` ```javascript const params = new URLSearchParams({ q: "rust" }); const res = await fetch(`https://api.onekey.dev/v1/hackernews/search_comments?${params}`, { headers: { "x-api-key": "YOUR_API_KEY" }, }); const body = await res.json(); if (body.success) console.log(body.data); else console.error(body.error.code, body.error.message); ``` ## Recorded response A real Hacker News response, recorded and returned in Onekey's shape. Fields the platform does not provide are `null`. ```json { "success": true, "data": [ { "content": { "id": "9999959", "title": "LLVM for Grad Students", "url": "http://adriansampson.net/blog/llvm.html", "text": "The issue is not having the type info available. AOT compilers certainly have that (or at least, enough of it to get the job done). The issue is that most compilers with precise GC---AOT or otherwise---are built around that assumption from the very beginning. Therefore, they choose representations, algorithms, and optimizations that are amenable to GC, and in particular don't destroy the type info necessary to make GC work. It is possible in theory to do the same with LLVM, but difficult in practice. Most existing LLVM-based GC'd languages compromise on performance by requiring LLVM to \"root\" pointers, effectively forcing them to stay on the stack (instead of registers) so that the GC can see them when it needs to. LLVM's optimizations (particularly at the machine-specific level) were previously allowed to do arbitrary things with register-based pointers, which is obviously bad for a GC if no copies of those pointers exist on the stack. It just takes a long time to take a code base that large and untangle the code from such basic assumptions. This appears to be changing, as the release nodes for LLVM 3.6 indicated. But it will take time. In the mean time languages on LLVM are either going with conservative GCs, or with precise GCs with the performance degradation noted above (e.g. OCaml), or with no GC (e.g. Rust for the time being). Source: My talk on precise GC for Rust (from 2012):