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

Go is opinionated how things are done, and just happens that its opinion fits yours, the issue is what when it doesn't?

With non-opinionated languages nothing is stopping you from structuring your code the same way.

Some people stated how hard go makes it when you try to have project that utilizes different languages. Another issue is when you try to use a fork of one of library.

Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.




> With non-opinionated languages nothing is stopping you from structuring your code the same way.

With Go, I can do `go build $project` from anywhere and get a releasable binary in the working directory. I can do `import "$oldproject/$package"` in my new project and start using it immediately. I can use `godef` to jump around all of the Go code installed on my system and quickly drill down all the way to the Go builtins if I need to. I can use `guru` to see all references to a definition across all of the Go packages installed on my system. The list goes on. And I can do all of that from a favorite text editor (and not a huge slow IDE). I never felt so liberated in any other programming environment, and I've used quite a few.

> Yet another is that it is much more complex to generate a package (e.g. rpm) of projects that has many dependencies.

Go binaries have only the standard system libraries for dependencies - for all practical purposes they can be considered static. Or you mean something else?

> Some people stated how hard go makes it when you try to have project that utilizes different languages.

I've used links successfully, but maybe my scenarios were not complex enough?

> Another issue is when you try to use a fork of one of library.

Vendor support since 1.6 made this a nonissue; it's now trivial to use forked versions of libraries.


> Another issue is when you try to use a fork of one of library.

A fork of a library is either identical to the original, or a new library. And you could argue (or rather: I do), that it is a good thing that you need to explicitly specify which one you intend to use.


So let say you use code with many dependencies, but you want to make a small change in one of the dependencies. In other languages you would then just compile and be done with it, but now with golang you now need to also modify potentially hundreds of places unless you resort to somehow cheat golang.

As I said, being opinionated is great if the opinion matches yours otherwise you might end up fighting it on every step.




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

Search: