5 ms·

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

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

ihumanable 9y ago
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 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.
- smt88 9y ago
  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.
  - bostonvaulter2 9y ago
    Out of curiosity, what languages do you prefer to work in?
    - smt88 9y ago
      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.
      - ninjakeyboard 9y ago
        Try to give scala a whirl. It's pretty nice.
  - dnautics 9y ago
    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.
    - duijf 9y ago
      > 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.
    - smt88 9y ago
      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.
- arianvanp 9y ago
  Purescript also has an Erlang backend !
- jameshh 9y ago
  I'm also making a backend for Idris: https://github.com/jameshaydon/idris-elixir https://github.com/jameshaydon/idris-elixir
Zalastax 9y ago
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.
- tormeh 9y ago
  Akka has solved them already. Just pattern match on the object you receive.
  - jeremyjh 9y ago
    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.
    - Zalastax 9y ago
      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.
    - brightball 9y ago
      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
      - jeremyjh 9y ago
        Akka clusters, like Erlang clusters, are completely trusted. This is not an integration technology, it’s for distributed processing by a single owner.
brightball 9y ago
Have you turned on Dialyzer?

ihumanable 9y ago

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

smt88 9y ago
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.
- bostonvaulter2 9y ago
  Out of curiosity, what languages do you prefer to work in?
  - smt88 9y ago
    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.
    - ninjakeyboard 9y ago
      Try to give scala a whirl. It's pretty nice.
- dnautics 9y ago
  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.
  - duijf 9y ago
    > 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.
  - smt88 9y ago
    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.
arianvanp 9y ago
Purescript also has an Erlang backend !
jameshh 9y ago
I'm also making a backend for Idris: https://github.com/jameshaydon/idris-elixir https://github.com/jameshaydon/idris-elixir

Zalastax 9y ago

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.

tormeh 9y ago
Akka has solved them already. Just pattern match on the object you receive.
- jeremyjh 9y ago
  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.
  - Zalastax 9y ago
    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.
  - brightball 9y ago
    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
    - jeremyjh 9y ago
      Akka clusters, like Erlang clusters, are completely trusted. This is not an integration technology, it’s for distributed processing by a single owner.

brightball 9y ago

Have you turned on Dialyzer?