2 ms·

> So the fact that Go provides no solid dependency management solution is "personal opinion"? The fact this is argued as a bad thing is personal opinion. He mi

> So the fact that Go provides no solid dependency management solution is "personal opinion"? The fact this is argued as a bad thing is personal opinion. He might have a valid point on that specific arguement but it's still an opinion piece as there have been others who have voiced how they like vendoring in Go. > If everyone followed this approach, we would never have ended up with amazing languages like Rust. Why try to improve C++ if you can build cool stuff with it, right? The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. I see language bashing really as more of a tribal ritrial rather than a productive contribution. Like the KDE Vs GNOME wars or the vi Vs emacs debates before that. For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars.

Cyph0n 9y ago
> The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. So how do you think new language development starts? Why do we have languages like Rust, D, Nim, and Crystal?
- laumars 9y ago
  > So how do you think new language development starts? By people writing code rather than pontificating > Why do we have languages like Rust, D, Nim, and Crystal? Because people wrote them rather than wasted hours on end arging why other popular solutions are garbage. As I said in my previous post: "For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars." Or to put things another way, you don't see the developer of Nim endlessly slagging off other languages. He just quietly gets on and creates something awesome.
  - wuliwong 9y ago
    >By people writing code rather than pontificating Or maybe a both things are important?
    - laumars 9y ago
      Sure, if the author has something new to add to the debate. However there becomes a point where the internet is already over saturated with opinion pieces and thus any newer ones only serve as flamebait by endlessly reiterating the same arguments. Submissions like this one happen weekly - and that's just one programming language. In fact this isn't even the first article on Go written by this author alone. So while I'm in favour discussion whether this article adds enough to the debate to be considered important. I'm inclined to say "no" since the author literally just rehashes the same points every other argument against Go has done already.
bbatha 9y ago
> how they like vendoring in Go Vendoring solves sharing dependencies with your team, it does not solve the addition of new dependencies. You still need to get your dependencies somehow, and they need to be able to specify what dependencies they work with. And your libraries can't vendor their libraries in go because then they'll have a different import path in vendor directory and in the main project and you won't be able to share types.
- bigdubs 9y ago
  1. Minimize dependencies. Much of the problems w/ dependency management have to do with over-coupling and adding lots of random dependencies for things you could just inline into your project. Also why the stdlib is so strong. 2. You can pick specific versions and follow basic semver constraints if you want by checking out the source for the dependency locally, and then copying to vendor. Automatic resolution would be nice but it's not like you can't do it. 3. Better automatic dependency management is coming. But honestly I prefer it to be arduous to add an external dependency. You should only do it if you absolutely need to. The bit about import paths being wrong I've generally not found to be the case; the go compiler will treat deps with the same in vendor or in gopath.
- laumars 9y ago
  Yeah I know; I wasn't trying to make an argument in favour of Go's vendoring. My point was far more meta than that :)

Cyph0n 9y ago

> The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. So how do you think new language development starts? Why do we have languages like Rust, D, Nim, and Crystal?

laumars 9y ago
> So how do you think new language development starts? By people writing code rather than pontificating > Why do we have languages like Rust, D, Nim, and Crystal? Because people wrote them rather than wasted hours on end arging why other popular solutions are garbage. As I said in my previous post: "For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars." Or to put things another way, you don't see the developer of Nim endlessly slagging off other languages. He just quietly gets on and creates something awesome.
- wuliwong 9y ago
  >By people writing code rather than pontificating Or maybe a both things are important?
  - laumars 9y ago
    Sure, if the author has something new to add to the debate. However there becomes a point where the internet is already over saturated with opinion pieces and thus any newer ones only serve as flamebait by endlessly reiterating the same arguments. Submissions like this one happen weekly - and that's just one programming language. In fact this isn't even the first article on Go written by this author alone. So while I'm in favour discussion whether this article adds enough to the debate to be considered important. I'm inclined to say "no" since the author literally just rehashes the same points every other argument against Go has done already.

bbatha 9y ago

> how they like vendoring in Go Vendoring solves sharing dependencies with your team, it does not solve the addition of new dependencies. You still need to get your dependencies somehow, and they need to be able to specify what dependencies they work with. And your libraries can't vendor their libraries in go because then they'll have a different import path in vendor directory and in the main project and you won't be able to share types.

bigdubs 9y ago
1. Minimize dependencies. Much of the problems w/ dependency management have to do with over-coupling and adding lots of random dependencies for things you could just inline into your project. Also why the stdlib is so strong. 2. You can pick specific versions and follow basic semver constraints if you want by checking out the source for the dependency locally, and then copying to vendor. Automatic resolution would be nice but it's not like you can't do it. 3. Better automatic dependency management is coming. But honestly I prefer it to be arduous to add an external dependency. You should only do it if you absolutely need to. The bit about import paths being wrong I've generally not found to be the case; the go compiler will treat deps with the same in vendor or in gopath.
laumars 9y ago
Yeah I know; I wasn't trying to make an argument in favour of Go's vendoring. My point was far more meta than that :)