Tbf, the author (prompter?) went on Postgres.fm [0] recently to discuss it, and while it didn’t make me entirely confident in it, it did at least seem like it was several steps above the average vibe project.
A lot of podcasters don't have the expertise to evaluate Ai generated/assisted output. I see this much more outside of the development community. Algorithms have warped the incentives and people have stopped doing basic due diligence.
To be fair to the postgres.fm guys (who I do like and appreciate), the pgrust code was not available a the time of recording.
I've hosted a Minecraft server, reading this I immediately thought that a Pi was just not powerful enough to do an adequate job at running one. Perhaps they figured that out once it was too late?
I had the same thought. Using one for yourself and probably a friend or two in the LAN could work, but I doubt it can run a proper server with a reasonable amount of slots. Maybe the first real test opened his eyes, but he still underestimated the problem.
A non-scam product would probably be targeted exactly at that scenario: plug it in, run a server for a handful of friends. Likely anything more than 10 players would never depend on a product like this.
The problem with this line is that it becomes an argument against me, rather than self education. There are many comments about this on this very post, and it's recent headline news!
The reason I asked in that way was to see if GP actually knew anything about what they had strong opinions about.
On the other I think asking someone for a citation to their rather strong claim isn't incorrect. Digging through unstructured HN comments isn't my idea of a good time and being sent off on a treasure hunt by fellow commentors isn't why I come to this website. Collaboration is how we move forward!
A regexp basically comes with a compiler. Who knows what sort of optimisations they've built in under the hood. It wouldn't be surprising if there was a special fast-path for efficiently searching for a substring; that'd be effective in practice.
But more importantly it is hugely context sensitive on how often the function is going to be called and what IO needs to happen around it to decide if speed matters at all.
Using a regex as a first attempt is entirely reasonable. Especially in an interview about Python. If we care about efficiently doing substring matching Python isn't the language of choice. If a programmer just wants to remember how regex work and get on with their day they'll do fine at handling string problems.
Questions like "how would you search for a substring?" are so incredibly dependent on what you're doing on a day-to-day basis, and what you're doing with the data once you've split it. Just because .split(...) is in all the tutorials doesn't mean the codebase you've worked on for the last 5 years actually uses that specific call with any regularity, and it may well be the case that your codebase does use regexs more often (maybe for query-portability purposes).
I write bare metal firmware, primarily in C, and I've had to make it a point to explain, in most every interview I do, that I've only ever used malloc(...) in tutorials. "In my world, malloc is a 4-letter word". So while I know what it does, and how it works, I actually have to google its usage, and I'm not as keyed into its pitfalls, because every system I've ever worked on could not afford the risks associated with dynamic memory allocation.
All of this to say, bad interviewers go looking for a specific answer, good interviewers go looking for good process. All of the jobs I've held are ones that accepted that I was rusty on this or that specific call, but could think about the system holistically.
It's simple, unless you're given a specific broader context (like we have an enterprise customer data pruning system that needs to handle a broad range of corner cases) then you must not resort to overengineering this early in an interview.
In recent months, Linus said it specifically about code for a personal side project of his. The quote was in the commit message. (I’m not the grandparent commenter, and I think grandparent commenter’s claims may be too broad or require context.)
There are a missing the context: The vibecoded application was written in python while the main code was written manually in C by Torvalds in this side project. He never ever said that AI produces better code than him in the language where he is proficientI.
> The python visualizer tool has been basically written by vibe-coding. I know more about analog filters -- and that's not saying much -- than I do about python. It started out as my typical "google and do the monkey-see-monkey-do" kind of programming, but then I cut out the middle-man -- me -- and just used Google Antigravity to do the audio sample visualizer.
> Personally I've always called this style "declarative schema management" since the input declares the desired state, and the tool figures out how to transition the database to that state.
Personally I've called it a mistake, since there's no way a tool can infer what happened based on that information.
For schema changes, it absolutely can, for every situation except table renames or column renames.
That might sound like a major caveat, but many companies either ban renames or have a special "out-of-band" process for them anyway, once a table is being used in production. This is necessary because renames have substantial deploy-order complexity, i.e. you cannot make the schema change at the same exact instant as the corresponding application change, and the vast majority of ORMs don't provide anything to make this sane.
In any case, many thousands of companies use declarative schema management. Some of the largest companies on earth use it. It is known to work, and when engineered properly, it definitely improves development velocity.
Uh, any database of sufficient size is going to do migrations “out of band” as they can take hours or days and you never have code requiring those changes ship at migration start.
Small things where you don’t have DBA or whatever, sure use tooling like you would for auto-changes in a local development.
Very large tech companies completely automate the schema change process (at least for all common operations) so that development teams can make schema changes at scale without direct DBA involvement. The more sophisticated companies handle this regardless of table size, sharding, operational events, etc. It makes a massive difference in execution speed for the entire company.
Renames aren't compatible with that automation flow though, which is what I meant by "out-of-band". They rely on careful orchestration alongside code change deploys, which gets especially nasty when you have thousands of application servers and thousands of database shards. In some DBMS, companies automate them using a careful dance of view-swapping, but that seems brittle performance-wise / operationally.
Right, but my point was that renames in particular typically can't go out well before the corresponding application change [1]. Thus, renames are "out of band" relative to the company's normal schema change process. (This is orthogonal to how schema changes are always "out of band" relative to code deploys; that wasn't what I was referring to.)
[1] In theory a custom ORM could have some kind of dynamic conditional logic for table or column renames, i.e. some way to configure it to retry a query with the "new" name if the query using the "old" name fails. But that has a huge perf impact, and I'm not aware of any common ORMs that do this. So generally if you want to rename a table or column that is already used in prod, there's no way to do it without causing user-facing errors or having system downtime during the period between the SQL rename DDL and the application code change redeploy.
Not to mention apps that may have differing versions deployed on client infrastructure with different test/release cycles... this is where something like grate is really useful imo.
