5 ms·
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.co
by 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 agoTHANK 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 agoOut of curiosity, what languages do you prefer to work in?
- smt88 9y agoNothing 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 agoTry to give scala a whirl. It's pretty nice.
- dnautics 9y agoI 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 agoI 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 agoPurescript also has an Erlang backend !
- jameshh 9y agoI'm also making a backend for Idris: https://github.com/jameshaydon/idris-elixir https://github.com/jameshaydon/idris-elixir