adwn

You just listed examples of unbounded lifetimes.

You're just splitting hairs and trying to weasel around the fact that yes, you really can create any lifetime you want using unsafe.

Not sure what you meant by this example since it doesn't compile.

That's because the crappy HN formatting ate some of the characters. Here's the original version:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

What you probably meant is […]

If you know what I meant, then what's up with your snarky comment about "So much for effectively disabling stuff"? In your playground link, you did effectively disable the borrow checker in safe parts of the code. Next thing you're moving the goalpost, now it's not about external, static analysis tools: "run this with UBSAN, ASAN, and other C tools". I don't think you're arguing in good faith here. Goodbye.

Please try to interpret comments in the context of the discussion, not floating freely in a vacuum. The context of the discussion is the Bun port's excessive use of unreviewed unsafe blocks. unsafe in Rust can easily be misused to create Undefined Behavior, which renders any safety guarantees otherwise ensured by Rust's borrow checker invalid.

Does bun actually do anything insane like that in its unsafe blocks?

Who knows? At 10k unreviewed uses of unsafe, I'd guess there are quite a few incorrect ones. LLMs don't produce perfect code (neither do humans), so there's a high probability that at least some of those create UB.

The only thing unsafe does is let you have an unbounded lifetime.

No, you're wrong: You can create any lifetime. Proof:

    fn oof<'desired>(x: &u32) -> &'desired u32 {
        let ptr = x as *const u32;
        unsafe { &*ptr }
    }

You don't disable anything.

I said "effectively disable". For example:

fn trust_me_bro<'a>(x: mut u32) -> &'a mut u32 { unsafe { &mut x } }

    fn main() {
        let mut x = 1_u32;
        let reference_a = &mut x;
        let reference_b = trust_me_bro(reference_a);
        *reference_b = 2;  -- Whoops
        println!("reference_a: {reference_a}  reference_b: {reference_b}");
    }

"Fun fact", it lets you largely circumvent the borrow checker by creating arbitrary lifetimes: https://news.ycombinator.com/item?id=48974824

True, but unsafe let's you conjure up any lifetime you want, or any lifetime necessary to satisfy the lifetime requirements in safe code. If you generously sprinkle pointer dereferences in unsafe code, you effectively disable the protection provided by the borrow checker – including in safe code – until you've checked and verified the correctness of all unsafe blocks.

Let me guess: you know that it's literally true because everyone repeats it, right?

People repeat that figure of speech because it's a meme (in the original sense of the word), not because it's unconditionally true.

Those systems you're alluding to received ungodly amounts of work and resources, vastly more than most projects can ever hope for, and yet they're still full of holes and security exploits. You're unwittingly making a great argument against using C, C++ – or Zig.

Are you sure about "rms types" specifically? Stallman is very ineffective in his proselytization, owing to his complete refusal of any kind of compromise or concession to dissenting positions. This stance may keep your soul pure and righteous, but it won't bring you one millimeter closer to your objectives.

The human brain hasn't solved NP-hardness, either. We make it work using heuristics and automation tools, which in turn use heuristics themselves. I see no reason why AI wouldn't be able to take the same approach.

Solving the halting problem is neither necessary nor sufficient to prevent DoS attacks.

It isn't necessary, because settings timeouts or other resource restrictions works way better to prevent DoS.

It isn't sufficient, because even if you can prove that a program will halt at some point, this alone doesn't tell you how long it will take. What good does it do to know that the program will run for 10 years before it halts? By that time, service will already have been denied. Even turning hash table lookups from O(1) to O(n) (still very much terminating!) can result in a DoS.

Hardware isn’t where the margins are

Baseless speculation

probably is somewhat of a loss leader for small-batch users

Wrong. AMD/Xilinx doesn't sell devices directly to customers, they sell them to distributors in huge quantities. Those distributors then sell them to "small-batch users", and they're not involved with AMD/Xilinx free-tier software at all.

they’re running at around -10% profit on small sales to try and drive subscription revenue multipliers

More baseless speculation

[…] that violates universal causality

I think you're conflating qualia with free will. These are very different concepts, and the experience of qualia has nothing at all to do with "violating causality".

So there should be no reason we cannot reduce these phenomena to actual quantifiable and there for Computable elements.

As long as we have practically no idea how qualia arise, or even what exactly they are, your claim has no base to stand on.

No, there is at least one other option, which is that consciousness [1] is a phenomenon that we can't replicate in non-biological brains [2], but from which the existence of a "God"-like being, as the term is understood by major religions, still doesn't follow.

[1] Or "qualia", to be precise.

[2] For example, the existence of qualia might require certain carbon-based structures which aren't present in silicon-based devices.

I thought we were way past the "bigger brain means more intelligence" stage of neuroscience?

And yet another "AI doesn't work" comment without any meaningful information. What were your exact prompts? What was the output?

This is like a user of conventional software complaining that "it crashes", without a single bit of detail, like what they did before the crash, if there was any error message, whether the program froze or completely disappeared, etc.

We could probably slash gas prices by banning oil exports, thus removing domestic oil supply from global market pricing (barring smuggling).

To my understanding, you couldn't do this, no. The US is a net oil exporter, but many of its refineries are tuned for processing oil with a chemical composition that isn't found in the US, or not found in sufficient quantity. So the US has to both import and export oil, it can't just replace imports with exports.

ironically because he thought it would avoid making him look weak and incompetent

Trump is what a weak man imagines a strong man to be like. Just look at his official portrait [1], trying to look tough and dangerous. Compare that to Dwight D. Eisenhower's portrait [2], a man who commanded entire armies in the largest war in human history.

[1] https://en.wikipedia.org/wiki/Donald_Trump#/media/File:Offic...

[2] https://en.wikipedia.org/wiki/Dwight_D._Eisenhower#/media/Fi...

Oil is a globally priced commodity. This means that downstream consumers of oil in the US will be just as affected by rising prices as European consumers. US producers of oil will benefit, though.

it forced US to spend huge amounts of money and military hardware which the EU simply didn't have

- Europe's monetary aid for Ukraine far outweighs that of the US.

- The US military aid for Ukraine mostly consisted of old and obsolete hardware.

- Since about a year or so, all weapons and munitions delivered by the US are paid for by Europe.

Since WWII […]

Europe didn't slack off militarily during the Cold War. Germany, for example, poured massive amounts of money and resources into the Bundeswehr to be able to fend of the Soviets. The US relied as much on the European members of NATO as the Europeans did on the US.

After the Cold War, both the US and Europe scaled back their military spending and enjoyed the peace dividend. It was only after 2001 that the US increased its budget again – but to fight insurrectionist wars (which EU members aren't particularly interested in), not in a peer conflict. They're not prepared for a pro-longed war against a near-peer power.

So although I agree that Europe should be rearming heavily, and should have started in 2022 at the very latest, it's not like the US did really much better. They're really good at curb-stomping much weaker opponents, like Venezuela or Iran, but they haven't seriously prepared for a war against China.

So why is the argument "write more code"?

It isn't, that's what you injected. The argument was "write [the same amount of] code faster". And that is undoubtedly a good thing, because execution speed can make or break your startup.

But for startups, side-hustles, VC-pitches and the inner-workings of companies and so on (HN crowd) coding was never the problem.

I'd say you're 180° wrong. Getting to an MVP fast is the most immediate problem when you've started a startup. Iterating on ideas fast is the most immediate problem once you've released your MVP. You need an MVP to get users, and you need to to iterate to find product-market fit. Perfectly crafted code is a luxury problem you can't afford in the early stages.

Tell them to use the Composer 1.5 model. It's really good, better than Sonnet, and has much higher usage limits. I use it for almost all of my daily work, don't have to worry about hitting the limit of my 60$ plan, and only occasionally switch to Opus 4.6 for planning a particularly complex task.

Thanks for the correction. I wasn't aware of this, but it makes sense now that you mention it.

"Expensive and painful body modifications"? Like, what, earrings? What a sacrifice.

One could argue that LLMs learning programming languages made for humans (i.e. most of them) is using the wrong interface as well.

Then go ahead and make an argument. "Why not do X?" is not an argument, it's a suggestion.

If I want to know the status of each item, I’d pass -v to the command.

I don't disagree. In my opinion, the default log level for CLI applications should be WARN, showing errors and warnings. -q should turn this OFF (alternatively, -q for ERROR, and -qq for OFF), -v means INFO, -vv DEBUG, -vvv TRACE. For servers and daemons, the default should probably be INFO, but that's debatable.

"Finished conversion of xyz.mp3 to xyz.ogg" is valuable progress information to a regular user, not just to developers, so it belongs in INFO, not DEBUG.

Those are the "sources" you chose to prove your claim? Is this supposed to be a parody?