Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've never used Erlang, but have read up on it a few times over the years. I think a large reason why it's not more popular is that the concepts are so abstract and hard to grok, partially because -- as you mention -- there is a lot of overloading of terms from Unix land. e.g. a VM isn't a VM by the definition used in most colloquial contexts [0], a process isn't a Unix process, etc. And yet despite all this, you can run it on Unix systems. This is confusing.

There isn't really a solution to it, since it's not like Erlang can start from scratch and rename everything, but I really think this kind of cognitive overhead discourages people from learning new languages. The same challenges exist in languages like Haskell.

That said -- "devs are too lazy to read" is no reason to stop innovating. Erlang seems quite cool and I hope I get an excuse to use it in production one day.

[0] Yes, I know that Beam satisfies all the technical requirements to be a VM (https://en.wikipedia.org/wiki/Comparison_of_application_virt...) My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor.



> My point is more that, colloquially, people usually refer to a VM in the sense of a guest operating within a Hypervisor.

Python, Ruby, Java, and JavaScript want a word with you. Bytecode VMs being called just 'VMs' colloquially is extremely common.


Yeah, I mean, ultimately my argument is that devs are too lazy to understand documentation, but of course I don't consider myself one of those, so I can't defend the claim that my biased and imaginary sample of devs understands VMs in the same way as your sample.

That said, I will stand by the argument that most people (myself included) are too lazy to understand documentation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: