7 ms·

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what mak

I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type?

conor- 2y ago
I think it depends on what kind of data you're dealing with. If you know the shape of your data, it's pretty trivial to create a struct with json tags and serialize/deserialize into that struct. But if you're dealing with data of an unknown shape it can be tricky to work with that. In Python because of dynamic typing and dicts it's a little easier to deserialize arbitrary data. Go's net/http is also slightly lower level. You have to concern yourself directly with some of the plumbing and complexity of making an http request and how to handle failures that can occur. Whereas in Python you can use the requests lib and fire off a request and a lot of that extra plumbing just happens for free and you don't have to deal with any of the extra complexity if you don't want to. I find Go to be bad for interviewing in a lot of cases because you get bogged down with minutiae instead of working directly towards solving the exact problem presented in the interview. But that minutiae is also what makes Go nice to work with on real projects because you're often forced into writing safer code
deleted 2y ago
[deleted]
badrequest 2y ago
I think other languages cause folks to understand JSON responses as a big bag of keys and values, which have many convenient ways of being represented in those languages. When you get to Go and you want to parse a JSON response, it has to be a well-defined thing that you understand ahead of time, but I also think you adapt when doing this more than once in Go.
- ljm 2y ago
  If I had one complaint, it’s the use of ‘tags’ to configure how json is handled on a struct, such that it basically becomes part of the struct’s type. It can lead to a fair bit of duplication of structs whose only difference is the json handling, or otherwise a lot of boilerplate code with custom marshal/unmarshal methods. In some cases the advice is even to do parse the json into a map, do the conversion, and then serialise it again! The case I ran into is where one API returned camelCase json but we wanted snake_case instead. Had to basically create another struct type with different json tags, rather than having something like decoders and encoders that can configure the output. I like Go and a lot of the decisions it makes, but it has its fair share of pain points because of early decisions made in its design that results in repetitive and overly imperative code, and while that does help create code that is clear and comprehensible (mostly), it can distract attention away from the intended behaviour of the code.
  - cpuguy83 2y ago
    You could wrap it in another struct and use a custom MarshalJSON implementation.
  - duskwuff 2y ago
    As an aside, you may be interested in some of the ongoing work to improve the Go JSON serializer/deserializer: https://pkg.go.dev/github.com/go-json-experiment/json https://pkg.go.dev/github.com/go-json-experiment/json
    - ljm 2y ago
      That’s some good news that will hopefully smooth json handling out.
- kloop 2y ago
  var res map[string]any err := json.Unmarshal(&res)
  - scubbo 2y ago
    Uh huh....and what comes next? Trying to descend more than a couple of layers into a GoLang JSON object is a mess of casts.
    - Yoric 2y ago
      Especially when you're not certain of the type used for numbers.
    - lenkite 2y ago
      Well, one used to have https://github.com/mitchellh/mapstructure https://github.com/mitchellh/mapstructure which assisted here, but the lib then got abandoned.
      - jen20 2y ago
        Blessed fork: https://github.com/go-viper/mapstructure https://github.com/go-viper/mapstructure
    - kloop 2y ago
      The same things that happens in JS or python. If you get a key wrong it throws (panics in go)
      - scubbo 2y ago
        I wasn't talking about getting the keys wrong, but rather the insane verbosity of GoLang - `myVariable := retrievedObject.(map[string]interface{})["firstLevelKey"].(map[string]interface{})["secondLevelKey"].(string)` vs. `myVariable = retrievedObject["firstLevelKey"]["secondLevelKey"]` "Oh, but that's just how it is in strongly-typed languages" - that may well be true, but we're comparing "JS or python" with GoLang here.
jay_kyburz 2y ago
Hold on, did you just say Go doesn't have a Dictionary data type? I'm a Javascript, Lua, Python, and C# guy and Dict is my whole world.
- bitwize 2y ago
  Go has had a dict-like data type from the jump; they're called "maps" in Go. Some of early Go's design decisions were kinda stupid, but they didn't screw that one up.
- AmpsterMan 2y ago
  It does. https://go.dev/blog/maps https://go.dev/blog/maps What the poster was alluding to is that you usually prefer to deseialize to a struct rather than a record/dict/map
- zhengyi13 2y ago
  Not a programmer, so this is every programmer's chance to hammer me on correctness. No, Go doesn't have a type named Dict, or Hash (my Perl is leaking), or whatever. It does have a map type[1], where you can define your keys as one type, and your values of another type, and that pretty closely approximates Dicts in other languages, I think. [1]: https://go.dev/blog/maps https://go.dev/blog/maps
  - duskwuff 2y ago
    And, if you hate strong typing, there's always map[string]any.
    - dwattttt 2y ago
      Really, the mismatch is at the JSON side; arbitrary JSON is the opposite of strongly typed. How a language lets you handle the (easily fallible) process of "JSON -> arbitrarily typed -> the actual type you wanted" is what matters.
      - throwaway2037 2y ago
randmeerkat 2y ago
> I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type? Have you considered that your interview process is actually the problem? Focus on the candidate’s projects, or their past work experience, rather than forcing them to jump through arbitrary leet code challenges.
- travisd 2y ago
  Making an HTTP request and dealing with JSON data is a weed-out question at best. Not sure if you are interpreting the grandparent comment as actually having them write a JSON parser, but I don't think that's what they meant.
  - mjevans 2y ago
    I either had that come up in an interview recently myself, OR it wasn't clear to me that I was allowed to use encodings/json to parse the json and then deal with that. I happened to bomb that part of the interview spectacularly because I haven't written a complex structure parser in years given every language I've used for such tasks ships with proper and optimized libraries to do that.
- mapcars 2y ago
  Well these are not arbitrary, we work with a number of json apis on a weekly basis, supporting the ones we have and integrating new ones as well. This is a basic skill we are looking for, and I don't see it as a "leet code challenge". Candidates might have great deal of experience debugging assembly code or generating 3d models, but we just don't have tasks like that.
nrr 2y ago
It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue. This variability is honestly one of the reasons why I dislike interviews that require me to synthesize solutions to toy problems in a very tightly constrained window of time, particularly if the recruiter makes me commit at the outset to one language over another as part of the overall interview process. It's frustrating for me, and, having been on the other side, it's noisy for the interviewer. (In fact, my favorite interview loop of all time required that I use gdb to dig into a diabolical system that was crashing, along with some serious code spelunking. The rationale was that, if I'm good with a debugger and adept at reading the source that's in front of me, the final third of synthesizing code solutions to problems and conforming to institutional practice can be dealt with once I'm in the door.)
- throwaway2037 2y ago
  I like your story about debugging during an interview. I can say from experience, you always have one teammate that can just debug any problem. I am always impressed to watch and learn new techniques from them.
  - nrr 2y ago
    This has also been my experience, yeah. My interviewers were very interested in watching me rifle through that core dump. (: Ultimately, it feels to me like selecting for people who both can navigate existing code and interrogate a running system (or, minimally, one that had gone off the rails and left clues as to why) is the right way to go. It has interesting knock-on effects throughout the organization (in, like, say, product support and quality assurance) that are direly understated.
- marcus_holmes 2y ago
  My favourite tech interview (so far) was similar: "here's the FOSS code base we're working on. This issue looks like about the size we can tackle in the time we have. Let's work on this together and solve it". I got to show how I could grok a code base and work out where the problem was quickly, and work out a solution to the problem, and how I understood how to contribute a PR. Way better than random Leetcode bullshit, and actually useful: the issue was actually solved and the PR accepted.
Yoric 2y ago
There is a dict-equivalent data type in Go for JSON (it's `map[string]any`), it's just rather counter-intuitive. However, as a Go developer, I'm one of the people who consider that JSON support in Go should be burnt down and rebuilt from scratch. It's both limited, annoying, full of nasty surprises, hard to debug and slow.
- pjbster 2y ago
  There was a detailed proposal to introduce encoding/json/v2 last year but I don't know how far it's progressed since then (which you probably already know about but mentioning it here for others): https://github.com/golang/go/discussions/63397 https://github.com/golang/go/discussions/63397
sethammons 2y ago
I've done, literally, hundreds and hundreds of coding interviews and an http api was a part of lots of them. Exported vs non-exported fields and json tags are about the only issues I've seen candidates hit in Go and I would just help in those kinds of cases. Python is marginally easier for many. The problem was java devs. Out of dozens upon dozens of java devs asked to hit a json api concurrently and combine results, nearly ZERO java devs, including former google employees, could do this. Json handling and error handling especially confounded them.

conor- 2y ago

I think it depends on what kind of data you're dealing with. If you know the shape of your data, it's pretty trivial to create a struct with json tags and serialize/deserialize into that struct. But if you're dealing with data of an unknown shape it can be tricky to work with that. In Python because of dynamic typing and dicts it's a little easier to deserialize arbitrary data. Go's net/http is also slightly lower level. You have to concern yourself directly with some of the plumbing and complexity of making an http request and how to handle failures that can occur. Whereas in Python you can use the requests lib and fire off a request and a lot of that extra plumbing just happens for free and you don't have to deal with any of the extra complexity if you don't want to. I find Go to be bad for interviewing in a lot of cases because you get bogged down with minutiae instead of working directly towards solving the exact problem presented in the interview. But that minutiae is also what makes Go nice to work with on real projects because you're often forced into writing safer code

deleted 2y ago

[deleted]

badrequest 2y ago

I think other languages cause folks to understand JSON responses as a big bag of keys and values, which have many convenient ways of being represented in those languages. When you get to Go and you want to parse a JSON response, it has to be a well-defined thing that you understand ahead of time, but I also think you adapt when doing this more than once in Go.

ljm 2y ago
If I had one complaint, it’s the use of ‘tags’ to configure how json is handled on a struct, such that it basically becomes part of the struct’s type. It can lead to a fair bit of duplication of structs whose only difference is the json handling, or otherwise a lot of boilerplate code with custom marshal/unmarshal methods. In some cases the advice is even to do parse the json into a map, do the conversion, and then serialise it again! The case I ran into is where one API returned camelCase json but we wanted snake_case instead. Had to basically create another struct type with different json tags, rather than having something like decoders and encoders that can configure the output. I like Go and a lot of the decisions it makes, but it has its fair share of pain points because of early decisions made in its design that results in repetitive and overly imperative code, and while that does help create code that is clear and comprehensible (mostly), it can distract attention away from the intended behaviour of the code.
- cpuguy83 2y ago
  You could wrap it in another struct and use a custom MarshalJSON implementation.
- duskwuff 2y ago
  As an aside, you may be interested in some of the ongoing work to improve the Go JSON serializer/deserializer: https://pkg.go.dev/github.com/go-json-experiment/json https://pkg.go.dev/github.com/go-json-experiment/json
  - ljm 2y ago
    That’s some good news that will hopefully smooth json handling out.
kloop 2y ago
var res map[string]any err := json.Unmarshal(&res)
- scubbo 2y ago
  Uh huh....and what comes next? Trying to descend more than a couple of layers into a GoLang JSON object is a mess of casts.
  - Yoric 2y ago
    Especially when you're not certain of the type used for numbers.
  - lenkite 2y ago
    Well, one used to have https://github.com/mitchellh/mapstructure https://github.com/mitchellh/mapstructure which assisted here, but the lib then got abandoned.
    - jen20 2y ago
      Blessed fork: https://github.com/go-viper/mapstructure https://github.com/go-viper/mapstructure
  - kloop 2y ago
    The same things that happens in JS or python. If you get a key wrong it throws (panics in go)
    - scubbo 2y ago
      I wasn't talking about getting the keys wrong, but rather the insane verbosity of GoLang - `myVariable := retrievedObject.(map[string]interface{})["firstLevelKey"].(map[string]interface{})["secondLevelKey"].(string)` vs. `myVariable = retrievedObject["firstLevelKey"]["secondLevelKey"]` "Oh, but that's just how it is in strongly-typed languages" - that may well be true, but we're comparing "JS or python" with GoLang here.

jay_kyburz 2y ago

Hold on, did you just say Go doesn't have a Dictionary data type? I'm a Javascript, Lua, Python, and C# guy and Dict is my whole world.

bitwize 2y ago
Go has had a dict-like data type from the jump; they're called "maps" in Go. Some of early Go's design decisions were kinda stupid, but they didn't screw that one up.
AmpsterMan 2y ago
It does. https://go.dev/blog/maps https://go.dev/blog/maps What the poster was alluding to is that you usually prefer to deseialize to a struct rather than a record/dict/map
zhengyi13 2y ago
Not a programmer, so this is every programmer's chance to hammer me on correctness. No, Go doesn't have a type named Dict, or Hash (my Perl is leaking), or whatever. It does have a map type[1], where you can define your keys as one type, and your values of another type, and that pretty closely approximates Dicts in other languages, I think. [1]: https://go.dev/blog/maps https://go.dev/blog/maps
- duskwuff 2y ago
  And, if you hate strong typing, there's always map[string]any.
  - dwattttt 2y ago
    Really, the mismatch is at the JSON side; arbitrary JSON is the opposite of strongly typed. How a language lets you handle the (easily fallible) process of "JSON -> arbitrarily typed -> the actual type you wanted" is what matters.
    - throwaway2037 2y ago

randmeerkat 2y ago

> I do programming interviews and I found candidates struggling a lot in doing http request and parsing response json in Go while in Python its a breeze, what makes it particularly hard, is it lack of generics or dict data type? Have you considered that your interview process is actually the problem? Focus on the candidate’s projects, or their past work experience, rather than forcing them to jump through arbitrary leet code challenges.

travisd 2y ago
Making an HTTP request and dealing with JSON data is a weed-out question at best. Not sure if you are interpreting the grandparent comment as actually having them write a JSON parser, but I don't think that's what they meant.
- mjevans 2y ago
  I either had that come up in an interview recently myself, OR it wasn't clear to me that I was allowed to use encodings/json to parse the json and then deal with that. I happened to bomb that part of the interview spectacularly because I haven't written a complex structure parser in years given every language I've used for such tasks ships with proper and optimized libraries to do that.
mapcars 2y ago
Well these are not arbitrary, we work with a number of json apis on a weekly basis, supporting the ones we have and integrating new ones as well. This is a basic skill we are looking for, and I don't see it as a "leet code challenge". Candidates might have great deal of experience debugging assembly code or generating 3d models, but we just don't have tasks like that.

nrr 2y ago

It comes down to how the standard library makes you do things. I don't think there's any reason why a more stringly-typed way of handling JSON (or, indeed, a more high-level way of using HTTP) is outside of the realm of possibility for Go. It's just that the standard library authors saw fit not to pursue that avenue. This variability is honestly one of the reasons why I dislike interviews that require me to synthesize solutions to toy problems in a very tightly constrained window of time, particularly if the recruiter makes me commit at the outset to one language over another as part of the overall interview process. It's frustrating for me, and, having been on the other side, it's noisy for the interviewer. (In fact, my favorite interview loop of all time required that I use gdb to dig into a diabolical system that was crashing, along with some serious code spelunking. The rationale was that, if I'm good with a debugger and adept at reading the source that's in front of me, the final third of synthesizing code solutions to problems and conforming to institutional practice can be dealt with once I'm in the door.)

throwaway2037 2y ago
I like your story about debugging during an interview. I can say from experience, you always have one teammate that can just debug any problem. I am always impressed to watch and learn new techniques from them.
- nrr 2y ago
  This has also been my experience, yeah. My interviewers were very interested in watching me rifle through that core dump. (: Ultimately, it feels to me like selecting for people who both can navigate existing code and interrogate a running system (or, minimally, one that had gone off the rails and left clues as to why) is the right way to go. It has interesting knock-on effects throughout the organization (in, like, say, product support and quality assurance) that are direly understated.
marcus_holmes 2y ago
My favourite tech interview (so far) was similar: "here's the FOSS code base we're working on. This issue looks like about the size we can tackle in the time we have. Let's work on this together and solve it". I got to show how I could grok a code base and work out where the problem was quickly, and work out a solution to the problem, and how I understood how to contribute a PR. Way better than random Leetcode bullshit, and actually useful: the issue was actually solved and the PR accepted.

Yoric 2y ago

There is a dict-equivalent data type in Go for JSON (it's `map[string]any`), it's just rather counter-intuitive. However, as a Go developer, I'm one of the people who consider that JSON support in Go should be burnt down and rebuilt from scratch. It's both limited, annoying, full of nasty surprises, hard to debug and slow.

pjbster 2y ago
There was a detailed proposal to introduce encoding/json/v2 last year but I don't know how far it's progressed since then (which you probably already know about but mentioning it here for others): https://github.com/golang/go/discussions/63397 https://github.com/golang/go/discussions/63397

sethammons 2y ago

I've done, literally, hundreds and hundreds of coding interviews and an http api was a part of lots of them. Exported vs non-exported fields and json tags are about the only issues I've seen candidates hit in Go and I would just help in those kinds of cases. Python is marginally easier for many. The problem was java devs. Out of dozens upon dozens of java devs asked to hit a json api concurrently and combine results, nearly ZERO java devs, including former google employees, could do this. Json handling and error handling especially confounded them.