dgroshev

I don't think there is any conceivable scenario in which Russia using nuclear weapons would lead to anything resembling "World War", except Russia launching a counter-value strike against continental US, which is just not happening. A high-altitude detonation is not a "World War".

Russia is a China's client state at this point, and China is very interested in keeping nukes taboo. They are so worried their own army is only allowed melee weapons in border skirmishes with India. There is no way a demonstrative breaking of the taboo would not get Putin's leash yanked, so even that remote possibility (that has nothing to do with WW3) is extremely improbable and would only hasten Russia's defeat. Unless, of course, our politicians use it as an excuse to abandon Ukraine.

Also, no one is "pushing Russia's back against the wall" in Ukraine, there are no M1A2s speeding to Moscow. Russia understands it perfectly well, too, denuding their borders with NATO to throw more soldiers into the meat grinder.

> the fact that we can't assume these people are acting rationally

I think this meme is largely a cop-out. A person just doesn't get to be a leader of a country by acting irrationally. They might interpret things differently or have different priorities, they might even put on an act of irrational buffoonery, but it's different from being "irrational". However, to see the rationality of their actions requires putting yourself in theirs shoes, which is uncomfortable and/or requires a deeper understanding, so it's easier to just write their behaviour as "irrational".

Putin is perfectly rational. The empty threats are working (as evidenced by this thread), there is no risk of a strategic exchange (because the actual signalling on the ground is one of business as usual), and Western politicians are successfully convincing their voters that they drag their feet because WW3, not because actually stopping the war (eg deploying a NATO peace keeping force) would incur a substantially higher domestic cost.

We don't really talk about potential North Korean aggression in WW3 terms, do we? We shouldn't do that in Russian case either.

> you don't put a nuke somewhere to kill people; you put it there to destroy infrastructure. More specifically nuclear missile silos, and bomb shelters (well, the people inside them.)

It depends.

"Counter-force" strikes aim to destroy the ability to respond or attack with nuclear weapons, not infrastructure per se. So that's just silos, warhead storage sites, submarines in port, airfields, etc. The US is doctrinally counter-force for about half a century. This doctrine is also reflected in technological choices: lower yields and higher precision mean lower fallout, collateral damage, and fratricide when hunting for silos, but aren't that useful for city busting.

"Counter-value" strikes are pure destruction of cities and killing of people. Russia seems to have this doctrine [1]. This is a very inflexible doctrine, because you can't credibly threaten to execute a counter-value attack on the US over things that don't seem to be worth a response in kind (like a defeat in Ukraine). It's much cheaper though.

> The very latest US ICBMs are suspected of having sub-100m CEP

Apparently the precision is good enough for photos like the one on page 23 here https://www.osti.gov/servlets/purl/1557069

[1]: At least strategically. There is a hybrid strategy of targeting military-related infrastructure, which Russia seems to have adopted for less-than-strategic forces according to recent leaks https://www.ft.com/content/237e1e55-401d-4eeb-875b-03fe68f81... .

There is no fear of WWIII, that's part media invention, part political excuse, part useful idiots. A "World War" requires an opponent worthy of a world-wide conflict, and Russia is anything but, being stuck in Ukraine for three years and losing most of its army in the process. Conventionally, Russia is no match for NATO, with enough political will it'd be a Desert Storm-like curb stomp. The only way it's not is the US abandoning NATO, then it can be quite painful, but even then Russian economy is no match for the EU.

As for nuclear weapons, they are practically useless. Anything but strategic use would have little impact on the battlefield, but will immediately alienate China and India. They have their own border conflicts and do NOT want the nuclear taboo to be broken, and they are holding the leash, being the only economic and technological lifeline Russia has. A strike against the US would be suicidal for obvious reasons.

Also, notice how Putin and his officials talk about nuclear use a lot, but there is still zero evidence of any action (such as dispersal of road-based ICBMs or 12th GUMO taking warheads out of storage). Rhetoric is cheap and not credible.

The only real fear of escalation here is "horizontal" escalation: Russia stirring shit elsewhere. Advanced anti-ship missiles to Houthis, handing nuclear technology to North Koreans or submarine technology to China, that kind of thing. But that's already seem to be happening, and there isn't much more that Russia can do.

Note that FPV drones in Ukraine are not squad-level, there are separate drone units (at the very least 2 operators, at least 1 explosives guy because arming drones with makeshift explosives is not trivial and super risky, plus cover). Plus they are supplied literally on the back of a minivan in cardboard boxes because they only need to survive one way trip over a couple hundred km, the US needs to supply their units half a globe away.

US army drones are squad-level, have proper safing/arming, transportable, and shelf-stable. It's not scope creep, it's a very different doctrine and circumstances.

I agree wholeheartedly (and I'm not surprised that you of all people often write raw futures!). I want to push back on the "async rust bad/failure/not ready" meme because

- it's perfectly possible to be a successful user of the async ecosystem as it is now while building great software;

- this two-tiered phenomenon is not unique to Rust, JS and Python struggle with it just as much (if not more due to less refined and messier design). As an example, [1] is elegant, but complex, and I'm less sure it's correct compared to a gnarly async Rust future, because the underlying async semantics are in flux.

Of course I'd love for the remaining snags (like AFIT) to go away, and simplified Pin story or better APIs would be great, but this negativity around async Rust is just wrong. It's a massive success already and should be celebrated.

[1]: https://github.com/florimondmanca/aiometer/blob/master/src/a...

Every single JS future is boxed. Moreover, they aren't just boxed, they are often backed by a hashmap (which may or may not be optimised away by the JIT). Elaborate allocation-free async is not an apple-to-apples comparison.

JS does support concurrent execution, Promise.all is an example. Without it, JS async would make little sense. The problem very much exists there, and try-catch is only a surface-level answer. As you can see here [1], the interaction of cancellation and async in JS is at least just as (or more) complex than in Rust.

By the way, multithreading has little to do with Pin. I presume you're thinking of Send bounds.

"To work at all" is very dismissive. Those wrappers are complex, but very well abstracted, well defined, and robust, the complexity is essential. Again, look at [1], JS async is hardly less complex, but also much more vague and ill-defined.

[1]: https://github.com/whatwg/streams/issues/1255

> Then I spent 2 weeks trying to do the same thing in rust… Eventually I gave up.

In my experience, that kind of difference boils down to a combination of three things.

- Comparing apples and oranges. For example, Box makes pinning trivial (you can just move in and out of Pin no problem), but oftentimes people new to Rust try to prematurely optimise and eliminate a single pointer lookup. If that's the case, were you really writing the same thing in JS and in Rust?

- An extension to the previous point, the behaviour is usually different. What would happen in your JS implementation if two streams were awaited concurrently, one received a message, and the other had to be cancelled? What if one threw an exception? In Rust, you're forced to think about those things from the start. In JS, you're coding the happy path.

- Trying to reproduce the exact same architecture even if it's awkward of inefficient. For example, it's really really easy to use a stream wrapper [1] to produce a stream from a channel, but then the architecture gets very different.

> Again I needed to produce an async stream, and thats impossible using async fn

I strongly recommend a channel instead. There's also async_stream [2], but channels are simpler and cleaner.

Over two years of writing embedded, web, and CLI rust I didn't have to write a raw future once.

[1] https://docs.rs/tokio-stream/latest/tokio_stream/wrappers/in...

[2] https://docs.rs/async-stream/latest/async_stream/

> But keeping the current half-baked async implementation doesn't make the language smaller or simpler. It just makes the language worse.

I can't disagree more.

In fact, I think that the current state of async Rust is the best implementation of async in any language.

To get Pin stuff out of the way: it is indeed more complicated than it could be (because reverse compatibility etc), but when was the last time you needed to write a poll implementation manually? Between runtime (tokio/embassy) and utility crates, there is very little need to write raw futures. Combinators, task, and channels are more than enough for the overwhelming majority of problems, and even in their current state they give us more power than Python or JS ecosystems.

But then there's everything else.

Async Rust is correct and well-defined. The way cancellation, concurrent awaiting, and exceptions work in languages like JS and Python is incredibly messy (eg [1]) and there are very few people who even think about that. Rust in its typical fashion frontloads this complexity, which leads to more people thinking and talking about it, but that's a good thing.

Async Rust is clearly separated from sync Rust (probably an extension of the previous point). This is good because it lets us reason about IO and write code that won't be preempted in an observable way, unlike with Go or Erlang. For example, having a sync function we can stuff things into thread locals and be sure that they won't leak into another future.

Async Rust has already enabled incredibly performant systems. Cloudflare's Pingora runs on Tokio, processing a large fraction of internet traffic while being much safer and better defined than nginx-style async. Same abstractions work in Datadog's glommio, a completely different runtime architecture.

Async Rust made Embassy possible, a genuine breakthrough in embedded programming. Zero overhead, safe, predictable async on microcontrollers is something that was almost impossible before and was solved with much heavier and more complex RTOSes.

"Async Rust bad" feels like a meme at this point, a meme with not much behind it. Async Rust is already incredibly powerful and well-designed.

[1]: https://neopythonic.blogspot.com/2022/10/reasoning-about-asy...

It doesn't, at least not under GDPR and not in that scenario. Contoso is a "[personal] data controller" and SAP is a "data processor". Contoso has a legal responsibility for all personal data and for all its vendors.

Contrary to a popular opinion, GDPR is fairly logical and close to common sense.

It gets murkier with "joint data processing" (a cursed cop-out for scenarios like Facebook acting both as a data processor for a website's ad tracking and as a data controller for its own ad tracking at the same time), but the scenario you described is not that.

Going against the consensus, I'd recommend a Prusa MK4S instead. It'll likely serve you much longer and will achieve better dimensional precision and slightly better quality at the same speed.

Be warned though, the printing part is just a tiny step in the rabbit hole. Soon enough you'll be lamenting the state of CAD, yearning for class A surfacing in your projects, and trying to decide between diving into Rhino/Grasshopper or mastering SOLIDWORKS.

I don't think there's much inherent value in the CoreXY geometry. MK4S seems to outperform everything Bambu has both on speed and on quality (especially on overhangs and dimensional precision) despite being a bed slinger.

On the other hand, continuing the bed slinger line let Prusa provide an upgrade path for existing printers.

In short:

- print quality and speed is similar (new MK4S seems to be a bit better)

- Bambu's design life is much shorter (Prusas are fully repairable with parts stocked in the online shop, and every new version release includes upgrade kits for old models)

- the amount of effort/babysitting is similar

- reliability seems higher on Prusa's side (no wonder, given that they print parts of the printer on the printers themselves on industrial scale)

Also, if this matters to you, Bambu behaviour (like patenting opensource designs they didn't invent [1] and hostile competitive intelligence [2]) seems quite problematic.

[1]: https://www.mdpi.com/2411-5134/8/6/141

[2]: https://twitter.com/josefprusa/status/1706713274455081120

Sure, but I believe the majority of OpenSCAD users are fine with non-commercial use.

It is, check out the sibling reply. Dassault's web 3DEXPERIENCE stuff is weird and unnecessary, but can be abstracted away behind a desktop shortcut.

SOLIDWORKS for Makers includes a full copy of SOLIDWORKS and costs $48/year https://www.solidworks.com/solution/3dexperience-solidworks-...

First of all, I'm sorry I upset you! That was definitely not intended.

I'm not comparing the two, I want to show what's possible. I often see people finding OpenSCAD, getting comfortable with it because it's all code, and stopping there. But there's so much more to solid body modelling, it's not too complicated to learn, and a bit more advanced CAD really expands the range of physical objects we can create! This is why I chose those slightly more complex examples, I'm not trying to gotcha OpenSCAD, I tried to show why one might want to branch out, despite all the downsides (subscription, non-code source files, Windows*, etc) you mentioned.

Fwiw I dream of a good open source CAD that syncs code and GUI (like KittyCAD) but doesn't fall into the trap of "procedural" modelling like OpenSCAD or KittyCAD. The combination of sketches+constraints+3D operations+projections is perfectly representable as code, it's just much more work than raw CSG, requires a geometric kernel, and is more mind bending. Still, I hope we will get one some day.

*: it does run perfectly well in Parallels though, so between Mac and native Windows I suspect it's more like 80% here

If you find yourself doing a lot of OpenSCAD, you might want to check out what you're missing from more traditional CAD systems:

A few examples of simple fillets in SOLIDWORKS: https://www.youtube.com/watch?v=f78gblpqxHc

Higher level continuity: https://www.youtube.com/watch?v=h5QN40d02cw

A good example of nontrivial surfacing: https://www.youtube.com/watch?v=cujS1icUTtg (the entire channel is a goldmine of surfacing tutorials)

Not every part needs G3 smooth curves, but being able use those tools when appropriate is a superpower.

I'm quite sure that's autosuggestion.

I was kayaking on the Thames too (up in Richmond/Teddington), but on marathon/sprint kayaks which are very narrow and unstable, so most people in the kayaking club (hundreds of people!) flipped pretty regularly. We also went to swim from the pontoon in the summer every weekend for years. I can't recall anyone experiencing a persistent metallic taste, and I'm only aware of a single case of food poisoning in the club over the five years I was an active member, and that could be anything.

I do remember seeing seals, fishes, eels, kingfishers, herons, and cormorants though. The Thames is a lovely river with bad reputation because of the silt that tides are constantly churning up, and the only problem left (sewer overflows during heavy rain) will be finally gone next year when https://en.wikipedia.org/wiki/Thames_Tideway_Tunnel goes operational.

SOLIDWORKS for Makers is $48/year [1]. That subscription includes a proper SOLIDWORKS installation, Dassault is pushing their web stuff, but you don't need to use it. Also, it uses local files by default, unlike Fusion [2]. The subscription comes with a no-commercial-use clause and the files can't be opened in the commercial version, but I'm sure if push comes to shove the file thing will be fixed on the high seas.

Re: Mac: SOLIDWORKS runs perfectly well in Parallels on M1. I moved from Fusion and it's been great. Just having fully working G3 surfaces/constraints [3] and patterning on sketch points alone is worth the expense.

[1] https://www.solidworks.com/solution/3dexperience-solidworks-...

[2] Recently Autodesk changed the policy and now Fusion360 will remove your files if you don't pay and not log in for a year.

[3] Something that I don't think we'll ever see in FreeCAD, considering the pace of Open CASCADE development https://git.dev.opencascade.org/gitweb/?p=occt.git

Same.

It's the best kind of science fiction, "society fiction" in SciFi clothes that tries to stay in the realm of plausibility and logic.

They are terribly underrated.

I'm really sceptical that anything will happen in the CAD space bar massive state investment into open source infrastructure. Open CASCADE doesn't look to be catching up [1], while Solidworks continues to release foundational features like G3 continuity constraints, so the capability gap is going to widen over time.

I'd be glad to be proven wrong.

[1]: https://git.dev.opencascade.org/gitweb/?p=occt.git

Proper footnotes have now landed! https://github.com/getzola/zola/commit/6a2b890545398bb21cab5...

I disagree with your "just" in "just receiving from a channel". Receiving from a channel is hardly distinguishable from IO, since it can take an arbitrary amount of time and the receiver needs to handle external resource failures (ie the other side of the channel getting dropped). That's very different from normal sync functions parsing JSON, adding matrices, or doing date math. Also note how functions that can't block are still sync, like tokio::sync::oneshot::Sender::send.

I also can't agree with the argument that if it's possible to hang the runtime there's no point in explicit async. Yes people can still make mistakes, but it's better when it's explicitly a mistake and not just haphazard IO everywhere being the norm.

What is the "async-less" codebase for? Why does it have to be "async-less"? A Go codebase is fully async at all times, so why shouldn't a Rust system extend async up to main() (or at least encapsulate IO-heavy parts in a separate async part)?

Runtime behaviour of async rust is ~equivalent to Go, so coming back to my original point, the difference is that 1) Rust allows to have non-async, predictable functions, async is opt-in 2) the opt-in must be explicit 3) you have more choice between intra- and inter-future concurrency (select! vs spawn). All those points are important and empowering, they aren't problems to be solved.

I agree that the flip side is that Rust forces explicit decisions upfront, but that's one of the core premises of Rust.

Yes, thank you, my bad. Fixed.

I'm not sure what you mean by "don't compose well".

You can call sync code from an async function perfectly well. Going the other way around is either very simple in a throwaway code (just use pollster or tokio's block_on), or requires appropriate care (because async means IO and calling a function doing IO means your function now does IO too).

I believe what most people are struggling with is having to think about doing IO instead of just doing IO wherever. But that's a feature, not a bug, and an overarching theme in Rust: you need to think what you're doing and how everything will work together. Yes you can't just put an async call somewhere down the stack without changing the signatures, but that's a good thing.

Legally they can't even with a typical banner, since consent has to be specific and informed. There can be no informed consent when the banner presents 100+ data processors. The problem is that it's not enforced in any way.

I agree that we need to change the way of thinking about this, but I disagree with your particular proposal.

The change we need is to realise that this is not a technical problem and it can't be solved by technical means.

On the one hand, some of the largest US corporations are interested in subverting people's privacy. Some of those corporations directly control our computers and software running on them. They also spend billions to keep ahead of any non-megacorp competition (there's a business reason why Google keeps extending Chrome at breakneck speed).

On the other, the underlying problem is a kind of a prisoner dilemma. Spying-driven advertising is ultimately zero (or negative) sum for society [1], but any "defecting" company will be punished by relative sales underperformance. It's a coordination problem and it requires disincentives for defectors, which is not something we can engineer our way out of.

The solution has to be well enforced privacy protecting laws. Think GDPR, but with actual teeth and antitrust action, not letting companies get away with malicious compliance like sham "consent" forms directly violating GDPR [2].

Unfortunately, even on this forum there is very little understanding of the necessity of regulation, and I doubt things will change much. It pays very well to destroy privacy and open web (remember AMP?), and there is very little financial gain in going the other way. In fact, it's professionally harmful, since enablers are more likely to gain and hold power over those who object.

My only hope is relative outsiders in the EU legislature.

[1]: We haven't seen an explosion of productivity attributable to FAANG, so ultimately customers have the same pool of disposable money that businesses are competing for. The businesses haven't shrunk their marketing budgets either, so if you step back and look at the before/after state of the system as a whole, nothing changed except the big shift of ad money from old platforms (including print media) towards FAANG.

[2]: GDPR requires consent to be informed and specific. Ask yourself, do you really understand what precisely your data will be used for when you look at a typical "cookie banner"? Have you ever received a notification asking you if you consent to your data being used in a new way, which is absolutely necessary under GDPR if a data controller (i.e., a business collecting your data) decides to onboard a new marketing SaaS? Have you ever heard of a substantial fine for a company collecting consent in a way that is not specific enough?

GDPR is not in any way ambiguous there, take a look for yourself [1]. Keeping an eye on those changes is a part of your responsibilities as a data controller, it's your vendors' responsibility to inform you of any changes, and it's your responsibility to vet vendors for GDPR compliance. Again, if your lawyers didn't explain this to you (and you haven't read the law yourself), I'd be very cautious of those lawyers.

On the other hand they probably realise there's zero chance for substantial review of your GDPR practices by the regulator (much less seeing them in court), so they can recommend sticking a useless plaster (opt-in has to be specific, and how can it be specific if you collect it for unknown future changes) and keep you in the dark about more substantial requirements.

GDPR is a very good and clearly stated law, you can read through it yourself in about half an hour to an hour, a negligible time investment for such an important piece of legislation. The purported ambiguity is a psyop by people who don't want to comply.

[1]: https://gdpr-info.eu/art-28-gdpr/

> We don’t control them, we don’t know what kind, if they can be considered personal info or not

If I were you, I'd consider changing my lawyers. This is explicitly forbidden by GDPR (art 28), you have to know what your contracted data processors are doing, and you have to have processes in place to assure data subjects rights (eg remove their data from your contracted third parties on request). Cookie banners have nothing to do with this, and you're in breach of GDPR cookie banner or not. If your lawyers didn't stop you from breaching art 28 but recommended slapping a cookie banner "to be extra careful", that's a major red flag.

I'm a bit confused. You're claiming what I'm saying is false, but you're just referring to someone advising something as a precaution? Do you have a primary source for a legislation mandating cookie banners? (Also, is there a cookie banner on apple.com?)

There is no "disproportionate punishment" under GDPR in practice, unless you're doing something egregious, and even then (see Facebook). I'm very familiar with the UK regulator, they publish their enforcement actions [1]. I'm not aware of a single case of a cautionary letter, much less "disproportionate punishment", that they sent over a cookie banner on its own. Are you?

Besides, you correctly hinted at the incentive structure. Your lawyer might advise you to slap a cookie banner just because because they have zero incentive not to, they don't care about your users' experience. You might care though. Personally I consulted multiple external DPOs and lawyers, as well as primary sources, before forming my opinion.

[1]: https://ico.org.uk/action-weve-taken/enforcement/