The last time I read Cosmos I hit the part about the Cassini-Huygens mission where he wondered what we might find under the atmosphere of Titan, and was able to immediately just find out.
I imagine a lot of people who work on space missions do not outlive their work - which feels sad but also ... inspiring?
I've taken the course and love the book. The key takeaways for me were to shun cleverness in favour of building demonstrably sensible models out of simple parts and clear causal assumptions. There's a lot of using models as random generators as a way to validate assumptions that demonstrates that your model makes sense before you start with inferencing which is a fantastic habit to stick with.
Doing my web stuff in Rust was fine but concurrency was a pain. A crate that abstracts web workers with transferrable types would help. After that you have to pick a component library of which there are few, and all are experimental. Making pretty, performant things is hard. Switching compontent libraries isn't easy. The backend stuff is a breeze, I think Rust is doing fine there.
I'm switching to Flutter for my UX needs. There's flutter-rust-bridge that binds Rust code concurrently without any headaches in the client, and I can deploy to the web, android, Linux, etc. with ease. Looks p. good out of the box. Got GRPC working quickly, am happy.
Using Rust in the client is nice because I have a single workspace that contains all of my business logic. Backend changes will cause errors in the client code if changes are necessary. The codebase is easy to refactor and trust. Dart ain't half bad.
I stayed away from Flutter at first because it doesn't respect the DOM etc but at this point I'm willing to sell my soul to the devil for how easy it is to make a great UX that deploys anywhere.
I don't love relying on something Google made, though. Feels a little like building a foundation on sand.
Laziness with a long view: I probably won't have to rewrite it, and if I do, it will be easy. I can write code like that in Python or something, but I have to be on my best behavior to do so and that's not lazy.
Using notepad for code is just masochistism though
I never got around to grinding enough karma points on there so that the platform will let me actually engage with it. Since I can't post answers or even vote on things, there's not a lot of reason for me to bother logging in. As a result I just mooch off what I find and leave.
I can't be the only one. Their walled garden kept me out.
I have been a daily logseq user for at least a couple years now, and I have not had a problem with my data being lost. I have heard of people having this issue with Synching - which I am also using - but I haven't had issues.
I like how the data storage is markdown files. I love the block centered outlier approach and use block references extensively.
I've developed some extensions too. The documentation is severely lacking here, but there are enough extensions on the (currently free and oss) marketplace that can be useful examples.
The query language is really freaking weird to me. It's clojure, datascript/datom. Not intuitive at all, but I've got several custom queries working as part of my workflow.
Overall Logseq is good software and I'd recommend it. Certainly take backups - I have from the start because of experiences like the above - but I haven't needed them yet.
One gotcha that would bug me with Rust/WASM today is concurrency in the browser. You only get one thread per WASM binary AFAIK, and the way to compute in the background is to use a web worker.
The abstraction libraries that are higher level than web_sys don't support transferable objects currently, so you'd have to write your web worker in web_sys directly to avoid needless data copying. It's pretty doable, and I've gotten started on a crate abstracting this part, but it's been a serious willpower blocker for me.
One thread is pretty limiting for any web app today. As soon as you want to do something interesting, you're blocking the main thread.
> Any application with a high shared buffers hit ratio: little difference.
> Any application with a high ratio of reads/writes: little difference.
> Data logging application with a low ratio of reads/inserts, and few updates and deletes:
little difference.
> Application with an equal ratio of reads/inserts, or many updates or deletes, and a low
shared buffers hit ratio (for example, an ETL workload), especially where the rows are
scattered among disk pages: expect double or greater CPU and disk I/O use.
> Run pg_dump on a database where all rows have already been previously selected by
applications: little difference.
> Run pg_dump on a database with large quantities of rows inserted to insert-only tables:
expect roughly double CPU and disk I/O use.
I've been using trunk for about a year and it hasn't gotten in my way at all. I used wasm-pack before but I prefer the trunk workflow. I was surprised how easy it was to add an external crate as a web worker.
I imagine a lot of people who work on space missions do not outlive their work - which feels sad but also ... inspiring?