4 ms·

Interesting idea, I would certainly have use for it. But the current severside library support is limited to Lua and Haskell - quite the sign that the project i

Interesting idea, I would certainly have use for it. But the current severside library support is limited to Lua and Haskell - quite the sign that the project is squarely in the hands of academics and has never seen real world dependent on a heavily used system. Even if my stack were based on a supported language, I would take pause at that.

lionkor 2y ago
luajit is stupid fast, and cooperating with a lua program from other languages is trivial. Might be worth a look?
- dotancohen 2y ago
  It is certainly worth a look, and of course if the project takes off then Python and other library support would be expected eventually. That's how open source communities usually develop. My point was that the current library support is a good proxy for the state of development and deployment, and currently this state is very early.
  - mst 2y ago
    Given there's both client and server code available for JS that seems like a perfectly reasonable place to start experimenting with it. The python community tends to be less neophilic than JS (often to its advantage) so I wouldn't expect that to show up until later.
josephg 2y ago
There are a couple nodejs implementations as well. I would know - I wrote one of them.
- junto 2y ago
  This looks somewhat similar to websockets and SignalR. What am I missing here? Is it like GRPC as a protocol, built on top of HTTP/2? I’d be interested in working on a port for .NET.
  - josephg 2y ago
    It’s like how http and tcp are different. Http adds a semantic layer on top of tcp which describes fetching documents and updating them. Of course you could make your own nonstandard http on top of tcp, but having a consistent protocol that everyone uses means we can have content-agnostic tooling and middleware for caching and fan out. When you use http, there’s a lot of existing tools that will just work and be compatible with your software. That’s what we want for braid. Braid is an extension of http which adds semantics for documents and data that change over time. (I’m no longer directly involved, but I really hope the project succeeds!)
- dotancohen 2y ago
  That's great to know. The fine article mentions only Haskell and Lua unfortunately - I wonder if it is out of date.
toomim 2y ago
Not sure where you're seeing "limited to Lua and Haskell." Most of the implementations are in Javascript. Check out braid-text, it's super practical: https://www.npmjs.com/package/braid-text https://www.npmjs.com/package/braid-text There are also implementations in Rust and Go.

lionkor 2y ago

luajit is stupid fast, and cooperating with a lua program from other languages is trivial. Might be worth a look?

dotancohen 2y ago
It is certainly worth a look, and of course if the project takes off then Python and other library support would be expected eventually. That's how open source communities usually develop. My point was that the current library support is a good proxy for the state of development and deployment, and currently this state is very early.
- mst 2y ago
  Given there's both client and server code available for JS that seems like a perfectly reasonable place to start experimenting with it. The python community tends to be less neophilic than JS (often to its advantage) so I wouldn't expect that to show up until later.

josephg 2y ago

There are a couple nodejs implementations as well. I would know - I wrote one of them.

junto 2y ago
This looks somewhat similar to websockets and SignalR. What am I missing here? Is it like GRPC as a protocol, built on top of HTTP/2? I’d be interested in working on a port for .NET.
- josephg 2y ago
  It’s like how http and tcp are different. Http adds a semantic layer on top of tcp which describes fetching documents and updating them. Of course you could make your own nonstandard http on top of tcp, but having a consistent protocol that everyone uses means we can have content-agnostic tooling and middleware for caching and fan out. When you use http, there’s a lot of existing tools that will just work and be compatible with your software. That’s what we want for braid. Braid is an extension of http which adds semantics for documents and data that change over time. (I’m no longer directly involved, but I really hope the project succeeds!)
dotancohen 2y ago
That's great to know. The fine article mentions only Haskell and Lua unfortunately - I wonder if it is out of date.

toomim 2y ago

Not sure where you're seeing "limited to Lua and Haskell." Most of the implementations are in Javascript. Check out braid-text, it's super practical: https://www.npmjs.com/package/braid-text https://www.npmjs.com/package/braid-text There are also implementations in Rust and Go.