A semi-interesting observation of the graph on one of the first slides: C# is highest on StackOverflow metric because the site has been historically concentrating more on Microsoft technologies. This also shows on how the different languages are separated by the diagonal line: technologies/languages closer to Microsoft are above the line and more "open" alternatives are under the line.
Because early adopters of the website were prominent Microsoft developers. Such as Jon Skeet. This caused network effects. To suggest just because a door is opened that every developer has an equal chance of walking through is absurd. This is not evidence that the general software community wants or needs c# more than any other thing. For many developers more traditional channels of q and a are still popular, such as mailing lists.
Jon Skeet is a Google developer. Well early Git adopters were Linux developers. Does it mean that GitHub is not really mainstream apart from a narrow group of people?
Assuming this isn't supposed to be rhetorical - yes, it works pretty well in fact. Windows's bizarrely ropey FS performance means it's a bit slower, but in general the experience is basically the same as using it under OS X. SourceTree/git gui/gitk are work the same.
It may be now (I'll take your word for it), but for the longest time, "windows support" was one of the only selling points anybody could provide for choosing mercurial over git (the other being some people prefer mercurial's branching/tagging to git's).
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.
Open source on Windows (and thus github usage) in general seems to be something of a second class citizen. There's Cygwin of course which brings you a lot of the open source tools, but it's far more common for Windows apps to be closed source it seems. Linux of course due to its nature tends to favor open source apps quite heavily, but it would be interesting to compare how many apps are closed vs. open on OS X as compared to Windows.
So? What percentage of those were (and is) in StackOverflow?
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.
It's kind of like how HN was initially very programming/computer science/lisp (?) centric in its early days (at least it seemed that way to me) primarily because of the people who read pgs essays and were interested in start-ups, etc.
That is of course a perfectly valid question and I'm sorry that you got down-voted for asking it. Indeed it was founded by Microsoft technology enthusiasts (Spolsky et.al.) and implemented with Microsoft technology stack. Possibly for these reasons it was (initially) populated heavily with .NET related questions.
> How can an open free Q&A site be concentrated on something?
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.
I was one of the first few hundred users and it was entirely .net/C# questions around this. This was mostly due to Jeff Atwood (at the time) visibility in that community - so it had a vast headstart, things have changed since then but that is how it started (well both Joel and Jeff were slightly more visible in the MS communities).
If I'm interpreting these slides correctly, I see an interesting bit of irony as a Clojure programmer. I can't tell you how many times I've been asked about my opinions of Erlang and I've lost count of how many times I've been told to learn Erlang because company X needs Erlang, or I should learn about scaling NoSQL databases, or whatever perception.
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 think it is used more than people perhaps realise - and if you are deep into clojure - you are probably already on the bleeding edge (at least as far as mainstream programmers are - remember there are a LOT of them) - thus would tend to come up against places that use erlang or clojure (self selecting?). (FYI I like both erlang and clojure, and have used both in anger).
I learned erlang before clojure - it I think the former helped me quickly pick up the latter, strangely.
Does that RedMonk chart not show that it is fairly cool? You have C# and Java at the top - I wouldn't call them cool, widespread, not cool. It's above, on both axes Arduino, Dart, TypeScript. It's in the vicinity of Clojure, Go, CoffeeScript.
I think the "cool kids" part of this is somewhat rhetorical. The whole point of the slides is basically what are the deficiencies of Erlang, and how can we fix them. The results are fairly interesting although not entirely surprising.
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.
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.
From the official docs: "The Arduino programming language is an implementation of Wiring, a similar physical computing platform, which is based on the Processing multimedia programming environment." and "the Arduino language is merely a set of C/C++ functions that can be called from your code."
Just saw this, but please note that Processing is not being run on the Arduino, but rather it is controlling the Arduino through the serial connection. And you can control an Arduino via a serial connection using just about any programming language, including Python and JavaScript.
So again, you can't run Java or Processing on the Arduino. Keep researching.
1. It is good the cool kids are not drawn to Erlang because then we would end up in the state Ruby and Node are now.
2. The biggest fail in IT - "I can't find experienced developers in Erlang/<some other tech>": Most employers are muppets. Rather than hire a decent developer and allow them to learn a new tech on the role, they scour the market for candidates that are probably just lying on the resume/CV. I have already seen resumes/CVs claiming 5 years+ of Swift on iOS. Quite a few retarded HR departments will fall for this.
Interestingly enough, in both the start up and corporate world I've seen hiring when the developer has NO skill in the language. This was true about Java, this was true about Ruby. This was true about python...
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?
If you're familiar with the Harry Potterverse, NEWTS are modeled on O Levels. Perhaps a bit like US Advanced Placement courses and tests, but much more institutionalized, and I gather they're part of how the U.K. university system can get away with 3 year bachelor's degrees.
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).
I think you are confusing O-levels and A-levels. O = Ordinary, A = Advanced, generally people going on to University would do A-levels, so leaving to get a job with only O-levels might be roughly equivalent to having a High School Diploma I think.
An O level is an obsolete English qualification. They got replaced by GCSEs.
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.
Compilers are well-suited for functional programming, which is why language designers seem to love it. Looping is almost never natural in a compiler. It's always recursion through trees of some sort.
I guess functional programming maps nicely to problems that do not simulate something through time and which primary work is not IO.
I think, the implication was that it attracts a disproportionate number of inexperienced yet very vocal and immature crowds. It creates and unfriendly and unpleasant community.
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.
Have to agree with the presenter. Simplicity and easy to learn are the killer features of node. Arguably, that is most important feature of any technology that one wants to work with.
As for callbacks for concurrency, I think once the language has support for coroutines (es7 generators), I think things will look more elegant.
I don't get this thing about having to find developers in a particular language. I work on a lot of OCaml programs, and have used and hired developers to work on the same programs. None of them had OCaml experience before, but they just learned it as they went along (because they are intelligent programmers). I actively don't want someone who only knows one language.
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.
There's something worth talking about, which is that a sophisticated and ingenious mess is orders of magnitude more costly than a simple minded mess. My experience with brilliant functional programmers is that it's hard to know whether you're getting someone who can use it as the best tool for a job in a simple, elegant, and maintainable way, or a cargo-cultist who delights in sophistication and cleverness and purity for their own sake, to great excess, and leaves a codebase that needs to be scrapped and re-written when they get bored and leave the company 6 months later, when everyone realizes that the twisty baroque monstrosity could just be handled by an imperative loop one quarter of the size that any high schooler could understand.
That isn't unique to functional programming. I've seen my fair share of Java and C# code bases that could best be describe as baroque monstrosities. It's like the authors read Design Patterns and then decided they absolutely had to use every single pattern at least once. The clean code book is also somewhat to blame here as people who go full retard on that tend to write stupidly complicated class hierarchies just so they can never have more than 1 line of code in any given method (effectively turning most classes into proxy wrappers for other classes providing some default values).
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.
This effect is even more pronounced with erlang, which has had several waves of popularity, going back to at least 2007. Because the language is harder to learn than most other languages due to the syntax being perceived as "difficult" (and it is for a week or two before you see its elegance) the barrier for entry is actually higher than many other languages.
Someone coming from Java has to learn both FP and the erlang syntax at the same time.
We hired a team of 10 Haskellers in 3 months with over 100 people doing our application task. It's really not hard to find developers, the market (at least for Haskell work) has plenty of supply and little demand. So, "learning Erlang/Clojure/Haskell" is a bad strategy if you just want to be employed, unless you are good enough to pit yourself against people with decades of experience, who write large amounts of open source code, who have built several projects in a host of other tech stacks and who can afford and are willing to take a (so far, up to 3x) pay cut to work full time in the language they love and helped build.
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.
I consciously and successfully did this with Python back when it was hard to find Pyguys. But, it took a killer app (Django use by media companies) to achieve self-sustaining demand growth. I also really, really love development in Python. Which probably was 80% reason of my success.
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.
An interesting thing is Common Lisp's place in the graph. It roughly translates to saying Common Lispers have less woes relatively. The CL nerds were right all along :)
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.
> 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.
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.
Java/Scala do allow you to do bad things. So add the following to Hershel's question:
"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?
> But as far as I'm aware the memory for a message in Erlang is shared between threads
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.
The large binary GC is actually pretty simple too: Shared binaries are refcounted; the references are in the process heap. When the references are GCed from the process, the shared binary can be freed. The reason that sometimes it takes a long time to free, is that some types of processes will get references to a large number of binaries, but not trigger a process garbage collection, leaving lots of binaries allocated in the shared space. Garbage collection for a process is only automatically triggered when the process heap would grow, so there are some common cases which result in bad behavior: processes that don't generate much garbage on their heap, but do touch a lot of binaries (often this is request routing); processes that grow their heap to some large size doing one kind of work, but then switch to another type that doesn't use much heap space, leaving a long time between GC; processes that touch a lot of binaries but then don't do any processing for a long time (maybe a periodic cleanup task).
Another common issues is taking references to a small part of a large shared binary.
That's exactly right. Erlang has per actor heaps, and it's garbage collector only stops the actors that are being garbage collected. This is highly concurrent and is a great property to have when you're trying to keep your response times low.
Hopefully with the upcoming Spores[1] feature in Scala, Akka will be able to enforce message immutability in some form. I was at Scala Days last week and the developer behind spores gave a great talk on the sort of immutability guarantees this feature will allow. Worth watching once it's posted online.
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...)
Well I wouldn't say "roll-over" to the new process is exactly simple but it is a good trick though. Forking has its interesting dark cases that have to be handled. Inherited file descriptors, what happens to threads, signals and so on.
Akka certainly does. At the company I work for all our heavy lifting is done by an Akka cluster running on EC2.
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...
In principle, transitioning from multithreaded to distributed with Akka is just a matter of configuration. I've never put this to the test, but akka does make this claim.
Erlang is not just classes with a thread and a queue attached to it. Anyone can do it. It is also fault tolerance. How many of the actor libraries support creating large number of processes that have isolate heaps? How many have completely concurrent and pause-less garbage collectors?
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 scheduler is preemptive. JVM doesn't have a preemptive scheduler so there are many situation where this is a huge plus.
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.
The value proposition of Erlang is a great deal more than "we have actors". Actors and message passing are "symptoms" of built from the core out for fault tolerant networked multiprocessing. If you need that you should prefer Erlang.
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.
It's different game. Nothing is shared (think: one gc per thread), can run 10M+ threads on one cpu and effectively schedule all of them (it has one-of-a-kind scheduler counting reductions, you cannot cpu lock even if you want), really transparent distributive programming, state of the art introspection: "login" to remote process on different node, see how many messages in the mailbox of some process, hot (= replace running code) code reloading etc.
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'm a long time Rubyist that is new to the Erlang world by way of Elixir mostly. I did use Celluloid in Ruby and it is actually what eventually lead me to Erlang/Elixir.
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.
Everybody thinks that the identifying characteristic of Erlang is the "Actor"(-like) model.
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.
Meta but I really wish we could ban the phrase "cool kids" from the programming community. It has a terrible connotation (high school cliques). And it feels out of place, especially when we're talking about something like practical choices about what programming language and tooling we choose. Even when talking about "trendy" languages and frameworks it's a poor choice of words because no one really make these choices to be "cool" and it would actually be interesting to take time to better understand what drives adoption (which, to be fair, is what the speaker of this talk is actually doing with his real work, he just choices a grating title). To be cool people wear trendy clothes, listen to particular music, etc. with the intent of signaling to other "cool" people. People make choices about programming languages & tooling because they've heard something good about the language, it seems to solve a problem you have or it's new and presumably someone else thinks it solves an existing problem in the programming ecosystem.
If you watch the video of the talk on vimeo below, the author addresses this issue head on at the start of his talk. The thesis is that there are many developers that use technologies for capricious reasons such as because other people do it, rather than for solid reasons of engineering.
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.
I'm definitely going to take time to watch his talk because the slides are excellent. And I agree with you wholeheartedly that the real world of software development is not wholly filled with reasonable people that strive for objectivity. Though in a serious conversation about technology adoption I'm not sure the best strategy is to target the unreasonable people. After all, are those even the people you want as advocates of your favorite technology? What you probably want is to win over the reasonable people and let the followers follow.
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.
It's not really much better on a browser. It took me about 10 minutes of clicking and swiping to figure out that you're meant to use the cursor keys to navigate. What a shitty user experience...
Seems like they used a Powerpoint-esque framework... it's not really intuitive when you think of it like the average web page, but for giving a presentation it's quite good
I feel I have a right to a bit of negativity after trying in vain for 10 or 15 minutes to use a website which is completely unusable on an ipad, and not very usable on other devices either (I just have to figure out that you're meant to use cursor keys). I'm just honest - if something is shitty I'll say so. I don't think that was a reason for getting downvoted. I've seen quite a lot of articles posted here with (usually gratuitous) swearwords in the title.
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.
