
Alpaca – Functional programming inspired by ML for the Erlang VM - knv
https://github.com/alpaca-lang/alpaca/
======
salimmadjd
Really hoping this project gets more traction.

I'm learning Elm now and I'm really liking the syntax to the level that other
languages feel rather cluttered to me now.

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.

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.

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 -

[https://www.youtube.com/watch?v=cljFpz_cv2E](https://www.youtube.com/watch?v=cljFpz_cv2E)

~~~
jerf
There's always room for another language.

What's hard is cracking into the very, very top tier, the C++, C#, Java, etc.
tier. I am also increasingly of the opinion that it simply takes massive
corporate backing to get to that level, based on the observation that I
haven't seen anything get to that level without it. Python's the only one that
has arguably gotten there, I think, and it's still debatable.

That said, I do think that if you want to make a new language right now and
really see it take off, you do need to find some problem that isn't well-
solved, or come up with a _reeaaalllly_ novel combination of things that
didn't exist well before. It seems to me that this project is going to be
shadowed by Haskell in a lot of ways.

But that's only _if_ you want to see it take off. Not all languages are put
out there with that intent.

~~~
spraak
I'd love to have something that takes the best of Go (static typing, fast
compiles, binaries, community) and functional paradigm.

~~~
jerf
Ocaml is close. Not sure how their concurrency is going, but I'm sure the act
of mentioning that will bring someone out to bring us up to date.

~~~
Athas
Compared to Go, OCaml is unfortunately a rather large language. It has many
non-orthogonal features, some of which are not used widely. The impression I
get from Go programmers is that the small size of the language is one of the
chief attractors.

~~~
jnbiche
> Compared to Go, OCaml is unfortunately a rather large language.

I agree. That said, ML is definitely a small language like Go, without OCaml's
extras like the object system.

Alas, ML lacks Go's awesome and very modern standard library, which is a key
part of Go's allure.

But yes, I would adore a functional language with Go's best features,
particularly the standard library, solid concurrency, simplicity/ease-of-
learning, fast compiles, binaries, static, etc.

------
platz
I continue to be believe even as a static typing fan that static types are
fundamentally incompatible with OTP and it's goals.

Distributed systems just seem to too thorny for static types to subjugate/bend
to their will.

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

~~~
sgrove
Would you mind elaborating, or sharing some papers on the subject? I'm
particularly interested in a dialect of ReasonML that would use the
BuckleScript compiler + ConcurrentML but target the BEAM VM, and I'd love to
know how bad of an idea it might be. Maybe because it lacks e.g. session types
it's hopeless, but I'm not sure.

So, would love to hear specifics!

~~~
platz
There are parts of OTP patterns that seem inherently dynamic. Message passing
is only one aspect. There are also deployment/upgrade concerns with a running
system.

Actors can receive messages that change their behavior entirely (
[http://erlang.org/doc/man/gen_server.html](http://erlang.org/doc/man/gen_server.html)
). Features like this are not there by accident.

Actors can hot-upgrade code their dynamically while the process is running.
For example, if an actor is hot-upgrading I'm not sure how it would work, if
the types of the old state and the new state don't exactly match. Sure, you
could write functions to do this, but you see the picture is much more
complicated.

I don't think I've presented the best arguments off the top of my head here
here, but if you think more about the deployment/upgrade scenarios, along with
partial updates along in certain nodes of the system, you can think about how
complex it could get.

Basically, never assume that you get to take the whole cluster down to do an
upgrade. Comprehensive "red/black" deployment strategies used by other non-
distributed languages are not really the OTP way of doing deployment/upgrades.

~~~
sitkack
I have version N of a struct and then having version N+1 of a struct in-flight
at the same time is almost impossible with current statically typed languages.
In a dynamically typed language, as long as the contents of version N+k struct
are additive and don't change the semantics, old code can read new data.

What needs to happen is both, immutable code, and versioned structs with pure
functions that can upgrade and possibly downgrade structs as needed. The
larger the distributed system, the versions of a struct (message) will be in-
flight at a time. Services need to contain no state, so that they can be
micro-rebooted and brought up with the new version.

Joe Armstrong had a comment on globally accessible but immutable code, which I
think would go a long way towards the ability to statically type the inputs to
a function in a distributed system. Interposition and routing would be the
only way to upgrade or deprecate old code paths.

------
haspok
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.

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).

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.

~~~
im_down_w_otp
I'm not sure I'm following you regarding the difficulty of encoding business
logic into your code in Erlang.

Erlang's function-head matching system is extremely close to being a Prolog-
style logic programming system when used a certain way.

I've found it extremely easy to take what would normally be a big weird
database of rules and values and instead precompile every possible route
through the system into a bunch of generated function-head matched function
calls + guard clauses. It makes assuring that given inputs will definitely
produce correct outputs very easy, and makes processing the rules extremely
fast.

------
Athas
I am intrigued by this snippet from the README:

    
    
        type messages 'x = 'x | Fetch pid 'x
    

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?

~~~
j14159
That's a good question and the short answer is that we're deliberately
breaking decidability to allow people to use types that are relatively in line
with what we're used to in Erlang (I get into this a bit in the talk linked
above). There's a reasonable argument to be made that we should knock this off
of course but I'm generally biased in favour of making interoperation with the
ecosystem simpler :)

We should actually clean up that example you pointed out, matching on the
`Fetch` constructor first. What we're _really_ trying to support is unions
like:

    
    
        type number = int | float
    

There's a yet un-had argument about the utility of this as well of course and
we may want to remove the ability to do this entirely. The way we type this is
by actually using type-checking guard functions like `is_integer` to convey
information to the typer at compile time.

------
jmcdiesel
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"

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?

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...

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?

~~~
SEMW
> why change?

They didn't. The syntax is explicitly stated to be a mixture of OCaml and Elm.
The -- comment syntax is from Elm. Elm in turn got it from Haskell.

------
pka
There's also purerl [0], an Erlang backend for PureScript. Would be cool if
the two projects could join forces.

[0] -
[https://github.com/purerl/purescript](https://github.com/purerl/purescript)

------
sctb
Related discussion from last year:
[https://news.ycombinator.com/item?id=11992773](https://news.ycombinator.com/item?id=11992773).

------
sergiotapia
>Apache License, Version 2.0

Pardon my ignorance, but why not make it MIT and completely avoid any
licensing issues?

~~~
geofft
The Apache license has an explicit patent grant (the MIT license says
"permission to use", which isn't a copyright grant, so it _probably_ has an
implicit patent grant), and an explicit statement that patches intentionally
submitted for merge are submitted back under the Apache license.

The reason we have licenses at all instead of the Unlicense or similar is to
make things unambiguous for courts and lawyers. Explicit is better than
implicit. The length of the MIT license isn't actually a feature.

(And the contribution section seems like it avoids licensing issues that MIT
doesn't.)

~~~
dmm
License bikeshedding is fun, so please indulge me.

People dislike apache because it's complicated and requires annoying notices
on distribution of modified versions. Debian and fsf say it's free. OpenBSD
believes the patent provisions are non-free and refuses to include apache
licensed software.

I think a project is better off having non-trivial contributers sign explicit
license grants, even you admit that explicit is better than implicit.

~~~
geofft
I don't understand how the OpenBSD project defines "free", so I can't usefully
comment on how they consider the Apache license "non-free".

It sounds from
[https://softwareengineering.stackexchange.com/questions/2632...](https://softwareengineering.stackexchange.com/questions/263227/why-
are-apache-2-0-works-excluded-from-openbsd) like they are reading the
existence of an explicit patent clause in the Apache license (regardless of
what that clause is!) as an "additional restriction". I want to know whether
they believe the MIT license has a patent grant, and if not, what they think
"Permission to use" means.

