HackerLangs
TopNewTrendsCommentsPastAskShowJobs

cetra3

no profile record

Submissions

The State of Rust Allocators in 2026

cetra3.github.io
2 points·by cetra3·vor 4 Monaten·0 comments

comments

cetra3
·vor 24 Tagen·discuss
It just looks like stdx has copied stuff from crates and put it in a git repo.

It feels like this is worse than a package manager? As in why would I trust a random git repo to keep things up to date over the officially published channel?
cetra3
·vor 2 Monaten·discuss
In pretty much every bit of code I've written both professionally and leisurely I have always used tokio.

However, there are reasons why you might not want to use it:

- You don't need async at all

- You want to own the async execution polling completely

- You want some alternative futures executor like io uring (even though tokio-uring is a thing)
cetra3
·vor 5 Monaten·discuss
Isn't your password manager a single point of failure?
cetra3
·vor 5 Monaten·discuss
Yeah would love this for logfire
cetra3
·vor 6 Monaten·discuss
Yes it is, page 29 of that PDF lists it:

- Sony WH-1000XM4
cetra3
·vor 7 Monaten·discuss
UDP and TCP are Layer 3 protocols, and so is ICMP. They all fill the same bits within network packets, like at the same level. So sending an ICMP packet (protocol 1) is not the same as sending a UDP packet (protocol 17).

You can see a list of network protocols in /etc/protocols actually, or here: https://www.iana.org/assignments/protocol-numbers/protocol-n...
cetra3
·vor 8 Monaten·discuss
For those like me who are obviously blind, the new location is at https://codeberg.org/ziglang/zig
cetra3
·vor 8 Monaten·discuss
> Node.js and Go are considered practically safe language

Node JS has had vulnerabilities in the past: https://www.cvedetails.com/cve/CVE-2021-22940/

Go is also not Memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html
cetra3
·vor 9 Monaten·discuss
I just added a deco planner for DiveDB (https://github.com/cetra3/divedb): https://divedb.net/dives/plan

Need to add gas planning next!
cetra3
·vor 3 Jahren·discuss
Thank you! I've tried to address your questions below. Most of these decisions stem from having the backend written in Rust, & using GraphQL. That decoupling in the end made it a lot easier to port from react.

- I am using a rust backend for the static files and didn't want NodeJS part of the request workflow. Most pages aren't changed all that much, like maybe once every few months & so having yet another service as part of the connection flow just adds resources/delay when it's not needed. It's a lot faster/easier/cacheable to serve a static file.

- The prerender doesn't take all that long, maybe a minute or so, it's fast enough for the site as it stands, but if it got super massive it'd be a different story. I throttle how often it happens currently, so that there is a bit of time between pre-renders.

- The frontend communicates to the backend via GraphQL & the backend is not part of svelte kit, it's an entirely separate service, and so things like `page.server.ts` won't apply.
cetra3
·vor 3 Jahren·discuss
I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet.

The only main frustrations I have are:

- Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them.

- Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh certain static pages as I know that changes are made. Right now I'm doing a janky refresh using a file lock notifier & it's a blemish on an otherwise great framework.

- The URL routing in svelte kit is... a little ugly. It's really hard when you have an editor open with 5 `+page.svelte` files. I wish they re-introduced file name routes, rather than folder name routes. It is entirely a personal preference I know, but I have seen a lot of negative things around it.

[1] - https://github.com/cetra3/divedb - deployed at https://divedb.net/