Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alpaca – Functional programming inspired by ML for the Erlang VM

github.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#21

Post by platz »

jerf wrote: post #17
platz wrote: post #3

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

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 l…

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

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#22

Post by spraak »

jerf wrote: post #15
salimmadjd wrote: post #4

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 th…

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 d…

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

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#23

Post by dmm »

geofft wrote: post #12
sergiotapia wrote: post #10

>Apache License, Version 2.0 Pardon my ignorance, but why not make it MIT and completely avoid any licensing issues?

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…

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.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#24

Post by liveoneggs »

dmm wrote: post #23
geofft wrote: post #12

Earlier quoted context omitted.

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…

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…

until they are taken to court the licenses are all just assumptions. Did OpenBSD have a lawyer review this decision and post the language somewhere?

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#25

Post by louthy »

platz wrote: post #18
msangi wrote: post #14

Earlier quoted context omitted.

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.

Distributed systems are not like traditional programs, because there is not just one "edge of the system". Every node becomes an "edge" in it's own right, and doesn't necessarily have global coherence with the rest of the system.

True, but if the sender wants the receiver to do something of value then it will need to meet a contract that the receiver enforces. That doesn't require a central repository of contracts, one node can diverge, but you must understand that parts of your network of services will start to fail. From that point of view it starts to look very much like the linker phase of a compilation, and that the types need to match up to the data structures being instantiated. It's just this 'linking' phase is in the programmers heads, and not particularly useful. A distributed system that can validate itself is a much more valuable concept.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#26

Post by jerf »

spraak wrote: post #22
jerf wrote: post #15

Earlier quoted context omitted.

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 d…

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

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.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#27

Post by platz »

louthy wrote: post #25
platz wrote: post #18

Earlier quoted context omitted.

Distributed systems are not like traditional programs, because there is not just one "edge of the system". Every node becomes an "edge" in it's own right, and doesn't necessarily have global coherence with the rest of the system.

True, but if the sender wants the receiver to do something of value then it will need to meet a contract that the receiver enforces. That doesn't require a central repository of contracts, one node can diverge, but you must understand that parts of your network of services will start to fail. From that point of view it starts to look very much like the linker phase of a compilation, and that the types need to match u…

Absolutely, the rubber meets the road at some point, nodes must understand/assume "contracts" about the data they are working with.

There already are static typed actor systems ( e.g. Orleans) which work well, but my point is that I believe OTP is more flexible for better or worse. Whether that flexibility is worth it to you for what you get is another matter.

Also I'm not sure how to think about binary compatibility between upgrades in such a system

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#28

Post by jerf »

platz wrote: post #21
jerf wrote: post #17

Earlier quoted context omitted.

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 l…

> 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 t…

'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?'

No, that's not how you do it. You marshal things directly into the desired types. Check out either aeson for Haskell or how Go does things via either the json modules or the generic Text/Binary Marshaler/Unmarshaler.

"but also the myriad deployment & upgrade & versioning scenarios."

The answer to all of those things is mostly that even a lot of Erlang shops don't use live upgrading. You really have to have a very particular use case for that to be the best solution vs. a rolling upgrade and server restarts. Even if the language is capable of it, it still requires you to write services that can handle being upgraded, and it's much easier to write services that can handle being restarted, especially since you 100% have to write that anyhow because services get restarted anyhow. Most people don't have that use case. Web services certainly don't have that use case.

Once you drop that, it's a lot simpler.

"Even thinking about something like a gen_server"

gen_server is partially as complicated as it is as a side-effect of other decisions in the language. While the concept of a gen_server is a strength in Erlang, the specific implementation of gen_server as this "behavior" thing is mind-blowingly complicated for what you actually get. (It reminds me of Python's "metaclasses". I spent many hours wrapping my head around what that was, but in the end, all that it amounts to is what is now called a class decorator, which is way more sensible. A metaclass isn't a class decorator in theory, but in practice, class decorators are way easier to understand and cover 99.9% of the use cases, if not 100%.) When I implemented supervisor trees in Go, my solution for gen_server/gen_fsm/gen_* was just to... not. Behaviors are just a very, very weird half-object-ish system with a lot of limitations. They are easily replaced by simply having some sort of "interface" system, be it via conventional classes or interfaces. It's why you don't see "behaviors" as Erlang defines them anywhere else. Erlang has a lot to learn from and copy from, but that part isn't it.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#29

Post by brightball »

louthy wrote: post #25
platz wrote: post #18

Earlier quoted context omitted.

Distributed systems are not like traditional programs, because there is not just one "edge of the system". Every node becomes an "edge" in it's own right, and doesn't necessarily have global coherence with the rest of the system.

True, but if the sender wants the receiver to do something of value then it will need to meet a contract that the receiver enforces. That doesn't require a central repository of contracts, one node can diverge, but you must understand that parts of your network of services will start to fail. From that point of view it starts to look very much like the linker phase of a compilation, and that the types need to match u…

Think of it this way: you have a struct type with 4 attributes that you want to pass to another function.

Currently, that function declares it will match on the pattern of those 4 attributes rather than a static type. Now, you update the Node and modify the type on the sending Node to have 5 attributes.

With pattern matching on the 4, everything still works. With static types on the struct the contract is now out of sync.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#30

Post by louthy »

platz wrote: post #21
jerf wrote: post #17

Earlier quoted context omitted.

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 l…

> 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 t…

> Can multiple types of a thing exist simultaneously? How is these types versioned? etc... it gets complicated.

I don't use Erlang, but I have developed an Actor system for C# [1] which is based on its (and Akka's) concepts. Clearly without a static type-checker for the whole distributed system we have to manually get involved and patch the old and new so that we can hot swap processes. Versioning I've found is best done by maintaining the old process that accepts the old message format, maps it to the new one, and then forwards it on to the new process that accepts the new message format. Any other node that is lagging behind will continue to work, and any new one will send to the new address for the process.

This isn't really rocket science, and if you stick to a few basic rules it tends to work out just fine. That doesn't mean that type safety goes out of the window, it just means that in creating a distributed process you must accept that you can't retire the old contract without it causing potential problems.

Apologies if I'm missing your point about OTP, but ultimately it seems that at some point (as the GP says) you are marshalling a message into a text or binary format, and then unmarshalling. At that point if the unmarshalled static type doesn't match the type that the process expects, then it will be off to the dead-letter queue. I don't really see how that's any different to giving the wrong type to a function in a dynamic language, or using an incorrectly typed variable that is picked up by a compiler in a statically typed language. In each case it's type checking at the earliest possible opportunity.

[1] https://github.com/louthy/echo-process

Post reply on HN