5 ms·

> Just all-around a trusty tool in the belt I agree. The Go std-lib is fantastic. Also no dependency-hell with Go, unlike with Python. Just ship an oven-rea

> Just all-around a trusty tool in the belt I agree. The Go std-lib is fantastic. Also no dependency-hell with Go, unlike with Python. Just ship an oven-ready binary. And what's the alternative ? Java ? Licensing sagas requiring the use of divergent forks. Plus Go is easier to work with, perhaps especially for server-side deployments. Zig ? Rust ? Complex learning curve. And having to choose e.g. Rust crates re-introduces dependency hell and the potential for supply-chain attacks.

theshrike79 1y ago
uv + the new way of adding the required packages in the comments is pretty good. you can go `uv run script.py` and it'll automatically fetch the libraries and run the script in a virtual environment. Still no match for Go though, shipping a single cross-compiled binary is a joy. And with a bit of trickery you can even bundle in your whole static website in it :) Works great when you're building business logic with a simple UI on top.
- richid 1y ago
  I've been out of the Python game for a while but I'm not surprised there is yet another tool on the market to handle this. You really come to appreciate when these batteries are included with the language itself. That Go binary will _always_ run but that Python project won't build in a few years.
  - pjmlp 1y ago
    Unless it made use of CGO and has dynamic dependencies, always is a bit too much.
    - mdaniel 1y ago
      Or the import path was someone's blog domain that included a <meta> reference to the actual github repo (along with the tag, IIRC) where the source code really lives. Insanity
      - pjmlp 1y ago
        I never understood the mentality to have SCM urls as package imports directly on the source code.
        mdaniel 1y ago
        Well, that's the problem I was highlighting - golang somehow decided to have the worst of both worlds: arbitrary domains in import paths and then putting the actual ref of the source code ... elsewhere import "gopkg.in/yaml.v3" // does *what* now? curl https://gopkg.in/yaml.v3?go-get=1 | grep github <meta name="go-source" content="gopkg.in/yaml.v3 _ https://github.com/go-yaml/yaml/tree/v3.0.1{/dir} https://github.com/go-yaml/yaml/blob/v3.0.1{/dir}/{file}#L{line}"> oh, ok :-/ I would presume only a go.mod entry would specify whether it really is v3.0.0 or v3.0.1 Also, for future generations, don't use that package https://github.com/go-yaml/yaml#this-project-is-unmaintained https://github.com/go-yaml/yaml#this-project-is-unmaintained
- traceroute66 1y ago
  > you can go `uv run script.py` and it'll automatically fetch the libraries and run the script in a virtual environment. Yeah, but you still have to install `uv` as a pre-requisite. And you still end up with a virtual environment full of dependency hell. And then of course we all remember that whole messy era when Python 2 transitioned to Python 3, and then deferred it, and deferred it again.... You make a fair point, of course it is technically possible to make it (slightly) "cleaner". But I'll still take the Go binary thanks. ;-)
  - rsyring 1y ago
    Installing uv is a requirement and incredibly easy. No, there is no dependency hell in the venv. Python 2 to 3: are you really still kicking that horse? It's dead...please move on.
- lenkite 1y ago
  uv is the new hotness now. Let us check back in 5 years...
deleted 1y ago
[deleted]
porridgeraisin 1y ago
> std-lib Yes, My favourite is the `time` package. It's just so elegant how it's just a number under there, the nominal type system truly shines. And using it is a treat. What do you mean I can do `+= 8*time.Hour` :D
- candiddevmike 1y ago
  The way Go parses time strings by default is insane though, even the maintainers regret it. It's a textbook example of being too clever.
  - nkozyra 1y ago
    By choosing default values instead of templatized values? Other than having to periodically remember what 0-padded milliseconds are or whatever this isn't a huge deal.
    - mdaniel 1y ago
      I'm not OP, but I also got tripped up the first time I saw time.Parse("2006-01-02 03:04:05") and was like what the actual?! https://pkg.go.dev/time#Layout https://pkg.go.dev/time#Layout
      - peterashford 1y ago
        Yeah, that's ugly as fuck. I hate it
- tux3 1y ago
  Unfortunately it doesn't have error handling, so when you do += 8 hours and it fails, it won't return a Go error, it won't throw a Go exception, it just silently does the wrong thing (clamp the duration) and hope you don't notice... It's simplistic and that's nice for small tools or scripts, but at scale it becomes really brittle since none of the edge cases are handled
  - 1y ago
gf000 1y ago
> Java ? Licensing sagas requiring the use of divergent forks. Plus Go is easier to work with, perhaps especially for server-side deployments Yeah, these are sagas only, because there is basically one, single, completely free implementation anyone uses on the server-side and it's OpenJDK, which was made 100% open-source and the reference implementation by Oracle. Basically all of Corretto, AdoptOpenJDK, etc are just builds of the exact same repository. People bringing this whole license topic up can't be taken seriously, it's like saying that Linux is proprietary because you can pay for support at Red Hat..
- pjmlp 1y ago
  There are other JVMs that do not descend from OpenJDK, but in general your point stands.
  - gf000 1y ago
    Yeah I know, but people have trouble understanding the absolutely trivial licensing around OpenJDK, let's not bring up alternative implementations (which actually makes the whole platform an even better target from a longevity perspective! There isn't many languages that have a standard with multiple, completely independent impls).
- traceroute66 1y ago
  > People bringing this whole license topic up can't be taken seriously So you mean all those universities and other places that have been forced to spend $$$ on licenses under the new regime also can't be taken seriously ? Are you saying none of them took advice and had nobody on staff to tell them OpenJDK exists ? Regarding your Linux comment, some of us are old enough to remember the SCO saga. Sadly Oracle have deeper pockets to pay more lawyers than SCO ever did ....
  - gf000 1y ago
    I have made a bunch of claims, that are objectively true. From there, basic logical inference says that you can completely freely use Java. Anything else is irrelevant. I don't know what/which university you talk about, but I'm sure they were also "forced to pay $$$" for their water bills and whatnot. If they decided to go with paid support, then.. you have to pay for it. In exchange you can a) point your finger at a third-party if something goes wrong (which governments love doing/often legally necessary) b) get actual live support on Christmas Eve if needed.
tempay 1y ago
> Rust crates re-introduces dependency hell and the potential for supply-chain attacks. I’m only a casual user of both but how are rust crates meaningfully different from go’s dependency management?
- tzekid 1y ago
  I think it's because go's community sticks close to the standard library: e.g. iirc. Rust has multiple ways of handling Strings while Go has (to a big extent) only one (thanks to the GC)
  - adastra22 1y ago
    What does String/OsSfeing have to do with garbage collection?
  - diarrhea 1y ago
    > Rust has multiple ways of handling Strings No, none outside of stdlib anyway in the way you're probably thinking of. There are specialized constructs which live in third-party crates, such as rope implementations and stack-to-heap growable Strings, but those would have to exist as external modules in Go as well.
- jaas 1y ago
  Go has a big, high quality standard library with most of what one might need. Means you have to bring in and manage (and trust) far fewer third party dependencies, and you can work faster because you’re not spending a bunch of time figuring out what the crate of the week is for basic functionality.
  - zozbot234 1y ago
    Rust intentionally chooses to have a small standard library to avoid the "dead batteries" problem. But the Rust community also maintains lists of "blessed" crates to try and cope with the issue of having to trust third-party software components of unknown quality.
brabel 1y ago
You forgot D. In a world where D exists, it's hard to understand why Go needed to be created. Every critique in this post is not an issue in D. If the effort Google put into Go had gone on making D better, I think D today would be the best language you could use. But as it is, D has had very little investment (by that I mean actual developer time spent on making it better, cleaning it up, writing tools) and it shows.
- maleldil 1y ago
  I don't think the languages are comparable. Go tries to stay simple (whatever that means), while D is a kitchen-sink language.
morsecodist 1y ago
This just makes it even more frustrating to me. Everything good about go is more about the tooling and ecosystem but the language itself is not very good. I wish this effort had been put into a better language.
- iTokio 1y ago
  Go has transparent async io and a very nice M:N threading model that makes writing http servers using epoll very simple and efficient. The ergonomics for this use case are better than in any language I ever used.
  - layer8 1y ago
    Implementing HTTP servers isn’t exactly a common use case in software development, though.
    - iTokio 1y ago
      Sorry I didn’t mean implementing a raw http server like nginx, but just writing a backend.
- p2detar 1y ago
  > I wish this effort had been put into a better language. But it is being put. Read newsletters like "The Go Blog", "Go Weekly". It's been improving constantly. Language-changes require lots of time to be done right, but the language is evolving.
Luker88 1y ago
> Rust crates re-introduces [...] potential for supply-chain attacks. I have absolutely no idea how go would solve this problem, and in fact I don't think it does at all. > The Go std-lib is fantastic. I have seen worse, but I would still not call it decent considering this is a fairly new language that could have done a lot more. I am going to ignore the incredible amount of asinine and downright wrong stuff in many of the most popular libraries (even the basic ones maintained by google) since you are talking only about the stdlib. On the top of my head I found inconsistent tagging management for structs (json defaults, omitzero vs omitempty), not even errors on tag typos, the reader/writer pattern that forces you to to write custom connectors between the two, bzip2 has a reader and no writer, the context linked list for K/V. Just look at the consistency of the interfaces in the "encoding" pkg and cry, the package `hash` should actually be `checksum`. Why does `strconv.Atoi`/ItoA still exist? Time.Add() vs Time.Sub()... It chock full of inconsistencies. It forces me to look at the documentation every single time I don't use something for more than a couple of days. No, the autocomplete with the 2-line documentation does not include the potential pitfalls that are explained at the top of the package only. And please don't get me started on the wrappers I had to write around stuff in the net library to make it a bit more consistent or just less plain wrong. net/url.Parse!!! I said don't make my start on this package! nil vs NoBody! ARGH! None of this is stuff at the language level (of which there is plenty to say). None of it is a dealbreaker per se, but it adds attrition and becomes death by a billion cuts. I don't even trust any parser written in go anymore, I always try to come up with corner cases to check how it reacts, and I am often surprised by most of them. Sure, there are worse languages and libraries. Still not something I would pick up in 2025 for a new project.

theshrike79 1y ago

uv + the new way of adding the required packages in the comments is pretty good. you can go `uv run script.py` and it'll automatically fetch the libraries and run the script in a virtual environment. Still no match for Go though, shipping a single cross-compiled binary is a joy. And with a bit of trickery you can even bundle in your whole static website in it :) Works great when you're building business logic with a simple UI on top.

richid 1y ago
I've been out of the Python game for a while but I'm not surprised there is yet another tool on the market to handle this. You really come to appreciate when these batteries are included with the language itself. That Go binary will _always_ run but that Python project won't build in a few years.
- pjmlp 1y ago
  Unless it made use of CGO and has dynamic dependencies, always is a bit too much.
  - mdaniel 1y ago
    Or the import path was someone's blog domain that included a <meta> reference to the actual github repo (along with the tag, IIRC) where the source code really lives. Insanity
    - pjmlp 1y ago
      I never understood the mentality to have SCM urls as package imports directly on the source code.
      - mdaniel 1y ago
        Well, that's the problem I was highlighting - golang somehow decided to have the worst of both worlds: arbitrary domains in import paths and then putting the actual ref of the source code ... elsewhere import "gopkg.in/yaml.v3" // does *what* now? curl https://gopkg.in/yaml.v3?go-get=1 | grep github <meta name="go-source" content="gopkg.in/yaml.v3 _ https://github.com/go-yaml/yaml/tree/v3.0.1{/dir} https://github.com/go-yaml/yaml/blob/v3.0.1{/dir}/{file}#L{line}"> oh, ok :-/ I would presume only a go.mod entry would specify whether it really is v3.0.0 or v3.0.1 Also, for future generations, don't use that package https://github.com/go-yaml/yaml#this-project-is-unmaintained https://github.com/go-yaml/yaml#this-project-is-unmaintained
traceroute66 1y ago
> you can go `uv run script.py` and it'll automatically fetch the libraries and run the script in a virtual environment. Yeah, but you still have to install `uv` as a pre-requisite. And you still end up with a virtual environment full of dependency hell. And then of course we all remember that whole messy era when Python 2 transitioned to Python 3, and then deferred it, and deferred it again.... You make a fair point, of course it is technically possible to make it (slightly) "cleaner". But I'll still take the Go binary thanks. ;-)
- rsyring 1y ago
  Installing uv is a requirement and incredibly easy. No, there is no dependency hell in the venv. Python 2 to 3: are you really still kicking that horse? It's dead...please move on.
lenkite 1y ago
uv is the new hotness now. Let us check back in 5 years...

deleted 1y ago

[deleted]

porridgeraisin 1y ago

> std-lib Yes, My favourite is the `time` package. It's just so elegant how it's just a number under there, the nominal type system truly shines. And using it is a treat. What do you mean I can do `+= 8*time.Hour` :D

candiddevmike 1y ago
The way Go parses time strings by default is insane though, even the maintainers regret it. It's a textbook example of being too clever.
- nkozyra 1y ago
  By choosing default values instead of templatized values? Other than having to periodically remember what 0-padded milliseconds are or whatever this isn't a huge deal.
  - mdaniel 1y ago
    I'm not OP, but I also got tripped up the first time I saw time.Parse("2006-01-02 03:04:05") and was like what the actual?! https://pkg.go.dev/time#Layout https://pkg.go.dev/time#Layout
    - peterashford 1y ago
      Yeah, that's ugly as fuck. I hate it
tux3 1y ago
Unfortunately it doesn't have error handling, so when you do += 8 hours and it fails, it won't return a Go error, it won't throw a Go exception, it just silently does the wrong thing (clamp the duration) and hope you don't notice... It's simplistic and that's nice for small tools or scripts, but at scale it becomes really brittle since none of the edge cases are handled
- 1y ago

gf000 1y ago

> Java ? Licensing sagas requiring the use of divergent forks. Plus Go is easier to work with, perhaps especially for server-side deployments Yeah, these are sagas only, because there is basically one, single, completely free implementation anyone uses on the server-side and it's OpenJDK, which was made 100% open-source and the reference implementation by Oracle. Basically all of Corretto, AdoptOpenJDK, etc are just builds of the exact same repository. People bringing this whole license topic up can't be taken seriously, it's like saying that Linux is proprietary because you can pay for support at Red Hat..

pjmlp 1y ago
There are other JVMs that do not descend from OpenJDK, but in general your point stands.
- gf000 1y ago
  Yeah I know, but people have trouble understanding the absolutely trivial licensing around OpenJDK, let's not bring up alternative implementations (which actually makes the whole platform an even better target from a longevity perspective! There isn't many languages that have a standard with multiple, completely independent impls).
traceroute66 1y ago
> People bringing this whole license topic up can't be taken seriously So you mean all those universities and other places that have been forced to spend $$$ on licenses under the new regime also can't be taken seriously ? Are you saying none of them took advice and had nobody on staff to tell them OpenJDK exists ? Regarding your Linux comment, some of us are old enough to remember the SCO saga. Sadly Oracle have deeper pockets to pay more lawyers than SCO ever did ....
- gf000 1y ago
  I have made a bunch of claims, that are objectively true. From there, basic logical inference says that you can completely freely use Java. Anything else is irrelevant. I don't know what/which university you talk about, but I'm sure they were also "forced to pay $$$" for their water bills and whatnot. If they decided to go with paid support, then.. you have to pay for it. In exchange you can a) point your finger at a third-party if something goes wrong (which governments love doing/often legally necessary) b) get actual live support on Christmas Eve if needed.

tempay 1y ago

> Rust crates re-introduces dependency hell and the potential for supply-chain attacks. I’m only a casual user of both but how are rust crates meaningfully different from go’s dependency management?

tzekid 1y ago
I think it's because go's community sticks close to the standard library: e.g. iirc. Rust has multiple ways of handling Strings while Go has (to a big extent) only one (thanks to the GC)
- adastra22 1y ago
  What does String/OsSfeing have to do with garbage collection?
- diarrhea 1y ago
  > Rust has multiple ways of handling Strings No, none outside of stdlib anyway in the way you're probably thinking of. There are specialized constructs which live in third-party crates, such as rope implementations and stack-to-heap growable Strings, but those would have to exist as external modules in Go as well.
jaas 1y ago
Go has a big, high quality standard library with most of what one might need. Means you have to bring in and manage (and trust) far fewer third party dependencies, and you can work faster because you’re not spending a bunch of time figuring out what the crate of the week is for basic functionality.
- zozbot234 1y ago
  Rust intentionally chooses to have a small standard library to avoid the "dead batteries" problem. But the Rust community also maintains lists of "blessed" crates to try and cope with the issue of having to trust third-party software components of unknown quality.

brabel 1y ago

You forgot D. In a world where D exists, it's hard to understand why Go needed to be created. Every critique in this post is not an issue in D. If the effort Google put into Go had gone on making D better, I think D today would be the best language you could use. But as it is, D has had very little investment (by that I mean actual developer time spent on making it better, cleaning it up, writing tools) and it shows.

maleldil 1y ago
I don't think the languages are comparable. Go tries to stay simple (whatever that means), while D is a kitchen-sink language.

morsecodist 1y ago

This just makes it even more frustrating to me. Everything good about go is more about the tooling and ecosystem but the language itself is not very good. I wish this effort had been put into a better language.

iTokio 1y ago
Go has transparent async io and a very nice M:N threading model that makes writing http servers using epoll very simple and efficient. The ergonomics for this use case are better than in any language I ever used.
- layer8 1y ago
  Implementing HTTP servers isn’t exactly a common use case in software development, though.
  - iTokio 1y ago
    Sorry I didn’t mean implementing a raw http server like nginx, but just writing a backend.
p2detar 1y ago
> I wish this effort had been put into a better language. But it is being put. Read newsletters like "The Go Blog", "Go Weekly". It's been improving constantly. Language-changes require lots of time to be done right, but the language is evolving.

Luker88 1y ago

> Rust crates re-introduces [...] potential for supply-chain attacks. I have absolutely no idea how go would solve this problem, and in fact I don't think it does at all. > The Go std-lib is fantastic. I have seen worse, but I would still not call it decent considering this is a fairly new language that could have done a lot more. I am going to ignore the incredible amount of asinine and downright wrong stuff in many of the most popular libraries (even the basic ones maintained by google) since you are talking only about the stdlib. On the top of my head I found inconsistent tagging management for structs (json defaults, omitzero vs omitempty), not even errors on tag typos, the reader/writer pattern that forces you to to write custom connectors between the two, bzip2 has a reader and no writer, the context linked list for K/V. Just look at the consistency of the interfaces in the "encoding" pkg and cry, the package `hash` should actually be `checksum`. Why does `strconv.Atoi`/ItoA still exist? Time.Add() vs Time.Sub()... It chock full of inconsistencies. It forces me to look at the documentation every single time I don't use something for more than a couple of days. No, the autocomplete with the 2-line documentation does not include the potential pitfalls that are explained at the top of the package only. And please don't get me started on the wrappers I had to write around stuff in the net library to make it a bit more consistent or just less plain wrong. net/url.Parse!!! I said don't make my start on this package! nil vs NoBody! ARGH! None of this is stuff at the language level (of which there is plenty to say). None of it is a dealbreaker per se, but it adds attrition and becomes death by a billion cuts. I don't even trust any parser written in go anymore, I always try to come up with corner cases to check how it reacts, and I am often surprised by most of them. Sure, there are worse languages and libraries. Still not something I would pick up in 2025 for a new project.