Live data from Hacker News

A Rust-TypeScript integration

github.com

51–52 of 52 posts

Re: A Rust-TypeScript integration

#51
post #48

Earlier quoted context omitted.

Ah the classic retort. X is merely a broken version of Y. Y has flaws. Therefore X has all of flaws of Y. No. I don’t accept that. Certainly not prima facie. Solid isn’t a broken version of react. It’s a fixed version of react. Signals aren’t the same as useState because in solid, dependencies are tracked automatically when you read from them and components automatically rerender as a result. Also because component f…

I am not interested in arguing whether state management libraries add value, or how React useState compares to Solid createSignal, but I will reiterate that with React server components, there is no need to manage state on the client at all.

Yeah because then you are managing a session in the backend. A backend that is not necessary. But still billing.

Re: A Rust-TypeScript integration

#52

Earlier quoted context omitted.

Thanks for all the details. I cloned the repo now to take a look. If I see it correctly here, it's a full sveltekit backend that does ssr, and not just used for serving static files. The +page.ts file has a universal load function so during ssr, the sveltekit backend loads data from the rust backend and later during hydration the client also loads data directly from the rust backend without the requests being proxied…

Yeah, you're probably right if you want ssr. My understanding was that most ssr frameworks have ssr as optional and people fight about the tradeoffs between page load time (better with ssr) vs rps per CPU core (better without ssr). I'm not sure if that's the case with svelte. > Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC? Pr…

Quite interesting! I get similar results on my machine. But let's also measure latency which is what should show the protocol stack overhead:

    $ netperf -H 127.0.0.1 -t TCP_RR
    Local /Remote
    Socket Size   Request  Resp.   Elapsed  Trans.
    Send   Recv   Size     Size    Time     Rate
    bytes  Bytes  bytes    bytes   secs.    per sec
    
    16384  131072 1        1       10.00    63506.58
    16384  131072
    
    $ netperf -t STREAM_RR
    Local /Remote
    Socket Size   Request  Resp.   Elapsed  Trans.
    Send   Recv   Size     Size    Time     Rate
    bytes  Bytes  bytes    bytes   secs.    per sec
    
    212992 212992 1        1       10.00    122526.23
    4608   2304
But I would agree now that it probably doesn't matter for most applications.
Post reply on HN