Hacker News new | past | comments | ask | show | jobs | submit login
[dupe] Developers love trendy new languages, but earn more with functional programming (arstechnica.com)
86 points by rbanffy on Mar 13, 2018 | hide | past | web | favorite | 78 comments

This article is based on the StackOverflow survey available at: https://insights.stackoverflow.com/survey/2018/.

Discussed at https://news.ycombinator.com/item?id=16574316.

Normally we'd merge the comments into the main thread but nearly all of them here are about the title of this one.

Oops ... sorry about that (I missed the other discussion). Want me to delete this instead?

No worries! No, it's usually better to let existing discussions continue.

Wait, I thought functional programming _is_ trendy!

(Currently reading https://www.manning.com/books/functional-programming-in-c-sh... and greatly enjoying it)

It is. And I get this is a joke, but the title says 'trendy new languages'. So it's talking about new languages which are trendy, not just trendy languages (or just new languages) :D

But I guess 'developers love trendy [programming] languages' is like saying 'teenagers love trendy teenager apps'. aka, if developers love the language, then it pretty much is by definition trendy.

IMHO this is a misleading outcome.

What isn't represented to remove a bias from the numbers is the number of years of experience and education. It's highly unlikely that bootcamp graduates will be working in OCaml/Erlang since these will bias to people with CS degrees who understand the why behind functional.

Misleading is the right word.

Wrong conclusion: E[Earnings|Language=OCaml] > E[Earnings|Language=Javascript]

More accurate conclusion: E[Earnings|Language=OCaml,School=Top10,Major=DualCS/Math] >> E[Earnings|Language=Javascript],

E[Earnings|Language=Javascript] >> E[Earnings|Language=OCaml,School=Who?,Major=Not DualCS/Math]

This can be stated more generally:

If you didn't explicitly control for it, your results probably only reflect selection bias.

I'd say that it is definitely possible for selection bias to indicate a causal relationship though. Because hiring and compensation isn't just controlled by technical ability or productivity. So there is chance a supposedly non-causal indicator will have a direct impact.

For instance, let's a dev with a really unremarkable resume gets paid significantly less than his coworkers in a really hot subfield because all his coworkers have a top-10 stem degree, research with top professors, and work experience at really hot startups. It's likely if he is a decent negotiator the underpaid dev's compensation will eventually revert to the mean. That will be the compensation of an extremely marketable dev if he can sell himself as a dev with really valuable experience.

while it's true that usually, you need to understand the basics of CS to write good functional code, we've often found that that doesn't need to be 100% correct.

we've placed a good amount of functional engineers from a Math, Physics, Logic sometimes even Biology background that had a strong affinity for functions and found OOP generally painful.

I think it's that functional programming is more of a niche with an even more disparity between demand/supply regarding the salaries.

Oh, and usually HR people have a pretty bad filter when it comes to functional engineers, so they only filter by keywords

There is a disproportionate usage of Erlang in the finance industry. That might be part of its high salary.

OCaml as well-- the first place that comes to mind is Jane Street.

I've met a few devs from Jane Street - very nice people. Had the pleasure of meeting Yaron Minsky as well (he was a guest lecturer). Harvard had an entire intro course dedicated to OCaml...while it was a nice introduction to functional programming I can't say I've ever touched the language since...

The first and the only.

What about Ahrefs? Also, some people must be using Ocaml's cousin F#, or Jon Harrop would not have a job.

Edit: oh, finance. Right.

Last time I've checked, Harrop was everything but happy with the current F# situation (tooling, ecosystem, etc.)

In years of finance mostly involved in trading, exchanges, and risk - from prop firms to bulge bracket. I can count 3 times I've seen Erlang used. None of them have been major projects.

It is still overwhelmimgly dominated by C++ and core Java with some Python in there too.

I mean, that's three times more than I've seen it used. I'd wager that finance is a second only to telecoms when it comes to "industries that use Erlang".

Even if AI is evil, most developers don't think it's the fault of the programmers. Fifty-eight percent say that ethics are the responsibility of upper management, 23 percent the inventor of the unethical idea, and just 20 percent think that they're the responsibility of the developer who actually wrote the code.

It's shocking to me that people would blame the invention of the idea. I think talking about unethical ways of doing business before they're adopted is useful, because it gives society a chance to frame the debate and possibly even criminalize the behavior before entire companies depend on it for their business model. Most unethical business behaviors are semi-obvious anyway, in the sense that they're going to occur to many people right away rather than waiting on a genius stroke of inspiration that might come this year or five years from now. If you think of an unethical idea at work, odds are that five other people are already thinking of it too, and one of them is planning how to implement it. Seize the initiative. Talk about the idea and frame it as evil. Make it a joke among the engineers. "Of course if we were really evil, we could do X." "Nice, what a way to fuck our customers over and make money from it." "Not that I could actually bring myself to do it." "Where's Martin Shkreli when you need him?" (Reference a company that went down in flames, a person who went crying to prison. It doesn't matter if Facebook or Mark Zuckerberg is a better comparison; don't mention a company with a thriving business or a person making bank with impunity. Success gives everything a halo.)

If you do this effectively, then the company has to consider the cost of embracing an idea that has already been framed as evil. They'll have to consider that they won't have the most enthusiastic cooperation from some of the engineers, that it will decrease people's pride and job satisfaction, that some engineers who have other opportunities might decide to leave so they can still be proud of their work. They will have to consider morale outside of engineering as well, because people in other departments will be saying, "What is the deal here? The engineers seem to think that what we're doing is really slimy. Am I going to be embarrassed to tell my friends about this?" Management might still go ahead with it, but on the other hand they might decide to do something else instead. And if they do it, they'll at least profit a little bit less because of the friction you created.

This bit stuck out to me as well, though you took it in a different direction. I wonder why they didn't have an "all of the above" option to that question: all of those people had a responsibility. "Just doing my job" can be an excuse, but only up to a point. There's a reason Werner von Braun is mostly remembered for the Tom Lehrer song about him:


Many unethical things are only obvious if you actually understand the low lever implementation of the system. So, no many of these things would never get implemented if developers did not share that they where possible.

It's shocking to me that a large portion of people would blame their bosses but not the developer. If your boss tells you to do something illegal, and you do it, you're just as much a criminal as they are.

And yet, the programmer may have a responsibility to bring a salary back to his family. People will call him a criminal for obeying his boss, but they usually will not come and help him if he does the right thing and takes flak for it.

This thread is somewhat framing this as ethics vs salary, but what I found most useful in your statement was the (somewhat implicit?) thought that there is often no ethical way to earn a salary for some programmers.

While this has not been true in my personal experience, I must say that I've been very fortunate in life. I can totally understand and see how this may be true for some programmers.

I wonder if, as an industry, there was a better way for us to handle such situations.

Programmers enjoy a rare market where employers compete for hiring a good dev, not the other way around. Unless lots o employers do things so unethical you can't stand working on them, you can just walk away from an unethical boss and spend time digging through numerous invitations from other companies.

You may simply not be a good dev. What then?

I live in a market where finding a job quickly makes it another shitty job, and only after amply signaling your submissiveness (ah, Europe). You get no unemployment money, because it's you who quit, of course.

There's also the fact that you're the good guy and yet you're the one getting shafted, while the arses above keep doing what they do. Anyone with a brain will sense something's wrong, and will rethink their ethics.

Programmers are highly in demand. The idea that a programmer and their family are going to be homeless because they didn't do what the big, evil boss said is not very convincing.

But programmers are in high demand because of the many artificial barriers that are put up to keep most of them out of work. Just because you have a programming job now does not mean you will make it through the 16 weeks of programming trivia that the next employer expects before considering you a potential hire.

I may agree that it is not a convincing argument for anyone, doing any job, but I'm not sure the programmer part makes any difference.

I'm not sure that I can agree with your statement. Most non-crappy developers can have a new job within a week or so.

I really don't know if I agree with yours. As a developer in a rural area, while there are certainly jobs for programmers, they are never advertised. You have to find them by word of mouth. It could easily take more than a week just to discover what jobs are available.

Moving isn't realistic within the span of a week. Remote might be an option, but brings its own challenges.

There are many devs making plenty maintaining old legacy systems in languages long since considered dead on sites like Stack Overflow. The biggest missing qualifier on that survey is the obvious "developers who are likely to answer a stack overflow survey....", or even use SO at all.

An org usually only hires functional programmers for specialized tasks, and specialization generally pays more. It's not about pay here, but about the nature of niches. The downside career-wise is that is that you have fewer alternatives, domain and geography, if your specialty slumps.

This sounds like the most likely explanation to me. The only programmers I've personally worked with that wrote code in a functional language for their day jobs were data engineers using Scala for an Apache Spark data pipeline. They weren't paid well because they wrote functionally, they just filled more of a niche role with a higher barrier of entry than a typical web developer.

I've been doing Scala professionally for a decade (so definitely not limited to Spark). There was a clear correlation between Scala jobs being higher paying and more interesting than what I was doing previously.

With React + Redux, a developer ends up writing functional code willy-nilly. If you use promises / futures, your code also has a high chance to end up monadic.

I see that React is also a niche, but it a rather less narrow one than most.

> Globally, F# and OCaml are the top average earners

Don't know about F# but the job market for OCaml consists of about 2 companies. What good is high average when you can count job openings on one hand?

I like OCaml, I wish it was more popular.

As long as the number is >0? That means that demand > supply. And the granularity is right, as we only tend to need over programming job per hacker.

This is hardly surprising. Everything new is exciting at first. Yet when it comes to making a decision what tools to use in production, I suppose most developers have the presence of mind to choose something robust and battle-tested.

But most of the functional languages in their list, are also new....

and some of the ones on the trendy list are functional (Rust)

I would question your assertion that Rust is functional.

Rust does have a lot of features that a lot of other functional languages have, Algebraic Data Types, closures. But one thing Rust misses is purity. Although you do have to be explicit about when you are mutating state, I think it would be very hard to actually write a program that doesn't, and it certainly wouldn't make for idiomatic Rust code.

I guess we are going into the definition of what makes a language functional. Rust is a great language and it does attempt to solve the same sort of problems that functional languages solve - multi threading, no surprising mutations.. It just uses a different paradigm to functional in order to solve them.

Rust doesn't have higher kinded types so I'm pretty sure it's not functional

Rust isn’t solely functional because it focuses on safe manipulation of mutable state (or to say, it transforms a functional solution to the state problem into a non functional one); it is multi paradigm, though. However, that has nothing to do with higher kinded types.

Scala is over a decade old, Ocaml two decades, Erlang three decades.

Not new.

Even Kotlin, as much as I love to complain about its (non-) approach to effects and lack of HKT, is more functional than the languages it's likely displacing.

I don't think it really works to think of Kotlin as a functional language. It's really more of a modern OO language that happens to have borrowed a couple more-or-less cosmetic things (default constructors, companion objects) from Scala.

Modern OO has adopted many things from FP, but I'm sure there's an old Smalltalker waiting in the wings, ready to come out and observe that a lot of this is equivalent to Renaissance Europeans rediscovering a lot of ancient Roman texts by reading their Arabic translations.

> I don't think it really works to think of Kotlin as a functional language. It's really more of a modern OO language that happens to have borrowed a couple more-or-less cosmetic things (default constructors, companion objects) from Scala.

My baseline for a "functional language" is ML; wikipedia's description of it opens "Features of ML include a call-by-value evaluation strategy, first-class functions, automatic memory management through garbage collection, parametric polymorphism, static typing, type inference, algebraic data types, pattern matching, and exception handling." Kotlin notably has all of those, and equally notably doesn't really have any other central, language-defining features (with the possible exception of delegation); in many ways the core languages is no more or less than ML.

> Modern OO has adopted many things from FP, but I'm sure there's an old Smalltalker waiting in the wings, ready to come out and observe that a lot of this is equivalent to Renaissance Europeans rediscovering a lot of ancient Roman texts by reading their Arabic translations.

Disagree; these ideas are not borrowed from Smalltalk, they were present in ML (ML and Smalltalk are contemporaries but quite independent of each other) which retains its own distinct lineage. Scala and Rust are openly of ML descent, and I think Swift also acknowledges an ML influence.

Is Kotlin's type inference and destructuring more powerful than what they describe in the tutorials? I have only spent a little time with it, but my take-away was that it had much weaker type inference (more similar to C#'s than ML's), and its version of pattern matching was rather limited compared to what you get in ML. And most of the rest of that feature list is also shared with Java.

Moreover, as far as language-defining features, it's hard to ignore how OO the type system is. Working with Kotlin, you won't be dealing exclusively with algebraic types and modules; you'll be dealing heavily in classes and interfaces and extension methods and all that.

For similar reasons, I hesitate to call Scala a true ML descendant. It takes a lot of obvious inspiration from ML, but the standard libraries are all intensely OO in their idiom, the type inference is still quite limited, etc. You can program in a very functional style in Scala if you want, but Odersky is pretty explicit about that not being what he was really about, and if you want to have a good time of it you'll want to be importing Scalaz or Cats rather than relying too much on the standard libraries.

Actually Odersky has been pretty explicit about Scala being related to OCaml, which is certainly a true ML descendant.


Unless things have changed really recently, Kotlin does not have pattern matching, which definitely disqualifies it from being an ML-alike.



It's especially disappointing that the supposed reason was it was "too complex"

Erlang has been around since the 70s...

It first appeared in 1986. Perhaps you are thinking of ML

No, I was confusing its date with the date for actor model, which is 70s. Thanks!

I've consistently seen functional programming used as leverage to offer lower salaries outside of a few companies known for paying well like Jet and Jane Street.

Breaking: People who work at Jane Street make a lot of money.

"functional" is so ambiguous in that context…

That's kind of what I was thinking - "trendy" new languages include Scala which is very functional.

But not particularly new.

Could it be true, erlang and clojure are assuciated with higher income both worldwide and in US? A little back, I remember, functional programming was thought as academic and not fit for production. Has that changed? This is interesting and almost too good to be true.

Erlang has been used for decades in telcom, ATM, and financial software and probably much more. It was literally invented to be used in a production telcom system.

> Has that changed?

Very much so, and not just functional languages. In addition the increasing adoption of functional languages into the "real world," Javascript is commonly written in functional style these days, even before we touch things like Clojurescript, Elm, PureScript, or ReasonML.

n=1 I am a clojure web consultant http://www.hyperfiddle-consulting.com/ (Hopefully not distasteful/shilling, just relevant context)

Markets have weird corners that move over time and for a while I made all my money doing React.js work. I make more than all of my peers, probably because I have a great portfolio, another correlation-but-not-causation. But does it really surprise anyone that the 24 year old who read Haskell books instead of netflix-n-chill, grew up to find more competitive opportunities?

I did eventually break through the freelancing rate ceiling by building a Clojure ecosystem product and offering product-related consulting now.

If WhatsApp manages to use Erlang at quite a scale I guess it's not that academic?

I suppose a lot of our phone calls and data traffic are handled by Erlang code. I don't think it was ever "academic" except in, perhaps, the sense it was exhaustively thought out.

What do people that use Ocaml all day actually do?

Have support group meetings about the build system and lack of threading.


More seriously, I think at this point it really is dominated by the Jane Street monoculture. Which is getting to be worrisome, because it means that the ecosystem is getting to be pretty optimized for the needs of a trading firm. ML was also originally designed for writing new languages (it stands for MetaLanguage), so it stands up well there, too, but I think that SML might still be more popular for the purpose. And a lot of "trying new ideas" stuff has moved to Haskell because the compiler is so easy to hack on.

I know its used for compilers, trading(jane street), soon webdev(reason)

More then soon for webdev, 50% of facebook messenger's web client is written in Reason[0].

[0] https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

Unikernels. Docker bought Mirage.


Jane street.

,,Fifty-eight percent say that ethics are the responsibility of upper management''

With the same reasoning management could say that ethics is the responsibility of investors who decide about how ethical a company should be and customers who may pay for the non-ethical product.

If you look at the actual survey results, you get a much more nuanced picture.[1]

58.5% would not write code for an unethical purpose, and only 4.8% would unconditionally say yes. 79.6% think that they have to consider the ethical implications of code they write.

The 57.5% who said that management is most responsible for ethical decisions would probably agree that developers are responsible as well, just maybe not as much as management (who have far more agency to just assign the task to someone more willing if anyone refuses). Since the options were limited to be mutually exclusive, those considerations were not captured by the survey.

[1] https://insights.stackoverflow.com/survey/2018/#ethics

FP people are generally older and more experienced, like Hickey have said "Clojure is for old tired programmers" (Love thinking, tired of pressing keyboard - description I fit pretty much too).

Young FP adepts, especially converts in their early 20s, especially those who are "in trend", are a pure disaster.. don't pay them too much..

Cobol developers are also generally older, more experienced and can also make a lot of money.

Developers love trendy new languages (like C and Basic), but earn more with Cobol.

>> trendy new languages (like C and Basic)

C and Basic... trendy? One doesn't often see those words in the same sentence. Or is this like bellbottom trousers, where I've waited long enough and they've come back around to fashion???

Keep in mind I'm speaking about languages relative to Cobol.

> Developers love trendy new languages (like C and Basic), but earn more with Cobol.

Those developers also have valuable knowledge of the systems they work on, something new Cobol developers won't have.

Obligatory link to "Evolution of a Haskell Programmer": https://www.willamette.edu/~fruehr/haskell/evolution.html

Applications are open for YC Summer 2019

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