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

621–630 of 816 posts

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

#621

Post by Ma8ee »

tmountain wrote: post #486
_xiaz wrote: post #473

Earlier quoted context omitted.

I believe people over-estimate the benefit of properly learning a language. 3-12 months seems to be sufficient for the specialisation benefits to outweigh the small hit to language competency. My strategy is to be a generalist superficially learning specialized languages.

Whatever time frames you apply, the only way to really learn a language is to use it. Reading a book, blog articles, and watching videos on YouTube won't give you the hands on experience necessary to internalize how everything works.

True, but actually reading a book about the language to understand the philosophy behind it and its trade offs speeds up the process enormously.

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

#622

Post by martinclayton »

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 =)

My experience is different to that.

I'd say people and businesses that best understand and balance risks against potential rewards are the most successful. I know a couple of skydiving accountants...

Use of innovative tech in finance is one way for companies to gain an "edge" which can make them a lot of money. I wouldn't characterise people working in those particular areas as more risk averse.

OTOH finance businesses (esp. those that manage other peoples money) are regulated and can't put new tech into Production without careful change control. But this evolves over time, and controls were looser in the past.

There's a steady creep of regulation and control into tech used in finance outside and around IT: so called EUC (End-User Computing). This can be a source of "wrong tool for the job" syndrome. I've seen some hellish SQL written by non-IT people, but it got the job done. It's also an area where source code control, testing, and release processes are inevitably more human and error-prone.

There is a culture clash internal to large finance between "move fast and break things!" and "nothing can change, ever - too risky!" This leads to a mixture of the very old and very new, and inevitably, more complexity. Achieving homogeneity once the heterogeneous is out of the bottle is very hard - attempts to do so often (always?) lead to a variation on the xkcd "Standards" situation https://xkcd.com/927/

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

#623

Post by physicsguy »

Lyngbakr wrote: post #487
physicsguy wrote: post #482

Earlier quoted context omitted.

I've had exactly the same experience, it's a nice language but using it for things it's not suited for like data exploration makes no sense to me. Production data pipelines on the other hand, but only after testing them well and as you say, making sure there's good testing if you're implementing things like numerical routines.

Do you have experience implementing ETL pipelines in Go? I think it'd be a better fit for us over our current language, but I'm curious to hear from people who've actually done it.

Yes. It works fairly well. With that said, I've got a feeling that life would be a lot easier to change around if we weren't using it, we end up writing a lot of code to do relatively simple things.

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

#624

Post by randomdata »

IshKebab wrote: post #460
randomdata wrote: post #316

Earlier quoted context omitted.

> And yes popular languages do have real type safe enums. Right, as we already established, but which is only incredibly narrow support within the features in question. While you can find safety within the scope of enums and enums alone, it blows up as soon as you want the same safety applied to anything else. No popular language comes close to completing these features, doing it half-assed at most. We went over this…

> Are you just not familiar with programming? I am very familiar with programming. The only things you've said so far have been attempts to redefine well-understood terms and now ad hominem and incoherent rambling. If you don't have anything useful to say...

There is no redefinition. You know that because you literally repeated what I said in your comment, so clearly you are accepting of what was said.

Seemingly the almost verbatim repetition, yet presented in a combative form is because you don't have familiarity with programming, and thus can only respond with canned responses that you picked up elsewhere. If you do have familiarity, let's apply it.

So, do you actually want to discuss the topic at hand, or are you here just for a silly fake internet argument?

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

#625

Post by Dylan16807 »

randomdata wrote: post #411
anonymoushn wrote: post #404

Earlier quoted context omitted.

Does the compiler do that? That sounds extremely unlikely, especially because an interface with only one implementation can store the nil type tag or a tagged pointer to an instance of that implementation.

The nil interface is another implementation. I mean, unless it is being used as the sole implementation, but I think we can assume that isn't the implementation being talked about given that it isn't a practical implementation. We're talking about where there is one implementation.

If a nil is another implementation then interfaces with a single implementation don't exist.

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

#626

Post by physicsguy »

fifilura wrote: post #499
Lyngbakr wrote: post #487

Earlier quoted context omitted.

Do you have experience implementing ETL pipelines in Go? I think it'd be a better fit for us over our current language, but I'm curious to hear from people who've actually done it.

What is current language and have considered doing it in SQL? I don't think go will be the right choice. It is just not its strength.

It depends on what you're doing right? The commenter here replied to me, and we're processing really large data files that are deliberately not in a SQL database due to size, only artefacts of these files eventually make it into a time series DB. For us Go works well and is performant without any great difficulty. For domain specific analytics we generally use Python, and Go just calls out to an API to do them.

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

#627

Post by Spivak »

umvi wrote: post #615
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've mostly seen the opposite - pandas and jupyter notebooks shipped directly to production because the data scientists and AI guys didn't know how to do anything but python. As a result, the solutions were not performant and often had lots of runtime crashes due to python's more loose typing

I'm not sure how you're going to fix this given the data science tools are in Python. Are you gonna implement a half-broken 20% of numpy/scipy for a one-off program and then try to port?

These libraries hide a lot of complexity and implementing even a few operators is a project.

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

#628

Post by whateveracct »

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.

Hopefully you never forgot to initialize a numeric field and had it default to 0!

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

#629

Post by markhahn »

andreif wrote: post #483
sph wrote: post #419

Earlier quoted context omitted.

2012: Python is Awesome! 2014: Python is a pain in the butt to manage packages and dependencies, how the hell am I gonna deploy this? It's still a mess 10 years later unless you live deep in the ecosystem and know what third-party solutions du jour to manage that complexity. At least we have Docker now. Also let's not forget the Python 3 migration fiasco that lasted ~2008-2018 and I still find myself porting librarie…

Dependencies is a sign of weakness.

and automatic internet-supplied dependencies are a sign of supplychain vulnerability

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

#630

Post by supermatt »

Spivak wrote: post #627
umvi wrote: post #615

Earlier quoted context omitted.

I've mostly seen the opposite - pandas and jupyter notebooks shipped directly to production because the data scientists and AI guys didn't know how to do anything but python. As a result, the solutions were not performant and often had lots of runtime crashes due to python's more loose typing

I'm not sure how you're going to fix this given the data science tools are in Python. Are you gonna implement a half-broken 20% of numpy/scipy for a one-off program and then try to port? These libraries hide a lot of complexity and implementing even a few operators is a project.

i dont think they are complaining about the libraries, but rather the scratchpads and notebooks that people use for ideation and evaluation being moved directly into a production environment because the authors don't have the experience or time to build more structured, efficient and maintainable code.
Post reply on HN