> most folks who might be interested in writing desktop apps with Rust probably aren’t coming from a web background, but instead from old school desktop UI frameworks

You'd be surprised. A lot of people migrating to desktop apps are people coming from a web background (this is after all by far the largest pool of UI developers) who want something more efficient than electron.

“More efficient” is relative. While tauri and dioxus can lower the install size, they’re not going to be meaningfully more efficient than electron for memory usage or speed since Chrome probably does better than the other frameworks, and consistently across OSes which dioxus and tauri struggle with since they are dependent on the host OS’s web implementation. Slint is interesting here but then it’s more rust and less web coding.

Oh, "more efficient" here isn't a refence to Tauri. It's a reference to the parent comment's mention of "(AppKit, win32, GTK, Qt, etc)".

I work on a framework (Dioxus Native) which I think sits at an interesting intersection of "rust" and "web": it renders using HTML/CSS (custom implementation, not using a webview) but it uses Rust scripting instead of JavaScript.

What's "rust scripting"? I don't see any mention of it in the docs nor dioxus native roadmap and AFAIK https://github.com/DioxusLabs/dioxus/tree/main/packages/inte... is used as the interpreter although I can't for the life of me figure out where the JS engine is actually instantiated.

Servo uses Taffy for CSS Grid. It could also very easily use it for Flexbox, but they currently prefer to use their own implementation there.

It was originally a derivative of React Native's Yoga implementation of Flexbox, and is currently developed primarily as part of the Blitz engine.

I believe that is wrapping the Wry crate (and a few other crates) in a C API that can be accessed over FFI (which can then presumably be called directly be Swift code).

Thanks for helping me understand! So to clarify, that file is wrapping Wry with a C API, and Wry itself is merely wrapping whatever webview is available on the OS?

> So to clarify, that file is wrapping Wry with a C API, and Wry itself is merely wrapping whatever webview is available on the OS?

Yep, that sounds about right to me. Although it looks like that file is also wrapping Tao (which is a cross-platform windowing/event loop library).

Yeah, but starting with a codebase that is (at least approaching) production quality and then mangling it into something that's very far from production quality... isn't very impressive.

> Holy hell HN, downvoted to -4 in record time. Y'all don't like what's happening, but it's really happening. > > I'm not lying about this. > > I provided my background so you'd understand the context of my claims. I have a solid background in tech.

There are lots of people claiming this. Many of whom have a solid background. Every now and then I check out someone's claim (checking the code they've generated). I've yet to find an AI-generated codebase that passed that check so far.

Perhaps yours is the one that does, but as we can't see the code for ourselves, there's no way for us to really know. And it's hard to take your word for it when there are so many people falsely making the same claims.

I expect a lot of HNers have had this experience.

Have you looked at antirez's code?

https://github.com/antirez/flux2.c

Generating code from scratch and modifying existing code are two different things, obviously the latter being where AI doesn't do great. Carefully managing and compressing context can somewhat help, but that is far from being a perfect solution.

But you can iterate over the code until you like it. If you don't review the code, you risk slop. But reviewing takes time, and most people don't do that in the prototyping stage, because the code might still significantly change. But as your project matures you become more critical of the code and you review it more closely. And over time you also get more feeling of how to work with the AI to get the results you want.

Something I've noticed is that AI code generation makes it easier/faster to generate code while shifting more work of the work of keeping code correct and maintainable to the code review stage. That can be highly problematic for open source projects that are typically already bottlenecked by maintainer review bandwidth.

It can be mitigated by PR submitters doing a review and edit pass prior to submitting a PR. But a lot of submitters don't currently do this, and in my experience the average quality of PRs generated by AI is definitely significantly lower than those not generated by AI.

I was expecting this to be the point of the article when I saw the title. Popular projects appear to be drowning in PRs that are almost certainly AI generated. OpencodeCli has 1200 open at the moment[1]. Aider, which is sort of abandoned has 200 [2]. AFAIK, both projects are mostly one maintainer.

[1] https://github.com/anomalyco/opencode/pulls [2] https://github.com/Aider-AI/aider/pulls

Even not-so popular niche projects are getting LLM spam. Curiously, at least where Ia m active most comes from account with India-related usernames.

Some are opening PRs, some are posting comments in issues that repeat what was said already, just in more words.

To me, an old guy, I would rather have LLM doing (assisting with) the code review than the actual code production. Is that stupid?

LLMs are great at reviewing. This is not stupid at all if it's what you want; you can still derive benefit from LLMs this way. I like to have them review at the design level where I write a spec document, and the LLM reviews and advises. I don't like having the LLM actually write the document, even though they are capable of it. I do like them writing the code, but I totally get it; it's no different than me and the spec documents.

Right, I'd say this is the best value I've gotten out of it so far: I'm planning to build this thing in this way, does that seem like a good idea to you? Sometimes I get good feedback that something else would be better.

If LLMs are great at reviewing, why do they produce the quality of code they produce?

Reviewing is the easier task: it only has to point me in the right direction. It's also easy to ignore incorrect review suggestions.

Imho it's because you worked before asking the LLM for input, thus you already have information and an opinion about what the code should look like. You can recognize good suggestions and quickly discard bad ones.

It's like reading, for better learning and understanding, it is advised that you think and question the text before reading it, and then again after just skimming it.

Whereas if you ask first for the answer, you are less prepared for the topic, is harder to form a different opinion.

It's my perception.

Its also because they are only as good as they are with their given skills. If you tell them "code <advandced project> and make no x and y mistakes" they will still make those mistakes. But if you say "perform a code review and look specifically for x and y", then it may have some notion of what to do. That's my experience with using it for both writing and reviewing the same code in different passes.

This makes sense to me.

I need to make decisions about how things are implemented. Even if it can pick “a way” that’s not necessarily going to be a coherent design that I want.

In contrast for review I already made the choices and now it’s just providing feedback. More information I can choose to follow or ignore.

Take a look at CodeRabbit and Sourcery if you want to give that a go.

No, because proper QA/QC will be the bottleneck.... AI is ill-suited to test for fit/use. I built an ANSi terminal with AI assist (rust/wasm/canvas)... it literally took longer to get the scrollback feature working with keyboard and mousewheel interactions than it took to get the basic rendering correct. And there are still a few bugs in it.

In the end, you should not just skip QA/QC and fitness testing. Many things can fit a technical spec and still be absolutely horrible. With AI assisted developmnet, imo it's that much more important to get the UX right. I don't want 10x the apps if they're all half-implemented garbage that look like garbage are hard to use and just painful to install, maintain and use.

Library creation still has a place here... and so far, getting AI code assistants to actually understand and use a given library that may be less popular has been at the very least, interresting.

Do you have anecdotes or evidence of this or is it speculative?

Those are the most mentally exhausting task. Are you sure putting this burden on single person is good?

Yeah, it should change things but also free up other energies to work on things

Not sure if you're being sarcastic or not?

> So much that having other engineers learn the codebase is probably not worth it anymore.

> Large scale software systems can be maintained by one or two folks now.

No, LLMs are not so powerful yet.

90CRI isn't good enough to replicate an incandescent bulb in my experience. Something in the high 90's can be much better (but admittedly hard to find). And of course you may want to match your preferred color temperature too.

Actually, this is the best I was able to find. The prices increase almost exponentially when you try to go to higher end of anything, and I was not in a mood for digging whole city and the internet for a single bulb. A Philips' 90CRI bulb is already a great upgrade from an 80CRI bulb, so I ran with what I was able to find in a pragmatic time frame.

There are passports and driving licenses which are the de facto forms of ID in the UK (there are technically other valid forms of ID for at least some purposes, but almost nobody uses them). ~85% of UK residents have a passport.

Yes, but luckily the people who don’t fly or drive can now show their jerking-off loicense while buying alcohol at whole foods.

https://www.waveformlighting.com/ sell 99 CRI LEDs. They're in strip form not bulb form, and they're definitely expensive, but they are available.

It's usually the Color Rendering Index (the spectrum of frequencies that the light puts out). Incandescent bulbs more of less mimic that of the Sun, they are "black body radiators". Cheap LEDs tend to be missing a lot of the red spectrum.

However, you can get LEDs that do this well. Look for one with a "CRI" of 95% or higher.

The CRI is an imperfect metric, I watch for both CRI and R9, both should be high.

There's a massive difference between the 2600K of regular incandescent bulbs, and the 6000K of sunlight. That's why hollywood used HMIs until they migrated to LED.

There is, but most humans are used to the spectral pattern of black body radiators at all color temperatures. Be that sunlight at higher temperatues or fires / candlelight at lower temperatures.

Regular exposure to fire/candlelight has only existed for a hundredthousand years, while mitochondria have existed almost unchanged for millions of years.

So even that assumption would require further study.

For professional applications there are sulfur plasma lamps which have a continuous spectrum at high efficiency. Unfortunately they aren't economical below about 1000 watts which is impractical for many applications.

The technology basically works by continuously microwaving (think oven) a small amount of sulfur gas. The development of solid-state microwave emitters — most microwave generation is still done with vacuum tubes — might help miniaturize the devices. However, it's hard to beat the simplicity of an LED.

wow - had no idea these things existed, fascinating.