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

81–90 of 816 posts

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

#81

Post by Cthulhu_ »

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 data wrangling like that, Go may not be the best choice and a functional programming language may be a better fit.

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

#82

Post by gnfargbl »

DarkNova6 wrote: post #4

If all you know is a Hammer… I was searching for reasons why to use the Go-Hammer when there are comparable ones such as Java, C#, etc. but the article left me wanting. It strikes me that Go is riding the peak of hype languages, succeeding Rust and Node.js (which are all good pieces of technology and absolutely have their merit). And like with most hype driven decisions there is little (self) awareness of context and…

It feels extremely strange to see Go described as a "hype" language. It was somewhat hyped around seven years ago, which is when I started using it almost exclusively. Before that, it had a strong hype peak about fourteen or fifteen years ago, just after it was born.

However, it's not a young language any more. At this point I would actually submit the opposite criticism: it is a mature language which is perhaps starting to suffer from middle-aged spread, as the bored maintainers start to stuff in more features which the language doesn't genuinely need. (Example: Iterators. Sure they're nice, but does the language really need them?) If anything, I would say it's going more the way of Java than Rust or Node.

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

#83

Post by markusw »

nerdponx wrote: post #35
caerwy wrote: post #5

This article is not so much about Go but about choosing to specialize in one language ecosystem instead of spreading one's attention across several.

With the caveat that the broadened perspective you obtain by learning a variety of languages will make you better at your primary language.

I would say there are many, many other ways to broaden my perspective, not just learning and using a different programming language. There are so many things to learn!

(And I don't necessarily suggest not learning different languages, if one fancies that. I just don't use any other ones at the moment.)

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

#84

Post by Cthulhu_ »

acyou wrote: post #49

Go is not a single tool. It's a vast set of tools. Using mostly Go is kind of like using mostly Milwaukee power tools. Then, when you need a tape measure or a level or a tool bag, if you're reasonable you can use another brand, where it makes sense. You still should always try to use the right tool for the job. Doesn't mean it has to be the absolute best tool or such a thing exists, the best tools are often the ones…

While this is true, especially in larger corporate settings there needs to be some pushback if someone tries to introduce a new tool, because a new tool or language means you need to include it in hiring and training.

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

#85

Post by tail_exchange »

busterarm wrote: post #66
tail_exchange wrote: post #44

Earlier quoted context omitted.

Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel. Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.

Obviously but if you look at a lot of Go projects you tend to see it. Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people. And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainl…

Because you are attributing things that are common in enterprise environments (Bazel, monorepos, and Protobufs) to Go. It's fine if you hate these things, but saying that these are the defaults of Go isn't right, and I bet that's why people are hating on you. There's nothing default about them in Go. If you work with enterprise-y code, it shouldn't be surprising that a lot of them are going to follow Google's steps.

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

#86

Post by Cthulhu_ »

lawgimenez wrote: post #3

I wish Go had a decent UI framework though.

TBH this can be said about most programming languages, and this is one reason why Node / Electron based UIs are so popular because there's so many well-developed UI options then that are automatically cross-platform.

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

#87

Post by laserlight »

danielvaughn wrote: post #48
busterarm wrote: post #20

Earlier quoted context omitted.

I didn't mean faster in terms of execution time but in terms of development time. And more expressive is doing more with less code. We're at complete opposite ends of the spectrum here -- how that indicated to you that I meant assembly...

I'm genuinely curious which language you see as having a better development time. I don't mean that as arguing, I'm actually curious. I don't know much about Go but I just began learning it 2 days ago. I'm already 50% of the way done through a really nice TUI app, and I haven't even touched the docs. To me at least, it feels extremely productive so far.

Developing with Python is faster.

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

#88

Post by BrandoElFollito »

I like that.

I have a similar attitude with Python and Go as back hammers and Quasar (Typescript + Vue + Vite + components) as the front hammer.

Whenever there is a date in Python I exclusively use Arrow (even for the simplest, most basic ones).

I know it is not effecive, but I am an amateur dev and having these hard rules keeps me from testing something new all the time.

I leave this for home automation and docker services where my motto is "fix it until you break it"

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

#89

Post by konart »

mapcars wrote: post #41
markusw wrote: post #21

Earlier quoted context omitted.

I wasn't aiming for that. My point is more: I know Go already, it's good enough for my purposes, so I'm using that as my hammer. I could just as well have been Java or C# I learned eight years ago and used that for everything. :)

Just looking at Go after having experience with Erlang and Crystal, does it still have a narrow-minded view of what features language won't support? Like I remember there was a whole drama about generics, errors being simple strings and always returned without being able to raise them, is this attitude still there or have things changed?

Well, Go has generics now and you can do quite a few tricks with errors. In the end error handling logic is up to developer.

UPD: thankfully Go does not try to bring in every "feature" possible. Not without consideration at least.

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

#90

Post by Cthulhu_ »

hk1337 wrote: post #27

This is the same thing everyone says about PHP, negatively. Don't make Go the next PHP. PHP has some good updates recently but it still has some people with a negative experience with it.

PHP fell foul of adopting other languages' features to try and make itself more popular though (OOP, typing, err... I don't know PHP anymore), Go is actively resistant to it. Or, resistant as in, "sell it to us" where it's a really hard sell to add something to the language that can already be done in a different way. The error handling debate from a few years ago was great, a few really well thought-out proposals were made but in the end, people were like "...this is not an improvement over how we do it right now".
Post reply on HN