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.
Go is my hammer, and everything is a nail
491–500 of 816 posts
Re: Go is my hammer, and everything is a nail
#492The 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…
Re: Go is my hammer, and everything is a nail
#493Earlier 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.
Re: Go is my hammer, and everything is a nail
#494Earlier 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…
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
#495Earlier 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.
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
#496Where 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.
Re: Go is my hammer, and everything is a nail
#497Earlier 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.
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
#498Re: Go is my hammer, and everything is a nail
#499Earlier 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.
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
#500Earlier 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 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