I've found the main advantage to this over a more specialized graph database is integration and maintenance alongside the rest of your application. Real world data is rarely just (or even mostly) graph data.
I've pretty much always kept my phone on silent. I don't mind notifications while I'm on my phone anyways, but if I do manage not to check on it for a while I see that as a good thing.
On the surface it's pretty obvious that classroom learning doesn't immediately translate to real world experience, but the paper's finding seems to be more about the extreme degree of discrepancy between the two cohorts. It almost feels like a comment on social class distinctions - there are children who get classroom educations that don't have to use it, while others have to use the skills but don't get the related education.
The absolute numbers are awe inspiring, but the paper actually only adjusted the previous best estimate by about an order of magnitude. It's cool to see incremental scientific improvements getting some spotlight!
I've always been curious to buy a headset display when traveling, but was never sure what I would actually use it for. This is pretty cool and might inspire some use case's I hadn't considered.
I've run into a similar problem many times at small companies. Effectively rejecting the idea of structure because of slippery-slope arguments. I've had pretty senior folks make comments like "If we require PR reviews on every little change, we'll be just like <pick an unpopular large tech company> and take forever to do anything."
My impression is that the disillusionment with startups has led to m a gradual shift towards small self sufficient software businesses. Some folks that would have previously started a VC backed startup for casual software ideas now just keep the scale down and supplement their income on the side.
I've used Github's built in VSCode for quick one-line PRs or docs cleanup. I'm lazy enough to appreciate the feature even if I would never do deeper work in it.
I would be super interested to know how this stuff scales physically - how much hardware ended up in that cage (maybe in Cloud-equivalent terms), and how much does it cost to run now that it's set up?
I'm having a real crisis trying to decide whether this system should be called a database or not. It's a system for managing data, so obviously it is.. but by that loose interpretation any CRUD webserver would count too.
This type of key editing always makes me nervous. I know how uuids behave. I'm not a security expert, but I'm 99% sure the formatting steps here don't increase the chance of key collisions or security implications significantly. Is that 1% risk worth it?
In my experience there is a MASSIVE difference in the type of feedback someone gives on code vs a design. A design doc encourages "why" questions to get everyone thinking about the problem space. For example, a design doc comment might be "why are we suggesting a Rust Webserver when nobody in the company is proficient in Rust yet?".
In my experience those more subtle questions are much harder to raise once a prototype is working - "why does the team's experience matter? look how great it works! If you don't block it we could get this to production in a week by just polishing the prototype!"
Isn't eventual consistency theoretically trivial...? You just delete the whole document after every transaction. I think it's safe to assume anyone talking about this _means_ the results remain meaningful - which for text/meaning is subjective.
The most surprising part of this article for someone uninitiated like myself is probably that products/algorithms are claiming this automatic reconciliation is consistently possible. Maybe I've spent too much time resolving code merge conflicts by hand, but this seems intuitively obvious to me...
I got a similar sense, especially the section where they talked about needing to build trust before trying to change things. I do volunteer photography, and feel the same way as this article any time I do a shoot for a small organization that has never gotten good photos for their business before. It's super rewarding, but a completely different thing than my dayjob managing a solid team of engineers.
Once you get to the examples of different types of webpages, the author basically admits React (and SPAs in general) is likely appropriate for a bunch of application types. At that point the argument seems to boil down to "use a CMS and a simple frontend if user sessions are simple enough".
The current system diagram implies using duckdb's default storage format directly. I wonder how well this would actually work with the proposed zero-ETL design of basically treating this as a live replica. I was under the impression that as an OLAP solution DuckDB makes performance compromises when it comes to writes - so wouldn't live replication become problematic?
What are the use cases for this? I can't imagine designing a database schemas to use this in a typical product. Is it intended for hybrid applications to back up local user data directly with their account info?
I know this article is about Google's culture and the author is a strong developer, but it reminds me of conversations with junior developers at other companies. I've worked with a lot of junior folks that think they should be a "senior" 2 years out of their undergrad CS courses. After all, fixing some tests independently fullfills the "leads complex projects" box on the leveling chart.
For how much the standards were referenced, nobody seemed to actually explain the history of the two syntaxes or the reasoning that led to the introduction of a dedicated join statement. If anyone has an article that summarizes the actual history (or even the RFC for introducing the JOIN syntax), I would love to read it.