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.
> 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.
Great UX, you say? Great UX!? Flutter’s unashamed pure-canvas approach makes it fundamentally and unfixably awful. Links don’t work because they’re fake (and it’s impossible to fake them), scrolling is atrocious for a significant fraction of users, text handling is obnoxious and wrong… seriously, speaking as a user, I’ve come across things made with Flutter three times in the last four years (plus looking at their demos), and Flutter makes for literally the worst user experience that I have come across in that time.
Now Flutter does actually have a DOM renderer, but it never seems to be used. I’m not entirely sure why. Actually, scratch that, I just went to find a link, and found https://docs.flutter.dev/platform-integration/web/renderers only talking about canvaskit and skwasm, no mention of the html renderer any more… it seems like they deprecated it earlier this year <https://github.com/flutter/flutter/issues/145954>, and will presumably remove it some time soon, doubling down on pure-canvas. Well, at least that lets me more unconditionally condemn Flutter for the web.
Text is bad, especially if you use emoji. Links are bad because they’re fake. Scrolling is bad for a decent fraction of users. And none of these three are fixable if you insist on pure-canvas. (Links you could kinda make work tolerably if you were willing to compromise a little, but the other two just can’t be done.)
If you want more substance to my complaints about the pure-canvas approach, search HN comments for “chrismorgan canvas” or similar. I still haven’t finished reducing it to an article on my website.
If you intend to target the web and care about the web at all, please don’t use Flutter.
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 stumbled on an obscure question years ago on one of the sub exchange sites that dovetailed precisely with something I'd been working on for years. All the proposed answers were subpar so it was like I was born for this particular question. After cracking my knuckles and preparing to reply I realized I couldn't. I didn't have enough karma or whatever. And that was the end of that.
Same for me. I have an account with zero karma on it. When I created it I was a total programming novice fresh out of uni and could not really contribute. As time went on, I could definitely have started contributing, but not having any karma became too high a barrier of entry - I'm using it during my work hours, I can't just spend endless time grinding.
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.
On my M1 mac "dd ... | cksum" takes 3 seconds while "dd | shasum" (sha1) takes 2 seconds. So cksum might not be the best tool for performance checking.
There is CPU specific code in the PG source in src/include/storage/checksum_impl.h
It is written as a plain nested loop in C. So performance is fully dependent on the compiler being able to parallelize or vectorize the code.
I would not be surprised if manually written SIMD code would be faster.
The bottleneck isn't at all the checksum computation itself. It's that to keep checksums valid we need to protect against the potential of torn pages even in cases where it doesn't matter without checksums (i.e. were just individual bits are flipped). That in turn means we need to WAL log changes we don't need to without checksums - which can be painful.
That's measuring 'cksum', which must have an awfully slow implementation. The document notes that this is distinct from measuring PG's checksum performance. (I think it's a pretty useless measurement.)
Earlier (page 4):
> How much CPU time does it take to checksum...
> ...a specific amount of data? This is easy to estimate because PostgreSQL uses the crc32 algorithm which is very simple, and (GNU) Linux has a command line program that does the same thing: cksum.
Yeah, using cksum as an estimate here appears to be very flawed.
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'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.
reply