Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

511–520 of 816 posts

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

#511

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

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

#512

Earlier quoted context omitted.

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

I think I'd want to try to decode into map[string]interface{} (offhand), since string keys can be coerced to that in any event (they're strings in the stream, quoted or otherwise), and a key can hold any valid json scalar, array, or object (another json sub-string).

That of course works, but the problem is then using this. Take a simple JSON like `{"list": [{"field": 8}]}`. To retrieve that value of 8, your Go code will look sort of like this:

  var v map[string]any
  json.Unmarshal(myjson, &v)
  lst := v["list"].([]any)
  firstItem := lst[0].(map[string]any)
  field := firstItem["field"].(float64)
And this is without any error checking (this code will panic if myjson isn't a json byte array, if the keys and types don't match, or if the list is empty). If you want to add error checking to avoid panics, it gets much longer [0].

Here is the equivalent Python with full error checking:

  try :
    v = json.loads(myjson)
    field = v["list"][0]["list"]
  except Exception as e:
    print(f"Failed parsing json: {e}")
[0] https://go.dev/play/p/xkspENB80JZ

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

#513
post #494
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…

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…

It still won't beat the deployment speed of

   scp executable user@host:direc/tory/
that you get with Go.

I still use python for stuff that never leaves my computer, but in most cases if I know I need to run it on Someone Else's Machine (or even a server of mine) I'll reach for Go instead.

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

#514

Earlier quoted context omitted.

Go maps have a defined type (like map[string]string), so you can only put values of that type in them. A JSON object with (e.g) numbers in it will fail if you try and parse that into a map of strings. As others have said, the issue with Go parsing JSON is that Go doesn't handle unstructured data at all well, and most other languages consider JSON to be unstructured data. Go expects the JSON to be strongly typed and r…

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.

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

#515
post #335

Earlier quoted context omitted.

That's why I love Go so much. You want to write a very clever library using elegant abstraction and generics to have a cool innovative interface to solve your problem? Tough luck, you can't. So instead, you will just have to write a bog standard implementation with for-loops and good old functions which you will have to copy and tweak as needed where you really need something more complicated. It will work perfectly…

> It will work perfectly fine and end up being very readable for you and for the other persons reading your code. And make all future work both 3 times simpler, and take 3 times as long. I suppose there’s situations in which this is great, but I’m partial to requiring more. I’ll admit that hasn’t worked out very well for me unless I’m working my myself though.

I'll take verbose and simple code over terse trickery every day.

People who disagree have never had to wake up at 3 in the morning to fix a critical production issue in someone else's code. And that someone else really loved "elegant and terse" code.

It's not fun to grok your brain around weird language trickery when you're half-awake and in a hurry to fix stuff before the customers wake up.

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

#516

I've been coding in Go for over five years. I like Go, but I don't love it. It's never my first choice, although I don't advocate for rewrites just to move away from it. The tooling is a mess. Go modules still feel like a 'first pass' implementation that never got finished. There's no consistency in formatting or imports (even though Go claims there is). Generics are a good step but are still very primitive (no gener…

What do you mean by no consistency in formatting? go fmt is a solid formatter that does its job

After using rustfmt, I feel gofmt is not up to snuff. My main gripe with it is there are multiple formattings that are valid: there is not one true format. E.g. gofmt does not enforce line length which makes diverging styles possible, like for function declarations.

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

#517
post #494
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…

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...

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

#518
post #377
post #364

Earlier quoted context omitted.

> It is the time it takes to where you can start to meaningfully contribute to evolving how the language is used and meaningfully coach architects, programmers and system designers. It is also what you need to absorb novices into the organization and train them fast. I think these criteria in particular are much more than a lot of people mean when they say "learn a language", which would explain why their estimates a…

2012: Python is Awesome! 2014: Python is a great language, but there are a few pitfalls 2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though. 2018: I like python, but I wish more people used type annotations. 2020: You know, metaclasses are freaking awesome! They saved me so much work! 2022: Why can't people code the most obvious solution in python? 2024: Celery!…

hah my journey was -- man im 100s of lines in what is the type of this thing that I am passing? ... man i really wish i had types or at least hints

and then we got type hints but then I think more of my work will be moving to go anyway

why is packaging still broken?

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

#519

There are a lot of aspects of Go that I’m really not a fan of, but I’ve been writing an increasing amount of it over the last few months and on the whole I’m finding it really enjoyable—even though I’m not sure I could empirically explain why. The tooling is heaven compared to other stuff we do a lot of at work (TS/JS of course being the main offender), and generally I find I spend less time thinking about things tha…

The "not having to think" is the best bit.

There are no fancy ways to do things, only the simple way.

If something feels like it's hard to do it's either the inefficient way to do it or the wrong way.

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

#520
post #467
post #377

Earlier quoted context omitted.

2012: Python is Awesome! 2014: Python is a great language, but there are a few pitfalls 2016: Python is a good language with the right IDE, tooling, and process. The people are pretty cool though. 2018: I like python, but I wish more people used type annotations. 2020: You know, metaclasses are freaking awesome! They saved me so much work! 2022: Why can't people code the most obvious solution in python? 2024: Celery!…

What's so bad about Celery?

curious as well!
Post reply on HN