Also since the VM is optimised for functional programming with no shared memory - it can do tricks you normally cant that help with speed. Like avoid GC in some cases.
In some countries (think "Europe") Bachelor degree is considered "incomplete", or just an intermediate step. Only Master of Science degree is regarded as true "higher education". There are even university programmes that take you straight to MSc degree, without stopping at BSc.
Well, yes, the idea that there will be GC pauses and you just cannot get a _consistent_ framerate no matter how hard you try does not sound good. (Disclaimer I currently write games with Unity ;D)
Obviously. Often kids start to have to walk to primary school here with 6, so they start to walk alone to library, bakery, etc with 5.
And when they start to have to use public transit to get to secondary school with 10 every day, it makes sense that they start by going shopping or similar places with 8/9 by bus/metro/etc.
I was driven to school, though I walked 250m to a neighbours house half the time for the lift. Walking to school would have taken over half an hour at a good, adult pace.
(The fear was probably traffic more than strangers.)
My elementary school was 1.4km away, the nearest bakery was like 800m, the grocery store was next to the bakery, the library was next to the school.
From 10 on I had to go to a secondary school which was 4.5km away, so I usually used the bike, but walked sometimes. At that age I also started using the bus to get to the other side of the city, or to take the bike and go to a cinema 12km away with friends, etc.
We obviously had almost no traffic here – except for busses and bikes. And construction vehicles.
Great idea, Erlang is very good for such tasks. Native communication between nodes, very high availability and fault tolerance (native as well) using "actor model"[1] and good performance. As an example, in one of my previous companies we built a message broker, which was able to keep 35K keep-alive connections on Amazon Medium EC2 instance and there still were reserves in CPU and Memory.
Plus it's easier to learn it than it seems first time when you see it. Most of our Erlang-developers came from other languages, but they learned basics very quick: 1-2 days until the first commit on production.
The only one thing, it's not so easy to debug it in the beginning. But it's a question of practice, I think.
Question: on a scale of Go to Haskell, how long on average does it take for devs only familiar with a couple of imperative languages (e.g. two of Python, C, Java or Ruby) to learn Elixir to the point that they can be productive with it?
We haven't measured the actual time. I would say the time learning Elixir has not been a hurdle or anyway limiting factor to the projects we are working on.
We basically switched as a company from writing servers in C#/nodejs/python to just Elixir. Did this gradually during end of last year and this spring.
Though I must mention that all of our developers were already familiar with multiple languages. And since we have multiple projects going on we can transfer knowledge easily. So YMMV.
Sorry, I'm not a person to whom this question was addressed. But in our company we had 3 developers coming from PHP and Python world. They learned basics in 1-2 days and started to commit in production repository. Then in 1-3 weeks they learned it much deeper. But in our case it was easier because we already had high traffic and there were a lot of production examples to learn.
Do they ever have to use an Erlang lib and find the documentation harder because they're Elixir programmers?
I love the Elixir syntax but worry it'd be like Scala: a better way for people who already know Java, rather than a way to use BEAM / OTP etc for people used to modern languages.
Most of my time I write Python, but I'm trying to spend more time with Elixir, and I haven't found using Erlang libs that hard.
There are a handful of rules to remember, if that, and it's reasonably straight-forward. module:func becomes :module.func, the erlang func probably wants char lists rather than strings, atoms are lower-case and should be changed to :atom, vars are upper case and should probably be lowered.
Learning the Elixir language is easy, thinking functionally less so (for me at least).
I don't remember that it was harder actually. We were using Mochiweb (was replaced by Cowboy at some point in time), Chicago Boss and some other additional Erlang libs and people switched from it to Elixir and other way around.
Agree with rossj, there're some rules to remember and then it's not that hard.
I would have to disagree with the other responses to this question. However, I cannot disagree completely. Learning Erlang/Elixir is a subject full of nuance.
Learning the procedural aspects of Erlang or Elixir is very easy. In that sense I agree with the previous responses. Erlang gets a lot of bad rap for the syntax. But, it is really no more difficult that any other language to learn. The syntax can easily be learned in a day. Elixir's syntax can be learned even more quickly because it looks a lot like Ruby or Python. Thus, you can certainly start write scripts in Erlang or Elixir relatively quickly. My guess is that the average, experienced developer could start writing basic scripts in an hour or two. However, those scripts would be entirely procedural in nature, unless they are already very familiar with functional programming and pattern matching.
The first hurdle in Erlang/Elixir is the functional aspects of the language and understanding the power of pattern matching. Both of these require rethinking how you build a program. But, both of these are also incredibly, incredibly worthwhile and powerful. Elixir in particular is a great medium for better understanding these concepts because it is a very approachable language. Getting over this hurdle did not happen over night for me. I rarely used recursion in Ruby or Javascript (there is no tail call optimization). On the other hand, in functional languages recursive functions are the norm. I learned to really love them with Erlang/Elixir and now it frustrates me when I can't use them elsewhere because it has become much easier for me to reason about recursive functions than loops. Overall, functional programming and pattern matching are amazing things to learn but really grokking them won't happen over night.
The next hurdle with Erlang/Elixir is understanding OTP. This is THE incredibly powerful aspect of the Erlang VM. However, it is also not an easy subject matter to approach unless you already have a strong background in distributed systems. I did not. Hence, it took me a while to compose programs that actually used the Erlang VM for what it was built for, OTP. Thus, this portion of the Erlang/Elixir learning curve felt long and slow. I was not used to spawning new processes on a whim and passing messages back and forth. Initially I would send messages only one way without realizing that the appropriate pattern is to view it in a standard server-client relationship where there should always be a request and a response. Eventually I started viewing all the little applications running inside my larger program as self-contained capsules/servers that communicated among each other. However, it took me weeks of really intense study to get comfortable with. But, once you get comfortable with OTP you have a lot of built-in power (people rarely mention Mnesia, DTS, ETS gen_server but they are awesome).
Overall, my experience with Erlang/Elixir has shown me one big thing: pick the best tool for the job and there are a lot of jobs that you don't need OTP for. When you need to build Whatsapp, you should pick Erlang/Elixir. When you want to build a simple web app that only has a couple of end points and much of the dynamism is handled on the front-end, use Go, Node, or my personal favorite Clojure. Erlang/Elixir shine in the context for which they were built. But, they are not built for everything. And, if you only want the procedural aspects of the languages, there is no reason to choose them over Go, Node, Clojure, or Scala...all of which have solid approaches to concurrency.
http://elixir-lang.org/getting-started/pattern-matching.html