eximius

I feel like most of our problems in the US are cultural/educational, not technical.

The US population just feels... increasingly both hostile to itself and aggressively, maliciously ignorant.

It is very disheartening.

The cheat book is written for some smeared set of versions since it's inception. It is out of date for 0.11 as well. The effort to keep it up to date is somewhat low since Bevy changes so much an so often in its current development.

While I sympathize, they're actually very much not the same product. It isn't a simple matter of cross compiling for a different CPU architecture, the APIs and platforms are sufficiently different to be distinct.

Unfortunately it's somewhat out of date

While I never spent a lot of time in GCP, it seemed like it was harder to understand GCP itself as a platform compared to AWS.

That is to say that Google APIs and services seem fine, but figuring out project management and infrastructure management feel incredibly weird. Not necessarily bad, but arcane and awkward where in AWS I can just hit the ground running.

Arguably, debatably, GCP might have the "more correct" model with resources scoped to projects and such, but it does make the learning curve harder.

They have the best integrations.

This is not an endorsement of the decision to use Okta, but I understand why.

A beverage is a combination of its compounds.

What else did you expect?

Ribbit.

One of the common comments in this thread is "can't we just make standard interfaces in std?" "well, no, sync+send is hard"

I can't help but wonder if there are two sets of interfaces necessary? a set of standard single-threaded traits and a set of multi-threaded traits? would that be sufficient?

As an aside, what workloads require true multithreaded reactors as opposed to a runtime which uses multiple singlethreaded reactors?

If you're just using Arc<T> without any other parallelism primitives, then it's immutable and the cores can all read without blocking. The only thing it does is reference counting to know when to Drop.

Blindly using Arc<Mutex<T>> without considering access patterns is a software architecture problem, not a problem with Arc or Mutex.

I think you'd need to be violating some other rule of rust to do that. e.g., single mutable access.

I think I read this somewhere but I am struggling to recall where, so hopefully I didn't dream this: I believe the larger channels are much, much larger and include adaptive techniques to dynamically exclude noisy regions within channel. It can afford to entirely sacrifice bands in this way because the channels are much larger.

Your complaint is they don't email you enough?

Sarcasm aside, I understand your complaint, but still, a little funny.

The system we're building now meets most of these but not necessarily in the way described.

First, we're building a runtime configuration system on top of AWS AppConfig. YAML/proto validation that pushes to AppConfig via gitops and bazel. Configurations are namespaced so the unique names is solved. It's all open in git.

Feature flags are special cases of runtime configuration.

We are distinguishing backend feature flags from experimentation/variants for users. We don't have (or want) cohorting by user IDs or roles. We have a separate system for that and it does it well.

The last two points - distinguishing between experimentation/feature variants and feature flags as runtime configuration are somewhat axiomatic differences. Folks might disagree but ultimately we have that separate system that solves that case. They're complimentary and share a lot of properties but ultimately it solves a lot of angst if you don't force both to be the same tool.

"rewrite everything correctly" does more or less solve the issue by definition but it is very hard for so many reasons.

Which isn't to say we can't take some learnings from the idea, just that it isn't simply a matter of money.

The problems with clicking past those errors are typically not due to network sniffing but with whatever crazy shit is on the page they are going to.

The only two valid usecases of big VPNs like these are

1. Very mild security increase over public wifi 2. Shifting your risk from the ISP spying to mullvad or the VPN provider spying or slightly anonymizing if mullvad rotates IPs.

(2) is a real benefit because ISPs are pretty terrible, but it's still pretty minor in the grand scheme of most people's threat models.

Our regulators need to find some conviction.

Just do it already.

I do with proc macros could evolve to be able to query the compiler for information (which would necessitate careful thought to adding stages to compiling). I've wanted to know "does this struct impl this trait" or "give me a list of all concretely implemented traits" or various things like this that would be very, very useful in a proc macro.

Fun book, but no. And I wouldn't describe those as YA. YA doesn't typically rant about ANSI C conferences. It's more like Discworld in that it's quite silly but not necessarily targeted at youth.

My reason for Forth is quite simple: it has extremely little structure which makes it a much much easier output target to work with.

At it's simplest, a series of glyphs could directly transliterate into Forth words. More complicated schemes are more interesting, for this purpose, but it would defeat the purpose of its use to target, say, C.

Also, Forth is easily embeddable and interpretable with only the words I want exposed. Whipping C again, but targeting C would mean a whole mess of sandboxing and C bindings which sounds much harder than Forth words or some such.

I have many other ideas too. Multiple rings of circles represent threads or some kind of concurrency, mana is used like 'gas' in the EVM to naturally denote the cost of spells and prevent abuse, possibly compile from Forth to some WASM target or something for performance, etc.

Edit: put another way, Forth-likes blur the lines between a programming language and a mutable environment of high level bytecodes which makes it a natural intermediary language for some cases.

A goal of mine that I currently lack the time or energy to execute on is a simple open world game with most of the game world rules exposed in a Forth-like API/programming language.

Then take some runes/glyphs/circles/shapes and train an NN to translate them into programs using that Forth-like. I think it would make a game world with a significant amount of wonder in the magic. And a bit of unknowability as I'd probably add a bunch of extra features (astrological cycles, environment effects, etc) that slightly affect the spells.

Sahara solar plants + carbon capture? Solar capture in Africa is supposed to have a lot of potential except for the problem of transporting the power. If you can use it locally, maybe it's more valuable.

It's not clear to me if direct carbon capture needs to be distributed.

I don't understand. This seems clearly illegal to have policies like this that claim consent by sitting in the car but the "user" has never been presented the policy in a way to consent to!

Is this just a good lawsuit away from being thrown out but no one has done it? Is there some particularly fucked up legal precedent that makes this tenuously legally stable?

Ledgers. They record a list of transactions, they don't just plus or minus the balance.

I am very hopeful that Xilem will prove an interesting local optimum that combines the necessary optimization and DevEx and UX.

My only complaint is it's being developed so slow! Which isn't a fair complaint, really, I just want it!

That hasn't been proven, has it?

No, it's all theoretical until it becomes liquid.

When I had to do this in the past for access control and compliance reasons, it was easy to just layer them. If you have a) fast search b) fast authorization, you can just do filter(lambda resource: can_read(resource, user), search(query)). There is some tuning necessary involved with pagination and such as you effectively have 2 paginations to maintain (one for user facing, one for your index which will included pruned resources).

I can understand how `InboundRequestContextFinderProviderFactory` comes about, hopefully due to a very mature, thorough testing environment where your `InboundRequestContextFinder` is injected via a provider and that provider needs to be constructed for different environments.

Though it does seem like perhaps the Finder itself is possibly an unnecessary abstraction.

Frankly, the longer I work, the more comfortable I am seeing these kinds of things. They can be misused, but they are also necessary for some really good things too. The absurd names are funny, but also somewhat standardized enough to be a signal on their own.

I'm sorry but you're saying a literal ton, over 2,000lbs, at $600 is expensive? I can't think of any material I can buy a ton of for $600.

A fake is a 'local' or lower fidelity implementation of the real thing. A array/memory backed DB instead of postgres, etc.

A mock is a cache for a desired return value (which is hopefully what the real interface would correctly return).

Edit: actually sethammons link is great