If you like the idea and work in robotics try out copper-rs, it works on the same underpinning concept but at compile time in rust + a graph description.
The latest addition to the kernel is a profile guided scheduling feature that allows you to optimize the concurrency of the graph still at compile time based on previous timing measurements from its deterministic logs.
It looks good reading it like this but I am always scared about the unintended effects. Like the ... cookie banners. Dynamic pricing absolutely has to go this is so unethical
The cookie banners are not required to be this way. They are deliberately designed to be as annoying as they can legally be (many actually moreso), in part to influence your perspective against GDPR.
The big problem with cookie banners is that they are quite often just outright in violation of the law, and just getting away with it.
I was really hoping for the EU to be more strict in enforcement. Guess they don't feel so strong in trade negotiations right now.
Here in the US, there is also the problem that people are way too overcome with FOMO about the dumbest stuff. I knew someone who would hit "Accept all" instantly for every dialog, and then I helped her with something and clicked the (mostly required and reliable) "Reject all" button instead, and when the site just loaded up and worked after that, she was shocked and said "I didn't know you could do that"
I don't know how to respond to that! The dialog openly tells you every single time that only the "Necessary" cookies are required and you can't turn those off, and every other option can be turned off.
People just don't read! Ever! At all! Their life could depend on it and they would panic instead of just reading one damn sentence in a dialog box and at this point I no longer accept "The industry trained them this way" as an excuse since this affects multiple generations who had dramatically different computing experiences.
In the modern day, every single American can usually access information about anything they want. They can try to answer any question they have. They can try and clear up anything confusing to them. They can form educated opinions!
Same thing happened with the release of a certain programming language release a few weeks ago (that seemed fully vibecoded, which is fine - but was making multiple grandiose claims which attracted pushback). Multiple sock puppet accounts defending the poster religiously with attitude that is more reserved for reddit than HN.
It happens more around things related to vibecoding, it seems that influencer culture, empowered by this new tooling is starting to distort tech communities.
More and more of this will be happening. Before AI coding - the fact that something like photopea or pixelr existed, meant that somebody had to commit years of focused work to even reach to the same level of quality before starting to provide value and attract users. That alone made copying a losing proposition, or at least it raised the bar as it meant one had to be a truly exceptional and dedicated builder.
Nowadays it can happen in an evening, so everything successful will get copied and attacked and attempted to be displaced by noise and hype on certain internet circles alone. Like the cheap ridiculous clones of popular ios games and apps of the past, except now on an industrial scale!
I guess this is the new world we are entering, but can we at least keep the astroturfing and bad faith behavior away damnit?
What warrants an off the cuff comment like this?
I can take any piece of software and just say a vague statement like that. All of software... What does it even bring to the conversation? Just vague "they"s again we keep on propping up? Who is unethical? The mold team? The AI? The rust foundation? The ASCII character set? The cloud system it has been compiled on? Oh no obviously the backdoors in there?! Oh let us guess!!
2. Most of those are obviously LLM-induced, unless there's a new breed of human trained on just the failures of LLMs and not the successes or other relevant information
3. I therefore assume that the rest of the project is an unverified LLM psychosis without meaningful human review
That's not the worst thing in the world for all software maybe. I recently found out my apartment complex in their latest AI rewrite generates SMS OTP based purely on the timestamp and ignores passwords, so I can log in as anyone else by knowing their email and having a valid email to grab the current OTP. That's a major security failing, but how bad is it really? I can grab the last-4 of their credit card numbers, pay their rent, see how much other tenants are being screwed, and so on, and only if I know their email addresses (solvable with a tiny bit of social engineering, but let's assume that's also moderately hard). How bad is that really? On the one hand, it's terrifying, since I presume they have the same level of attention to detail with respect to payment methods and PII despite my having opted out of having them stored, but (a) that's all already been exposed via dozens of breaches and is being handled behind the scenes by my bank anyway, and (b) if we examine the immediate blast radius of the known bugs then there's approximately fuck-all an attacker can do with that information.
For a multi-threaded linker? Come the fuck on. I don't care if it's written in Rust. If you ignore all of the memory ordering intrinsics and `unsafe` then maybe it's more okay, but not having easily available UAF and other memory bugs is very different from actually implementing the correct behaviour, and for a linker where you're explicitly joining together multiple independent binary blobs and choosing what and how to execute on a machine instruction level, Rust's guarantees 100% don't save you from broken, unvalidated "business logic."
The bun to rust rewrite broke tls authentication and failed open... that alone puts it in the "massive failure" category.
If a breaking bug of that magnitude does not register to you as "huge failure" then you and I have such different views on software quality that theres no possibility of a conversation.
(a) That's mostly irrelevant to my point. This project has major issues with an LLM signature in a safety-critical context. If we assume that the bun rust rewrite went off without a hitch and that doing so is repeatable then it's worth trying to understand what the difference was.
(b) I'm not sure those assumptions hold. Bug reports spiked 2-3x when the rust version was introduced. HMR broke. There were utf-16 parsing panics. The result was slower out of the box and needed a lot of hand-tuning. There were FFI regressions. The rust rewrite had its own concurrency bugs despite rust's "fearless concurrency." In a JS runtime where the rest of the ecosystem is already usually broken, especially since the bugs seemingly weren't safety-related, maybe that's fine, but it wasn't exactly a "no major issues" rewrite.
phrasing is a classic AI hallmark, doubling down on nonsense via the shortest path which is plausibly maybe correct sometimes. In the context of a broken AI rewrite, that felt a bit like an intentional piece of humour, enough to warrant asking.
Beyond that, in the context of a linker, userspace logic matters much more than generic "memory safety" or whatever. The core algorithm is dynamically choosing which bytes to load and execute, and being off by a byte as a userspace bug is a major safety failing, regardless of whether it's "memory safe" or has "fearless concurrency" or other such bullshit. I'm not aware of any study, or even any good anecdotes, suggesting that Rust is better on average from a userspace logic pespective than even Python of all things. In the context of a linker, I somewhat doubt that there's any evidence of Rust having "lower rates of exploitable vulnerabilities than C or C++ code." It might be better, but I doubt that evidence exists yet.
Lol. You've got AI paranoia dude. It's pretty obvious that Rust is more reliable than C++ in many ways, and trying to blame such an absolutely obvious statement on "AI" just because you disagree with facts to try to discredit this statement just makes you look silly.
> In the context of a linker, I somewhat doubt that there's any evidence of Rust having "lower rates of exploitable vulnerabilities than C or C++ code."
That it's a linker does mean exploits would be a bit more special case than if it was say a web server yes. But the number of exploitable issues is still going to be way higher, even if the real world severity is low.
It is probably very domain specific. In robotics for example everything is a zero sum game: CPU, memory bandwidth, GPU, battery life etc ... So it is really a topic, probably true for anything embedded actually. Some other offline applications: HFT, Telco etc..
I wish the GUI apps devs respect more the laptop resources they are running on, don't get me started on the 4 instances of chrome I need to run just for discord, signal etc ...
GUI engine developers need to trade EVERYTHING for execution time, otherwise JavaScript would simply not be fast enough to handle modern applications.
If your device has enough resources to power V8, modern GUIs are certainly very pleasant and snappier than a more minimal GUI like HN. Otherwise they are horrendous and very laggy.
I don't know if you got my point. Starting a multi gigabyte machinery for the web just for a chatting app is pure insanity sorry. It will be slow to start, slow to react and a battery hog vs a comparable quality QT app. The worse part is usually people use the web stack for desktop app because they don't want to bother giving a good experience to the people on their own native platform.
True, I wrote my own chat app in Qt, and it is substantially faster and more efficient (lower battery usage) than anything made with web technologies.[1]
I do wish more things were written in Qt, but Qt Widgets is very unpleasant to work in for a modern dynamic app.
QtQuick/QML/JS is very pleasant and I do wish more people would use it, but from I've seen it's 25-50% the resource use of electron, not some multi-order-of-maginute improvement, do I understand why many people still prefer electron for portability in this case.
