Here's more about electric tugboats: https://www.youtube.com/watch?v=mu9XZIpOTcw

They can have super high torque. Quiet motors allow them to operate where diesel wouldn't be allowed due noise pollution.

Nix also breaks if you try to update it, and you'll eventually have to update for security issues.

I'm stuck with a defunct Nix project I can't update, because crane and fenix flakes made breaking changes, and nix is giving me incomprehensible errors. I've spent enough time googling the errors that I'd be quicker to start over with a nix-less VM.

These are cheap "city" EVs with small batteries and slow charging. They have all the compromises and annoyances that people don't like about EVs.

The desirable EVs have 2x-3x more range and charge 3x-4x faster. That completely changes the equation, because that makes them good enough to be the primary/only car. Even for people who don't have a charger at home, even for people who need to drive long distances.

For compatibility with the Web content, the `click` event has become a device-independent activation event. Sites can't be expected to listen for events from every kind of device, so instead all devices send `click`s.

They care, because focus for keyboard-controlled screen readers sending "click" should behave differently: an element inside the menu should receive focus, even though it's not the element that has been clicked. Otherwise if focus stayed on top-level menu bar, screen reader users would be lost, and had to navigate to menu's content themselves.

Interesting. Seems like something that should be exposed more explicitly.

I'm amazed how well the Send/Sync bounds work.

Finding all possible data races in arbitrarily large and complex programs (even across 3rd party dependencies and dynamic callbacks) seems like a challenging task requiring specialized static and dynamic analyzers. But it turns out it can be reduced to automatically marking structs as safe to move to a thread, and type annotations on mutexes and thread-spawning functions.

It's an example of richer, expressive interfaces that allocate responsibility for who ensures what behavior properly for the problem. Send and Sync don't fundamentally make thread safety easier. What they do is that library authors can provide abstractions to users and each side has a clear scope of diligence. Rust's realization through Send/Sync is more complicated in practice, demonstrated by that one bug for Mutex(Guard?) in the standard library, but pulls its weight well.

How does it prevent two actors from waiting on each other?

There are no locks. There is no blocking wait, the IO lib is nonblocking throughout. Actors cannot wait.

Messages are guaranteed to be processed ordered sequentially.

https://tutorial.ponylang.io/index.html#whats-pony-anyway

There are while loops, though, so actors can still livelock.

Because most applications aren't written in C++.

People don't write web apps in C++, because they would have to deal with memory safety issues in addition to all the other issues related to auth, injections, etc.

I'm concerned that Bluesky has taken money from VCs, including Blockchain Capital. The site is still in the honeymoon phase, but they will have to pay 10x of that money back.

This is Twitter all over again, including risk of a hostile takeover. I don't think they're stupid enough to just let the allegedly-decentralized protocol to take away their control when billions are at stake. They will keep users captive if they have to.

EU should simply buy it.

True, you need to know what is and isn't possible in the borrow checking model to avoid learning it the hard way after writing the code.

There are some gotchas that you need to learn (e.g. self-referential structs won't work, or & returned from a &mut method won't be shareable).

But besides a few exceptions, it's mostly shared XOR mutable data in the shape of a tree. It's possible to build intuition around it.

I've used it a while ago, but got burned by very uneven support across compilers — MSVC required special tweaks, and old GCC would create crashy code without warning.

It was okay for basic embarrassingly parallel for loops. I ended up not using any more advanced features, because apart from even worse compiler support, non-trivial multi-threading in C without any safeguards is just too easy to mess up.