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

91–98 of 98 posts

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

#91

Post by bjt »

leshow wrote: post #74
spraak wrote: post #22

Earlier quoted context omitted.

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

Haskell? Some of it's parallelism and concurrency features should look familiar to you (it has an M:N threading model), complete with channels, and some stuff you've probably never heard of like STM. It compiles to a binary, has a type system much more powerful and expressive than Go's, and the community is very helpful. I will say the compile times aren't very speedy, I assume you want fast compile times in order to…

"It compiles to a binary..."

That's one of the things I love best about Go. Compile for your platform, then copy the binary somewhere else and run it. Awesome.

I really want this to be true for Haskell too, but there's a glaring exception with libgmp. Google "haskell libgmp" for many stories of people thinking they could just copy their haskell program to a new system and run it, only to realize they were wrong.

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

#92

Post by dalailambda »

leshow wrote: post #75
dalailambda wrote: post #39

Earlier quoted context omitted.

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.

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

In regards to Purescript/Typescript, they're both statically typed and that results in friction when trying to integrate with the existing JavaScript ecosystem/libraries. Erlang/OTP might be different, but there will probably be situations where the type system is either incompatible with a certain library, or the type system is made less strict (e.g. an any type).

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

#93

Post by di4na »

sgrove wrote: post #6
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

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!

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.

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

#94

Post by di4na »

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…

False. In erlang, your message passing is "at most once".

If you send a bad message, the receiver will crash or discard it and it is how it is intended to be.

Erlang embrace laws of maths and physics.

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

#95

Post by di4na »

jrobn wrote: post #13
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

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

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

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

#96

Post by di4na »

jrobn wrote: post #13
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

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

Found it !

https://youtu.be/PtgD5WRzcy4

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

#97

Post by leshow »

dalailambda wrote: post #92
leshow wrote: post #75

Earlier quoted context omitted.

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

In regards to Purescript/Typescript, they're both statically typed and that results in friction when trying to integrate with the existing JavaScript ecosystem/libraries. Erlang/OTP might be different, but there will probably be situations where the type system is either incompatible with a certain library, or the type system is made less strict (e.g. an any type).

That wasn't what I got out of the previous post, it seemed to be saying there was something inherently unsafe about compiling down to a dynamic language.

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

#98

Post by leshow »

bjt wrote: post #91
leshow wrote: post #74

Earlier quoted context omitted.

Haskell? Some of it's parallelism and concurrency features should look familiar to you (it has an M:N threading model), complete with channels, and some stuff you've probably never heard of like STM. It compiles to a binary, has a type system much more powerful and expressive than Go's, and the community is very helpful. I will say the compile times aren't very speedy, I assume you want fast compile times in order to…

"It compiles to a binary..." That's one of the things I love best about Go. Compile for your platform, then copy the binary somewhere else and run it. Awesome. I really want this to be true for Haskell too, but there's a glaring exception with libgmp. Google "haskell libgmp" for many stories of people thinking they could just copy their haskell program to a new system and run it, only to realize they were wrong.

I'm sorry I don't understand, the results seem to be about people having difficulty installing GHC, not deploying a binary. I can say anecdotally I've never had any problems.

edit: Ah ok, apparently libgmp is dynamically linked in binaries, but you can pass a flag to GHC to statically link all runtime dependencies. Is that what you were talking about?

Post reply on HN