What does HackerNews think of verona?

Research programming language for concurrent ownership

Language: C++

I would love a language (or C++ subset!) where we could get the benefits of that secret sauce, while mitigating or avoiding some of its downsides.

Like Boats said, the borrow checker works really well with data, but not so well with resources. I'd also opine that it works well with data transformation but struggles with abstraction (both the good and bad kinds), works well with tree-shaped data but struggles with programs where the data has more intra-relationships (like GUIs and more complex games), and works well for imposing/upholding constraints but can struggle with prototyping and iterating.

These are a nice tradeoff already, but if we can design some paradigms that can harness the benefits without its particular struggles, that would be pretty stellar.

One promising meta-direction is to find ways to compose borrowing with mutable aliasing. Some promising approaches off the top of my head:

* Vale-style "region borrowing" [0] layered on top of a more flexible mutably-aliasing model, either involving single-threaded RC (like in Nim) or generational references (like in Vale).

* Forty2 [1] or Verona [2] isolation, which let us choose between arenas and GC for isolated subgraphs. Combining that with some annotations could be a real home run. I think Cone [3] was going in this direction for a while.

* Val's simplified borrowing (mutable value semantics [4]) combined with some form of mutable aliasing (like in the article!).

* Rust does this with its Rc/RefCell, though it doesn't compose with the borrow checker and RAII as well as it could, IMO.

[0] https://verdagon.dev/blog/zero-cost-borrowing-regions-part-1... (am author)

[1] http://forty2.is/

[2] https://github.com/microsoft/verona

[3] https://cone.jondgoodwin.com/

[4] https://www.jot.fm/issues/issue_2022_02/article2.pdf

Their approach lines up pretty well with how we do regions in Vale. [0]

Specifically, we consider the "spine" of a linked list to be its own private "region", separate from the elements' region. This lets us freeze the spine region, while keeping the elements region mutable.

This mechanism is particularly promising because it likely means one can iterate over a collection with zero run-time overhead, without the normal restrictions of a more traditional Rust/Cyclone-like borrow checker. We'll know about this iterating benefit for sure when we finish part 3 (one-way isolation [1]); part 1 landed in the experimental branch only a couple weeks ago [2].

The main difference between the two approaches is that Vale doesn't assume that all elements are self-isolated fields, it allows references between elements and even references to the outside world. However, this does mean that Vale sometimes needs "region annotations", whereas the paper's system doesn't need any annotations at all, and that's a real benefit of their method.

Other languages are experimenting with regions too, such as Forty2 [3] and Verona [4] though they're leaning more towards a garbage-collection-based approach, where Vale is more like a memory-safe C++.

Pretty exciting time for languages!

[0] https://verdagon.dev/blog/zero-cost-borrowing-regions-overvi...

[1] https://verdagon.dev/blog/zero-cost-borrowing-regions-part-3...

[2] https://verdagon.dev/blog/regions-prototype

[3] http://forty2.is/

[4] https://github.com/microsoft/verona

Verona has been exploring the idea of "behavior-oriented programming" as compared to "actor-oriented" like we have in Pony.

Verona's model allows for something along the lines of what is being suggested. How that works out in the long run, we'll see. It's still very early days for Verona.

A number of folks working on Pony also are associated with Verona and vice-versa so there's a cross-polination of ideas going on.

https://github.com/microsoft/verona

In particular see:

https://github.com/microsoft/verona/blob/master/docs/explore...

and

https://github.com/microsoft/verona/blob/master/docs/explore...

Microsoft has Rust bindings for WinRT and I think some internal tools at Azure. But Microsoft has a long history of creating programming languages for every niche, so they'll probably make one in the tradition of Rust.

https://github.com/microsoft/verona

If they want to use Rust, and have more faith in it than their own Verona[1], then they should discontinue Verona dev and let those developers go back to Pony[2]. I imagine having their core team working on Verona full-time is considerably delaying Pony development.

[1] - https://github.com/microsoft/verona

[2] - https://github.com/ponylang/ponyc

(edit: formatting)

As much as I appreciate what Microsoft is doing here, your NIH praise is not entirely well targeted - look at this research project from Microsoft, which aims to build a slightly different Rust. https://github.com/microsoft/verona
There's also Project Verona [0], a research project inspired by Rust, Cyclone and Pony.

[0]: https://github.com/microsoft/verona