Why The Cool Kids Don't Use Erlang
gar1t.com
gar1t.com
Compared to whole languages communities, for languages like PHP, Java, etc (and .NET), the number of "people who follow Spolsky and started using SO because of that" is miniscule. A statistical noise at best.
Does git even work well on Windows yet?
So, if git didn't work fine on windows for a long time, there would be plenty of time for network effects to entrench github as a non-windows site, and indeed that is the case. Github is where you'll find a lot of javascript, trendy open source projects, and even os x apps, but not so much windows stuff.
Very easily. For instance, if there was one toolset that either had worse user-facing documentation or a higher proportion of users who were bad at extracting solutions to specific challenges from general purpose documentation (perhaps because of mandatory use at the kind of places that employ such users), then one would expect that an open, free Q&A site with no deliberate focus would disproportionately end up serving that toolset.
There's a multitude of other ways such a Q&A site could end up with a skewed pool compared to overall use, too, that's just one example.
As far as I can tell, Erlang may not have a visible mind-share, but it has a much higher impact on mind-share and companies than it appears. Of course, this may just because many people consider Erlang / Haskell / Clojure languages that solve similar problems and are thus diametrically opposed to each other.
One person told me about how he asked a bunch of Haskellers about Erlang. Their answer: "Why would we learn a language no one uses?"
I learned erlang before clojure - it I think the former helped me quickly pick up the latter, strangely.
Does anyone know why they would include a hardware device among a ranking of programming languages? The most prominent language used to program Arduinos is probably C, followed by C++ and then AVR assembly.
I don't understand why they would include it among programming languages.
So again, you can't run Java or Processing on the Arduino. Keep researching.
It's also worth considering that these questions were asked of Erlang users, so it's the communities opinion of itself. I as an outsider would say my biggest issue with Erlang is that it's a highly event driven system and I don't like event based systems. Events are basically a more opaque form of GOTO and thus suffer the same criticisms. Events are sometimes the simplest way to model something, but as a general paradigm to solve all problems they really suck and do terrible things to your program architecture.
I think what would be a more interesting analysis is what cohort pre-selects themselves to functional languages, or projects where that technology is used? Out of all the software today, where is the most prominent functional code use and why?
My instructions where Keith will give you an hours instruction on how to use the PDP there is a book on fortan in the company library go and learn it.
Oh BTW that was leaving high school with 5 O Levels
I once worked with a Jamaican who'd earned several O Levels (Caribbean counties had their own versions of them modeled on the British system), he was very smart and productive (and like many other good EEs had his own MOSIS chip to flash).
Hearing someone got 5 O Levels immediately causes my talent antennae to twitch ^_^, and I'm not surprised he picked up FORTRAN easily (then again, I found it very easy to learn starting a couple of years earlier than walshemj, and I'll bet with quite a bit less mathematical maturity, just Algebra I and Geometry, with concurrent Algebra II, but all taught by very good to excellent teachers).
So change O -> A in the above, and O-Levels in the Potterverse correspond to OWLs.
Now a lot of jobs that where available to school leavers are graduate entry - talk about grade inflation :-)
The system used to be O levels ("ordinary") for high achievers, and CSE ("certificate of secondary education") for the rest. Both of those were replaced in about 1986/1987 with GCSEs. These are taken by school children at age 16 at the end of their secondary education.
They are followed by A (advanced) levels or other further education college course.
I guess functional programming maps nicely to problems that do not simulate something through time and which primary work is not IO.
Or are you saying Erlang is underdeveloped and you would prefer it that way. Because in my eyes, node is doing great.
Also the marketing innovation or advantage it proclaims -- "callbacks as a concurrency mechanism" are thought by some to betray a understanding of how concurrency can be handled in a sane way. So anything said or promoted afterwards is discarded just based on that assumption.
As an example it is like someone saying "oh we have this new awesome paradigm invented and it is a sorting algorithms and it compares every element to each other and swaps places". And everyone will say yeah cool that bubble sort or something like that. It is not very interesting. But you know with additional marketing and a vocal community one can grow and promote that idea despite the apparent flaws at its base.
Now node has very good qualities. It makes it very easy to get started, lots of packages. A lot of example. So those are probably things to look at and copy. And if you see that presentation (or watch the video) that is what the author drives towards. Simplicity. Easy to learn. And so on.
As for callbacks for concurrency, I think once the language has support for coroutines (es7 generators), I think things will look more elegant.
Also we're using RabbitMQ (written in Erlang). At the moment there are a couple of us mostly just reading the code and fixing the odd bug -- I guess we'll want to extend it in future. You just plug away at it, read the code, read the Erlang docs. It's not that difficult.
I agree with you that whilst familiarity with a rare, powerful language might be a signal of quality, lack of familiarity with rare languages does not imply the reverse.
Someone coming from Java has to learn both FP and the erlang syntax at the same time.
I suspect the problem is the two most popular ways of hiring developers in tech companies (tapping your network, and recruiters) fail hard at finding functional programmers, unless you yourself are a functional programmer.
tldr; The best success is achieved by doing things you are passionate about. Not chasing jobs/tech/money.
I monkey around with Erlang you know where the jobs are? Silicon Valley and Miami.
I couldn't find much Erlang anywhere in Sol Cal. There are jobs description that have Erlang in there but they put that only as an example of a functional language skill set they want.
Also SO is kind of geared towards entry level programmers, which applies to few CL folks.
And because the JVM does global stop-the-world garbage collection, which makes soft real-time implausible because of the unpredictability of GC affecting your actors. Erlang has per-process heaps.
Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library.
edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
Does it? Back when I was in HFT, we were definitely running a JVM with background thread GC.
It is really a fantastic piece of technology:
http://www.azulsystems.com/zing/pgc
Even just marveling at the complexity and how they got it working.
Otherwise, besides those tricks, how would you do it when you have multiple threads accessing objects on a shared heap?
Erlang's VM is another even wonderful piece of engineering. Each little process lives in its own memory heap. Then pauseless garbage collection become trivial. It has many other really cool and unique features (hot code reloading, inter-node distribution, ability to load C code, etc etc...)
"Assume developers are non-malicious and will only pass immutable objects across actor/future boundaries."
Also, I'm not that familiar with Erlang's memory model, so I might be wrong on this. But as far as I'm aware the memory for a message in Erlang is shared between threads - it's only local variables that use private memory. This means Erlang will also need some sort of concurrent garbage collector - does Erlang's version not stop the world, or at least the messaging subsystem?
No, the messages are truly copied: http://jlouisramblings.blogspot.dk/2013/10/embrace-copying.h...
edit: the exception being large binaries apparently
Yes and no. Some large binaries (a specific Erlang data type, that can say represent a packet or block of data from disk), will be shared and reference counted when passed between processes instead of copied. They are immutable just like most datatypes in Erlang. These binaries have a specific GC algorithm that it just might take longer sometime for them to be reclaimed. But it seems all that could presumably be done via atomic updates to counters and references.
In general most messages are copied on send. So implementation wise GC is very simple then. On another level because data in Erlang is immutable, the fact that messages get copied is also an implementation detail! One could conceive another implementation of a VM that only passes references and immutable data on message send (well minus when it sends it to another machine, of course). But that would make GC a bit more tricky just like in case of those binaries.
Another common issues is taking references to a small part of a large shared binary.
How hard are the limits of "soft" realtime?
Not quite. Every environment needs some shared memory semantics. In Erlang that's done with ETS tables, which don't undergo GC at all. Java's GCs are so good now, that, if shared data structures are used sparingly, would still give you better performance than BEAM. Plus, you have commercial pauseless GCs, as well as hard realtime JVMs.
> Basically the Erlang VM was created for this use case while the JVM was not, and its not something you can just add with a library. edit: Also the lightweightness of Erlang processes compared to Java threads[1] and hot code upgrades.
The JVM is so versatile, though, that all this can actually be added as a library, including true lightweight threads and hot code swapping (see Quasar[1]).
Nevertheless, BEAM was indeed designed with process isolation in mind, and on the JVM, actors might interfere with one another's execution more so than on BEAM, but even on BEAM you get the occasional full VM crashes. If total process isolation is not your main concern, you might find that Java offers more than Erlang, all things considered.
Do any of the library actor models offer something like that?
We found that the difficulty didn't lay in getting Akka to work in a clustered fashion—that was simple—but rather in architecting our backend's work distribution mechanics so as not to overload any given node. I blogged about our experience with Akka: http://blog.goconspire.com/post/64130417462/akka-at-conspire...
The closer abstraction is probably OS processes + IPC. Then you get closer to the spirit of it. And Chrome browser and other software take that approach. It isolates faults. But well, you have to do a lot more work around it and those are not exactly light-weight. Erlang processes are only a few K of memory each.
The closer abstraction is probably more like a distributed fault tolerant OS + processes using network transparent IPC.
Erlang's process are just threads pretending to be process which will spawn much faster than Akka.
I believe there are a few articles of Akka actor limitation versus Erlang's. I haven't delve deep into this but there are caveat with receiving message and how to handle it versus Erlang not having such caveat.
Coding in a language that isn't built with Actor/Concurrency in mind is a huge pain in the butt. Think of Javascript and Node.js and callback hells, which of course have push Javascript to adopt things such as future and etc..
Of course you can say Scala is built with concurrency in mind same with Clojure. But the underlying gears, the JVM was not compares to Erlang.
There are trade off between Erlang's VM and Java's VM. And if your requirement is a perfect match for either Erlang and Java you mind as well pick the best because coding against what the tool was intended for is just for people who enjoy pain and frustration.
Otherwise, the speaker seems like a good representative, but the presentation is so verbose it makes me want to concurrently handle his thesis asynchronously in parallel threads and remove the human... in jRuby, using Celluloid.
Edit: Essentially: some actor library for language X is not even remotely (if any) erlang. Maybe cloud haskell some day will be there, but its all introspection parts is basically nonexistent right now.
I think Celluloid is neat and a great set of abstractions for multi threading in Ruby. However, there's more to actors than just having it implemented in a library. Erlang's VM was designed for the actor model whereas Ruby MRI is not. Celluloid actors run in OS threads which can't scale to hundreds of thousands where as Erlang processes can. Using Celluloid with JRuby is closer but still not quite the same.
All that said, Celluloid is damn cool and Tony Arcieri did incredible work on it.
This is untrue.
This is also why all the "Actor"(-like) libraries grafted on to other programming languages that proudly proclaim themselves "Erlang-like" are wrong and make me laugh out loud when I run across them.
In my experience, huge swaths of the real world of software development are not wholly reasonable, objective, nor immune to groupthink. There's plenty of posturing and social signaling going on among developers.
Also, "other people do it" is not a capricious reason for adopting technology. It's not an engineering reason, but there are reasons to follow the crowd. If there is a crowd there will probably be lots of libraries, if there is a crowd there are more people that may do the thankless work of documenting and patching libraries, if there is a crowd there are more people to answer questions on stack overflow. The crowd may not be an engineering reason but it can definitely be a productivity reason.
The site also crashes the ipad most of the time, although I think that is just iOS being shitty rather than any fault of the website.