[wavemode]

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.

[yarekt]

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

[rqtwteye]

I think Newtonsoft is quite ok, but the MS library lacks a lot.

[nathanaldensr]

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.

[rqtwteye]

I may indeed be outdated. Does Microsoft now support deserializing into dynamic for example?

[neonsunset]

You should never do that. Please do not, and I can't stress this enough, use `dynamic`.

If you need DOM-style JSON handling, please use JsonDocument and JsonNode instead: https://learn.microsoft.com/en-us/dotnet/standard/serializat...

[rqtwteye]

There are plenty of cases where dynamic saves a ton of code.

[Yoric]

Are then even worse than Go's?

[tmpz22]

What is bad about encoding/json?

[TheDong]

What do you think the following does?

    type Data struct {
     Moon   string `json:"m"`
     Sun    string `jsn:"s"`
    }

    func main() {
     var d Data
 err := json.Unmarshal([]byte(`{"m": "m1", "M": "m2", "Moon": "m3", "s": "s1"}`), &d)
     fmt.Printf("err=%v, data=%+v\n", err, d)
    }

The answer is "Moon:m2 Sun:"

In list form:

1. Specifying unmarshaling shapes isn't checked by the compiler at all, typoing `json:"s"` as `jsn:"s"` should be a compiler error in any sane statically typed language, but in go, struct tags are untyped strings, it does not help you.

2. There are hidden unchangeable unmarsheling rules, like the fact that Moon=m2 is because unmarshaling is case insensitive, even when you specify an exact key name.

3. It's very slow, due to reflection.

4. The API also is not really type safe, things like `json.Unmarshal([]byte, d)` return an error, but should instead not compile because that's a type-error (non-pointer passed to function that requires a pointer).

5. It's slow. It requires a lot of allocation.

6. `json.RawMessage` is subtle and difficult to use

7. It can't stream, so it's very easy to open yourself up to DoS, or to run across json documents `encoding/json` simply cannot handle

I can't think of any other supposedly statically typed language, other than C, where the most commonly used json library integrates so poorly with the language's type system.

Rust's `serde` is what a good well-typed json library looks like.

[danielscrubs]

Google really is the IBM of the past.

No matter how smart people are or how much money they get, they won’t create something good if the incentives for the individuals aren’t there. Everyone wants to prove that they are above the pack by instead implementing llms from scratch and boosting on Twitter, even though they just followed a guide for a week.

Im not sure how to fix it, but I think it starts with management that are strong willed, have pride, are aligned with the customers are able to make the developers proud in turn and dishing out low status tasks to everyone from time to time.

[pkaye]

There is a version 2 being implemented to fix some of the known issues.

https://github.com/golang/go/discussions/63397

https://pkg.go.dev/github.com/go-json-experiment/json

[Yoric]

Thanks for the link. It looks like it might be a bit less painful?

It's still a pretty sharp disappointment to compare Go's json/encoding to Python's Pydantic or Rust's serde. One is all sharp edges, bad DX that permeates every use you make of them, and its only upside is that it provided as part of the stdlib. The other two are unobtrusive and just work.

[nextaccountic]

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.

[_xiaz]

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

[anonzzzies]

> 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.

[tome]

Gooby doesn't suck though. (I'm not joking.)

[anonzzzies]

> 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.

[aranchelk]

Definitely the same story for PureScript. I rarely reach for Haskell now because I know I can leverage virtually any library off of NPM.

[drewcoo]

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.

[aranchelk]

> It's hard to know from an interview what the quality of your Haskell code is.

Please explain.