maclockard

A replicated SQLite is very cool! One question I would have is why expose that as the storage instead of the platform providing a managed storage API? I guess I might be concerned about replication lag and complexity for consumers with the replicated SQLite.

Is it to have more sympathy for LLMs? More 1:1 with a local dev environment?

I think that trust needs to be 'pushed deeper' than that so to speak. While this would be an improvement, what happens if there is a malicious actor at Github? This may be unlikely, but would be even harder to detect since so much of the pipeline would be proprietary.

Ideally, we would have a mechanism to verify that a given build _matches_ the source for a release. Then it wouldn't matter where it was built, we would be able to independently verify nothing funky happened.

What does MSW stand for here? Maybe "Mock Service Worker" https://mswjs.io/?

I love dan luu's blog posts. Great examples of principled thinking. Much of their writing on (computer) performance has pushed my own thinking and expectations.

Not just delivery, but also security. Browsers offer a level of isolation and safety that you generally don't get with native desktop apps. Things like iOS do bridge the gap a bit more though

> make the browser a full blown VM and just write normal programs that run in it

This is actually happening, albeit slowly, with recent efforts around WASM etc. If you want a fun hypothetical of where this all goes, check out the talk "The Birth & Death of JavaScript". Link here: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Wrote about something similar a while ago https://hex.tech/blog/a-pragmatic-approach-to-live-collabora...

Using a server to tie break and locking has worked pretty well for us

I understand what you are saying here in terms of the difference between using wall-clock or causal ordering to determine who 'wins' for LWW. However, both of these strategies seem convergent to me? In any case, all clients will agree on whose changes win.

1. With wall-clock decided by clients, A + B changes will win since C's wall-time is earlier (yes, C could lie, but still would converge).

2. With wall-clock decided by server C will win and everyone will agree.

3. With causal ordering, everyone will agree that A + B won.

2 is not a CRDT since it requires a central server, but I think 1 would still count? Or stated another way: I'm not sure the _convergence_ is what determines if these strategies are CRDTs or not, but rather whether or not this decision making is _distributed_ or not.

> This is the same guy who tried to make "effective altruism" part of his image. That was a pretty strong signal that the outcome we all witnessed was highly likely.

Why do you think that was such a strong signal?

FWIW I'm not sure analogies between intellectual property and actual property really work, since they are pretty fundamentally different if you compare the specifics.

Even better, Jamie Lee Curtis was in both of those movies.

I actually talked to the drifting in space team about our experience implementing multiplayer. Really cool to see their findings!

Our team ended up having a similar take away, we wrote a blog post detailing our approach and experience here: https://hex.tech/blog/a-pragmatic-approach-to-live-collabora...

For the most part is been surprisingly solid! I was very much expecting to need to completely rewrite it by now, but its met most of our present needs.

The only real shortcoming is not being able to support line specific commenting. While we _could_ support it, any minor update to the text would result in the comment being marked 'stale' with a high false positive rate. I've considered adopting CRDT/OT just for the text editing portion to solve this.

I really like how well this bookends with https://hex.tech/blog/long-live-code!

(Disclaimer, I work at Hex but wish more tools would embrace ejecting to code in the same way)

I'm also pretty cynical of most JS rebuild/reinvention projects. I'm very tentatively excited by this one _because_ it looks like all it does is incrementally improve. Having something that is a drop-in API compat replacement for yarn 1/npm and node makes it potentially really easy to get the benefits of incremental perf improvements _without_ needing to reinvent the wheel like yarn 2 or deno.

https://linear.app is pretty great

This sounds really similar to Dutch Blitz! https://www.dutchblitz.com/ surprised I haven't seen anyone else call it that in this thread

That's assuming that these people only contribute to PostgreSQL. I'm betting most of the folks listed here make major contributions on other projects or at work.

Your comment feels like a bit of unfair judgement, particularly since a lot of those you are implying that are 'only 1x programmers' are effectively donating their time.

How much time do you spend a month on marketing for placecard?

I really love how reactivity is being utilized across the stack. It's been pretty big on the frontend for a while now (React, etc), but I think data is another space it can really shine.

If you publish the code anywhere, potentially. You could be (unknowingly) violating the original license if the code was copied verbatim from another source.

How much of a concern this is depends heavily on what the original source was.

Doesn’t fufill your wish for no-sign up link yet, but https://hex.tech supports live collaboration for python notebooks.

I think as time goes on, live collaboration is becoming “table stakes” for a lot of tools.

Oh hey! I work here. Happy to answer any questions folks would have

I think they were referring to the historical value of the bond itself makes it worth far more than its strict monetary value over time. So even if its 'worth' 30-50 times more when you do the math, a collector maybe be willing to pay 500 time more due to its rarity.

no. typescript doesn't add any runtime type checking.

In my experience bigger companies seem possibly _more_ prone to a DIY approach than scrappy startup. Especially if there is a 'not built here' mentality.