Hacker News new | past | comments | ask | show | jobs | submit login

>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).




> 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.


How so? The project just includes a script that git clones the forks into your Go workspace for the project /foobar/src....


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.


Besides a shell script with a "for each repo. git clone", there is no build process (besides running the go build command)...


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: