I've been programming in Rust for 5 years and I could barely understand the code in their repo. Not because it was somehow advanced but because it didn't make any sense. It felt like that with every decision they could make, they always chose the hardest way.

On the other hand, I have never done any C++ (besides few tutorials) in my life and yet I found both Serenity/Ladybird and also WebKit to be very readable and understandable.

BTW: If anyone wants to reply that Rust is different then yes, of course it is - but that's the point, if there is a language that maps nicely to your problem domain, it's also very fast, and well-understood then why the hell you'd use a language that is well-known to NOT map to OOP?

And it makes a lot of sense, the pre-training is not perfect, it's just the best of what we can do today and the actual meaning leaks through different tokens. Then, QKV lets you rebuild the meaning from user-provided tokens, so if you know which words to use, you can totally change the behavior of your so-far benign LLM.

There was also paper about sleeper agents and I am by no way a doomer but the LLM security is greatly underestimated, and the prompt injection (which is impossible to solve with current generation of LLMs) is just the tip of the iceberg. I am really scared of what hackers will be able to do tomorrow and that we are handing them our keys willingly.

But from (let's say) El Capitan, I am always postponing upgrades, and recently I've been only upgrading by buying a new machine every 2 ys (except this year, I had to upgrade because of Metal, but I'm still one version below, still scared to upgrade to Tahoe). Every new feature they add to their OS I'm just disabling, every time I upgrade. Either I am not their customer anymore, or they are more and more clueless.

And it's not that hard, I just want it to work so that I can focus on my own stuff.

Sadly, accidental complexity is a common theme among react devs, not just ui libs, but also react-router, redux, redux-form, even tanstack useQuery() is way over-engineered and the core idea can be implemented in <50 lines and then you own the code and can make project-specific changes.

Maybe that's the biggest issue after all, people being lazy, expecting to do npm install and being able to reuse everything in any situation. Except that it almost never work like that and a lot of damage is done in the name of it...

There are also some bugs, and I don't intend to support, nor develop this much further, consider it vaporware which you are free to fork and use it for something, or just have some fun reading the code and figuring out how it works (I certainly had a lot of fun implementing it - no LLMs, so it was a nice exercise too).

BTW: I know it's probably very inefficient, and I don't care - it goes through 67 files in 0.19s and I don't expect it to be ever a bottleneck for this use-case, so I've spent exactly 0 minutes trying to optimize it.

Comments URL: https://news.ycombinator.com/item?id=46660964

Points: 10

# Comments: 0

For example, here's comptime dependency-injection container, which notably, can be configured and extended, completely in comptime, and the final glue is something which in theory the compiler could optimize away too (no idea if it does). https://github.com/cztomsik/tokamak/blob/main/src/container....

And regarding what they discuss in article, I did something similar for N-API, note how much you can do in few hundred lines, and I'd say that you can use it for most of what people do with napi-rs except that napi-rs is huge (and also unsafe, because it allows indirect recursion, which allows breaking all the rustc promises) https://github.com/cztomsik/napigen/blob/main/src/napigen.zi...

Comments URL: https://news.ycombinator.com/item?id=45407468

Points: 3

# Comments: 0

And it might be also something with GC, because I suppose the big boys are doing some GRPO over synthetically generated/altered source code (I would!) but obviously doing that in C++ is much more challenging - and I'd expect Rust to be straight impossible.