4 ms·

> Zero dependencies This is something seldom attempted, but I congratulate you. Go is one of a few languages that really is batteries-included. Just about anyt

> Zero dependencies This is something seldom attempted, but I congratulate you. Go is one of a few languages that really is batteries-included. Just about anything you could need is included in the stdlib.

seanw444 2y ago
One of the reasons I prefer it over something like Rust for most projects. I don't have to waste time figuring out what third-party library is the defacto standard that I should be using.
- iknowstuff 2y ago
  It’s a tradeoff. Do you prefer to be stuck with bad built-in file and time APIs, or a robust ecosystem of external crates? https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
  - hu3 2y ago
    So your argument is that an ecosystem of external crates which are created and maintained mostly by individual contributors is on average better than the standard library backed and dogfooded by trillion dollar company and used by other giants of the industry? Can't say I agree. Not to mention nothing prevents anyone from using or writing their own library only for the parts that need specialization. You're free to do that and many have. And standard libraries can be versioned and deprecated too.
    - everforward 2y ago
      I actually wouldn’t be surprised, if only because the standard library is so much harder to make backwards-incompatible changes to. I would generally expect that the average quality of the third party libs is lower, but the top 1% is probably better than stdlib. Eg I don’t find the stdlib logging library particularly great; not bad, but not impressive. Ditto for the stdlib errors package before they added error wrapping
    - iknowstuff 2y ago
      Uh, which ones would you like to compare? C++ std regex vs rust’s regex crate?
  - mijamo 2y ago
    "robust ecosystem" is a rather optimistic view of the rust situation... I would have said "a bunch of 0.x libraries that do 80% of the work and let you figure you the hard 20% while being slightly incompatible with each other, and that will be painful to glue together because of the rules for traits"
  - pjmlp 2y ago
    I rather have something that works everywhere there is a full implementation of the platform, instead of whatever third parties decided to support.
  - kbolino 2y ago
    The file API is mostly fine. Opening with that is the wrong approach to me; the comparison with Rust doesn't really illustrate any serious issues. All of the complaints could be addressed with better documentation. The time API, on the other hand, is that bad, and worse. Besides the bizarre monotonic time implementation, there's also the bloated size of the time.Time struct, and the lack of actual "dates" (YYYY-MM-DD) and "times" (HH:MM:SS) that you can do arithmetic on. You can't really roll your own robustly either because time.Time isn't a great foundation to build on and //go:linkname is getting locked down. Thankfully, build constraints are much better now, since they just use regular boolean operators, e.g.: //go:build windows && (i386 || amd64) I agree that there shouldn't be any _buildtag.go magic, and I think they ought to remove that "feature" entirely in a future version of Go (which can be done so that it doesn't affect older or unversioned code). It seems they added a "unix" build tag too. Also, one of my personal gripes is that the standard library exposes no guaranteed way to access the system CSPRNG. Any code can replace (crypto/rand).Reader with another implementation and compromise cryptographic operations. It's a trivial supply-chain attack vector, and even in non-malicious scenarios, it can be done mistakenly and break things all over the place in a subtle but dangerous way. The language developers have so far refused to fix it too. Then there's log/slog with no TRACE or FATAL levels built-in; yeah, you can roll your own levels, but why should you have to?
    - pjmlp 2y ago
      Anyone with enough experience in C derived languages large scale preprocessor spaghetti, welcomes _buildtag.extension alternative. This is actually one of the few things I fully agree with Go designers.
      - kbolino 2y ago
        Is the file foo_bar.go (no build tag line) compiled or not? If your Go version doesn't know of such a build tag as "bar", then foo_bar.go is unconditionally compiled. If Go in a later version adds "bar" as a known build tag, then foo_bar.go becomes conditionally compiled. Better hope you know this is how things work (reality: lots of Go devs don't). Build tag lines don't have this problem. They always specify compilation conditions, even if the build tag is not already known to the compiler. They also apply to the whole file, the same as _tag in the name; there's no preprocessor spaghetti possible.
  - Thaxll 2y ago
    Rust has multiple http server and async framework which creates a lot of confusion.
  - metadat 2y ago
    Great example, and more of a horror show than I anticipated. It would have been interesting if the author had a suggestion on what the Golang team should've / could've done instead, beyond correctly communicating the nature of the breaking change in the Go 1.9 release notes.
_mlbt 2y ago
Interestingly, Erlang is very batteries included as well. Probably even more so than Go in most cases.
- worldsayshi 2y ago
  Does Elixir inherit those batteries or is the ecosystem partially disconnected from Erlang?
  - brightball 2y ago
    Elixir inherits it. You can call anything in Erlang directly.
    - throwawaymaths 2y ago
      Not strictly true. Some stuff in the Erlang distribution must be included in extra_applications before you can call them.
      - seivan 2y ago
        [dead]
pjmlp 2y ago
Still doesn't have half of batteries that Python, Java and .NET include.
- philosopher1234 2y ago
  No doubt that is true, but are there particular batteries you’re thinking of?
  - pjmlp 2y ago
    GUI, dependency injection, huge collection libraries, dynamic runtime Interoperability, distributed objects, compiler plugins, custom runtime schedulers,... for example. Some of the above will never be in Go due to how the community and language designers are philosophically against them.
    - limit499karma 2y ago
      > dependency injection It's been a while since I played with the furry thing but is that even possible in Golang?
      - pjmlp 2y ago
        I was speaking about Python, Java and .NET standard libraries. In Go you can naturally do it, by using the manual constructor approach, however there is no magic auto wiring like you can do with attributes and compiler plugins, plus standard libraries infrastructure for locating services, from those three ecosystems above.
        limit499karma 2y ago
        Well, in my head DI at this point requires the magic bits. Otherwise it is (as you say) just constructor args.
        pjmlp 2y ago
deleted 2y ago
[deleted]

seanw444 2y ago

One of the reasons I prefer it over something like Rust for most projects. I don't have to waste time figuring out what third-party library is the defacto standard that I should be using.

iknowstuff 2y ago
It’s a tradeoff. Do you prefer to be stuck with bad built-in file and time APIs, or a robust ecosystem of external crates? https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
- hu3 2y ago
  So your argument is that an ecosystem of external crates which are created and maintained mostly by individual contributors is on average better than the standard library backed and dogfooded by trillion dollar company and used by other giants of the industry? Can't say I agree. Not to mention nothing prevents anyone from using or writing their own library only for the parts that need specialization. You're free to do that and many have. And standard libraries can be versioned and deprecated too.
  - everforward 2y ago
    I actually wouldn’t be surprised, if only because the standard library is so much harder to make backwards-incompatible changes to. I would generally expect that the average quality of the third party libs is lower, but the top 1% is probably better than stdlib. Eg I don’t find the stdlib logging library particularly great; not bad, but not impressive. Ditto for the stdlib errors package before they added error wrapping
  - iknowstuff 2y ago
    Uh, which ones would you like to compare? C++ std regex vs rust’s regex crate?
- mijamo 2y ago
  "robust ecosystem" is a rather optimistic view of the rust situation... I would have said "a bunch of 0.x libraries that do 80% of the work and let you figure you the hard 20% while being slightly incompatible with each other, and that will be painful to glue together because of the rules for traits"
- pjmlp 2y ago
  I rather have something that works everywhere there is a full implementation of the platform, instead of whatever third parties decided to support.
- kbolino 2y ago
  The file API is mostly fine. Opening with that is the wrong approach to me; the comparison with Rust doesn't really illustrate any serious issues. All of the complaints could be addressed with better documentation. The time API, on the other hand, is that bad, and worse. Besides the bizarre monotonic time implementation, there's also the bloated size of the time.Time struct, and the lack of actual "dates" (YYYY-MM-DD) and "times" (HH:MM:SS) that you can do arithmetic on. You can't really roll your own robustly either because time.Time isn't a great foundation to build on and //go:linkname is getting locked down. Thankfully, build constraints are much better now, since they just use regular boolean operators, e.g.: //go:build windows && (i386 || amd64) I agree that there shouldn't be any _buildtag.go magic, and I think they ought to remove that "feature" entirely in a future version of Go (which can be done so that it doesn't affect older or unversioned code). It seems they added a "unix" build tag too. Also, one of my personal gripes is that the standard library exposes no guaranteed way to access the system CSPRNG. Any code can replace (crypto/rand).Reader with another implementation and compromise cryptographic operations. It's a trivial supply-chain attack vector, and even in non-malicious scenarios, it can be done mistakenly and break things all over the place in a subtle but dangerous way. The language developers have so far refused to fix it too. Then there's log/slog with no TRACE or FATAL levels built-in; yeah, you can roll your own levels, but why should you have to?
  - pjmlp 2y ago
    Anyone with enough experience in C derived languages large scale preprocessor spaghetti, welcomes _buildtag.extension alternative. This is actually one of the few things I fully agree with Go designers.
    - kbolino 2y ago
      Is the file foo_bar.go (no build tag line) compiled or not? If your Go version doesn't know of such a build tag as "bar", then foo_bar.go is unconditionally compiled. If Go in a later version adds "bar" as a known build tag, then foo_bar.go becomes conditionally compiled. Better hope you know this is how things work (reality: lots of Go devs don't). Build tag lines don't have this problem. They always specify compilation conditions, even if the build tag is not already known to the compiler. They also apply to the whole file, the same as _tag in the name; there's no preprocessor spaghetti possible.
- Thaxll 2y ago
  Rust has multiple http server and async framework which creates a lot of confusion.
- metadat 2y ago
  Great example, and more of a horror show than I anticipated. It would have been interesting if the author had a suggestion on what the Golang team should've / could've done instead, beyond correctly communicating the nature of the breaking change in the Go 1.9 release notes.

_mlbt 2y ago

Interestingly, Erlang is very batteries included as well. Probably even more so than Go in most cases.

worldsayshi 2y ago
Does Elixir inherit those batteries or is the ecosystem partially disconnected from Erlang?
- brightball 2y ago
  Elixir inherits it. You can call anything in Erlang directly.
  - throwawaymaths 2y ago
    Not strictly true. Some stuff in the Erlang distribution must be included in extra_applications before you can call them.
    - seivan 2y ago
      [dead]

pjmlp 2y ago

Still doesn't have half of batteries that Python, Java and .NET include.

philosopher1234 2y ago
No doubt that is true, but are there particular batteries you’re thinking of?
- pjmlp 2y ago
  GUI, dependency injection, huge collection libraries, dynamic runtime Interoperability, distributed objects, compiler plugins, custom runtime schedulers,... for example. Some of the above will never be in Go due to how the community and language designers are philosophically against them.
  - limit499karma 2y ago
    > dependency injection It's been a while since I played with the furry thing but is that even possible in Golang?
    - pjmlp 2y ago
      I was speaking about Python, Java and .NET standard libraries. In Go you can naturally do it, by using the manual constructor approach, however there is no magic auto wiring like you can do with attributes and compiler plugins, plus standard libraries infrastructure for locating services, from those three ecosystems above.
      - limit499karma 2y ago
        Well, in my head DI at this point requires the magic bits. Otherwise it is (as you say) just constructor args.
        pjmlp 2y ago

deleted 2y ago

[deleted]