Nonsense, if we view proving as providing evidence for, then absolutely we can prove a negative. We have our priors, we accumulate evidence, we generate a posterior. At some point we are sufficiently convinced. Don't get hung up on the narrow mathematical definition of prove (c.f. the exception[al case] that proves [tests] the rule), and we're just dandy.
I like to think that what the “can’t prove a negative” phrase originated from was someone grasping at the difference between Pi_1 and Sigma_1 statements . For a Pi_1 statement, one needs only a single counterexample to refute it, but to verify it by considering individual cases, one has to consider all of them and show that they all work (which, if there are infinitely many, it is impossible to handle them all individually, and if there are just a lot, it may still be infeasible) . Conversely, for a Sigma_1 statement, a single example is sufficient to verify the claim, but refuting it by checking individual cases would require checking every case.
From the looks of it, Rust is usable un a tiny embedded system but it is not "great". I think that out of the recent, trendy languages, Zig is the best suited for this task, but in practice C is still king.
The big thing is memory allocation, sometimes, on tiny systems, you can't malloc() at all, you also have to be careful about your stack, which is often no more than a few kB. Rust, like modern C++ tend to abstract away these things, which is perfectly fine on Linux and a good thing when you have a lot of dynamic structures, but one a tiny system, you usually want full control. Rust can do that, I think, like C++, it is just not what it does best. C works well because it does nothing unless you explicitly ask for it, and Zig took that philosophy and ran away with it, making memory allocation even more explicit.
Rust has no malloc in the language whatsoever. In embedded, you don't even include the libraries for dynamic allocation in the first place, unless you want to. And it's very normal not to.
It probably depends how tiny you mean. If the reason you can't allocate memory is because the only 1024 bytes of static RAM is all stack, then, yeah, Rust won't be very comfortable on that hardware. On the other hand C isn't exactly a barrel of laughs either. In my mind if I can sensibly chart what each byte of RAM is used for on a whiteboard then we should write machine code by hand and skip "high level" languages entirely.
I don't know where I've lied about this, supposedly. Unless you say that, because of this implementation exception (which is based on target, not std vs no_std by the way) as meaning that "there's no UB in safe Rust" to be a lie.
I would still stand by that statement generally. Implementation issues on specific platforms are generally not considered to be what's being discussed when talking about things like this. It's similar to how cvs-rs doesn't make this a lie; a bug isn't in scope to what we're talking about 99% of the time.
In context, I'd have no reason to deny that this is something you'd want to watch out for.
> For an example, if a function in no_std overflows, it can result in undefined behavior, no unsafe required. And stack overflows are easy in Rust, like they are easy in most other systems languages.
This is true, no_std has no Rust runtime so it doesn't provide stack protection. I am aware of efforts to address this for embedded, but they're not available at the moment.
> Steve Klabnik has lied about that in the past, as he is wont to do.
1) I don't know what Steve has to do with anything I asked so it is bizarre to bring up and 2) I find this is to be a ridiculous statement.
I learnt the most from bad teachers#, but only when motivated. I was forced to go away and really understand things rather than get a sufficient understanding from the teacher. I had to put much more effort in. Teachers don't replace effort, and I see no reasons LLMs will change that. What they do though is reduced the time to finding the relevant content, but I expect at some poorly defined cost.
# The truly good teachers were primarily motivation agents, providing enough content, but doing so in a way that meant I fully engaged.
I think citation would be needed on this. Obviously any artist producing fully original music or art doesn't.
And many content creators might benefit from an expanded public domain, or they might not... There's already tons of creators, they seem to be getting by? Well, actually, some are getting by and most are probably hobbyists or underwater much like most arts. I'm not sure expanded quantities of available characters would necessarily change much.
> Obviously any artist producing fully original music or art doesn't.
I would suggest that artists who say they're producing fully original works are just poorly educated in art history. Making something that has no prior influences would be extraordinary in the modern world.
Also, the entities most capable of exploiting long copyright terms are corporations. Individuals simply don't have the resources to keep something relevant decade after decade save for a very small handful of exceptions like J.R.R. Tolkien.
I'm not even really advocating for or against the copyright position.
I also think you're missing my point a bit. Just cause you study lots of works and create an original creation which borrows influences isn't the same thing as requiring use of a copyrighted piece of work.
It's pretty silly to suggest I was implying artists have no influences cause I classified works without any copyrighted material as original.
My point was more... just cause a bunch of copyrighted work becomes available does not necessarily imply creators and artists lives will be substantially different or better off.
Oh really? You don't think all the creators who do things like make video essays on 20 year old movies would benefit from not getting the rug pulled out from under them? You don't think they would prefer being legally in the right making money from analysis of media that was a generation ago?
You don't think the Techmoans and Technology connections would prefer having better demonstration material than whatever recordings from 1912 exist, so that they could actually show you what they are trying to demonstrate without having their livelihood threatened by a capricious and byzantine system hell bent on pleasing a few megacorps?
You don't think the creatives who made "The Katering show" for example would prefer that more people watch their artistic output than have it locked behind some business leaving it languishing in a random digital storefront rather than letting more people buy it because they just cannot be assed? Oh, you don't actually have to guess, because they uploaded a youtube video where they encourage people to pirate their work so they can see it.
Creatives and artists tend to enjoy their work being consumed and riffed on (not plagiarized) and well adjusted artists recognize that there's "nothing new under the sun" and that remixing and riffing are essential parts of the creative and artistic process.
Hell, the music industry even understands this, which is why letting songs get licensed out for remixes and future use is common.
Isn't the question whether it's reasonable for people to be rentiers? Clearly lots of the population are, but wouldn't it be better if they carried on creating rather than sitting back and doing nothing for the remainder of their place on earth?
While I agree, in practice they can actually be parallel. Case in point - the Java Vert.x toolkit. It uses event-loop and futures, but they have also adopted virtual threads in the toolkit. So you still got your async concepts in the toolkit but the VTs are your concurrency carriers.
Could you give an example to distinguish them? Async means not-synchronous, which I understand to mean that the next computation to start is not necessarily the next computation to finish. Concurrent means multiple different parts of the program may make progress before any one of them finishes. Are they not the same? (Of course, concurrency famously does not imply parallelism, one counterexample being a single-threaded async runtime.)
Async, for better or worse, in 2025 is generally used to refer to the async/await programming model in particular, or more generally to non-blocking interfaces that notify you when they're finished (often leading to the so-called "callback hell" which motivated the async/await model).
If you are waiting for a hardware interrupt to happen based on something external happening, then you might use async. The benefit is primarily to do with code structure - you write your code such that the next thing to happen only happens when the interrupt has triggered, without having to manually poll completion.
You might have a mechanism for scheduling other stuff whilst waiting for the interrupt (like Tokio's runtime), but even that might be strictly serial.
That doesn't follow. Say you write a proof for a something I request, I can then check that proof. That doesn't mean I don't derive any value from being given the proof. A lack of trust does not imply no use.
Right, not intrinsically. Sometime tokens are IOUs e.g. redeemable stablecoins, where the issuer promises to swap the token for bank money. But for tax purposes most jurisdictions still treat them as commodities AFAIK, to my point earlier.
And fiat isn’t that different either: central bank currency are technically liabilities, but there’s nothing concrete you can redeem them for beyond more of the same money…
This is what a lot of people get wrong. Money doesn’t have to have liabilities, only fiat currencies do. Commodity money eg gold or silver are valuable in and of themselves, for instance. The government sues signiorage there.
However, individual liabilities are a great way to introduce currencies into circulation. Start with eg loyalty points at a restaurant or credits redeemable aboard a ship etc. We are working on that: https://community.intercoin.app/t/local-community-currencies...
All money ever has had an associated liability. Commodity money absolutely relied on the face value as the basis of the commodity value. Any metal/face value disparity could lead to cross border arbitrage (making use of counterfeiting), but intrinsic to the process is the associated liability of the issuer. Otherwise you're just trading assets.
Seigniorage absolutely relies on the fact that money redemption value is different to the value of metal (or whatever). That difference is the liability.
reply