mbell

> Rails has started to show its age amid with the current wave of AI-powered applications. It struggles with LLM text streaming, parallel processing in Ruby

Not at all my experience, actually it was incredibly easy to get this working smoothly with hotwire and no javascript at all (outside the hotwire lib).

We have a Rails app with thousands of users streaming agentic chat interfaces, we've had no issues at all with this aspect of things.

Armchair aerospaceing here, but it feels like he's a whole class of positioning sensors in this analysis. It seems to be you only need GPS and related absolute positioning systems to get you close to the tower. At that point, what you care about is the relative positioning of the tower and the booster. I would think this can be done very accurately with a host of options: cameras, radar, lasers, ILS style systems, etc, etc.

> Sqlalchemy stands out as a library having probably one of the most complete and pragmatic APIs for database access across all languages.

I can't disagree more. Identity map based ORMs are _awful_ to use, in almost every way.

I'm not sure what the current state of things are since I haven't use MySQL recently but this used to be a perfectly valid thing to do.

The issue was that MySQL doesn't use a full int to store enums. If your enum has 8 values, it stores in 1 byte, if it has more than 8, it stores it in 2 bytes. Adding that 9th value thus requires re-writing the entire table. So yes - it can make sense to "reserve space" to avoid a future table re-write.

You also had to be careful to include `ALGORITHM=INPLACE, LOCK=NONE;` in your `ALTER TABLE` statement when changing the enum or it would lock the table and rewrite it.

"If addition doesn't work, I have no way of reasoning about anything in a program."

Hardware addition is filled with edge cases that cause it to not work as expected; I don't see it as that much different from the memory safety edge cases in most programming models. So by corollary is there no way to reason about any program that uses hardware addition?

We used InfluxDB back in the 0.8/0.9 days and it worked really well, scaled nicely with the large number of metrics we were storing.

The switch to a tag based architecture in 1.0 completely broke the database for our use case, it could no longer handle large metric cardinality. Things improved a bit around 1.2, but never got back to something usable for us.

We ultimately moved to using clickhouse for time series data and haven't had to think about it since.

Where is influx at now? Can they handle millions of metrics again? What would bring us back?

The biggest issue with current attempts at typing in Ruby is the choice of a nominal type system. If there ever was a language that called for structural typing, it's Ruby.

> Our test harness didn't catch it (weird combination of reasons, too long ago for me to remember the details) & it rolled out.

This is why I'm pretty dogmatic about variable comparison in tests.

This is dangerous and stuff like this has caused a lot bugs to slide though in my experience (and maybe ops):

    expect(account1.balance).to eq account2.balance

This is safe and specifc:

    expect(account1.balance).to eq 2500
    expect(account2.balance).to eq 2500

Unfortunately I've run into a lot of folks that take major issue with the later because of 'magic numbers' or some similar argument. In tests I want the values being checked to be be as specific as possible.

Client side validation, regardless of the technology used, is a performance and UX optimization.

The backend must always validate and it's this validation that matters for any sort of 'security' or data integrity issue.

> In React 17, React automatically modifies the console methods like console.log() to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases where a workaround can be used.

I feel like when you've gotten to the point that something like this has been proposed and accepted as a good solution to a problem your framework is facing, it may be a good time to stop and reconsider the approach of the framework.

"Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands."

- Someone

Not with PG. A couple weeks ago I was working on a project that used truncation cleaning, the test suite took 3m40s. I switched it to cleaning with transactions and the the test suite ran in 5.8s.

Truncation cleaning is extremely slow, not only because the cleaning is slower but because you actually have to commit everything your test code does.