I see!
Still wondering what you could do in Cure that you couldn’t do in Gleam. Apparently I have my head wrapped around ADTs but not GADTs. Would Cure vs Gleam be a question of the complexity of the domain?
eileennoonan
AstonJ
I haven’t looked at Cure or Gleam in any great detail but the most obvious difference to me is syntax - Cure has def ends which is much more like Elixir. It does also look like @mudasobwa is targeting Cure as a complementary tool to Elixir and Phoenix:
So for instance as per your example:
In specialist cases where Elixir might not be a good fit Elixir users might opt for Cure because its syntax is familiar/more in line with their taste. Those who like Rust/ML languages might opt for Gleam (IIRC Gleam’s syntax was inspired by Rust/ML languages).
Ultimately each language has to carve a space for itself and syntax is an important and deciding factor (as is general philosophy and USP). I wish both Cure and Gleam all the best - if they can bring more people to the BEAM, great!
One thing I would add which I have said elsewhere on the forum is that due to the advancement of LLMs I think it will be harder for the newer languages to gain traction, so if Cure really is designed to complement Elixir (rather than be a competitor to it) it could be a very smart move…
2
matt-savvy
Onor.io
I may be incorrect but dependently typed languages (of which Cure is one) allow a developer to far more tightly constrain the type checking done by the compiler. The canonical example is a Vector. If I type something as a Vector I have no way of constraining its size. Dependently typed allows me to create a type which is Vector of a specific size. It also allows me to specify types of functions (for example AddToVector) with the notation that the result will be a Vector (or whatever type) plus the added elements. The compiler can then try to see if there is any code which violates that constraint. I’m not as versed in CS as I’d like to be–I think there may be some reasons that it cannot be checked in certain cases but I may be remembering incorrectly.
I think the main concern about dependently typed is performance but I’m sure someone will correct me if I’ve gotten that point (or any of the others) wrong! 
3
lpil
Creator of Gleam
I don’t think this is the case. From reading the documentation it seems that both have static type systems, but that’s where the similarities end. Gleam and Elixir have much more in common than Gleam and Cure do.
Compared to the stated features of Cure’s website Gleam offers very little in terms of static-analysis enforced correctness. If Cure’s static analysis functionality is a fighter jet then Gleam’s is a paper plane!
It will be interesting to see how the language develops. Both dependent types and SMT verification are active open areas of computer science research, and while useful and extremely powerful, how to make either of them approachable and productive in a language is an unsolved problem. Idris may be the most successful project there for dependant types, but even then it is a very challenging language to learn and write.
I couldn’t find any documentation on these features in Cure, and I wasn’t able to get any of the examples to compile and run, so I can’t say anything specific about their approach. I’m looking forward to seeing more as the language matures!
Dependant types are very slow to compile, however at runtime they can be used to produce significantly improved performance, as the compiler knows much more about the program. Unfortunately this benefit is likely not possible for Cure, as the BEAM doesn’t permit the programmer to disable runtime type checking. If it did Gleam could do that, making it substantially faster than Erlang or Elixir!
5
Schultzer
I have a hard time believing this to be true, unless you’re thinking about cases where users are writing suboptimal code with a ton of unnecessary guards and pattern matching.
Can you give a more concrete example where the compiler lacks, bonus point if you throw some BEAM assembly in there too! 
0
lpil
Creator of Gleam
It’s not that the compiler is lacking at all, it’s just a property of the sort of virtual machine that the BEAM is. All operations on such a virtual machine will check the type tag of the values given to them and raise an error if the types are not appropriate for the operation. The cost of this checking is small, but since it applies to every single operation it ends up having a significant impact on performance. Systems that do not have these checks (e.g. C, OCaml, Chez Scheme with checks disabled) have greater performance in this area.
Erlang’s JIT compiler is really pretty good, and when it’s type analysis can infer that the data will always be of a specific type (such as there being guards at the level above) it will emit code that doesn’t do any runtime checks! This is a big part of why the JIT is so fast.
Understanding all the possible shapes the data can have at runtime is a hard requirement for omitting these runtime checks, and Erlang’s static type analysis is very limited, so unfortunately this optimisation cannot be applied often. Other BEAM languages such as Gleam and Purerl (and presumably Cure!) have total and perfect type analysis, so theoretically they could apply the optimisation to the entire program, but there is no way to do this on the BEAM.
2
Schultzer
I’m looking forward to seeing this being push upstream, I’m sure with the upcoming type system then there would be more reasons to improve the compiler in a way that it could take advantage of this information.
0
lpil
Creator of Gleam
Elixir’s type system is a fantastic bit of engineering and very useful, but I am sceptical that it’d be able to provide information that the BEAM’s static analysis cannot. Elixir’s type system is gradual, so intentionally not total, while the BEAM’s static analysis is designed for this specific task.
The OTP team won’t ever accept anything other than total confidence in the type analysis, and we won’t ever have a “just trust me!” style API as found in Chez Scheme. It’ll always be based upon what can be inferred from the Erlang or the bytecode, and any extra information from 3rd party static analysis could not be used.
0
AstonJ
Do you mean syntax or how it works under the hood? Syntax-wise Cure appears to be a lot more like Elixir - in the same way Elixir was a lot like Ruby, and Elixir being different under the hood did not impede adoption of it from the Ruby community*, in fact given a very large number of Elixir’s earliest adopters were from Ruby does suggest my hypothesis, that syntax matters, may be correct.
I had a whole section on syntax in my What’s special about Ruby blog post. Syntax mattering may be more important to those who have an eye for aesthetics and feel (so those who tend to like languages like Ruby and Elixir).
*Just for clarity’s sake I don’t think people will leave Elixir for Cure, but rather may opt for it when there is a tangible specialised need for it.
1