Live data from Hacker News

Go is my hammer, and everything is a nail

maragu.dev

491–500 of 816 posts

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

#491

Earlier quoted context omitted.

And then you have the ever changing ecosystem, that can take years so sort out on it's own and must be constantly studied. E.G: if you arrive in Python right now, numpy is in version 2 and polars is stable. uv is all the rage, pydantic gained so much perf it's not even funny, toml is part of the stdlib and textual is looking very good. Type hints are much better than 2 years ago, htmx is used a lot in the web departm…

IMHO, that's not part of learning the language. You don't really even need half of the packages you mentioned unless you don't know the language and, instead, rely upon third-party crutches.

Depends on what your goal is. If your primary purpose for learning python is to be able to use numpy and pandas, then you should probably start learning them from day 1. Learning how to inefficiently implement parts of pandas in pure python on an ad-hoc basis is a waste of time for most people compared to just spending that time learning how to efficiently use pandas.

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

#492
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…

Go is not good for data science and ML. It doesn't even have a proper, maintained dataframe library for data-science. R and Python beat it hands on. Rust also beats it now thanks to polars. And mobile ? gomobile is not maintained. Fyne is amateur level on mobile. AFAIK Go has no maintained 3d game engines. Go has its well-established niche for middle-ware services and CLI tools. And that's about it. If your domain is…

Is the reason for the absence of a well-maintained dataframe library lack of demand? It looks like Gota and Dataframe-go are abandoned, while Gonum isn't particularly active. Did these wither on the vine because no one used them?

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

#493

Earlier quoted context omitted.

Doing this allows you to mock out that implementation in unit tests.

A lot of times you want to be able to cmd+click on something and actually see what the hell the code actually does and not get dead-ended at an interface declaration.

What are you using that can cmd+click to take you to a definition, but can't also take you to an interface implementation? I develop Go in Emacs with the built-in eglot + gopls, and M-. takes me to the definition, C-M-. takes me to the implementation(s). It's a native feature of gopls. Sure, it's one extra button, but hardly impossible.

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

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

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 of library requirement to use Python 2 in years.

Your criticisms WERE valid 5 or 10 years ago. In my experience, the ecosystem has improved greatly since then. I wouldn't use Python for large and shared developer code base but for one-man experiments and explorations, Python is pretty compelling these days in my opinion.

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

#495

Earlier quoted context omitted.

> 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?" I am extremely doubtful that this is true and would like evidence.

kind of hard for someone to prove a negative - feel free to find some Go code that meets that definition.

I looked around for something like CppQuiz or its Rust analogue, where you're presented puzzling "Why would anybody do that?" fragments and asked what happens -- something that's often extremely difficult. If I had found one of those for Golang I could maybe see whether there are people who just ace the quiz first time.

But what I found were the sort of softball "Is Go Awesome, Brilliant, Cool or all of the above?" type questions, or maybe some easy syntax that you'd see in day 1. So I have no evidence whether in fact many, some or even a few Go programmers have this deep comprehensive understanding.

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

#496

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.

With generics you can now write all of those in Go.

And it would be an order of magnitude slower than plain loop because compiler is not smart enough to optimize it.

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

#497
post #262

Earlier quoted context omitted.

> it's pretty difficult to over engineer I don't know about that. Every programmer's first Go program seems to like to go to channel city. Perhaps more accurately: Over-engineering your Go program is going to quickly lead to pain. It doesn't have the escape hatches that help you paper over bad design decisions like some other languages do.

Also: interfaceiritus. Someone saw "accept interfaces, return structs" somewhere and now EVERYTHING accepts an interface, whether or makes sense or not. Many (sometimes even all) of these interfaces have just one implementation.

Agreed. It's not as 'traditional Go' but I find there is way less interface boilerplate if you just pass functions around.

ie instead of

```

type ThingDoer interface { DoThing() }

func someFunction(thingDoer ThingDoer) { ThingDoer.doThing() }

```

just have

```

func someFunction(doThing func()) { doThing() }

```

Then when testing you can just pass a test implementation of the 'doThing' function that just verifies it was called with the expected arguments.

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

#499

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.

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.

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

#500
post #262

Earlier quoted context omitted.

Also: interfaceiritus. Someone saw "accept interfaces, return structs" somewhere and now EVERYTHING accepts an interface, whether or makes sense or not. Many (sometimes even all) of these interfaces have just one implementation.

Can't Go compiler statically prove that such single implementation interfaces are indeed that and devirtualize the callsites referring to them? Either way, the problem seems to happen in most languages of today, if they (or their community) ever happen to accidentally encourage passing an opaque type abstraction over a concrete one.

I think it actually does that, but in local contexts, where this analysis is somewhat easy.

I also believe you don't actually have to prove it statically: PGO can collect enough data to e.g. add a check that a certain type is usually X, and follow a slow path otherwise

Post reply on HN