3 ms·

> Statically compiled. Statically typed. Interops with C++. Memory safe. Typesafe. Data-race-free. So it is for C++ what rust is for C?

tialaramex 3y ago
Val has a similar but different strategy to the big problem as Rust. In Rust the reference semantics are lifetime checked (hence all the talk about a "borrow checker") but in Val there are no reference semantics. In Rust there are some things you can't (safely) do because the checker can't see why they're ok. Val guesses that, with appropriate language features in place, you can extend that to everything and still have a useful language but now you don't need to teach this complicated and difficult feature. Because Val is young it's not yet obvious whether this is basically always better, or whether it's too limited.
- _a_a_a_ 3y ago
  The a typing feature[1] in the language Eiffel was based on the assumption of the author that the typing holes it apparently introduced could be statically detected. It turned out he was wrong after the language was released IIRC. I guess you have to be pretty certain of something before basing a language around it. On top of that being a generally shite language doomed Eiffel. [1] IIRC again, you could cancel features in subtypes, so "all birds can fly" but "penguins are birds but can't fly". That would break the Liskov Substitution Principle, which Bertrand Meyer thought he could deal with but apparently couldn't.
  - pjmlp 3y ago
    May many languages be as successful as Eiffel is. Eiffel Software is still in business, whereas many others hardly reach any audience.
    - Tozen 3y ago
      Very true. So many languages people haven't heard of. It's like if not in the top 10 or 20, some think they don't matter. In regards to Eiffel, always felt that hindrance to wider adoption was more about the licensing. Still, they are in business and in use.
    - mardifoufs 3y ago
      I know it is used in education in some parts of Europe. But now I'm wondering, is it used in production? Or rather, does it have a niche or an industry where it is more widely used? I'd be curious to know what software is written in Eiffel! (Mainly to get an idea of what Eiffel source code looks like, beyond toy examples)
- AnimalMuppet 3y ago
  > Because Val is young it's not yet obvious whether this is basically always better, or whether it's too limited. This is sound wisdom. It's not always obvious at the beginning what the limitations are going to be, and what the opportunities are going to be. If it's a promising direction, pursue it, even though it won't always work out.
- nine_k 3y ago
  Since Val seems to be liable to infer more about the actual data flow, I wonder how does it reflect on compile times.
- phatskat 3y ago
  As someone generally not in the loop on these kinds of languages, what is the “big problem”?
  - tialaramex 3y ago
    If another function / sub-routine / thread / whatever alters this Thing while I'm looking at it, lots of nasty surprises await. For example maybe the Thing is a container of Objects and I was looping over it, taking out one object at a time and sometimes calling unrelated_function() but for some reason unrelated_function destroys the Thing occasionally and then... Boom, use-after-free. It turns out that although we've often thought of this as a variety of different hard problems, including "data races" and "use after free", they're actually all one big problem, that of mutating something while somebody else used it. Solving this effectively solves all of those hard problems, at least in a subset of your language where you are able to address it. In a language like C or C++ it's easy to make one or more references to a Thing, and then give away the references, or the Thing, or both, and then the programmer loses track (or maybe never knew they were related) and these nasty surprises are their reward. In Rust, their borrowing / lending metaphor prevents the surprise. If you lend a mutable reference to the Thing, the borrower can't destroy it, that's not what "lending" means, and you can't even use it until they've stopped borrowing it. If you lend immutable references, nobody can destroy it, or mutate it at all, until all those references are given back. But this does make the language more complicated because of the new metaphor. In Val, you can't have any references, so unrelated_function couldn't destroy Thing, you've got Thing, so unrelated_function doesn't have Thing and can't destroy it. No surprises.
    - gsliepen 3y ago
      And of course the trick is to avoid the nasty surprises and do do it in such a way that is still is easy to program. If you can only do it by adding additional hoops for a programmer to jump through (like having to annotate all your function parameters with lifetimes), it's not ideal. Val's subscripts are a nice idea; they make writing a function that returns a reference quite easy. On the other hand, it doesn't look as flexible as a regular function, so maybe it has the same amount of hoops, just different ones.
KingLancelot 3y ago
[dead]
sharts 3y ago
I thought it was that Go is to C what Rust is to C++? This seems like another animal altogether.
- jacquesm 3y ago
  Rust is very much aimed at the same space of Go where Go can be used to replace C. I'd argue Rust is more aimed at the C space than the C++ space because of its accent on systems programming.

tialaramex 3y ago

Val has a similar but different strategy to the big problem as Rust. In Rust the reference semantics are lifetime checked (hence all the talk about a "borrow checker") but in Val there are no reference semantics. In Rust there are some things you can't (safely) do because the checker can't see why they're ok. Val guesses that, with appropriate language features in place, you can extend that to everything and still have a useful language but now you don't need to teach this complicated and difficult feature. Because Val is young it's not yet obvious whether this is basically always better, or whether it's too limited.

_a_a_a_ 3y ago
The a typing feature[1] in the language Eiffel was based on the assumption of the author that the typing holes it apparently introduced could be statically detected. It turned out he was wrong after the language was released IIRC. I guess you have to be pretty certain of something before basing a language around it. On top of that being a generally shite language doomed Eiffel. [1] IIRC again, you could cancel features in subtypes, so "all birds can fly" but "penguins are birds but can't fly". That would break the Liskov Substitution Principle, which Bertrand Meyer thought he could deal with but apparently couldn't.
- pjmlp 3y ago
  May many languages be as successful as Eiffel is. Eiffel Software is still in business, whereas many others hardly reach any audience.
  - Tozen 3y ago
    Very true. So many languages people haven't heard of. It's like if not in the top 10 or 20, some think they don't matter. In regards to Eiffel, always felt that hindrance to wider adoption was more about the licensing. Still, they are in business and in use.
  - mardifoufs 3y ago
    I know it is used in education in some parts of Europe. But now I'm wondering, is it used in production? Or rather, does it have a niche or an industry where it is more widely used? I'd be curious to know what software is written in Eiffel! (Mainly to get an idea of what Eiffel source code looks like, beyond toy examples)
AnimalMuppet 3y ago
> Because Val is young it's not yet obvious whether this is basically always better, or whether it's too limited. This is sound wisdom. It's not always obvious at the beginning what the limitations are going to be, and what the opportunities are going to be. If it's a promising direction, pursue it, even though it won't always work out.
nine_k 3y ago
Since Val seems to be liable to infer more about the actual data flow, I wonder how does it reflect on compile times.
phatskat 3y ago
As someone generally not in the loop on these kinds of languages, what is the “big problem”?
- tialaramex 3y ago
  If another function / sub-routine / thread / whatever alters this Thing while I'm looking at it, lots of nasty surprises await. For example maybe the Thing is a container of Objects and I was looping over it, taking out one object at a time and sometimes calling unrelated_function() but for some reason unrelated_function destroys the Thing occasionally and then... Boom, use-after-free. It turns out that although we've often thought of this as a variety of different hard problems, including "data races" and "use after free", they're actually all one big problem, that of mutating something while somebody else used it. Solving this effectively solves all of those hard problems, at least in a subset of your language where you are able to address it. In a language like C or C++ it's easy to make one or more references to a Thing, and then give away the references, or the Thing, or both, and then the programmer loses track (or maybe never knew they were related) and these nasty surprises are their reward. In Rust, their borrowing / lending metaphor prevents the surprise. If you lend a mutable reference to the Thing, the borrower can't destroy it, that's not what "lending" means, and you can't even use it until they've stopped borrowing it. If you lend immutable references, nobody can destroy it, or mutate it at all, until all those references are given back. But this does make the language more complicated because of the new metaphor. In Val, you can't have any references, so unrelated_function couldn't destroy Thing, you've got Thing, so unrelated_function doesn't have Thing and can't destroy it. No surprises.
  - gsliepen 3y ago
    And of course the trick is to avoid the nasty surprises and do do it in such a way that is still is easy to program. If you can only do it by adding additional hoops for a programmer to jump through (like having to annotate all your function parameters with lifetimes), it's not ideal. Val's subscripts are a nice idea; they make writing a function that returns a reference quite easy. On the other hand, it doesn't look as flexible as a regular function, so maybe it has the same amount of hoops, just different ones.

KingLancelot 3y ago

[dead]

sharts 3y ago

I thought it was that Go is to C what Rust is to C++? This seems like another animal altogether.

jacquesm 3y ago
Rust is very much aimed at the same space of Go where Go can be used to replace C. I'd argue Rust is more aimed at the C space than the C++ space because of its accent on systems programming.