and I really want to find a use for Swift.
Didn’t really start liking Rust as much until after I started Elixir, but now I think they have many useful commonalities and complement each other well. Upcoming Rust Emscripten support is also very exciting.
And don’t forget Rustler to make Rust Ports and NIFs for Elixir/Erlang!
I’m not a Haskell aficionado but I’ve dabbled with it for more than I have with Elixir and so I can say the following:
Haskell is not remotely close to Elixir, barring that they are both function languages.
Haskell is strong, statically typed language. And by strong I mean ironclad: you can’t even add an
Int type with a
Float type (if you want/need ambiguity about your numeric types your best bet is the
Num typeclass (a conceptual equivalent of Java’s interfaces, only way “souped-up”). Also, as the example states, no automatic type casting. No type casting at all.
Ironclad strong typing.
Haskell is also functional language in that function application has the highest priority and binding: if, for example
mySquare squaress its argument (which, as stated before must be declared as a specific numeric type, or the
Num typeclass) then
mySquare 2 * 7 is 28, not 196 (to that you’d parenthesize:
mySquare (2*7), or use the identity operator:
mySquare $ 2 * 7).
Haskell is lazy by default. All operations are lazy. No
Enum is strict but
Stream is lazy.
You want strict, you’re gonna have to go to some lengths to accomplish that.
Syntax itself is very succinct. No parenthesis unless needed to create explicit binding order, for example.
(Can’t come up with more involved examples. It’s much more succinct then Elixir though).
Currying is built in. You define a function
myFunc :: a -> a -> a which means it takes two arguments of type
a and return an answer of the same type, and you can run
myFunc a and it’s perfectly legal. You got yourself a thunk. Want to bind to a variable? Go right ahead:
myThunk = myFunc a. Now you can call myThunk with the second argument to get the result.
Haskell’s guard are more complex and allow more fine-tuned control of the branching then Elixir allows.
Haskell is truly pure functional language. If you need state you must use monads. No abstraction like there are in Elixir. Same for I/O.
Due to all the above stated differences between the two languages, Haskell’s testing library can, for certain types of programs, prove that the code is bug-free or buggy. Of course “bug free” is subjective, but if the specs for the tests are defined as such-and-such the code can be proven either bug-free or buggy with respect to the specs.
I’m certain there’s many more changes between the languages I’m not aware of (being a newbie to both).
The way I see it, they are not competing languages, they complement each other: Elixir, being a sort-of wrapper for Erlang is great for “nine-nines” connectivity, for example. Haskell can be better used as an API engine behind the scenes.
And as for the original poster’s question, my interest, other than Elixir that is, lays with Haskell, PureScript (a subset of Haskell that trans-compiles to JS), Clojure and, of course… Elm (which is heavily influenced by Haskell, yes).
Well, my main interests in terms of languages actually are:
Side by side with Erlang and Elixir (of course).
I’ve just added Bucklescript to my list
And I am just on my way to edit [purescript] into mine
3 posts were split to a new topic: Why Purescript?
Well yeah, you’re advocating it very well on this forum. lol
I should probably give it a try…
Blame @OvermindDL1 - he’s doing a great job evangelising
I am not quite converted myself, but it’s definitely in my shortlist for when I start an SPA app.
I am spoiled in that I get to use Elm and Elixir professionally for work, and those are my primary languages these days.
Here’s a new one:
Eta: a pure, lazy, strongly typed functional programming language on the JVM.
main :: IO () main = print $ quicksort [1, 123, 42, 90, 24, 12, 3] quicksort  =  quicksort (x:xs) = quicksort left ++ [x] ++ quicksort right where left = [ y | y <- xs, y < x ] right = [ y | y <- xs, y > x ]
Looks like Haskell.
Now wait for all the people to tell you that this implementation of quicksort is awful, should not exist and that using mutable data structures is faster anyway.
Rather, because the underlying datatype is a linked list, merge sort is faster to use than quicksort.
I myself am looking into how Forths and similar concatenative stack-based languages can be built, because I am in the process of building my own.
Also… I just realized that I’ve been programming in about ten different languages interchangeably during this week. This cannot be healthy…
Inefficient but mathematical:
let rec sort = function  ->  | pivot :: rest -> let left, right = List.partition (( > ) pivot) rest in sort left @ pivot :: sort right
Compared to the highly efficient sort in OCaml itself:
Sorting is hard. ^.^
PHP is actually getting decent if they accept pipe RFP with all the things added in 7.0 and 7.1 it’s now surprisingly usable . On a side note had to refresh my memory on Python and among other things watched all keynotes from 2012 to now by Guido it’s very entertaining it basically goes like this
Year N people criticize Python because of X,Y and Z but none needs X,Y and Z
Year N+2 we added X,Y and Z people criticize Python for X’,Y’ and Z’ but none needs X’,Y’ and Z’
Yup, I’m definitely also very interested in Elm. Right now, for frontend work, I reach for React. However, once Elm hit’s 1.0 and if Elm Native is still showing progress and promise I’ll likely switch over.
You mean this right? God I didnt knew about that, being stuck with PHP at work this would be awesome!
Yep it’s available in Hack, had a chance to land in PHP 7.1 but there was much debate hope it makes 7.2.