treyd

Angie Nixon is currently a Florida state rep who is running for US senate: https://angienixon.com/

"Small candidates", for US senate?

You're mixing up two issues. The need for oracles is a "hard problem" but it's not the problem in this case.

USDC has a central issuer that can freeze funds because that's the only way you can currently have an asset that "looks like" dollars on a crypto ledger. Someone gets a dollar, mints a unit of the bearer token, and pinky swears they'll redeem it. It's a systemic concern that calls into question the legitimacy of the system, but that's not an oracle.

This is wild, I had no idea Lean could be used for things like this.

Once you internalize it it's really not a problem. That's why I said "after a few rounds of this".

This is a viable approach for many scenarios. Uniffi is a tool/library from Mozilla that makes this a lot easier across platforms.

After a few rounds of this though it might end up seeming like it's not worth the hassle and it's easier to build the whole application in Rust.

I've totally written a phrase like this before.

And in this context, literally yes that's what it sounds like. The .ani file can contain multiple animation sequences that each have a name.

It has a wider feature set and is just generally easier to use. When I had to set up GHA I was constantly surprised with how hard some very basic things were that were trivial with GitLab CI.

GHA was based on Azure Actions, which was never intended as a CI system nor meant to be used in a context where actions could be malicious. So it's the wrong tool for the job that had to be adapted to fit another use case, straying from its original design principles to make it work.

Unfortunately the only way I can spend directly from my work-sponsored FSA account is if I download their app. I haven't, since I can still just submit receipts, but they won't send you a physical card.

Regardless of the probability that this cosmically unlikely occurrence naturally happened 8 times in a row, we all know what the privkeys are now so the certs can't be trusted anymore.

My understanding is that while dogs can understand words and put them together to understand basic (even novel) commands, they do not generally have a comprehension of syntax, which is an essential part of language. To them, a sentence is just a bag of concepts bundled together without structure.

Removing hate from a privately-run platform is not censorship. It just feels like censorship to reactionaries because their political beliefs are hateful and do not respect the categorical imperative.

You can flip through the pages of a book much faster than it'd take you to actually read them normally. But if you're putting the book in a scanner then you're still extracting information, faster than the "natural speed" of reading them.

It's not being played through a desktop audio stack, they're operating on the waveform decoded from the audio file. There's no constraints relative to the "natural speed" of the source, just like for video transcoding, it's limited by compute.

I don't understand this framing of recomps using the word "stolen". For most games the hard part and the valuable part is not "writing the code", it's everything else.

The bots might be run in the datacenter and proxied through residential IPs as the exit point.

I don't know if anything like this has been built, but I'd imagine you could have the hypervisor capture stack traces / log buffers / core dumps when a unikernel VM crashes.

> Even rust makes ffi unsafe.

Which is why every library that wraps C APIs provides safe wrappers that express the implicit expectations within Rust's type system. Yes the low-level calls are unsafe, of course they are, but then we expose them with a safe interface that consumers actually use.

> you should design it so that your language is easily and correctly statically checked.

You do that by making the type system more sophisticated.

If you have a really important invariant that you really don't want to be violated due to run-time behavior/input, it's a huge benefit to have a compiler that can statically check that it actually can't be. That's one of the main benefits of having type systems, not just describing the shape of data structures in memory.

How could that possibly work without a semiconductor?

So why does the government get to do all of those things? Especially when they've already demonstrated that they're not very good at using them to achieve the stated goal of improving security.

This is a dishonest comparison. The atmosphere warming has a much more immediate impact and the ocean isn't a perfect heat sink.

Air has a specific heat (~1) less than a quarter per unit mass than water (~4.1). The atmosphere has a mass of ~5 billion kgs and the ocean has a mass of ~1.4*10^21 kgs.

It requires a lot less trapped energy to warm the atmosphere by 1 C than the ocean. We're well on track for 2.5 C increase since preindustrial levels.

Yes, it'd probably be compiled into very machine code. However defining an enum for it puts the intention into the source code more explicitly, so that's considered the more idiomatic way. You'd probably have a `fn peer_id(&self) -> Option<Inet4Addr>` accessor that you'd use in the case where you'd want the Option.

This is an experience I personally had as well. It's a saving grace when working with junior developers because you know they won't end up writing parallelism-related heisenbugs.

It's also just as easy to incorrectly share memory and cause race conditions. There's no protection against it and it violates memory safety.

> not only do you need specialised data structures, but all (transitively) allocating calls need to be specialised

Most crates for containers will be written such that the container types take an optional allocator type parameter that defaults to the global allocator. You can set it and it transparently uses the other allocator.

To improve the ergonomics, you'd define local aliases that use that allocator.

    type MyVec<T> = Vec<T, A = MyAlloc>;

Can you point to a specific example that ends up being a "worst of both worlds" in your perspective?

Here's an article about the research on it which lays out the properties in simple terms: https://smallcultfollowing.com/babysteps/blog/2016/10/02/obs...

I'm curious why you think that statement is doing heavy lifting. It's much easier to write and verify that a few lines of code are correct than it is to write and verify that an entire program is correct. But that's the norm in C and Zig, and historically people haven't been very good at it. That's why we try to do it as little as possible.

That's just not an accurate description of how you write Rust in practice. There's no separate "high level" and "low level" parts/forms of the language any more than the software development process already is all about building abstractions. You should be doing this in Zig, too.

It's just that sometimes some of the abstractions you need to build go outside what the ownership and borrowing system can model. And when you don't need to do that (which is 99% of the time) you also get all the benefits of the ownership/borrow system for free.

> the very thing you reach for a low-level language for - they typically require unsafe

There's a formal proof asserting that if you keep up the safety invariants within an unsafe region then that will not infect other code, even in the presence of arbitrary other correctly-written unsafe blocks.

This means you can build abstractions on top of these low-level primitives to keep it contained, so consumer code never has to even think about or know there's unsafe blocks in it. The type system lets you build very powerful abstractions so these go a long way.

There's a lot of woo-woo scare quoting around how much you actually have to use unsafe code in Rust. It's fairly uncommon to actually have to reach for them in practice. Most of my usage ends up being things like converting a &[u8] to a &str when I know it's already valid UTF-8 so I want to skip the linear-time validity check. Very rarely do I have to build data structures with complicated pointer juggling, because there's often a library that already does what I need!

> which is that over time, as program changes and evolves over years, things tend to drift toward the more general mechanisms that rely on malloc/free on an individual objects, and the program gets slower and slower

What are you talking about? I've never encountered this and I've been using Rust for 10 years.