It seems like a case of different incentives for different people.

If the incentive is to ship product then choosing the language you already have a team for makes the most sense.

If you are choosing based on hiring a new team, then the current flavors work. 20 years ago that was Java. Today it's C#. 20 years from now it'll be something else.

If you are a developer looking to grow a resume for the next job, then it's a double-edged sword. Sure it's easier to get a C# gig. But it pays less because you're in a bigger pool. It's harder to stand out. Conversely it's harder to get say a Cobol gig. But it's easier to build a profile in the Cobol community (simply by being under 80 years old) and there is a Lot of work around, and is very well paid.

Equally something that's marginally popular now will have a long tail and can be very lucrative. Erlang might be obscure, but there are plenty of shops who would love to pick up another experienced, capable, erlang developer. You're a bigger fish in a smaller pond.

So yeah, language is like most things, dependant on your point of view. That's why we gave so many of them.

20 years ago, Java was already becoming pretty big in the enterprise. Today there are plenty of Java jobs from your bog standard banks and insurance companies all the way up to the BigTech companies. The biggest ponds don’t have fish using Erlang.

BTW, what languages do you think all of those BigTech companies that pay well are using?

I just keep bringing up C# because that’s the language I have the most experience with. But substitute $any popular language.

Certainly not C#, lol.

Even OCamls share would be bigger within big tech, thanks to Meta.

C# is much bigger then OCaml. Even F# is bigger than OCaml!

(and I say this as a big fan of OCaml)

> within big tech

I saw that and C# is still bigger, largely due to Microsoft.

I work in BigTech now. In the last two years I’ve done projects in C#, Java, Go, Python and Typescript…

Erlang might be slightly more obscure, but there are plenty of big household names using the language - Klarna, Bet365, and William Hill are all household names. And that's excluding the obvious cases of Ericsson or WhatsApp.

Except for WhatsApp, from what I can find on Levels, all of the companies you named pay on the low end of even enterprise dev salaries.

I would be more likely to hire a JS dev if they have Elixir experience not less, but I am not in the enterprise world.

Work is not only about money for me. My best work environments have been a small team of skilled people tackling a big problem. For this we would use whatever is the best tool for the job, regardless of its outside popularity.

I don't think it's always easy. it's been quite a struggle becoming proficient in Haskell, just drinking from the firehose of type theory you need to get things done.

also note that Jane Street does everything in OCaml. I can't believe it's bad for their employees' careers. probably because they're not looking for the same jobs as the average JavaScript pleb.

> That doesn’t mean I would be a competent Android developer.

Sure you will. There’s no “Android developer”, there’s Java/Kotlin developer who uses Android SDK.

And I assure you that someone who needs an Android app written wouldn’t care about your distinction or are you claiming that a Java developer who never wrote an application for Android would be just as effective as one who had?

Who would you rather lead the development of your Android app? Someone with no experience with Android or someone with previous experience.

I’ll absolutely pick competent Java developer who never touched a line of Android over mediocre “Android” developer.

And how do you think that would work out if you’re hiring a lead developer to oversee a team who is trying to release an Android app?

That depends on the team leader and how well they can take suggestions. It's a team, not everyone will have the same background and, probably, nor would it be best that they did.

So if the team lead that I’m hiring to be the subject matter expert can’t be the go to person for technical solutions based on relevant experience in the domain, who should it be?

A team lead does not need to be:

a) the most experienced amongst the team in any particular language

b) the most experienced amongst the team in any particular domain

c) the go-to person for any particular problem

The whole point of a team is to cover several different sets of knowledge and experience because no one person can know it all or do it all. A leader does their best to enable this collective to produce the best it can.

Leaders know this.

The language is only easy if you have basically learned the language already. Java, C#, C++, Python, Go etc. all differ but fundamentally they are all the same language with different amounts of window dressing. So yeah if you know one of them it's easy to "learn" the others. But I wouldn't really call this learning a new language.

It's a fundamentally different ask to learn Haskell, datalog, SaC. You are actually learning a new language instead of just the flavour of the week imperative programming.

If the language is the hard part, something is wrong with it. Usually. I've seen and user a whole slew of opinionated languages, and they almost always have a big chunk of problems they will be awkward to use for, or even almost insoluble. Every succesful one supports multiple programming paradigms, better or worse, usually decently.

Now the real stuff that can cause problems is bad tooling and lack of support. You cannot code your things when you're trying to fix the compiler, build tools or the debugger.

The last time I had a job where I only had to learn “the language” to be effective was 1999 programming in C and FORTRAN on VAX and Stratus mainframes. By 2000, “knowing C or C++” didn’t do any good without knowing MFC, COM, etc.

What good is a language in 2022 without a complete ecosystem of frameworks for most jobs?

Even esoteric languages have a relative complete ecosystem of frameworks. I use Haskell in my day job and I never had issues finding a library.

Haskell is not particularly esoteric, but heavily opinionated.

Libraries cannot change that basic fact - there are just problems it will be extremely unsuited for.

Java has some of the same problem by the way in reverse. (Package handling, forced garbage collection and unknown real time and memory usage characteristics.) The difference being that Java's core has much less important opinions about algorithms, while Haskell tries to make everything functional or it is awkward.

So, while Haskell will be hard to use for problems best described in an imperative way (in addition to other issues say Java has), Java will only have serious problems where memory and runtime determinism are paramount.

It so happens that a lot of the programming is done in imperative way. Including the libraries.

Say I’m developing an application that needs to interact with cloud services.

The last time the third party Haskell SDK for AWS was updated was in 2014. I do see a third party GCP SDK. But if GCP and Azure works like AWS, as soon as a new API is released by a service team, all of the officially supported SDKs automatically get updated.

I am sure there are other service providers that have SDKs and code samples for popular languages.

I would assume it's just a REST service which has an openapi spec. Then you can just generate the client.

How much more “productive” do you think they would be just by being able to import a module in any of the supported languages?

https://aws.amazon.com/developer/tools/

I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages? What are the chances that any new developer could ramp up faster or already knows Boto3 (the AWS SDK for Python)? If they have an issue, they can go to StackOverflow or raise a ticket with their TAM.

Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”

AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.

> How much more “productive” do you think they would be just by being able to import a module in any of the supported languages?

The same language? Maybe a few % considering a client is a small part of what you need to create. A different language? Depends on the comparison. I would be tens to hundreds % more efficient in Haskell then in Go or Python.

> I believe the list for GCP and Azure are about the same. What are the chances that your problem is such a special snowflake that it can’t be solved with one of those languages?

Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.

> Which would have more assurances are designed correctly, the one from the vendor or yours? I was able to take advantage of new APIS for one of AWS services the day it was introduced, no need to waste cycles on creating my own wrapper. Creating a wrapper around my cloud providers APIS, “doesn’t make the beer taste better”

> AWS’s SDKs automatically take care of retries, exponential back offs, wrapping the APIs to be idiomatic including logical exceptions being thrown, any underlying changes, etc.

Did you ever try openapi generated clients? They can handle retries and exponential backoffs as well. There is no design to be done here. It just exposes the API as designed.

None of the cloud providers provide the internal specifications used to autogenerate the SDKs for the languages I listed. In the case of Boto3 (the Python AWS SDK), while there are one to one generated mappings from the spec, there are also higher level constructs for the most popular services like S3 and DynamoDB and also helper functions like Waiters for asynchronous operations where you need to poll for an operation to be complete and Pagers that handle get request where the requests are being polled. Sure you could do all of this yourself. But again, “does it make the beer taste better”?

This isn’t meant to be a rah rah AWS is the bees knees. It’s just the cloud provider I know the best (and the one I work for), I’m sure knowing MS, the developer experience is just as good as AWS. I just don’t have experience with it.

> Of course it can be solved in those languages. I can also solve it in Assembly or brainfuck with enough elbow grease. What matters is speed of implementation and correctness. With the exception of Rust all these language have debilitating flaws.

What’s the old saying about it’s a poor craftsman that blames his tools? If you can’t be productive in any of the nine languages that are popular enough to be supported by the major cloud providers, does that say more about the tools or the craftsmen?

The latest update to Amazonka (the Haskell library for AWS) was 3 hours ago.

https://github.com/brendanhay/amazonka

I use the package directly from GitHub in my project.