Alpaca – Functional programming inspired by ML for the Erlang VM

by knv • 9 years ago

217 96 9 years ago

sctb• 9 years ago

Related discussion from last year: https://news.ycombinator.com/item?id=11992773.

platz12• 9 years ago

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

brightball3• 9 years ago

I tend to agree with you. Message passing and static types don't mesh unless there is some type of contract between the sender and receiver. It would be a nightmare.

msangi3• 9 years ago

How does dynamic typing help if there is no contract between sender and receiver? Even in that case they must agree on the content of message.

Even if you insist in keeping the message untyped, with a static type system one could always convert (and possibly reject) messages as soon as they are received into a more precise type. That would keep the code that the compiler can't verify to the edges of the system.

jordwest• 9 years ago

I would say there should always be a contract between the sender and receiver, whether that's using static types or otherwise. Not having a contract is a nightmare.

For example, say a satellite sends a number to the throttle control in feet/second, but the throttle control thinks its in m/s. To each of those systems, they're just passing a number and don't know any better.

sgrove• 9 years ago

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!

platz12• 9 years ago

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

di4na4• 9 years ago

Well the first question you have to answer is simple : what is the type of self(), your own pid. This is a really hard problem and what stopped SPJ in the late 90s/early 2000s

Then the second problem is that at any given time you can receive a message from another node/process 10 years in the future compared to you, that you know nothing about his code or types. How do you type check it?

Finally, the actor model in general allows unbounded nondeterminism. This is not really something you can build into a static type checker.

The "easy" solution is to make messages an opaque black box that can be anything... but at that point you are leaking static typechecking everywhere.

jrobn• 9 years ago

I also agree with this premise. I favor the gradual typing philosophy more and more. For me at least, productivity wise, being able to write something, play around with it, make changes, etc without worrying to much about satisfying type requirements is great. When the idea and and implementation feels solid go back and gradually add in type requirements.

I would love to see Erlang get a LLVM based JIT compiler backend. I think this http://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf is the latest work done in that area.

di4na4• 9 years ago

There was a talk at the eef17 this week from the OTP team on it. It is on erlang solutions YouTube channel.

Sadly on phone so can hardly link it

di4na4• 9 years ago

Found it !

https://youtu.be/PtgD5WRzcy4

jerf4• 9 years ago

You have to model sending a message across the cluster as marshaling into a binary form and unmarshaling it again. I don't mean that you "should" model it that way... you have to model it that way, because that's what is happening. Therefore, when receiving a message, you really only ever get a Maybe Message or Either Message Error or whatever you want to model it as. The act of marshaling the message back into the local representation is also when you check it for whether it conforms to the type restrictions you think it should have.

Because you must already model this as a process that can fail, I don't think it does break the static typing model at all. In fact I routinely "statically type" messages coming from things that were actually emitted by dynamic languages!

What gets tricky is if you try to model this as a process that can't fail. But the problem there isn't static typing, it's a specific instance of the general principle that you can not build robust systems based on the principle that networks can't fail.

I also think this is an instance of the general misunderstanding about static types, which I understand deeply because I once held it, that static types somehow prevent errors. They don't. What they do is provide a gateway that says "in order to get into this type, you must meet these criteria, and the compiler is going to statically check that you've verified these criteria". A static typing system doesn't force things through that gateway, it forces you to check whether things fit through that gateway, and do something with the things that don't. Then, it also allows you to strictly declare that everything that uses that type is statically checked to be "behind" that gateway, so there are no other ways around it to get in, thus creating a space in which you can count on the fact that the values have been checked for certain properties and you can now write code that counts on those without constantly checking them. A statically typed system faced with the task of, say, parsing a number out of a string, does not prevent a user from sending me a string of "xyz"; it just prevents me from just sending it through the system as-is.

platz12• 9 years ago

everything that uses that type is statically checked to be "behind" that gateway

In a distributed system, the largest the "gateway" can reliable be is a single node, because you don't get guarantees about the code that other nodes in the system are running. Even the single node case poses difficulties, because I believe in OTP the upgrade path means you have to transfer state during upgrades. What if the types of the state during the upgrade don't exactly match? Can multiple types of a thing exist simultaneously? How is these types versioned? etc... it gets complicated.

Therefore, when receiving a message, you really only ever get a Maybe Message or Either Message Error or whatever you want to model it as.

Sure, you can receive messages as "Object" and then cast/parse them inside the node. Does that mesh with the vision of what people have when they want to bring static typing to erlang?

---

The hard part about thinking about OTP is not just the message passing, but also the myriad deployment & upgrade & versioning scenarios.

I am a fan of static typing over dynamic typing in everything else , i.e. normal programs.. just not _OTP-style_ erlang for distributed systems.

Even thinking about something like a gen_server (http://erlang.org/doc/man/gen_server.html) makes my head hurt... though if someone can figure out a way to do it that's faithful, more power to them.

dalailambda2• 9 years ago

While I agree that the OTP perhaps is not as easily statically typed, since it was built with Erlang in mind, I do think that static typing adds a layer of robustness to distributed systems, especially if you design it that way upfront. In my experience the problem comes when you try to apply static typing to a dynamic system.

leshow5• 9 years ago

In my experience the problem comes when you try to apply static typing to a dynamic system.

As in, because it compiles down to a dynamic system, it's no good?

There are plenty of languages that give us strong static guarantees and compile down to dynamic or untyped languages. Look at Purescript, Elm, etc. They all do quite well compiling down to JS.

Don't forget that assembly isn't strongly typed either, and most languages compile down to that. I don't see anything wrong with a static typed layer that compiles to dynamic code, the interface you're providing is still type safe.

runeks2• 9 years ago

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

The more I've learned to leverage types, the more I realize that it's my limited knowledge of type systems that prevents me from expressing something in it. Types do not bend to the will of programs; programs bend to the will of types (in statically typed languages).

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 don't understand. The components of distributed systems communicate via protocols. What prevents the implementation of these protocols from leveraging type safety, thus transforming a runtime error into a compile-time one?

Static typing is about catching programmer mistakes, by communicating your intent to a compiler -- "I expect the type of this to be a Maybe Int, fail if that's not the case". There's no essential difference between a test informing you that a value-level property doesn't hold up at runtime, and a type error, informing you that a type-level property doesn't hold up at compile-time.

platz12• 9 years ago

What prevents the implementation of these protocols from leveraging type safety

Global invariants of a running distributed system are different than local invariants in a single program that you can stop, deploy re-compiled binaries to, and then start again.

Now, you can use static types in actor systems, and they are some of these that exist. These typed actor systems don't do all the same things that erlang/OTP does (that may be ok - maybe you don't need them). If your use case fits into what the typed actor systems actor systems provide, by all means, one of those are probably a better fit for you.

Tarean• 9 years ago

I think it is necessary to go with an erlang like style if one wants to get a remotely acceptable cost model.

I am not sure how much static typing actually hinders and how much that is a matter of tooling, though. Maybe static typing could do things like checking whether the new version will be compatible with other nodes before deploying?

nv-vn• 9 years ago

I suggest you look into Session Typing, specifically Multiparty Session Types as these provide a refreshing approach to the problem of communicating threads. A lot of it is still kind of experimental but there's some good traction being made for sure and it's probably as expressive as you'd need to get to model 95% of the type information in an Erlang program. Type inference obviously isn't a choice yet, but I think a good language offering some of these features on the BEAM VM is all that is needed to make them hit the mainstream and actually get used for real software so that more work can go into the theory, etc. The problem is being solved on the bleeding edge of things, just not as fast as Erlang itself is progressing.

salimmadjd3• 9 years ago

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

platz12• 9 years ago

enough eyeballs left for a new language that does not have a large corporate backing

It's a solid point if the goal is winner-take-all style competitive victory. But I'm not sure software should co-op SV-startup-business exponential growth-or-die mindset. What happened to hacker culture? Are open source developers corporatist now?

/end-speculative-rant

bbcbasic• 9 years ago

Open source is massively corporatist. Developers working for $0 to create tool chains that other developers spend their weekend learning so that the shareholders of their employers can increase their wealth.

alextheparrot• 9 years ago

There does seem to be a significant push to contribute to open-source at many large companies. Having money and people contributing as part (or all) of their day job can be quite a boon for projects.

I agree with the premise of your point, though.

salimmadjd3• 9 years ago

The point I was making is for something to get enough traction, so that it would get active contributors who help mature the language, tools, etc.

I think there are only handful of people out there who can contribute in a meaningful way for a project like this. If they are consumed working on open source Swift or doing pull request on many things pushed by FB or Google or working contributing to existing projects like GHC, etc. Then the Alpaca project wont get the contributors it needs to show progress. If there is no progress, it falls into a vicious circle of no progress -> no traction -> no contributors -> no progress

jerf4• 9 years ago

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• 9 years ago

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

WhitneyLand2• 9 years ago

Seems a bit contradictory. Which is it, corporate backing or novel ability?

I would like to see language advantages better quantified. How confident can we be a language is a practical improvement, in what contexts is it true, and what do the improvements buy in cost, quality, innovation, etc.

If we had all this data for a new language it would probably be easier to gain critical mass.

psiclops• 9 years ago

I haven't used Elm yet, but if you like it, check out the language it is implemented in, Haskell

salimmadjd3• 9 years ago

I've been trying to crack Haskell for a while, but didn't find it approachable at first. Somehow Elm and building simple web apps made grasping FP easier.

So now that I've learnt a bit of Elm, I find I can grasp Haskell more and spend a bit playing with. The best part is, after reading this [0] I'm finally grasping Monads.

[0] http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

leshow5• 9 years ago

I think Elm is great, but the language designer has really crippled it IMO by not including abstractions for types. Something analogous to typeclasses would be hugely beneficial. As it is the language gets around it by making some built in things magic, I found this frustrating after a while.

sergiotapia• 9 years ago

Apache License, Version 2.0

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

geofft2• 9 years ago

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• 9 years ago

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.

haspok• 9 years ago

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• 9 years ago

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.

Athas2• 9 years ago

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• 9 years ago

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.

pka• 9 years ago

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

jmcdiesel• 9 years ago

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?

SmellyGeekBoy• 9 years ago

SQL uses '--' for comments.

yawaramin• 9 years ago

You may be pleased to hear that ReasonML chose /* */ for its OCaml syntax refresh just for familiarity.

lepoetemaudit• 9 years ago

It's -- in both Elm and Haskell for comments, so it's not new and part of the heritage of the language.

SEMW• 9 years ago

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.

Alpaca – Functional programming inspired by ML for the Erlang VM

Related Stories