hylo VS effekt

Or Val[0], now called Hylo (for a good reason), or V[1].

[0] https://www.hylo-lang.org

The evolution of C++ has been a multi-decade history of dealing with difficult reality.

I have great hope that Herb can create with his cppfront project “The Very Best of C++” to carry that tremendous legacy forward.

If I was to throw my hat into a “C++ successor”, it would be https://www.hylo-lang.org/ with its “all the safeties” and “tell you when you’re doing it sub-optimal” approach.

Paper: https://2023.splashcon.org/details/iwaco-2023-papers/5/Borro...

> Hylo is a language for high-level systems programming that promises safety without loss of efficiency. It is based on mutable value semantics, a discipline that emphasizes the independence of values to support local reasoning. The result—in contrast with approaches based on sophisticated aliasing restrictions—is an efficient, expressive language with a simple type system and no need for lifetime annotations.

> Safety guarantees in Hylo programs are verified by an abstract interpreter processing an intermediate representation, Hylo IR, that models lifetime properties with ghost instructions. Further, lifetime constraints are used to eliminate unnecessary memory allocations predictably.

https://www.hylo-lang.org/

https://github.com/Hylo-lang/Hylo

A model without lifetimes is also being explored in other languages, e.g. in Hylo. It sacrifices expressiveness, but on the other hand you don't have to deal with explicit lifetimes!

Why go through all the trouble when you can do this: https://www.hylo-lang.org/ and not spend a second thinking of lifetimes? No, copies will not be issued unless necessary.

Or why not keep exploring this idea as well? More research-oriented than the first one right now, though, so take it with a grain of salt: https://vale.dev/

Get rid of references at the cost of some expressivity (see Hylo, formerly Val)

I like it. Modern languages that distinguish between pure and impure programs like Flix, Koka, and Effekt do so on the type level instead of syntactically. This has three advantages:

The problem with checked exceptions been identified and solved. The same problem and solution applies to effect handlers. Effekt is a language with lexical effect handlers which doesn't have this problem. Consider the following program in Effekt:

Yes, for you this is the right decision. But for us going to CPS makes everything significantly easier and in cases where you do use control effects significantly faster. For our language Effekt we are exploring different tradeoffs in different backends.

This pattern they observe is nicely captured by effect handlers. These examples are written in Effekt.

This is beyond my level of expertise. But effect tracking? There are some cool languages out there that do that consistently! Search for "algebraic effects". My favorite is Koka. Effekt also seems to be a popular choice.

https://effekt-lang.org/ A research language with effect handlers and lightweight effect polymorphism

Examples are languages like Koka, Effekt, Links, or Unison. These languages come with a type-and-effect system: a function's type not only tell you which values the function accepts and which values it returns, but also which effects it has. This is relevant to your question, because throwing an exception is one such effect.

It seems that with Effekt we are pursuing the same goal, but coming from the opposite direction, perhaps one day we will meet in the middle :). We start from a purely functional language and carefully add effects like mutation.

- https://effekt-lang.org/