Hacker News Reader

Comment by tsaprailis | Hacker News Reader

Probably Elixir

I second Elixir, though if trends continue you're going to get a bunch of long time Ruby/Rails people (not bad or good, but something to be aware of).

Elixir is great in the sense of attracting people who are interested in functional programming, distributed systems, and scalability, but aren't willing to give up pragmatism/productivity/readability in exchange. In my experience, these are the best kinds of people to work with. Cs theory + get shit done = good engineering.

The only problem, in my opinion, is the lack of explicit types. From what I can see, the compiler provides some safety that doesn't exist in typical scripting languages. But I think we're pretty much at a point where so many of the commonly used scripting language idioms can be effectively described in a type system. TypeScript proves this. But it also proves that's it's still pretty difficult to add types to a programming language ecosystem after the fact, so it feels like that ship has likely sailed for Elixir.

For what it's worth:

http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html

http://elixir-lang.org/getting-started/typespecs-and-behavio...

Not the same as TypeScript or Haskell, but may help.

Note that Erlang/Elixir programmers don't care about most runtime errors as we use Supervisors to restart processes that may crash because of them.

> Note that Erlang/Elixir programmers don't care about most runtime errors as we use Supervisors to restart processes that may crash because of them.

That doesn't give me a whole lot of comfort. A program that handles crashes gracefully doesn't fix its own mistake. Supervision is great, but it's even better to not have the crash in the first place.

I would argue that enforcing, or at least favoring, immutability and the ability to trace data flow is more helpful that static types. You could have both, but I know which one I would rather give up first. (actually, in the best of all worlds, I would want optional [compile time] types as well as type inference)

Happy to report that I'm one of those people! I like how Elixir keeps itself very practical, but at the same time lets you extend it however you want if you feel something is missing in your project. For example, you'll never find monads in the standard library but people have made their own monads through macros.

So, you're saying that, by choosing other functional programming languages, I'm giving up pragmatism/productivity/readability? Can you give me an example of such languages?

What that person means is that Elixir is a "practical" functional programming language. Of course, that's because Erlang is too.

Note that "practical" functional programming is something I just made up, but in general to me it means a language that provides immutable data, first class functions/higher order functions, and provides ways to minimize side effects. Elixir/Erlang do these. The language is geared towards functional programming, but it's impure.

But compare it to Haskell, a "pure" language: Elixir has no strong types, monads/functors/burritos, you can do side effects whenever you want with no penalty, there aren't many restrictions or things the compiler will yell you at about that aren't obvious mistakes.

I'm not saying either choice is better, but the average developer with little experience in both Elixir and Haskell can probably build a product faster in the former.

Reply on news.ycombinator.com