> Meanwhile, you're a week behind on that Jira ticket for issuing JSON Web Tokens because there's no actively maintained JWT libraries for Gooby.

> I've seen buggy pre-1.0 libraries used for critical production softwareNot "critical" as in "if it goes down it's really annoying", but "critical" as in "checks and stores passwords" or "moves money from one bank account to another". simply because it was a wrapper library written in a functional language, as opposed to a more stable library written in an imperative language.

I do think if you're using a niche language in an industrial capacity, you need to know how to work with libraries outside the language. Admittedly this is easier for some languages than others. But I've run into candidates who wanted to interview in clojure but who didn't know how to call into pre-provided java libraries.

The post is based on a misguided premise. Don't hire based on experience with a niche language. Hire based on the ability and motivation to learn and use it effectively. Many interesting and useful things I learned on past jobs--actually almost everything except BASIC, Atari machine/assembly, and datastructures+algorithms. I got hired for a Ruby/Rails position having no experience with either on an invite from their CTO.

> Are you sure you don't use Gooby just because it's fun to write?

A lot of technically minded people do not have the self-awareness to answer that question honestly even to themselves.

Wouldn't desire to learn a language like go or c show they want to be a software engineer, while desire to learn a functional language (unless they learned it from djisktra) show that they don't care. Some functional languges (lisp) are designed for easy throwaway code, while some like haskell are for proving correctness. You can't know just from the fact that someone uses a functional language that they are a rockstar. In reality they probably just started with it cause someone told them to. IMO the false premise is that most first learns with some language js/c then they learn a functional language later.

Anyway I'd be very skeptical of a unix dev who doesn't use c, just like I'd be skeptical of a webdev who doesn't use javascript/typescript. In part due to the reasons laid out in the article, but also that there is a big difference between a polyglot and a native, a polyglot may be able to make themselves understood, but a native understanding the culture, won't waste time designing something others in the culture have no context to understand, since they don't. First they would do research starting from a cultural touchstone

We live in a corporate culture where small shops have been psyoped by big tech to throw away their senior devs. Losing a senior is a tragedy that regularly blocks progress for years, this practice has become so normalized that nobody noticed the wider software industry has been stagnate for 2 decades. (part of that psyop were those tiktok ads)

I dabbled in F# which is quite good but I think the future belongs to mainstream languages adopting functional features.

Or just use Scala which has has a robust library ecosystem already, and everyone criticizes the BDFL for being an out of touch academic so you don't need to worry about appeals to authority.

Some months ago, I applied for a job. Seemed like a cool place, very off-the-wall, maybe a match for my mildly annoying but generally harmless personality. They work in Haskell, and I thought, "that would be really interesting. I wonder what they do with it, why they selected it, the costs and benefits they see," etc. I've played with Haskell a little, admired its beauty and elegance, but I wouldn't really think of it when selecting a language for a modern multiuser webapp, device apps, etc.

So I had the initial call with the hiring person, and she posed a sort of dilemma: essentially, do you want to work with Haskell so you can ship frequently, or so you can create beautiful and elegant code that you can reason about?

And I said "both." The purity and power of Haskell appeals to me for deep, almost spiritual reasons, but I have encountered friction in my ability to be as effective with it as Python or Rust or TypeScript. Perhaps that's a personal deficiency, in which case I'd like to address it and be a better engineer. Perhaps it's a weakness of the language, in which case perhaps I can address it and move the world ahead in some small way.

She was not satisfied with that answer. I got the feeling that Haskell was a quirky choice, t3h penguin of doom holding a spork. All that really mattered at the end of the day was shipping, because after all, that was what paid people's salaries.

So I decided they were not a serious company.

But yeah, I tend to blame the same underlying phenomenon identified here: that ZIRP enabled companies to make the same mistakes that, previously, only a senior engineer could make. And I think ZIRP also contributed to a lot of title inflation, ensuring that senior engineers could make mistakes that, previously, only a junior engineer would make. Combine the two and we have companies picking languages based on vibes.

https://news.ycombinator.com/item?id=40628050 - Discussed (and [flagged]) at the time. 133 comments from June 9, 2024.

My opinions on functional languages in a practical professional setting is that they largely seem like a curiosity and a bit of an oddity when you encounter them in business software at work. I worked at a company migrating a huge amount of engineering data between two different PLM systems (in our case this was data around peristaltic pumps - 3D models, 2D designs, code, electrical schematics etc). We were using model manager for the source system and windchill for the target system and model manager uses Lisp for its automation of data management tasks and despite the fact I'd had to use Miranda (the precursor to Haskell) in my functional programming module at university (UCL) I found using Lisp for something so kind of quotidian didn't really give me the same feeling that 'this is something really special' when using it for something fairly mundane. It didn't really use any of the advantages of functional languages (and their advantages are sort of more around quite academic things anyway).

Going out of your way to use functional languages at work seems a bit like deliberately using a fountain pen and purposefully writing all business communication in a handwritten beautiful cursive style - it's kind of a cute affectation rather than actually of benefit