Really hoping this project gets more traction.<p>I'm learning Elm now and I'm really liking the syntax to the level that other languages feel rather cluttered to me now.<p>The more I'm playing with types and learning to leverage them, the more I appreciate their power (yes, I'm late to the game) so making this statically typed is very interesting.<p>However, there seem to be a saturation of new languages and not sure if there is enough eyeballs left for a new language that does not have a large corporate backing (FB, Google, Apple) or happens not to arrive on a perfect time with the right set of answers. Maybe BEAM, ML/Elm syntax and static typing is what everyone else is looking for.<p>Edit:
Video posted today of creator of Alpaca (Jeremy Pierre) giving a talk at Erlang Factory. It gives a nice overview of the state of the language -<p><a href="https://www.youtube.com/watch?v=cljFpz_cv2E" rel="nofollow">https://www.youtube.com/watch?v=cljFpz_cv2E</a>
I continue to be believe even as a static typing fan that static types are fundamentally incompatible with OTP and it's goals.<p>Distributed systems just seem to too thorny for static types to subjugate/bend to their will.<p>Sure, you can declare global invariants ahead of time that your cluster must uphold, but it's a bit less "distributed" in a real sense then
I think this is great news for the Erlang VM: while you wouldn't want to use static typing for any program you write, there is a very specific use-case where you definitely want to do that: embedding business logic in your application.<p>I've been there, done that: encoding business rules in Erlang is no fun, hard to test, and definitely hard to read and modify later. In this particular domain the constraint of types does not slow you down, in fact, it speeds up development. A large amount of unit tests can become unnecessary just because of the type checking. And the more expressive your type system, the fewer tests you need - and the code and the remaining tests can concentrate on validating business logic instead of validating programming language logic ("here is a map - do I have a value with key X in it?" - maybe a bad example because of pattern matching, but I hope you get the idea).<p>You definitely have to be able to interface with OTP, but I don't see it as a huge problem - parts of your application could and should be written in Erlang, there is nothing wrong with that.
I am intrigued by this snippet from the README:<p><pre><code> type messages 'x = 'x | Fetch pid 'x
</code></pre>
This appears to define a sum type where one of the variants is left with an implicit constructor. How do you pattern match on that? How do you do type inference?
Can anyone explain why it seems like so many new languages are reinventing things that seemingly have little effect, but they seem to be changing them "just because"<p>We have comments in code for decades now. // and /* */ are easily the bigest standard, with # coming in second. Why '--' in this language? Why "``" in another language i saw recently?<p>I cant imagine this gives any real benifit to the coder or the compiler, and it seems to be more difficult because now the IDEs have to be configured for a(nother) new comment type, it has be become muscle memory again, its yet another "common ground" peice of code that requires context switching to change between languages...<p>I get doing new things with the functional features of a language, im all for trying new things and seeing what works... just seems wierd to have so many ways to comment code... such an insignificant part, why change?
There's also purerl [0], an Erlang backend for PureScript. Would be cool if the two projects could join forces.<p>[0] - <a href="https://github.com/purerl/purescript" rel="nofollow">https://github.com/purerl/purescript</a>
Related discussion from last year: <a href="https://news.ycombinator.com/item?id=11992773" rel="nofollow">https://news.ycombinator.com/item?id=11992773</a>.