←back to thread

One year after switching from Java to Go

(glasskube.dev)
257 points pmig | 4 comments | 18 Feb 25 16:55 UTC | HN request time: 0.25s | source
Show context
honkycat ◴[18 Feb 25 22:53 UTC] No.43096164[source]▶
After dealing with constant build issues between Java and Typescript and Node and Python: I love go so much. The package management alone makes it worth it.
replies(1): >>43096583 #
scubbo ◴[18 Feb 25 23:40 UTC] No.43096583[source]▶
After dealing with constant build issues with Go, I hate Go so much. The fact that they've conflated "source code" with "consumable library" means that you need a special case in your CI to publish new versions of a library in Go vs. every other language that builds and publishes an executable, and any tooling that pulls from a private repository has to hack `git config` rather than authenticating like you would any other artifact repository.

And that's before we even get onto the "v2" nonsense[0], because apparently it's unidiomatic to continue developing your packages after you publish them. Actually.....given that this language arose at Google, I may be onto something...

[0] https://go.dev/blog/v2-go-modules

replies(2): >>43096762 #>>43097758 #
diamondfist25 ◴[19 Feb 25 00:00 UTC] No.43096762[source]▶
Btw js/ts, python, and golang, which one do you find more productive with?
replies(1): >>43097048 #
1. scubbo ◴[19 Feb 25 00:34 UTC] No.43097048[source]▶
Hard to pick between Python and TypeScript - they have different strengths. TypeScript's type system is more useful (you'd hope, given the name!), but Python "just works" more often for simple use-cases IME (though I have well over double the lifetime experience with Python, so that might be a me-factor rather than a language factor).
replies(1): >>43104984 #
2. fullstackchris ◴[19 Feb 25 17:45 UTC] No.43104984[source]▶
Baffling. If you're seriously saying package management for python "just works" and for go "always breaks"... I guess your either a troll, or you've never written production software. And I'm not talking some clever Jupiter notebooks used for some internal auditing or whatnot, I'm talking about customer facing software used by _at least_ 100 people. I'm 12 years in the game and Python has always caused me nothing but pain, while Go hasnt ever cost me a second of afterthought, working in multiple environments after nothing more than git clone. But, if you like making "virtual environments", a horrible shim gimmick which wasnt even supported by the language itself originally, be my guest!
replies(2): >>43106709 #>>43130267 #
3. honkycat ◴[19 Feb 25 19:55 UTC] No.43106709[source]▶
Agreed! python easily has the worst package management out of all of them!
4. scubbo ◴[21 Feb 25 17:24 UTC] No.43130267[source]▶
No, that wasn't what I was saying. I was asked a tangential question about which language I preferred; and considering the language _itself_ rather than the ecosystem, I find that Python is the one that typically "just works" - that is, the barrier between thought/design and expression is smallest.

I've repeatedly heard terrible things about Python's packaging, and I have to believe that they're true, even if I've never experienced them myself. And, yeah, you've guessed partially correctly - my own 14 years of professional experience have been primarily with Java and TypeScript, with Python being my language of choice for _personal_ projects. So - yes, I never have written production Python.

To once again be clear, I'm not making any claims that Python's packaging is better than Go's. I'm making two separate and unrelated claims (because the latter was prompted by a tangential question):

* For someone currently building development tooling for a polyglot company, Go's dependency-management system requires more special-casing (both for publication and for consumption) than the others combined.

* For me personally, when translating thoughts/algorithms/designs into code (without considering publication), Python is the language in which I can do so fastest and most intuitively. Never having published a package with it, I've never had to engage with that side of things - I believe folks who tell me that it sucks, but from the consumers' side `source .venv/bin/activate; pip install -f requirements.txt` has always works flawlessly for me.