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

551–560 of 816 posts

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

#551

Post by aragilar »

shakna wrote: post #517
derriz wrote: post #494

Earlier quoted context omitted.

At least for Python dependency management, I'd hardly call it a mess these days and yes it was a horrible 10 years ago. The de-facto standard of venv and pip (using a requirements.txt file) is generally painless these days. To the extent that moving between MacOS, Linux and Windows is feasible for most (of my) Python work. And the Python 2/3 pain stopped being an issue a few years back. I haven't been forced because…

> The de-facto standard of venv and pip (using a requirements.txt file) is generally painless these days. Except Python themselves now recommend the third party, pipenv. [0] Which means that there are multiple authoritative voices saying different things, and that produces confusion. [0] https://packaging.python.org/en/latest/tutorials/managing-de...

Now being from 2017 ;) I suspect no-one has touched that file properly since then because of old scars :(

Part of the issue is there's not a lot of differentiation between most of the "project management" tools (apart from their age, which in some cases explains certain design choices), and the coupling of most of these to their PEP 517 backend doesn't help. There are backends where there is differentiation, such scikit-build, meson-python/mesonpy and enscons for wiring into pre-existing general purpose build systems (cmake, meson and scons respectively), maturin for rust, and flit-core as a bootstrapper, but given setuptools can be used without a setup.py now, I'm not clear on what some of the others provide.

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

#552

Post by kevindamm »

cybrexalpha wrote: post #338
zik wrote: post #311

Earlier quoted context omitted.

It sounds to me like there are some people who don't follow the style, rather than there not being a consistent style.

Which of those options do you view as 'the style'? One block, two blocks (core library and others), or three (core library, 3rd party, same-source-tree).

The first rule of any style guide should be "adhere to the conventions of surrounding code." So the answer to your question is it depends on what the convention in the file (and surrounding files) has already chosen. If there is only one grouping and you're adding enough imports that you have to choose between making two or three, then I would say use two because that is what the canonical & normative style guide recommends [0], but if you're working in an organization that has chosen to use goimports or has alternative guidance in its org-specific style guide then go ahead and make it three groups.

[0]: https://google.github.io/styleguide/go/decisions#import-grou...

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

#553

Post by lenkite »

simiones wrote: post #514
lenkite wrote: post #455

Earlier quoted context omitted.

Umm, you can unmarshall into a map[string]any, you know ? dataMap := make(map[string]any) err = json.Unmarshal(bytes, &dataMap)

You can, but then it's a lot of work to actually traverse that map, especially if you want error handling. Here is how it looks like for a pretty basic JSON string: https://go.dev/play/p/xkspENB80JZ . It's ~50 lines of code to access a single key in a three-layer-deep JSON.

Its more like 30 lines of code without the prints. However, one generally should code generic functions for this. The k8s apimachinery module has helper functions which is useful for this sort of stuff. Ex: `NestedFieldNoCopy` and its wrapper functions.

https://github.com/kubernetes/apimachinery/blob/95b78024e3fe...

Ideally, such `nested` map helper functions should be part of the stdlib.

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

#554

Post by sanderjd »

theshrike79 wrote: post #511
afiodorov wrote: post #462

I used to work for a Go shop. We dealt with financial data. I found it so annoying that many of my colleagues would use Go for one-off tasks such as aggregating CSV files, updating the database with some data, or fetching data from the database, and then trying to make a plot. I saw my colleagues again and again implementing basic algorithms such as rolling median, or finding a maximum. Instead of loading data into P…

> I used to work for a Go shop. We dealt with financial data. People dealing with finance are THE MOST risk-averse people I know. No new tool will be used without years of vetting and it'll still be blamed if something goes wrong - even if the new tool never touched that bit of the process =) Source: Consulted for a finance company and it was Ye Olde Java and COBOL all the way down =)

Using Go for data analysis is not the risk averse choice. If the comment were "everyone was using excel and maybe R and I couldn't get them to use python", then the risk aversion comment would be spot on :)

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

#555

Post by sanderjd »

classified wrote: post #537
afiodorov wrote: post #462

I used to work for a Go shop. We dealt with financial data. I found it so annoying that many of my colleagues would use Go for one-off tasks such as aggregating CSV files, updating the database with some data, or fetching data from the database, and then trying to make a plot. I saw my colleagues again and again implementing basic algorithms such as rolling median, or finding a maximum. Instead of loading data into P…

> Instead of loading data into Pandas and doing a group by SQL can do `group by`. No need for overkill with "data science tools".

If you have a csv, pandas is the "less overkill" route than loading it into a database to use sql.

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

#556

Post by rkangel »

m_a_g wrote: post #540
bborud wrote: post #94

People always under-estimate the cost of properly learning a language. At any given time I tend to have a "main go-to language". I typically spend 2-4 years getting to the point where I can say I "know" a language. Then I try to stick to it long enough for the investment to pay off. Usually 8-10 years. A surprising number of people think this is a very long time. It isn't. This is typically the time it takes to under…

Here is the thing: many software engineers don't need to learn a language "properly." When you start a new job, there will almost always be an existing code base, and you'll have to make contributions to it. Pattern recognition will get you a long way before you need to dive deep into the language internals.

This is true, and it makes the people who do actually know the language in depth extra valuable.

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

#557

Post by cloudrkt »

Dylan16807 wrote: post #425
nemo1618 wrote: post #279

Earlier quoted context omitted.

One of the most important qualities of Go is that it is actually possible to fully understand the language -- in the sense that you never see a snippet of Go code and think "wtf, you can do that?" or "hang on, why does that work?" Getting to that point takes many years, to be sure. But the language is simple enough, and changes slowly enough, that it is not an unrealistic goal -- the way it would be in C++, or Rust,…

Why is that important? Let's say one language has me find a weird rabbit hole every 50 hours of use, and I spend half an hour learning about it. Let's say another language has no rabbit holes, but I'm 5% slower at coding in it. Why would I not prefer the first language? (And 5% is supposed to be an intentional lowball. I'm confident I can find language pairs where my productivity differs by significantly more.)

Because not all code is yours. In a team, the time spent on “rabbit holes” adds up, increasing the risk of bugs. A `slower` but predictable language can lead to more consistent, maintainable code, which is often more valuable in the long run or last but not least, running in production.

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

#558

Post by lolinder »

theshrike79 wrote: post #511
afiodorov wrote: post #462

I used to work for a Go shop. We dealt with financial data. I found it so annoying that many of my colleagues would use Go for one-off tasks such as aggregating CSV files, updating the database with some data, or fetching data from the database, and then trying to make a plot. I saw my colleagues again and again implementing basic algorithms such as rolling median, or finding a maximum. Instead of loading data into P…

> I used to work for a Go shop. We dealt with financial data. People dealing with finance are THE MOST risk-averse people I know. No new tool will be used without years of vetting and it'll still be blamed if something goes wrong - even if the new tool never touched that bit of the process =) Source: Consulted for a finance company and it was Ye Olde Java and COBOL all the way down =)

It sounds like every single data operation in this shop was done with a "new tool" written on the spot in Go.

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

#559

Post by radicalbyte »

munksbeer wrote: post #465
radicalbyte wrote: post #443

Earlier quoted context omitted.

I have a nice way of testing a language - I download a couple of projects written by beginner / mid-level developers and not having commercial dependencies and see how much effort it takes to get them running. Python is one of the worst performers (and Java is shockingly bad too, although a lot of that is down to the way the JVM/language have been mismanaged). At least unless you're comparing it to very low-level lan…

> and Java is shockingly bad too, although a lot of that is down to the way the JVM/language have been mismanaged This is interesting and not what I would expect. Generally to get a java app running from github you'd install the correct JDK and that should be about it. Many projects will use maven, which will know how to obtain dependencies. Could you describe a typical issue?

Dependencies requiring you edit some random XML file somewhere on your machine to get them working.

That and the whole JVM fragmentation and not being able to touch Oracle because it's Oracle and they'll use it as an excuse to sue you (at least that's the impression I had, the entire lawsuits thing is why I left Java back in the day).

You can say the same about other package managers, but it's not very often that I have to add another source to apt unless I'm running in a locked-down environment.

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

#560

Post by AnimalMuppet »

drdaeman wrote: post #370
daghamm wrote: post #47

The author lists multiple reasons for this, but for me the biggest one is the first one: Go is good for almost everything . I have extremely good productivity when using Go. Once your project exceeds 100 lines it is usually even better than python. And yes, I am aware that Rustians did a survey where Rust was crowned as the most efficient language but in my reality (which may differ from yours) Go is simply the best…

I can totally agree that Go is good enough for most projects, to the extent it's a go-to choice for many. However, it's not always the best tool - frequently it wins just because it allows to prototype quicker. YMMV, but for me, it's not a love relationship, it's a love-hate relationship. > The language is extremely simple. Simplicity is a double-edged sword. It didn't even have basic generics for a long while, and i…

"Good enough" plus "I already know it" almost always beats the perfect tool that I don't already know.
Post reply on HN