Well “it” becomes you and “taste buds” are the microwasps.

Like the recursive game of life?

Or just good ol’ laws and regulations.

If negative externalities are an issue, just tax those and let people decide if the investment is still worth it.

Small dogs can do OK in your typical suburban block. (Block as in land for single dwelling). They need walks though yes.

What is the language agnostic answer to the same question?

I imagine something to do with memory usage or avoiding thread or thread pool starvation issues. Maybe performance too?

I don't have a lot of experience with async/await at high numbers of tasks, but I've run Erlang with millions of processes. It's a lot easier to run millions of Erlang processes on one machine than to run a million OS threads. I suspect async tasks would be similar; an OS thread needs its own stack, and that's going to use at least a page of memory, but often much more. Otoh, an async task or green thread might be able to use less.

If you're running real OS threads, I think task switching is going to be real context switches, which might mean spectre mitigations clear your cpu caches, but task switching can avoid that.

You may end up with more system calls with OS threads, because your runtime might be able to aggregate things a bit (blocking reads become kqueue/epoll/select, but maybe that's actually a wash, because you do still need a read call when the FD is ready, and real blocking only makes a single call)

Asynchronous code has race conditions and synchronization issues too.

I pray for all the code written by people who think they didn’t need to learn about synchronization because they wrote asynchronous code.

And unfortunately I’ve come across and had to fix asynchronous code with race conditions.

You cannot escape learning about synchronization. Writing race-condition-free code is not hard.

What is actually hard is writing fast lock-free routines, but that’s more a parallelism problem that affects both threaded and asynchronous code. And most people will never need to reach that level of code optimization for their work.

Async-await is about concurrency, not parallelism. It can work in both a single-threaded and multi-threaded context, the latter exposing all the typical failure modes of multi-threaded code.

Also, Rust’s ownership model only prevents data races, that’s only the tip of the iceberg of race conditions, and I don’t think that any general model makes it possible to statically determine that any given multithreaded code is safe. Nonetheless, that’s the only way to speed up most kind of code, so possibly the benefits outweigh the cost in many cases.

You can write safe code using threads if you enforce that the only way threads can communicate is by sending messages to each other (via copying, not pointers). This is what Erlang does.

No, you can get races and deadlocks in a pure actor system as well. It's actually easier in my experience to end up with problems in actors. I tried writing an app in that style once and had to back off that design and introduce some traditional shared memory multi-threading on some codepaths.

There are no shortcuts, no silver bullets when it comes to concurrency. Programmers have to learn about multi-threading and the ways it can go wrong because it's a fundamental thing, not a mere feature you can design your way out of.

> There are no shortcuts, no silver bullets when it comes to concurrency.

But you can identify the opposite of the silver bullet, which is shared mutable state, and then hurry away from it as quickly as possibly.

Rust defaulted to avoiding sharing and Haskell defaulted to avoiding mutability.

For application code, I've yet to see a better concurrency story than 'use pure functions where possible, or use STM when you absolutely need shared mutation'.

>No, you can get races and deadlocks in a pure actor system as well.

You can't get data races, which is what Rust prevents. Rust's async doesn't prevent deadlocks or other kinds of races.

> You can write safe code using threads if you enforce that the only way threads can communicate is by sending messages to each other (via copying, not pointers).

At which point they're not really threads, they're more, well, processes.

> This is what Erlang does.

Exactly.

> IMO the biggest reason to avoid threads is simply that it's ~impossible to write safe code using threads (e.g. without race conditions).

Javascript has race conditions too, even with no threads involved.

At a FAANG. Depends if you can jump the requisite hoops and also stick it out.

My memory is rubbish generally except I can draw the floorplan of anywhere I have lived or stayed. But directions, conversations, dates, forget it!

Chairs would have a tail hole. Just imagine having to sleep and roll over with arms in the way!

What is the dead mans switch guy dies?

Presumably you'll get an email from him to tell you so

What if I am dead?

It is not an either or. Best thing average jo can do is auto set up to overpay their tax efficient retirement vehicle, make sure said vehicle is an index of US share or perhaps an international mix with a decent US weight, and buy a residence somewhere there is and probably will be high demand. So NYC, London etc. (due diligence assumed)

With that you can spend all you earn, you will be forced to save a bit naturally due to mortgage repayments and the retirement setup and you have diverse investments.

Once you gave equity you can borrow to invest more.

If you get any bonusy kind of money like RSU then invest that as you go along unless you need it to create more cushion for your mortgage.