physix's comments

"Sprawling distributed systems".

I like that. Sounds like a synonym for "Platform Engineering". :-)

I remember being amazed that lambda architecture was considered a kind of reference, when it looked to me more like a workaround.

We like to build IT cathedrals, until we have to run them.

That may hold to a certain extent for relational databases where your business model doesn't align well with physical model (tables). Although you might wonder why stored procedures and triggers were invented.

In databases where your domain is also your physical data model, coupling business logic to the database can work quite well, if the DBMS supports that.

https://medium.com/@paul_42036/entity-workflows-for-event-dr...

Take off, eh!

It's missing.

I was curious to know the statistics on the mentions of various programming languages on HN over the years, so I got me a copy of all HN comments from a BigTable public source. But now I need to interpret each comment and so what I need is a semantic grep. The easiest would be to prompt an LLM.

Comments are pretty short, but there are many millions of them. So getting high throughput at minimum cost is key.

I'm hoping that Inception might be able to churn through this quickly.

If you folks have other ideas or suggestions, what might also work, I'd love to hear them!

The idea is having a semgrep command line tool. If latencies are dropping dramatically, it might be feasible.

This looks to be really well written. After 25 odd pages, I'm saying to myself, can't wait to read the whole book.

Thanx!

What's ASI?

I vote for "unhinged" as Word Of The Year.

Interesting that The Economist thinks they are "verging on the unhinged", and not yet actually unhinged. Is that a buy signal? :-)

I think that's what evolution did when developing the brain! :-)

I'm a total noob in ML. I just had to vent something for not understanding this stuff and realizing that knowing physics doesn't mean you can grok ML mechanics.

We developed an Entity DBMS where the entities are FSMs.

https://medium.com/@paul_42036/entity-workflows-for-event-dr...

I believe that FSMs are a very powerful approach, even for building entire systems. So much so, that it forms a core part of our product.

I was waiting for that comment to appear.

If your core product isn't any good, A/B testing seems like rearranging the deck chairs on the Titanic.

I think it's indeed the opportunity cost and the commoditization of the infrastructure and operational expertise that drives startups to AWS. But over time, as you scale, they can easily become your biggest component to your marginal cost, without an easy exit, because they locked you in.

It was cool reading your article.

We're also bootstrapped and use Hetzner, not AWS (except for the occasional test), for very much the same reasons as you.

And we are also fully infrastructure as code using Ansible.

We used to be a pure software vendor, but are bringing out a devtool where the free tier runs on Hetzner. But with traction, as we build out higher tier services, it's an open question on what infrastructure to host it on.

There are a kazillion things to consider, not the least of which is where the user wants us to be.

We met on a project in a bank. Worked together for a number of years. Became friends.

We trust, respect and understand each other. I think that's really important. You'll be going through think and think together.

It's an interesting article that makes intuitive sense. But from what I understood, the scenarios are still pre-AGI.

From what I understand, we are far from achieving AGI, and the article would have benefited from defining the term and putting it into relation.

Because the disruption is significant even without AGI.

A colleague upgraded the production database for a securities financing settlement system on a Friday evening by accident 20 years ago.

We were devs with root access to production and no network segregation. He wanted to upgrade his dev environment, but chose the wrong resource file.

He was lucky it was a Friday, because it took us the whole weekend working round the clock to get the system and the data to a consistent state by start of trading.

We called him The Dark Destroyer thereafter.

So I would add network segregation to the mix of good ideas for production ops.

Ah, yes.

> I immediately messaged my co-founders.

I dunno. The effort needed to ensure you have backups is tiny compared to the work done to create the product. And to pull a backup before deleting stuff in production only needs a smidgen of experience.

They were extremely lucky. Imagine what the boss would have said if they hadn't managed to recover the data.

Without having looked at it, I would assume the value comes from not having to know the data model in great detail, such that you can phrase your query using natural language, like

"Give me all the back office account postings for payment transfers of CCP cleared IRD trades which settled yesterday with a payment amount over 1M having a value date in two days"

That's what I'd like to be able to say and get an accurate response.

> Build sociotechnical systems with “normal people” in mind

From the perspective of the composition of software engineering teams: Most of us have to make due with the average, we strive to find the above average and avoid the mediocre, but mostly we are teams composed of "normal" people. The article has some good advice for making the best out of a group of normal people. It particularly relevant because it's unlikely that you'll see anything else.