4 ms·

>Things like the weird split between functions returning errors but occasionally panicking, lack of inheritance, and poor dependency management through github l

>Things like the weird split between functions returning errors but occasionally panicking, lack of inheritance, and poor dependency management through github links make Go a poor choice for applications within a business setting. FWIW I've been using Go since 0.8 and this stuff isn't really an issue for me. 1. Panics should not cross package boundaries unless they are meant to be fatal! 2. "lack of inheritance": 90% of the time embedding does the job of inheritance for my use cases just fine. It also prevents a lot of stupid... (from me and others) 3. "poor dependency management through github links" For all my non-trival projects I always fork all my dependencies into their own repos and then link upstream as upstream. If there is not feature I want or bug that needs fixing, I update them every 6 mo - 1 yr. I do this with every language I use where my dependences are source code and not distributable libraries (.a, .so, .jar etc).

mi100hael 10y ago
> For all my non-trival projects I always fork all my dependencies into their own repos That sounds absolutely terrible. Even worse than having to track down & install libraries and headers for C projects. At least in the case of those libraries, you can enforce a particular version using autoconf or whatever. Vendoring source code for dependencies (especially in separate repos) is fragile and a pain for anyone else to track down when jumping in to your existing project.
- voidlogic 10y ago
  How so? The project just includes a script that git clones the forks into your Go workspace for the project /foobar/src....
  - mi100hael 10y ago
    And then you have to maintain a bunch of ad hoc shell scripts separate from your actual build process. Like I said: fragile and a pain.
    - voidlogic 10y ago
      Besides a shell script with a "for each repo. git clone", there is no build process (besides running the go build command)...
  - lowmagnet 10y ago
    And of course the fact you're forked off means you can update at your own pace and not have to take someone's ticket to "fix" a "broken" build. While I don't do this forking, it can help control churn, especially in projects with lots of deps.
deleted 10y ago
[deleted]

mi100hael 10y ago

> For all my non-trival projects I always fork all my dependencies into their own repos That sounds absolutely terrible. Even worse than having to track down & install libraries and headers for C projects. At least in the case of those libraries, you can enforce a particular version using autoconf or whatever. Vendoring source code for dependencies (especially in separate repos) is fragile and a pain for anyone else to track down when jumping in to your existing project.

voidlogic 10y ago
How so? The project just includes a script that git clones the forks into your Go workspace for the project /foobar/src....
- mi100hael 10y ago
  And then you have to maintain a bunch of ad hoc shell scripts separate from your actual build process. Like I said: fragile and a pain.
  - voidlogic 10y ago
    Besides a shell script with a "for each repo. git clone", there is no build process (besides running the go build command)...
- lowmagnet 10y ago
  And of course the fact you're forked off means you can update at your own pace and not have to take someone's ticket to "fix" a "broken" build. While I don't do this forking, it can help control churn, especially in projects with lots of deps.

deleted 10y ago

[deleted]