Atom's new concurrency-friendly buffer implementation
blog.atom.io
blog.atom.io
Xi also keeps track of changes using a data structure like Patch. It doesn't use a tree to do so, although we may eventually switch some to use Xi's generic Rope tree data structure. One interesting difference is that Xi always creates another "layer" for every edit and never modifies anything. This leads to lots of layers, but instead of working forwards from a "base text" we work backwards from the current text. So accessing the current text is very fast, and accessing a past snapshot may require mapping in reverse past a small number of edits.
They both solve the same problems though, although Xi's approach of layers for every edit also enables seamless multi-device concurrent editing via a full CRDT merge implementation.
If you're interested in reading in detail about the approach Xi uses, I wrote a big document about it near the end of my internship working on Xi's CRDT: https://github.com/google/xi-editor/blob/master/doc/crdt-det...
Incidentally, I've also been working on an in-depth article on a particular CRDT: Victor Grishchenko's Causal Trees[1]. The original paper only uses the data structure for text, but I believe it can be extended to a variety of other data types. In brief, the basic convergent structure is a tree of immutable "atoms". This tree is stored in memory as a DFS in-order traversal. I treat each atom as an atomic operation ("insert char" or "delete char" in case of strings), and thus, every user action involves an O(N) mutation of the tree array to insert the new atom in the correct spot, followed by an O(N) re-read of the array to update the user-facing data. This requires the effect of each atom to be O(1) when read in DFS order, but with strings, this follows naturally. A CT string in memory looks a whole lot like your "union string" with explicit delete ops instead of tombstones, e.g. ["ins D","ins O","ins U","del","ins G"] which parses as DOG in O(N), except each atom does in fact have a unique ID and holds a reference to its causal atom — the character intended to be on its immediate left. (So no need for crazy coordinate transforms!) As with xi, you also get a full revision history which can be garbage collected if needed.
My implementation is a work-in-progress, but I've already extended it to basic Bézier drawing and I'm really curious to see how it scales compared to a more OT-like CRDT such as yours. My guess is that CT won't work very well with large files on account of the full O(N) read/write requirement as well as the ~10x memory cost vs. C strings, but on the other hand, it seems that very few other CRDTs can be painlessly tweaked for use with other data types, and this would be a worthwhile tradeoff for me. CT also benefits from a mostly O(N) merge and O(N) past revision viewing, provided you keep to the reconstruct-data-in-linear-time-on-DFS-traversal invariant.
Anyway, CRDTs are super cool! Interesting to see them being used in local contexts, but it totally makes sense, especially since consistency w/garbage collection isn't a concern.
[1]: https://ai2-s2-pdfs.s3.amazonaws.com/6534/c371ef78979d7ed84b...
Yes the Xi CRDT (closest we have to a name) is based on Raph's work, plus some discussions we had and about one week of me standing in front of a whiteboard figuring out how to apply the concepts to doing a merge on Xi's specific CRDT structures.
Currently Xi also stores many bytes for each character typed, but one of our planned optimizations is to delta-encode chunks of old revisions. The operations are stored with fields that are designed to delta-encode efficiently so for runs of normal insertions we should be able to get down to ~2 bytes per character.
1. Dynamic typing
2. Global interpreter lock
3. Automatic garbage collection
4. Interpreting the code (instead of compiling to a single binary).
5. Virtual machine shit
It is just the matter of time, until the team accepts the pain to learn "How to do stuff in C/C++/Rust?".
Tracing GC is not an issue for the majority of applications, and just because a language has a GC doesn't mean it lacks support for value types, e.g. Modula-3, System C#, ...
Regarding affine types, while a great approach, the ergonomics still need to be improved.
The fact that Oracle, Microsoft, Google and Apple are now on the JIT/AOT train, tells it all.
To be fair, .NET always had AOT native compilation support from the early days, but NGEN is a simple AOT compiler only meant for faster startup.
For many applications running on a VM on different platforms Just Works. The idea is most definitely not over, in fact it is becoming ever more popular. Just look at the rise of abominations like Electron.
We don't need VMs, what we need is rich libraries and there are plenty of languages with support for AOT compilation to native code with such libraries.
Something that even C++ is finally adopting.
Regarding Electron, I hope it joins MSHTML in a couple of years.
When feeling like the rest of the world is running in a direction of utter madness, it makes sense to re-read "Worse is better" [1] once in a while. However, I agree, DT and GIL aren't helping anything but writing poor code faster and blinder.
You have to copy and paste the url.
jwz has strong opinions about Hacker News
Also...
> Retarded
Come on. Let's have an adult conversation here.
Think for a second: why can't you produce a better working text editor that people actually use, if all current ones are produced on inefficient technologies by subpar engineers with impaired judgment that led them to current choice of techniques? What are the real barriers to do that?
It just wouldn’t be an improvement for the vast majority of our code, because JavaScript already runs very fast thanks to V8, and using JS allows for excellent customizability by our users.
PHP, using HipHop.
I don't know about you, but I sure don't want my new Audi running on stone wheels.
The only benefit of WebAssembly would be if we wanted to port Atom to work in a regular web browser. We can even already do that without WebAssembly by compiling the superstring library to JS with emscripten. This works today and benchmarks show that it's already quite fast, but I think WebAssembly will make it even more efficient.
I don't even ... but better late than never.
So it's just an opinion thing - not objectively terrible as you think.
Here you go:
https://www.google.co.nz/search?lr=&as_qdr=all&q=allintext%3...
> the "reinvent poorly" comment comes up all the time on Atom posts.
That's likely because they reinvent things and do it poorly. This post is about yet another instance of that. It isn't something I've seen discussed before, it is a brand new part that has been reinvented poorly.