It's to drive engagement. Why give you exactly what you want, when they can make you click some other stuff? There's no real competition, and if there were, the competition would soon realize it would have more revenue if it used the same strategy.

You can bet that somewhere, someone was looking at some A/B testing with these "features" and they saw an uplift of X% in revenue, so why not do it?

You have the order reversed. In Buddhism, you learn to let go of attachments, and because of that you let go of smoking, alcohol, etc. It's not the other way around.

It is not necessary but you won't make much progress without one. Spiritual practice without a teacher is like navigating without a map, you may end up in America thinking it's India.

If you are somewhat serious about spiritual practice, of course you should find someone who walked some of the path already, otherwise it's impossible for you to know - by definition, you haven't walked the path yet so you don't really know.

Yeah but you miss the point. You think it’s about getting to the destination. That is what a map is for.

The journey is the destination. And if you are being led and shown you don’t develop your own compass.

Take tips, listen and gather some info BUT the only thing you need is to listen to ‘you’ and the other ‘you’ and decide how it works.

In my opinion of course.

At this point we are basically nitpicking over the Internet, but even if you want to take a journey just for the sake of the trip, a map is still very useful.

Most of the human endeavors (art, science, etc) are facilitated by having teachers. Spiritual advancement is no different and in my book, anyone who thinks different is delusional. You may be perfectly happy with no teacher, but you are leaving out a huge chunk of it by navigating on your own. Of course you are free to disagree, but I think it is essential to know about the range of possibilities before deciding if it's worth to have a teacher, and most people simply have no idea.

A good tourist’s guide to enlightenment map

I’ve listened to a lot of Watts, which isn’t to say I understand it but rather I can recall it. your p1 concerns making progress, p2 on being serious. Watts talks on progress being an illusion, that the deer hunter doesn’t see the mountains. He also talks the same in being serious, rather than sincere, in that it’s like being an oak that cannot away in the wind, constantly concerned with holding yourself together lest you might accidentally fall through the ground.

By trying for America while worrying about India, would be like being hung up on trying not to be hung up. Or competing about who has attainted the most enlightenment, who sat for longest or the most uncomfortably. ~it cannot be grasped by thinking, it cannot be perceived by not thinking. ~The goose flying over the lake doesn’t mean to cast a reflection, and the lake has no mind to retain it. But still, it happens.

Unless they want "read your writes", otherwise bugs start appearing "why isn't the data i just put showing"?

Do people actually consider Alibaba and GCP? I would wager that most of the potential customer base of the two don't intersect.

As I understand it, structured concurrency is part of the same deliverable, tracked in this JEP: https://openjdk.org/jeps/428

Here's the example from the JEP:

    Response handle() throws ExecutionException, InterruptedException {
        try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
            Future<String>  user  = scope.fork(() -> findUser());
            Future<Integer> order = scope.fork(() -> fetchOrder());
    
            scope.join();           // Join both forks
            scope.throwIfFailed();  // ... and propagate errors
    
            // Here, both forks have succeeded, so compose their results
            return new Response(user.resultNow(), order.resultNow());
        }
    }

I'm aware of the JEP. I said "as seen in this very release" after all.

I don't see the advantage to this over async/await style programming. I think you'll see very similar error cases with unobserved exceptions and such.

The advantage is that the method signature is indistinguishable from a blocking method. The subtle difference is that scopes close within a method where as async tasks can continue. I suppose you could see an even worse coloring where scopes and futures are used in half the methods instead of async.

I'm trying to wrap my head around how this would play out if you were attempting to write a GUI or something where the pattern is a single main thread. I suppose it would work just fine and look very similar to async style programming but with a lot more code one tab to the right.

> I don't see the advantage to this over async/await style programming

Harmonious with the platform (jvm) which is based on threads, better stack-traces, accurate profiling info and simpler programming model (without adding async/await/suspend keyword everywhere) etc are some of the advantages.

I've not normally seen people say async/await is a form of structured concurency.

As I understand, structured concurency mostly imply automatic cancellation and supervision that allows retry/restarts.

Does async/await gives you that?

Automatic? I suppose not. But excuse me, I'm just comparing the APIs for a specific use case. I didn't mean to call them the same thing.

The additional features of structured concurency affect the API though, because you need to introduce scopes of supervision/cancellation/retries.

If any async operation fails, at what level up the waiting chain do you want to cancel all other concurent tasks under it and retry the entire async flow?

So you need the APIs/syntax to have ways to define these scope of cancellation/retries.

As I understand, this is why it is called "structured", it refers to similar "structured" programming that introduced lexically scope restricted procedures, conditionals and loops.

Edit: Also, just want to point out that you shouldn't get mixed up between async/await and future/promise. Async/await often uses future/promise, but don't necessarily have too. But future/promise is an async API that existed before async/await, and supports threaded concurency just fine. You can use future/promise in Java with both threads or virtual threads. Using it with virtual threads won't color functions because at any time you can block on a future/promise and extract the value, so it's possible to go from a future/promise returning function to one that doesn't return a future/promise.

As far as defining scope goes, C# gets away with unchecked exceptions. Exceptions just bubble up naturally. Task scope is more implicit in syntax but scheduling Context is used in a similar way to scopes. The difference is context is usually inferred instead of explicitly defined at every use.

It's not about the exception, it's about the exception handling.

If 4 tasks are started asynchronously and one of them throws? What do you want to happen to the other 3?

In structured concurency you could say, if any of them fails then cancel all others, and retry them all.

Or for example, if one task is waiting on another and that first task throws an exception, you might want to say, ok, retry the first and re-schedule the other one to wait on that retried task.

These are all things you can handle yourself as well, but structured concurency is just trying to make that less effort and automatic. So if you define a supervision scope, everything inside it no matter how complex the async graph is, it'll all cancel/retry appropriately at that scope.

The scope will also guarantee that when we leave the scope, all concurent tasks are done, nothing is left running, either because it's all cancelled or the scope waits for all tasks to complete.

Here's some good articles that explains the motivation for it:

https://elizarov.medium.com/structured-concurrency-722d765aa...

https://github.com/apple/swift-evolution/blob/main/proposals...

async/await is just syntactic sugar for futures/promises. The future API itself generally lends itself towards structured concurrency, but your particular implementation may not be.

For example, Rust's `Future` is structured (although executors may introduce escape hatches), while JavaScript's `Promise` is unstructured.

Can you explain a little how Rust adds cancellation and retry supervision using future? I'm not familiar with Rust.

Does this not give you working stack traces?

Most of the time, 1 gamer = 1 card; for crypto, it's like a dozen guys run hundreds if not thousands of GPUs. It's basically hoarding a finite resource.

Absolutely no, other GMs such as Daniel Naroditsky said that at that level they only need to get assistance at a couple of critical moments.

Mostly due to profiling, the JIT gets informed on actual program execution.

I wouldn't word it as vastly superior, because if you have a JIT you're probably doing some kind of tradeoff (most of the times, memory usage?), but the JIT can optimize based on the runtime profile, where an AOT't program cannot.

I'm glad for you, but that quote is a huge simplification of a nuanced theme. Maybe it's hard for a completely different ethnicity to become parisienne, but I'm sure France is a big country. Maybe it applies to Japan, but not to Spain. Etc.

I have been to America and it feels lots of different countries living in the same place, not necessarily a good thing. Again it's a subject full of nuances, but I have seen different people being completely integrated after just a single generation. What I think is relevant is how much a culture is exposed and capable of absorb different people from different cultures.