4 ms·

It's kind of hard to decode the explanation given that it spends a lot of text on useless formalism instead of substance, but it seems like this language has th

by devit 6y ago

It's kind of hard to decode the explanation given that it spends a lot of text on useless formalism instead of substance, but it seems like this language has three fatal problems: 1. Borrowed pointers are not a first class concept, but just syntax sugar over returning a parameter from a function, i.e. &T or &mut T are not actual types in Rust parlance 2. There is no mention on how to achieve safe shared mutable data or even just shared read-only data, i.e. the equivalent of Rust's Arc<Mutex<T>> or Arc<T>, which probably means the language has no support 3. It seems there is no way for a struct/record/tuple to contain another non-primitive data type without the latter being allocated on the heap So as far as I can tell aside from the dependent types this language is much less powerful than Rust and cannot fully utilize the CPU, and hence far from the goal of having a perfect Rust+dependent types language.

h-cobordism 6y ago
I'm pretty sure you're right on all counts; I'm not even sure that shared immutable borrows would work under the very simple transform given in the README. Edit: Also, the user-facing language doesn't seem to have linearity at all, i.e. all values may be cloned. But linearity is something that people use to guarantee certain invariants all the time in Rust (and ATS, I've heard), so this seems like a misstep. It also means that memory allocation is implicit, which makes things less predictable for users.
- ferzul 6y ago
  yes, i found the first example quite surprising. there doesn't seem to be any request to copy the string; it is simply unintuively copied/produced three times. i would prefer the language have some kind of `dup` or something, which gives you an additional reference to the object. as it stands, it has transferred allocation from the runtime to the compiler. but the objective is to put it into the hands of the developer, since only then is it known when reading and writing code. i begin to suspect that a typed joy may be more practical (or rather: match my desired improvements) than clarifying allocations in haskell.
_bxg1 6y ago
I don't think it aims to be "as powerful as Rust", and I think that's okay. It's decidedly a narrow, pure, opinionated language, while Rust has practicality as one of its main priorities. This language is more like Haskell, or even more Haskell than Haskell, in that while some people might want to do real projects in it, its main purpose (from what I can tell) is to explore a concept. Nothing wrong with that.
amelius 6y ago
From a Rust perspective, this may be true. But from a Haskell perspective, this language promises to completely eliminate the garbage collector, which is a big deal.
- _bxg1 6y ago
  Is it something that could potentially be back-ported to Haskell and friends? I'm afraid it was a bit over my head too
  - amelius 6y ago
    Well, they say that: > Practically, this means that you can write your program in the ordinary lambda-calculus without any extra restrictions or annotations, and at the same time are allowed to control how resources are used in the program. You can rewrite any Haskell program into the ordinary lambda-calculus, and this can be automated. The only possible problem might be that Haskell uses lazy evaluation, and I don't expect this to interfere with the control of resources but I could be wrong.
    - _bxg1 6y ago
      Haskell also allows you to share heap-allocated immutable data structures between threads, right? I think someone said this language doesn't support reference sharing across threads, but that could've been wrong
      - amelius 6y ago
        Yes, indeed threads could be problematic. But as long as you're not storing closures in those shared data-structures, these structures will always be acyclic, and could be collected through simple reference counting. Perhaps that's an acceptable compromise.
        ferzul 6y ago
        isn't: let x = 1:x cyclic, but without closure? unless closure is so broad as to capture essentially any haskell value. it's not going to be obvious when there is a cyclic reference (e.g. if you use `let x = repeat 1` instead of the definition above)
voxl 6y ago
Just because you're not capable of interpreting the formalism doesn't make it useless or not substantive. This readme wasn't written for you it was written for a type theorist.
- zozbot234 6y ago
  Eh, I'm not sure about that. A type theorist would expect to see a clear description of what translations are performed as part of compiling this language, and a rigorous argument that this helps solve a real issue, e.g. wrt. memory management. It's hard to see either in the linked readme - it reads like a description of some promising, rough experiment, but not quite fully worked out in a way that would make it clearly understandable to uninvolved folks. I'm not saying that there's anything wrong with that, and it's definitely on par with many Show HN's. Just trying to call for some perspective.
- _bxg1 6y ago
  The parent comment comes off as arrogant but so does this one. Oftentimes concepts like these are presented in language that's more impenetrable than necessary. I don't know if that's true here but it's a genuine problem.
noelwelsh 6y ago
You could have easily made a comment with the same substance without the arrogance.
matvore 6y ago
Why should any of what you talk about be the responsibility of the language as opposed to the linter, an annotation library and static analyzer, a library, or clean design? Remember the Unix philosophy.
- the_why_of_y 6y ago
  The results of that philosophy in terms of CVEs shipped to end users can be seen on https://www.cvedetails.com/vulnerability-list.php?vendor_id=0&product_id=0&version_id=0&page=107&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=1&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=5339 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
  - matvore 6y ago
    So you have linked me to a list of security vulnerabilities - are you suggesting all security vulnerabilities need to be addressed by the language spec and the compiler? I doubt such a wide and diverse range of problems be addressed at such a low level. At a glance, most of those look like bounds checking problems. tcc (Tiny C Compiler) allows you to compile in bounds-checking with all pointer dereferences. C++ STL implementations generally have bounds checking all over the place - this requires compiling in debug mode IIRC, but it is evidence of the possibilities of safety without language or compiler support. Lisp-style meta-programming can get you basically anything you want from a language without language or compiler support.
    - the_why_of_y 6y ago
      > So you have linked me to a list of security vulnerabilities - are you suggesting all security vulnerabilities need to be addressed by the language spec and the compiler? These vulnerabilities are typically in code implemented in C or C++. I am suggesting that if you want to have a secure system, they have to be addressed by the language; if you are happy with systems that have exploitable memory management bugs, there are lots of existing UNIX variants to choose from. > I doubt such a wide and diverse range of problems be addressed at such a low level. May I suggest reading about some low-level languages that have been used in production and address these problems to varying degrees of success, for example ESPOL (from 1960s), Mesa/Cedar, Modula-2, Ada, or Rust. https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language https://en.wikipedia.org/wiki/Executive_Systems_Problem_Orie... > tcc (Tiny C Compiler) allows you to compile in bounds-checking with all pointer dereferences. This sounds impossible, there's not enough information in the C type system to know in the general case what the bounds are. > C++ STL implementations generally have bounds checking all over the place This wasn't true last I checked for libc++ (the most "modern" implementation), and isn't applicable for any non-STL container in a program anyway; nothing prevents using a plain C array. > this requires compiling in debug mode IIRC I'm not aware of anybody who enables this in production because the culture of C++ is all about performance. > but it is evidence of the possibilities of safety without language or compiler support Language or compiler support would reduce the performance overhead, because it makes it easier for the compiler to elide checks that can be statically proven to always succeed. > Lisp-style meta-programming can get you basically anything you want from a language without language or compiler support. Meta-programming cannot remove features from a language, which is typically the problem here.

by devit 6y ago

h-cobordism 6y ago

I'm pretty sure you're right on all counts; I'm not even sure that shared immutable borrows would work under the very simple transform given in the README. Edit: Also, the user-facing language doesn't seem to have linearity at all, i.e. all values may be cloned. But linearity is something that people use to guarantee certain invariants all the time in Rust (and ATS, I've heard), so this seems like a misstep. It also means that memory allocation is implicit, which makes things less predictable for users.

ferzul 6y ago
yes, i found the first example quite surprising. there doesn't seem to be any request to copy the string; it is simply unintuively copied/produced three times. i would prefer the language have some kind of `dup` or something, which gives you an additional reference to the object. as it stands, it has transferred allocation from the runtime to the compiler. but the objective is to put it into the hands of the developer, since only then is it known when reading and writing code. i begin to suspect that a typed joy may be more practical (or rather: match my desired improvements) than clarifying allocations in haskell.

_bxg1 6y ago

I don't think it aims to be "as powerful as Rust", and I think that's okay. It's decidedly a narrow, pure, opinionated language, while Rust has practicality as one of its main priorities. This language is more like Haskell, or even more Haskell than Haskell, in that while some people might want to do real projects in it, its main purpose (from what I can tell) is to explore a concept. Nothing wrong with that.

amelius 6y ago

From a Rust perspective, this may be true. But from a Haskell perspective, this language promises to completely eliminate the garbage collector, which is a big deal.

_bxg1 6y ago
Is it something that could potentially be back-ported to Haskell and friends? I'm afraid it was a bit over my head too
- amelius 6y ago
  Well, they say that: > Practically, this means that you can write your program in the ordinary lambda-calculus without any extra restrictions or annotations, and at the same time are allowed to control how resources are used in the program. You can rewrite any Haskell program into the ordinary lambda-calculus, and this can be automated. The only possible problem might be that Haskell uses lazy evaluation, and I don't expect this to interfere with the control of resources but I could be wrong.
  - _bxg1 6y ago
    Haskell also allows you to share heap-allocated immutable data structures between threads, right? I think someone said this language doesn't support reference sharing across threads, but that could've been wrong
    - amelius 6y ago
      Yes, indeed threads could be problematic. But as long as you're not storing closures in those shared data-structures, these structures will always be acyclic, and could be collected through simple reference counting. Perhaps that's an acceptable compromise.
      - ferzul 6y ago
        isn't: let x = 1:x cyclic, but without closure? unless closure is so broad as to capture essentially any haskell value. it's not going to be obvious when there is a cyclic reference (e.g. if you use `let x = repeat 1` instead of the definition above)

voxl 6y ago

Just because you're not capable of interpreting the formalism doesn't make it useless or not substantive. This readme wasn't written for you it was written for a type theorist.

zozbot234 6y ago
Eh, I'm not sure about that. A type theorist would expect to see a clear description of what translations are performed as part of compiling this language, and a rigorous argument that this helps solve a real issue, e.g. wrt. memory management. It's hard to see either in the linked readme - it reads like a description of some promising, rough experiment, but not quite fully worked out in a way that would make it clearly understandable to uninvolved folks. I'm not saying that there's anything wrong with that, and it's definitely on par with many Show HN's. Just trying to call for some perspective.
_bxg1 6y ago
The parent comment comes off as arrogant but so does this one. Oftentimes concepts like these are presented in language that's more impenetrable than necessary. I don't know if that's true here but it's a genuine problem.

noelwelsh 6y ago

You could have easily made a comment with the same substance without the arrogance.

matvore 6y ago

Why should any of what you talk about be the responsibility of the language as opposed to the linter, an annotation library and static analyzer, a library, or clean design? Remember the Unix philosophy.

the_why_of_y 6y ago
The results of that philosophy in terms of CVEs shipped to end users can be seen on https://www.cvedetails.com/vulnerability-list.php?vendor_id=0&product_id=0&version_id=0&page=107&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=1&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=1&trc=5339 https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
- matvore 6y ago
  So you have linked me to a list of security vulnerabilities - are you suggesting all security vulnerabilities need to be addressed by the language spec and the compiler? I doubt such a wide and diverse range of problems be addressed at such a low level. At a glance, most of those look like bounds checking problems. tcc (Tiny C Compiler) allows you to compile in bounds-checking with all pointer dereferences. C++ STL implementations generally have bounds checking all over the place - this requires compiling in debug mode IIRC, but it is evidence of the possibilities of safety without language or compiler support. Lisp-style meta-programming can get you basically anything you want from a language without language or compiler support.
  - the_why_of_y 6y ago
    > So you have linked me to a list of security vulnerabilities - are you suggesting all security vulnerabilities need to be addressed by the language spec and the compiler? These vulnerabilities are typically in code implemented in C or C++. I am suggesting that if you want to have a secure system, they have to be addressed by the language; if you are happy with systems that have exploitable memory management bugs, there are lots of existing UNIX variants to choose from. > I doubt such a wide and diverse range of problems be addressed at such a low level. May I suggest reading about some low-level languages that have been used in production and address these problems to varying degrees of success, for example ESPOL (from 1960s), Mesa/Cedar, Modula-2, Ada, or Rust. https://en.wikipedia.org/wiki/Executive_Systems_Problem_Oriented_Language https://en.wikipedia.org/wiki/Executive_Systems_Problem_Orie... > tcc (Tiny C Compiler) allows you to compile in bounds-checking with all pointer dereferences. This sounds impossible, there's not enough information in the C type system to know in the general case what the bounds are. > C++ STL implementations generally have bounds checking all over the place This wasn't true last I checked for libc++ (the most "modern" implementation), and isn't applicable for any non-STL container in a program anyway; nothing prevents using a plain C array. > this requires compiling in debug mode IIRC I'm not aware of anybody who enables this in production because the culture of C++ is all about performance. > but it is evidence of the possibilities of safety without language or compiler support Language or compiler support would reduce the performance overhead, because it makes it easier for the compiler to elide checks that can be statically proven to always succeed. > Lisp-style meta-programming can get you basically anything you want from a language without language or compiler support. Meta-programming cannot remove features from a language, which is typically the problem here.