Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

Post reply on HN
Print view View original

231–240 of 816 posts

Re: Go is my hammer, and everything is a nail

#231

Post by runeblaze »

nasretdinov wrote: post #218
jayd16 wrote: post #214

Earlier quoted context omitted.

I'm asking this earnestly but is Go suitable for native GUI apps (not web)? 3D graphics/Games? Audio processing?

For games potentially Ebiten, I believe it has some audio processing support too.

Probably not Ebiten for 3d games. To be fair at this point when you are doing somewhat specialist things Go starts to lose its edge. I remember trying to replicate some Numpy code in Go and that was a pain. However that's just because Python is too good at scientific things.

Re: Go is my hammer, and everything is a nail

#232

Post by cpuguy83 »

ljm wrote: post #224
badrequest wrote: post #208

Earlier quoted context omitted.

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.

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 s…

You could wrap it in another struct and use a custom MarshalJSON implementation.

Re: Go is my hammer, and everything is a nail

#233

Post by absoflutely »

jay_kyburz wrote: post #221
mapcars wrote: post #151

Earlier quoted context omitted.

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?

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.

Go has maps, json parsing and http built in. I'm not exactly sure what this person is referring to. Perhaps they are mostly interviewing beginners?

Re: Go is my hammer, and everything is a nail

#234

Post by sbhitz »

gcau wrote: post #229
blt wrote: post #216

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now. Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I g…

Is this something Go intentionally didn't add?

https://go.dev/doc/faq#overloading

Re: Go is my hammer, and everything is a nail

#235

Post by kloop »

badrequest wrote: post #208
mapcars wrote: post #151

Earlier quoted context omitted.

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?

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.

    var res map[string]any
    err := json.Unmarshal(&res)

Re: Go is my hammer, and everything is a nail

#236

Post by ridiculous_leke »

jillesvangurp wrote: post #139

I understand the sentiment. My goto hammer is Kotlin, which I like a bit better than Go. But that's a highly subjective thing of course. And I use plenty of other languages as well (including very occasionally some Go). It's not about what is better in general but about what is better for you. Better here means less time wasted with figuring out syntax, tools, APIs, frameworks, etc. Once you know how to do a certain…

I am planning a switch to Kotlin just because it seems more readable. As someone who has done both how do you rate Kotlin's STL?

Re: Go is my hammer, and everything is a nail

#237

Post by hello_computer »

blt wrote: post #216

I really like most aspects of Go, but as someone who writes a lot of numerical code, no operator overloading is a deal breaker. It's so hard to accept something like Add(Scale(s1, vec1), Scale(s2, vec2)) over s1 * vec1 + s2 * vec2. So I stick with Python and C++ for now. Rust is really appealing as a C++ replacement, but it has too many rules to replace Python for one-off scripts. Still need to try Nim and Swift, I g…

Something like Elixir's function composition operator (->) would go a long way toward smoothing that out, but they rejected that as well.

I think the best we can do at the moment is runtime expression evaluation with something like this:

https://github.com/expr-lang/expr

or this: https://github.com/Knetic/govaluate

Re: Go is my hammer, and everything is a nail

#238

Post by duskwuff »

ljm wrote: post #224
badrequest wrote: post #208

Earlier quoted context omitted.

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.

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 s…

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

Re: Go is my hammer, and everything is a nail

#239

Post by [deleted] »

Cthulhu_ wrote: post #81
fifilura wrote: post #71

Where I feel go is lacking is for data wrangling. Group by, filter, map, join. It is just very error prone, inconvenient and slow to implement with for loops.

Go does support functional programming constructs (as it has first-class functions) and there are some FP libraries out there, but they are discouraged because the execution is so much slower; Go is not optimized for FP, and chooses "clumsy" for loops over clever functional programming because the loops have mechanical sympathy and are simply faster in execution speed. That said, if you have a use case with a lot of…

[deleted]

Re: Go is my hammer, and everything is a nail

#240

Post by duskwuff »

zhengyi13 wrote: post #227
jay_kyburz wrote: post #221

Earlier quoted context omitted.

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.

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

And, if you hate strong typing, there's always map[string]any.
Post reply on HN