5 ms·

Keep it simple, just don't use dependencies.

yjftsjthsd-h 5y ago
I guess that's fine so long as you're covered by the standard library and/or are willing to reimplement a lot of stuff yourself, but that's a significant trade-off you're asking.
- 0des 5y ago
  It sounds defensive but Go stdlib is all you need. I believe I'm qualified to say that as last year I challenged myself to only use stdlib, out of several languages I used over the course of the year on big projects, Go was painless and that was a unique experience. So far this year I haven't seen much need to add libraries to my work because everything is already within grasp.
xxpor 5y ago
Kind of ironic for a language that was the first that I know about where you can straight up import libraries with a URL directly in your source.
- deleted 5y ago
  [deleted]
- throwaway894345 5y ago
  It's not a URL, it's just an identifier that sort-of resembles a URL similar to Kubernetes annotation conventions.
  - benhoyt 5y ago
    It may not be quite a URL, but it contains the URL. It definitely more than just "sort-of resembles a URL". See how the module path to URL lookup is done here: https://go.dev/ref/mod#vcs-find https://go.dev/ref/mod#vcs-find
    - throwaway894345 5y ago
      I understand your meaning, but that link supports my claims. The package path helps the Go tool infer the actual URL, but it doesn't contain the URL itself (e.g., the actual URL has a scheme/protocol component and potentially a `go-get=1` query string argument which don't exist as part of the path). This is what I meant when I said it "sort-of resembles a URL", but I understand from this conversation how that wording wasn't clear.
      - benhoyt 5y ago
        Fair. Strictly speaking it doesn't even "contain" a URL. But I think in the context of this conversation it acts like a URL -- it allows the Go tooling to fetch code from an arbitrary domain and path on the internet.
nu11ptr 5y ago
One problem: unless you have an endless amount of time, money, patience, and...did I mention patience? that just isn't a viable approach for anything but the smallest of hobby projects
- Friday_ 5y ago
  Build things by KISS principle. Dependencies will complicate system you are building. ( with things like supply chain attacks, bloat, liscensing etc...)
  - nu11ptr 5y ago
    Except KISS is subjective, as are most things. Please don't take this the wrong way, but anyone who touts any one, true "religion" in sw development I have learned to take with 6 grains of salt. There is no one magic way or solution. Everything is trade offs and I've learned this over the last 30 years through trying every new magic elixir that was going to "save us all". That said, most sw projects are determined by business need. I can't think of a single one I've ever written that hasn't needed dependencies or would have been viable had I not used some. Going to a theory level, there is no reason to think the stdlib is magically immune to the issues of a very popular dependency either. Shun absolutes and make the correct trade offs based on your business goals.
  - throwaway894345 5y ago
    So we just don't build GUI applications unless we understand all of the nuances of layout, text rendering, graphics programming, etc sufficient to implement it ourselves (and without the bugs that even domain experts have introduced but which have been found and fixed over time in libraries)? Or maybe we just say "fuck users who speak languages that aren't easily expressed in ASCII"? There's a reason libraries exist. It's not like they were the default state of computing and no one has tried to write applications without them. On the contrary, we tried to build applications by writing everything ourselves, but that doesn't survive encounters with the real world. And "well if you can't do it yourself, you don't need it" (which may or may not be your argument, I genuinely can't tell) is just technologically regressive ideology.
adtac 5y ago
sure, just don't use Postgres, OAuth, payments, RPCs, metrics, non-standard crypto, or anything important
riking 5y ago
This is the exact point of the final section of the article, yes.

I guess that's fine so long as you're covered by the standard library and/or are willing to reimplement a lot of stuff yourself, but that's a significant trade-off you're asking.

0des 5y ago
It sounds defensive but Go stdlib is all you need. I believe I'm qualified to say that as last year I challenged myself to only use stdlib, out of several languages I used over the course of the year on big projects, Go was painless and that was a unique experience. So far this year I haven't seen much need to add libraries to my work because everything is already within grasp.

xxpor 5y ago

Kind of ironic for a language that was the first that I know about where you can straight up import libraries with a URL directly in your source.

deleted 5y ago
[deleted]
throwaway894345 5y ago
It's not a URL, it's just an identifier that sort-of resembles a URL similar to Kubernetes annotation conventions.
- benhoyt 5y ago
  It may not be quite a URL, but it contains the URL. It definitely more than just "sort-of resembles a URL". See how the module path to URL lookup is done here: https://go.dev/ref/mod#vcs-find https://go.dev/ref/mod#vcs-find
  - throwaway894345 5y ago
    I understand your meaning, but that link supports my claims. The package path helps the Go tool infer the actual URL, but it doesn't contain the URL itself (e.g., the actual URL has a scheme/protocol component and potentially a `go-get=1` query string argument which don't exist as part of the path). This is what I meant when I said it "sort-of resembles a URL", but I understand from this conversation how that wording wasn't clear.
    - benhoyt 5y ago
      Fair. Strictly speaking it doesn't even "contain" a URL. But I think in the context of this conversation it acts like a URL -- it allows the Go tooling to fetch code from an arbitrary domain and path on the internet.

nu11ptr 5y ago

One problem: unless you have an endless amount of time, money, patience, and...did I mention patience? that just isn't a viable approach for anything but the smallest of hobby projects

Friday_ 5y ago
Build things by KISS principle. Dependencies will complicate system you are building. ( with things like supply chain attacks, bloat, liscensing etc...)
- nu11ptr 5y ago
  Except KISS is subjective, as are most things. Please don't take this the wrong way, but anyone who touts any one, true "religion" in sw development I have learned to take with 6 grains of salt. There is no one magic way or solution. Everything is trade offs and I've learned this over the last 30 years through trying every new magic elixir that was going to "save us all". That said, most sw projects are determined by business need. I can't think of a single one I've ever written that hasn't needed dependencies or would have been viable had I not used some. Going to a theory level, there is no reason to think the stdlib is magically immune to the issues of a very popular dependency either. Shun absolutes and make the correct trade offs based on your business goals.
- throwaway894345 5y ago
  So we just don't build GUI applications unless we understand all of the nuances of layout, text rendering, graphics programming, etc sufficient to implement it ourselves (and without the bugs that even domain experts have introduced but which have been found and fixed over time in libraries)? Or maybe we just say "fuck users who speak languages that aren't easily expressed in ASCII"? There's a reason libraries exist. It's not like they were the default state of computing and no one has tried to write applications without them. On the contrary, we tried to build applications by writing everything ourselves, but that doesn't survive encounters with the real world. And "well if you can't do it yourself, you don't need it" (which may or may not be your argument, I genuinely can't tell) is just technologically regressive ideology.

adtac 5y ago

sure, just don't use Postgres, OAuth, payments, RPCs, metrics, non-standard crypto, or anything important

riking 5y ago

This is the exact point of the final section of the article, yes.