3 ms·
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 han
by wavemode 2y 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.
- yarekt 2y agoAs 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 2y agoI think Newtonsoft is quite ok, but the MS library lacks a lot.
- nathanaldensr 2y agoYour 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 2y agoI may indeed be outdated. Does Microsoft now support deserializing into dynamic for example?
- neonsunset 2y agoYou 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/serialization/system-text-json/use-dom https://learn.microsoft.com/en-us/dotnet/standard/serializat...
- rqtwteye 2y agoThere are plenty of cases where dynamic saves a ton of code.
- neonsunset 2y agoNo, it never does. There are better containers than dynamic, that do not have its performance drawbacks and have way better UX. The fact that this does not raise an eyebrow is a legitimate concern over the state of the codebase that uses it!
- Yoric 2y agoAre then even worse than Go's?
- tmpz22 2y agoWhat is bad about encoding/json?
- pkaye 2y agoThere is a version 2 being implemented to fix some of the known issues. https://github.com/golang/go/discussions/63397 https://github.com/golang/go/discussions/63397 https://pkg.go.dev/github.com/go-json-experiment/json https://pkg.go.dev/github.com/go-json-experiment/json
- Yoric 2y agoThanks 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.
- TheDong 2y agoWhat 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.
- drewcoo 2y agoThat 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 2y ago> It's hard to know from an interview what the quality of your Haskell code is. Please explain.
- aranchelk 2y agoDefinitely the same story for PureScript. I rarely reach for Haskell now because I know I can leverage virtually any library off of NPM.
- nextaccountic 2y agoI 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.
- anonzzzies 2y ago> 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.
- _xiaz 2y agoI 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
- tome 2y agoGooby doesn't suck though. (I'm not joking.)
- anonzzzies 2y ago> 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.