441–450 of 465 posts
This seems like the type of thing that LLMs would be great at, since you already have a fully specified application (all requirements and details worked out). Has anyone attempted something like this?
I did the same thing with one of my projects. I built a simple webcam viewer that is optimized for USB microscopes as I couldn't find anything out there for this purpose. Basically all of the functionality was implemented in the renderer. As I was planning for App Store submission, I realized that a 500mb webcam viewer might not be the best thing. I decided to port it to Tauri V2 and got it down to about 15mb.
Out of interest, how did you stream the video data to the frontend?
https://developer.mozilla.org/en-US/docs/Web/API/MediaStream
I recently built an Electron app ( http://dyad.sh/ ) and I looked at other options like Tauri, but Electron has such a mature ecosystem (e.g. https://www.electronforge.io/ ) that I was able to ship a cross-platform app in a couple weeks (Mac+Windows) and then adding Linux support was pretty trivial. The only downside from my point of view is the large installer size for Electron apps, but it hasn't been a big issue f…
Earlier quoted context omitted.
Possibly but not guaranteed. For desktop apps UI quality and rendering speed is paramount. There's a lot of stuff buried inside Chrome that makes graphics fast, for example, deep integration with every operating systems compositing engine, hardware accelerated video playback that is integrated with the rendering engine, optimized font rendering... a lot of stuff. If your Rust UI library is as advanced and well optimi…
Having worked on a graphical application in rust for a (albeit not a complex one) computers today are fast.. latencies top out at 3 ms with cpu based rendering in an application with just a few rendering optimizations. The fact that you just draw on the screen instead of doing whatever html parsing / DOM/IR is probably doing it? And doing rendering on the gpu means extra delay in the processing moving from cpu to gpu…
It's sad to witness how much suffering developers are ready to endure (and make their users suffer) just not to part ways with HTML/CSS/JS stack. The stack that was never designed properly, let alone for modern UI apps. Flutter would be much better choice for such a desktop app, for example.
you still can't have multiple windows with flutter, which disqualifies it for building desktop apps.
It's sad to witness how much suffering developers are ready to endure (and make their users suffer) just not to part ways with HTML/CSS/JS stack. The stack that was never designed properly, let alone for modern UI apps. Flutter would be much better choice for such a desktop app, for example.
wxWidgets or QtWidgets if you want a proper desktop GUI app.
There were also some subtle issues like the child windows leaking a lot of memory in the GTK implementations when idle (something like spamming gobjects).
I wouldn't touch Qt even with a ten foot pole, too much bloated for me.
Earlier quoted context omitted.
> Can an LLM help me identify the source of this bug? No. Can I say "fix it"? No. In the past I said "Write a test-case for this CP/M BDOS function, in the same style as the existing tests" These are all things I've done successfully with ChatGPT o1 and o3 in a 7.5kloc Rust codebase. I find the key is to include all information which may be necessary to solve the problem in the prompt. That simple.
7.5 kloc is pretty tiny, sounds like you may be able to get the entire thing into the context.
Honest curiosity — why did you choose a service like Redis over a more straightforward embedded solution like SQLite? In my head Redis seems better suited to distributed solutions but I've never actually built a desktop application so I'm probably speaking from ignorance.
Beware the greenfield effect. I don’t want to comment on the technology choices specifically here, but in general the whole “we rewrote our app in X and now it’s better” is essentially a fact of life no matter the tech choices, at least for the first big rewrite. First, you’re going to make better technical choices overall. You know much better where the problems lie. Second, you’re rarely going to want to port over…
Microsoft rewriting typescript tools in Go and getting a 10x speedup? It's wild that they would choose Go for that. And a surprising level of speedup. https://devblogs.microsoft.com/typescript/typescript-native-...
https://github.com/microsoft/typescript-go/discussions/categ...
Hejlsberg also says in this video, about 3.3x performance is from going native and the other 2-3x is by using multithreading. https://www.youtube.com/watch?v=pNlq-EVld70&t=51s
Earlier quoted context omitted.
There are two specific places where Python is not performant. I ran some tests in a few languages and Rust and C++ came out on top, by far. I could write Rust components and access them via Python. I could also use C++ and stick with Qt. Or I could take the plunge with Rust. As this is a personal app with no other users, this is a good place to keep sharpening my skills.
Then I’d say just pick the one you are most familiar with