Although it is technically a purely functional language, you can almost mutate variables (in reality it is creating a new immutable variable with the same name, which takes precedence)
a = 1
# a == 1
a = 2
# a == 2
Concurrency feels very natural: # concurrent
numbers = [1,2,3,4,5]
doubles =
|> numbers
|> Enum.map(fn(n) -> Task.async(fn -> n * 2 end) end)
|> Enum.map(&Task.await/1)
# doubles == [2,4,6,8,10]
# consecutive
numbers = [1,2,3,4,5]
doubles = numbers |> Enum.map(fn(n) -> n * 2 end)
# doubles == [2,4,6,8,10]This (purity) stirred my interest, but as far as I can see it's incorrect. This[1] Wikipedia page on pure languages does not list Elixir, and the Elixir Wikipedia page itself does not mention purity at all.
Can anyone clarify?
[1] https://en.wikipedia.org/wiki/List_of_programming_languages_...
FPGAs may or may not deserve that distinction, depending on your point of view.. but even if you concede that, they're still heavily bandwidth limited. An SDRAM interface takes up quite a bit of floor space, especially if you want more than one FIFO to move data with -- and even then, you're still standing behind relatively slow memory interface. There's SRAM on newer chips, but it's still too paltry an amount to really do anything close to general purpose computing on.. especially with the languages you've mentioned.
> why Moore's law no longer works
Moore's law no longer works because we hit 4GHz in silicon, there's nowhere to go but sidways now, and that's true whether you're in dedicated or reconfigurable chips.
Err...I respectfully disagree. They're HDLs and more akin to hardware design than any traditional software abstraction, assembly included.
It also may depend on where you learned your craft - my decade as a logic designer seemed to show people who started life as an EE and went straight into logic design coded at a lower level than people who started as programmers (who tended to be more productive as a result) ....
But this is old data - the world changes
The exception to this are those with good hardware sympathy. They can after carry over that detail oriented thought process.
Not sure why they wouldn't use it instead.
The best languages to take advantage of chips that aren't compute-limited* are things like Erlang, Elixir, Go, MATLAB, R, Julia, Haskell, Scala, Clojure.. I could go on. Most of those are the assembly languages of functional programming and are also not really usable by humans for multicore programming.
I personally vote no confidence on any of this taking off until we have a Javascript-like language for concurrent programming. Go is the closest thing to that now, although Elixir or Clojure are better suited for maximum scalability because they are pure functional languages. I would give MATLAB a close second because it makes dealing with embarrassingly parallel problems embarrassingly easy. Most of the top rated articles on HN lately for AI are embarrassingly parallel or embarrassingly easy when you aren't compute-limited. We just aren't used to thinking in those terms.
* For now lets call compute-limited any chip that can't give you 1000 cores per $100