Interesting idea. While waiting for my verdict I was asked the same question (and provided the same answer) over and over. Was expecting a bunch of different questions, rather than the same questions, repeated.

huh, maybe. I didn't know about this or find it when I was looking around. thanks, I'll check this out.

it does seem very similar. the instantiation syntax and the way you handle things is very, very similar for sure.

Most of my code is in Ruby, but I've been watching languages like Go, Elixir, and ideas around the Actor model for years, trying to take the best ideas from these and applying them in my own system.

Inspired by all of these examples, but desiring a dead-simple solution for the Ruby applications I maintain - I created nobject.

It's not quite RPC. It's not quite the Actor model. It's not quite lightweight processes/channels. It's the ability to instantiate an object in one process but then push it to another process, yet be able to use that remote object like it's still local.

The example code in the repo's README will get you up-an-running in minutes.

Not sure why AI agents wouldn't also be connected to an ad platform eventually. Google does this currently.

While the author says that they are bypassing Google, that's not most people, and Google's results are front-loaded with AI answers, so Google results are already giving you specific answers, hallucinations and all. Not sure why average users would long-term switch to not-Google if Google can give them the amount of AI assistance that want or don't want.

What an incredibly pointless and long ad disguised as a blog post.

Many of the core challenges that are fundamentally about human factors and collaboration haven't changed, such as the conflict between business requirements, engineering approaches, and the desire for no-code solutions.

Ex.: People were writing about agile, no-code, and the challenges of reducing cost and complexity before we had the terminology for it and before a whole industry of consultants existed to explain it.

Application Development Without Programmers https://a.co/d/2kKeOTx

It depends on whether you want to play the game or break it. :D

Most people are taking this as a fun algorithmic exercise, assuming imperfect knowledge.

Tom's writeup inspired me to dig a little more. I unfortunately (for me) discovered a very simple way to solve the game on the first guess every time. My fault for reading the game's code, but I just can't look at the puzzle the same way anymore.

I liked the first half of the essay - some interesting nuggets of some possible ideas, particularly the point about schisms forming rather than continued collective action once a group becomes large enough.

The last half sounds a little bit too much like the bias towards markets and profit motives and whatnot without question and without critique. There are plenty of dysfunctional for-profit orgs that don't allocate resources well, in spite of overwhelming feedback, from the market and elsewhere. The majority of for-profit orgs also have a sales team that is out there pounding the pavement trying to drive sales: it's not all, "Build it and they will come."

I don't buy that a successful company needs to be a mission either. That's very common thinking in the startup world, but not even close to representative of the whole.

I do prefer PostgreSQL if I have a choice, but from the practicality standpoint that many people are hitting on, I'm okay with various design decisions (i.e. take a look at some of the flags for MySQL's `sql-mode` option over the years) being phased out via the normal (warn -> deprecate -> throw error -> remove) lifecycle that things like this often go through in software. Once a technology gets wide adoption, no matter how "flawed" or not earlier versions were, you start to prioritize stability and reliability over "correctness" at some point. This leads to the understandably practical approach to many bugs in many enterprise systems where the team supporting a tech stack learns to work around the rough edges, and might even depend on certain "weird" functionality because it's simply more practical in both the short and long term than not doing it.

None of the above means that I don't see MySQL as flawed in some ways. I'm in a group of developers that I suspect make up a sizable portion of the MySQL community who didn't choose MySQL, but must support it, if for no other reason than because we see ourselves as professionals, and that's what professional do: make the employer's application work reliably.

For applications that have already survived past the point of finding product/market fit, a wholesale conversion of DBMS is rarely worth it, and conversions of this type are costly/risky even if it is worth it. I do understand many of the benefits (real and theoretical) of PostgreSQL, and if I'm around at the moment when a project's DBMS is being selected I'm going to recommend _not_ MySQL, but at some level I'm also paid to make the application that my employer is running on top of their DBMS work reliably ... and the fact is even among people who get PostgreSQL - who prefer it, would choose it if they could - many of us are also pragmatic enough not to pull the rug out from under a running application for "reasons".