4 ms·
https://willspeak.me/2021/11/24/red-green-syntax-trees-an-overview.html https://willspeak.me/2021/11/24/red-green-syntax-trees-an-ov... >The idea of red / gree
by tester756 3y ago
https://willspeak.me/2021/11/24/red-green-syntax-trees-an-overview.html https://willspeak.me/2021/11/24/red-green-syntax-trees-an-ov...
>The idea of red / green syntax trees initially came from the Roslyn C# compiler. It was adopted by Swift in their libsyntax implementation. The Rust Analyzer project built further upon this with the Rowan crate. Rowan extends the model of red-green syntax trees with the idea of dynamically typed nodes.
Also probably this:
https://joeduffyblog.com/2015/11/03/blogging-about-midori/ https://joeduffyblog.com/2015/11/03/blogging-about-midori/
>Midori was a research/incubation project to explore ways of innovating throughout Microsoft’s software stack. This spanned all aspects, including the programming language, compilers, OS, its services, applications, and the overall programming models. We had a heavy bias towards cloud, concurrency, and safety. The project included novel “cultural” approaches too, being 100% developers and very code-focused, looking more like the Microsoft of today and hopefully tomorrow, than it did the Microsoft of 8 years ago when the project began.
- mrkeen 3y agoI checked out the Midori blog: https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/ https://joeduffyblog.com/2016/11/30/15-years-of-concurrency/ > Developers already had several mechanisms for introducing concurrency, and yet struggled to write correct code. > STM could handle all of the decisions transparently like figuring out how coarse- or fine-grained synchronization to use, the contention policies around that synchronization, deadlock detection and prevention, and guarantee that you didn’t forget to lock when accessing a shared data structure. All behind a tantalizingly simple keyword, atomic. > STM also came with simple, more declarative, coordination mechanisms, like orElse. So, although the focus was on eliminating the need to manually manage locking, it also helped evolve synchronization between threads. Fascinating stuff. > Unfortunately, after a few years of prototyping deep runtime, OS, and even hardware support, we abandoned the efforts. Oh well. > It wasn’t even clear that STM would be the correct tool for the job once we got to that point. This is just sour grapes. You already identified the problem and the solution. There's no walking that back. > My brief summary is that it’s more important to encourage good concurrency architecture than it is to make poor ones “just work” We'll I guess there's just nothing to do but leave it to the programmer to get right! Miles ahead? Or DNF?