Comment by wavemode
2 years ago
The problem, as posed, seems to be "when you hire $LANG devs, all they want to do is write $LANG, even when $LANG is poorly suited to solving the problem at hand".
To me, this doesn't seem to be a problem unique to functional programming languages. You'd have this problem when choosing any language outside the mainstream, I think.
From the article:
> Then, one thing leads to another, and you're knee deep in learning about homotopy type theory or continuations or whatever. 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.
You wouldn't have this problem in the first place if the language you chose -did- have an actively maintained JWT library.
Like, a company that chooses Haskell is a lot more likely to run into this problem than a company that chooses Clojure, due to the simple fact that Clojure can use Java libraries, whereas Haskell exists within its own isolated ecosystem. So, between the two, the likelihood is generally lower that you will, in the first place, run into a problem that Clojure can't easily solve.
So, in my mind, this essentially boils down to the same sort of risk/reward assessment you always need to make when choosing any language for any project.
As with everything, there’s some truth to that, but also C#’s json parsing libs are sub-par… and that’s really the least that a modern language should do well
I think Newtonsoft is quite ok, but the MS library lacks a lot.
Your information is very out of date. Microsoft long ago worked with the Newtonsoft.Json creator when introducing their native .NET replacement for Newtonsoft.Json. Performance in the new set of libraries is excellent as they rely heavily on the newer performance primitives like Utf8String, Span, etc.
4 replies →
Are then even worse than Go's?
What is bad about encoding/json?
4 replies →
I don't see why anyone should be a $LANG dev. All programming languages suck (there is this theoretical language that doesn't suck, but it isn't invented yet). Surely $LANG devs recognize that their language sucks, right?
And that's why we switch languages constantly. For some problems, some languages suck a little less.
I agree with your sentiment for the inverse reason.
Most programming languages are pretty neat. Learning is a joy. That's why language hops are fun and common.
But yes, few things make me cringe more than someone selling themselves short by introducing themselves as a $LANG dev
> And that's why we switch languages constantly
I only have one life and I prefer not to suffer too much; switching languages is not helping me at all in preventing that suffering.
Gooby doesn't suck though. (I'm not joking.)
> You wouldn't have this problem in the first place if the language you chose -did- have an actively maintained JWT library.
Actively maintained does not mean it’s good. We have to read and fork all libs we use (regulatory) so it won’t end up getting hacked etc, at least, less likely and a lot of ‘actively maintained libraries’ especially npms/pips are total garbage. We often spend less time just rolling ourselves than figuring out if this unreadable, overarchitected resume driven garbage even works.
Definitely the same story for PureScript. I rarely reach for Haskell now because I know I can leverage virtually any library off of NPM.
That approach also keeps you from hiring disgruntled devs.
It's hard to know from an interview what the quality of your Haskell code is.
It's probably relatively easy to find out in an interview that you had a lot of trouble with Clojure and are currently porting to Java.
> It's hard to know from an interview what the quality of your Haskell code is.
Please explain.