I agree. When you write your own code, you know what your intention was when writing it. Furthermore, as you gain experience and mature you know in the back of your mind that every mistake during code writing costs disproportionately more to fix later on. You only get that feeling by owning the code. AI cannot do that. It can't have skin in the game in that way.

No matter how you feel about the situation, the law is pretty clear that colluding to limit R&D with your competitors is anticompetitive. The fact that these CEOs have called for this in public is pure arrogance enabled by horrific legal controls within the companies (OpenAI's blog post about the Apple lawsuit points to this too) or they're so confident about the degree of corruption in America they feel they can act with impunity. Either way we desperately need the rule of law to do its job and deter these antisocial behaviors.

I agree with the conclusion but not necessarily the why. I don't think therapy is always about projecting your other relationships on to your therapist. A lot of time its your relationship with yourself that you're trying to work through. Or sometimes you just need someone who can observe and challenge you. Or sometimes you just need the space to be honest about what's going on in your mind where there won't be the social consequences of saying that to your friends or family.

I agree that the frame of the therapist-client relationship is key. I agree that AI simply cannot replicate that. You need someone on the other end who has both the deductive ability but also the emotional intelligence to either suss out or help you suss out what exactly is causing discomfort. And AI just can't create that frame because of how we expect to use it.

I agree with the sentiment here but if you are building anything that relates to finance for the love of god please have a page that's just a list of PDFs of every document that is considered formal communication from the institution. It should have the name of the document, the date it was "sent", and a download link. It should be append only, persistent, and be sorted from most recent to oldest. Like for every party involved we ought to have that.

I've been looking at this and the Clicks Communicator which should both be out by the end of this year. I'm not really a "dumbphone" person nor am I really a physical keyboard hound. I just want a smaller phone that feels better in the pocket and in the hand. I thought about a Razr but the proportions are a little awkward when opened. Its a little too long.

I get what you are saying. I'm coming from a Sony Xperia 10 IV with a width of 68 mm and it was perfect, albeit a bit tall (21:9 format). Now I use a Motorola Edge 60 Neo with a width of nearly 71 mm with the "traditional" 16:9 format. It is almost as tall and just slightly out of reach of one-handed use for me. The Minimal 2 is wider at 72 mm, the Clicks is even wider. I'm going to look at the Razr, it's frustrating.

Didn't realize they were iPhone width and wider. Puts a damper on seriously shopping on it for me. Thanks for the info.

This and Clicks Communicator seem eerily similar.

As someone on the periphery looking in, it's because they make up a large web. Its an extended community that shares a lot of people between its many arms. There are also some shared values between all these people, even at the very extended edges. For example, they share a superiority complex. From my experience, most of these people believe that they see further or know more because they believe in certain things that are, on their face, unintuitive. I don't want to pass more judgement than to say, having members believe contradictory or outright falsehoods is a thing that cults do. I'm not saying this is a cult because I haven't seriously sat down and thought about it but that is reminiscent of something cults do.

Read HPMOR. Unlike what I thought it might be, the protagonist does not solve problems through pointing out logical fallacies or something. Harry Potter is a straight-up superhero who is infinitely smarter and more talented than anyone around him. It's not so much rationality as a narcissistic fantasy that goes on for hundreds (thousands?) of pages.

Even though I had been well-disposed to rationalism and read HPMOR to learn more, I could not take Yudkowsky seriously in any way after I gave up halfway through.

Had a similar experience trying to read that. You know you meet or have to work with people like that in your life and hopefully you use those experiences to remind yourself what kind of person you don't want to be.

No. AI is far too compute and energy constrained to exist outside humanity's control. AI is not scaling in such a dramatic way that it could happen soon. It is more likely than not that there are physical limits that neither we nor AI will be able surpass.

The damage AI is causing to society is real and happening now. Potential doomsday scenarios are a distraction from the real harm AI companies are doing at this very moment. They have amplified nearly every asymmetry and turning into mulch whatever was left in trust we had in society. Disinformation is now more convincing than ever. Computer security threatens to become a fiasco, only available to those who can pay the AI mob (the very same people who pioneered the tools attackers use). The entire intellectual property of humanity has been plagiarized without compensation to build these things. Every day more and more is asked of workers for the same compensation. Academic work is sniped at best and outright stolen at worst. Education has become a disaster with students unable to pass the same competency walls as students even just five years ago. Not to mention the environmental damage.

I'm not saying that the technology isn't impressive. I'm just saying its suspiciously convenient that we're suddenly focussed on some potential future big bad done by a vague uncontrolled AI when the harm is here now and under the purview of humans.

Tasks and channels is the way. You can get something that feels like programming a real preemptive concurrency model like BEAM languages or golang but with minimal overhead.

When you send a message in Erlang, nothing the recipient does with the message impacts anything on the sender side. That's good!

In principle, they could have used something like copy-on-write for this, but in practice they really just make a copy of the bytes.

Alas in Go, when you mutate what you received on a channel, you mutate the object the sender might still be holding. That's pretty annoying. It gets worse, because Golang has no way to declare something as `const` (like in C) nor that you are holding an immutable borrow (like in Rust). So you need to rely on conventions and perhaps a linter.

Slighty less of a tangent: task and channels and software transactional memory (STM) are all great. I see mutexes as more of an implementation detail that you can use to implement these higher level abstractions (but they aren't the only way).

I honestly stopped taking Go channels seriously when I found out that reading from a closed channel is indistinguishable from reading the zero value, but writing to a closed channel will panic. I don't want to have to use booleans and write `true` in order to ping another task and have it tell the difference between getting pinged or being hung up on, and I really don't want to have to architect things so that I need to have my tasks know when the other side of a channel is closed before writing to it (or catch panics instead of using regular error handling) because that feels like it defeats the whole purpose of not needing direct knowledge of the state of the other side. It genuinely seems like those design decisions basically came from a desire to use special operators on channels rather than just having `send` and `receive` methods (or worse, to intentionally avoid "tedious" error handling/optional checks), which is mind-boggling.

I hadn't even considered the implications of sending a reference over a channel, but I'll add that to the existing reasons I have to never want to touch Go again.

Historically, Go was also really weird in having a very arrogant design: the language designers allowed themselves a lot of generic operators and structures (like arrays, map, channel, the 'make' function etc), but they were considered taboo for the hoi polloi which had to make do with the equivalent of void* pointers and runtime casting (the empty interface shenanigans).

I say historically, because they got generics a while ago.

Yeah, I honestly was surprised they did end up eventually getting generics. My brief stint with it ended a while before then, but my impression at the time was that they were bizarrely insistent on trying to come up with a design from first principles rather than taking the time to understand the literal decades of designs that came before. It was impossible for me to tell the difference between their position and "we don't like Java generics and are either not aware of languages like ML or are too arrogant to read about them".

Give a task ownership of some state, communicate through channels and suddenly a lot of locking just disappears from the design

I've long pined for an ergonomic way of defining actors in Rust. I feel like there must be some way to abstract things that doesn't leak a bunch of a details into the mental model around how to think about starting/stopping/communicating between actors, but every time I've tried to figure it out (or use a solution someone else made) it ends up being way more complicated than it feels like it needs to be, and not worth it over writing a bunch of manual tasks wrapping private structs that have a bunch of channels in them. I feel like I've tried everything I could think of in terms of API design to make this work in a way that doesn't require users either having to learn a bunch of bespoke rules for the implementation or spend a lot of extra effort on manual boilerplate, including some very wacky things (like a macro where you pass a name and a function and it defines you a new macro with that name for spawning the actor task), but nothing ends up like I'd want.

Yeah the Actor model just doesn't fit well with Rust without feeling like a DSL. Tokio works well because Rust's ownership model overlays with tokio nicely. The language is already doing the hard data safety stuff for tokio, tokio just adds a lot of conveniences.

Erlang and Go make their concurrency models work because it is embedded into the fabric of the language. Neither cares about zero cost abstractions or minimal runtime (and runtime transparency). Both languages accept that there is a runtime that the developer cannot fully control as part of the deal for their concurrency models.

For Rust to have this, you have to break assumptions Rust developers have about writing Rust code. You would effectively be writing a runtime in Rust and then code that uses this Actor library would essentially run on it. But it wouldn't feel right because it would look like Rust code but feel like something else. That sort of heavy framework stuff doesn't mesh super well with Rust even if the language is capable of it.

I guess in the framing you're describing, the issue I ran into is that Tokio still just isn't anywhere close to as opinionated as a runtime as the other ones you mention. Even just taking message passing as an example, Go gives you one channel, and that's what you have to use for everything; Tokio gives you a single use channel, both a bounded and unbounded channel for an arbitrary number of senders to a single receiver, and two separate multi-producer-multi-consumer channels with different properties. I could make a bunch of opinionated choices of my own about how this should work, but at that point I'm adding a bunch of potentially leaky abstractions on top of a runtime that already isn't core to the language (and as the blog post indicates, there's a learning curve about how to get the most out of it).

Good to know someone is trying to make protection rackets work in 2026. Nice computer system you got there, it would be a shame if someone developed a hacking tool and had all the compute necessary to run it. Welcome back Tony Soprano.

I think for kids coming out of university, going against the grain might be one of the most valuable things you can do. The essential skills of critical thinking, problem solving, intuitive and linear thinking, and improvisation are not going anywhere. AI is a very impressive technology but it also is one that steals valuable mental exercise from its users. I can't say that eschewing AI will lead to a successful startup but I have a good feeling that connecting with other people who want to do things the hard way and then doing it will be an extremely valuable experience this early in your tenure. If this AI trend does continue, this will give you and your friends a leg up on those who didn't put in the hours.

Very insightful and encouraging words, thank you!