Hacker News Reader

Comment by ninjakeyboard | Hacker News Reader

I wrote a book on Akka with many years of experience with it and I have been using Elixir professionally for 7 months or so on greenfield/replatforming efforts and I have to say that the BEAM VM is really an incredible piece of technology that leaves Akka on the JVM in the dust in several aspects because the VM is actor-model native. I wish there was a statically typed language that ran on BEAM but Elixir and Erlang are great technologies to run in production if you can accept some of the associated risk of newer eco-systems in Elixir (but erlang has your back!).

View on HN

You may already know about it, but if you are looking for a statically typed language that runs on BEAM, you might want to check out Elchemy.

https://github.com/wende/elchemy

It allows you to write elm-like code that transpiles into easy to read and idiomatic (for the most part) elixir code.

THANK YOU. I didn't know about this, myself.

I love the philosophy and robustness of the BEAM VM, but I can't go back to the stone ages of a language with a poor (or non-existent) static type system.

Out of curiosity, what languages do you prefer to work in?

Nothing is a slam dunk. I love and hate even my favorite languages (TypeScript, F#, Elm). Hoping Rust will be the silver bullet once I have time to try it.

Try to give scala a whirl. It's pretty nice.

I don't find staticness to be the gating criterion for me. Go, for example, has a static type system that's IMHO very poorly designed - for example, if you want to multiply a time interval by some integer, you have to convert the integer to a time type and then multiply, which breaks my poor science brain (violates fundamental concepts of dimensional analysis). You also have to do things like pick between implementing something with slices versus fixed size arrays, and generic functions are not an option. I couldn't write fn dot_product{n}(v [n]int){...} for example.

What you probably want is a strong type system. Functional programming languages (I'm thinking Julia as an archetype of strongly typed systems) especially are really good at dispatching over types, and can make robust optimizing inferences using a well-designed type system.

BEAM languages are strongly typed, but there are far fewer types (and no true custom types) like julia. However, gating based on functional guards is simply amazing and more than makes up for a limited type system in terms of code clarity. As for compile-time vs runtime error trapping - part of the point of BEAM languages is "who cares?" An error doesn't bring down your VM. It gets logged, you can see it, and apply a hot patch and fix it if you need to.

> An error doesn't bring down your VM. It gets logged, you can see it, and apply a hot patch and fix it if you need to.

It won't bring down your VM, but it will impact any end-users of your service. Not all errors can be solved by restarting a process or retrying a request (but I recognize the argument that you should aim to catch those types of errors in tests because they are part of the core business logic).

Also just wanted to note that hot-patching has serious costs. Code upgrades/downgrades can be difficult to write and the upgrades themselves also need testing (and this often doesn't get the attention it needs).

There are no silver bullets, basically.

I like a type system that leans closer to Haskell than not. As someone else mentioned, my users prefer me to catch errors before compile time :)

Expressive, algebraic types allow me to tell my compiler, IDE, and code heirs what I'm trying to do so they know just by reading my code if I failed. That's indispensible.

Purescript also has an Erlang backend !

I'm also making a backend for Idris: https://github.com/jameshaydon/idris-elixir

The problem of static types for the communicating parts of the actor model is not really solved yet. In the meantime there's Alpaca-lang and Simon Fowler did a run-time monitor for Erlang with behavioral types from Scribble. I think we'll see some nice progress in this area in a few years.

Akka has solved them already. Just pattern match on the object you receive.

Before I send you an object, I’d like a static guarantee that you can process it. Typed channels is one approach used in Cloud Haskell - I think Akka tried and abandoned it.

I think a protocol type system like Scribble is a really good solution to the problem. It's very tricky to verify it statically though, so it will take time to get there.

The guarantee you can process it only works when your compiler has access to both sender and receiver.

When you connect to a cluster to send to something on another node, it’s no different than making an API call to a service that you don’t control. The compiler can’t make any guarantees there without contracts in hand, which can change at a whim on a deploy or when new nodes are added.

For message passing across a cluster, setting up Dialyzer is probably the most realistic approach. Function calls on the BEAM are more like request routing I think.

Node -> Module -> Function -> Arity -> Pattern

Akka clusters, like Erlang clusters, are completely trusted. This is not an integration technology, it’s for distributed processing by a single owner.

It is, but code updates still happen. Nodes aren't all identical.

As these things change, the contracts have to be exchanged with every member of the cluster which would not only add significant communication overhead, it would also bypass those compile time guarantees.

That's before even considering things like hot deploys where the code is updated live, while running, mid-execution.

The contract enforcement becomes akin to the goals of WSDL, which added a ton of overhead with minimal benefit aside from making consuming APIs easier for statically typed languages because of generators.

Is the overhead worth the difference from...

Client (this message will fail on this server) -> don't send

to...

Client -> (this message failed)

Especially when talking about a cluster which you own...that benefit is questionable at best.

The feature I'm talking about is a compile-time constraint. The sole purpose of it is to make development and refactoring easier by providing immediate feedback to the developer when they change code in a way incompatible with its interface. It is not really about providing global run-time guarantees. Solving evolving messages through deployment is really a separate topic, and something you have to do whether you have compile time checks or not.

In that case, I'm not following where Dialyzer doesn't already address the problem?

It doesn't cover every case, but it covers enough of them to provide a very watchful eye without getting in your way.

https://speakerdeck.com/jvoegele/elixirconf-2016-dialyzer-op...

I wrote and maintain Dialyxir. I'm familiar with Dialyzer. What it can't do, is tell me whether any given pid can actually accept and process a message of a particular type. You can write a module interface to your actor that does this, which is what most people do. But it is not quite the same as typed channels. And whoever started this thread was complaining about the "issue" in Akka. Messages are inherently dynamic in this style of communication. Its not the only possible style in either language, but its a valid criticism of this particular approach.

This requirement is incompatible with the actor model. Use channels (Go, Rust) if this is what you want. The lines of communication between actors are untyped because real life networks are untyped. When you receive a packet over the network you always have to look at it before you use it. Typed channels are fine for single machine use, but untyped is necessary for distributed computation.

I think if you have an evolved enough type system, then there isn't such a problem. I have written an Elixir backend for Idris and given some examples of well-typed actor communication here:

https://github.com/jameshaydon/idris-elixir

By coincidence The Morning Paper has this today:

A static verification framework for message passing in Go using behavioural types, Lange et al., ICSE 18

http://blog.acolyer.org/2018/01/25/a-static-verification-fra...

Have you turned on Dialyzer?

Reply on news.ycombinator.com