151–160 of 178 posts
That's one of the things I like in go most. Having decentralized packages via domains and URLs and then index them (godoc.org works very well), it mirrors the design of the Web. In contrast npm, Rust and others that are tightly coupled to one site feels like Google AMP - centralizing and hosting everything in one place.
Earlier quoted context omitted.
> "golang" is the official disambiguation, so it's factually incorrect to call people out for using that term. I don't think "factually incorrect" is warranted. It's factually correct that the language is called Go. And while "golang" is a useful alternative for searchability and where "go" is taken, it is still a valid criticism to request using "Go" in natural language and prose. As for "official disambiguation", I…
Seems like you're splitting semantic hairs. The language maintainers regularly and consistently use "golang" as a disambiguation: * golang.org * github.com/golang * Twitter @golang and #golang * golang-nuts In this context, it seems pretty "official" and the rebuke "factually incorrect" or at least the rebuke applies equally to the maintainers. That said, it was a single wayward comment and it is (in my experience) o…
"Sydney Golang Meetup - Rob Pike - Go 2 Draft Specifications"
Earlier quoted context omitted.
If one wants to be a pioneer and be one of the people who starts the movement, now is the time to jump in and make a name for yourself.
I'm not certain that Go is a great fit for this particular area. Others have mentioned generics, but I'd also worry that the lack of operator overloading is a weakness. There is a lot of Fortran out there, so operator overloading is not required, but I'd worry about the ergonomics of Go, especially given the strength of the other options.
Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with "npx"; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn't compile.) I am glad to see that the go team is working on cleaning u…
This is exactly why I personally think efforts for language-specific package management in general are misguided. This is a solved problem in general-purpose package-managers (apt, dnf, pacman,…), for all their flaws. I don't understand why we need to re-invent that over and over again, including all the duplication of effort to re-package everything over and over again…
So instead of creating M packages * N OSes, we do it just once.
Earlier quoted context omitted.
If you realize something is wrong a couple years in and it takes 5+ years to fix it, then that seems like a long time to me.
In between community developed many solutions when official solution was lacking. So it's not like people were twiddling their thumbs for 5 years. Also check how long Java took to get official module solution. Work on that started in 2008 and solution was delivered in 2017.
Earlier quoted context omitted.
GOPATH behaves very, very differently from PYTHON_PATH and CLASSPATH, it is not the same thing at all. Basically before go 1.11, it was impossible to just do git clone ... somedir cd somedir # build code and run something You had to instead make sure "somedir" ended up somewhere within a particular deep directory structure. That is what people mean when they say "GOPATH".
> Basically before go 1.11, it was impossible to just do That's not true. It was always perfectly possible to do that, the code you build just couldn't import any libraries not installed in GOPATH. AIUI that is exactly the same as in other languages.
I guess it is not all that different from Python, with Python you need to add the source path to PYTHONPATH / sys.path (and often do so at runtime in the entrypoint script). With go you need the "src/github.com/dagss" prefix to the path. Or at least, according to conventions. You are right that it is more similar on a technical level than what I thought.
Earlier quoted context omitted.
> Same applies to Maven, in fact many enterprises forbid access to Maven central "Maven central" implies there is a central repository though.
There are two different meanings of 'central' in play here, 'center' as in a town square, and 'center' as in the centralized component of a system. It does not imply that there is a central repository when using 'central' to mean 'a unique, difficult to replicate, or otherwise somehow special component in a system' as in 'centralization'. Central in the case of 'Maven Central' means something closer to 'default' or '…
It's not, though. Because github isn't the default. You have to explicitly specify that you want a project from github every time you use it.
The difference might be minor from a technological standpoint, but it means a lot in terms of how centralized things become culturally.
Earlier quoted context omitted.
This is exactly why I personally think efforts for language-specific package management in general are misguided. This is a solved problem in general-purpose package-managers (apt, dnf, pacman,…), for all their flaws. I don't understand why we need to re-invent that over and over again, including all the duplication of effort to re-package everything over and over again…
Because a language-specific package management work in all OSes supported by the language, while OS specific packages work in a single distribution, or not all in OSes that don't offer such support. So instead of creating M packages * N OSes, we do it just once.
No, creating M packages x N OSes is exactly what we do. In fact, we create M+N package-managers x N OSes - and then also create MxN packages.
If you can write a language-specific package manager for all OSes, you can also write a non-language-specific package manager for all OSes, so I the "it doesn't work in all distributions" argument is just a symptom of my complaint. Instead of working towards a cooperative packaging solution where the effort of packaging can be re-used, we continue to create more and more special snowflakes and fragmentation.
Earlier quoted context omitted.
Because a language-specific package management work in all OSes supported by the language, while OS specific packages work in a single distribution, or not all in OSes that don't offer such support. So instead of creating M packages * N OSes, we do it just once.
> So instead of creating M packages * N OSes, we do it just once. No, creating M packages x N OSes is exactly what we do. In fact, we create M+N package- managers x N OSes - and then also create MxN packages. If you can write a language-specific package manager for all OSes, you can also write a non-language-specific package manager for all OSes, so I the "it doesn't work in all distributions" argument is just a symp…
My C++, Java and .NET packages work everywhere there is a toolchain available.
Earlier quoted context omitted.
There are two different meanings of 'central' in play here, 'center' as in a town square, and 'center' as in the centralized component of a system. It does not imply that there is a central repository when using 'central' to mean 'a unique, difficult to replicate, or otherwise somehow special component in a system' as in 'centralization'. Central in the case of 'Maven Central' means something closer to 'default' or '…
> Saying that 'maven central' implies maven isn't decentralized would be the same as saying "Most go projects are on github, so go can't be hosted in a decentralized way because github is 'golang central'". It's not, though. Because github isn't the default. You have to explicitly specify that you want a project from github every time you use it. The difference might be minor from a technological standpoint, but it m…