Oddbean

also, again, it's obviously been a while since you used Go because building a Go app anywhere has been the same since around 2018, it's more reliable and fast for building packages on any system than any other language i know of, literally you can just go install url.of.repo/path/to@latest and if you configured your path correctly to point where GOBIN has been added, it's instantly available

yeah, and as such have a very difficult time changing the repository or eliminating dependencies thus we have perl, python, gcc, clang, and a whole bunch of other things in there because the tree of dependencies is more complex than a 1000 year old ficus' root system this is also why Go itself pioneers the concept of multi-binaries, an idea which started with busybox every architectural and engineering decision has consequences and you should not ignore the outliers that your chosen one gives you and it's a hard problem to fix because of the highly decentralised open source development ecosystem, that's why we still have perl even though you can do all that stuff with C or python

also, it's a bit of a foggy domain this issue lives in... normal packages don't alter the rc files of shells, there is one main one in /etc and when you install Go it doesn't add to that in fact, it should be obvious that the shell configurations should actually have a `shell.d` directory which would facilitate that being non-destructive or racy i like how modules freeze versions of imports and ensure they are valid via git hashes but it was one of the neat things about GOPATH - like the old days of BSD with the /src directory now, that is something i would like to see come back... pure source OS, so you literally on install drop the source of everything core, bootstrap the compiler and then build everything, using a Go style caching/modula style build cache, and that would also make it a bit easier to introduce dynamic linking if there was a 1:1 between source and binary probably something that will eventually come in the future... there is already efforts in this direction, and some notable historical attempts towards this kind of goal such as Oberon and Oberon2, actually, one of the earliest, and probably closest to what we see now with the javascript/browser platform was the original Smalltalk, and notably one of Go's founders, Rob Pike, at one time attempted to make a GUI oriented, CSP concurrency language for programming UIs that looks remarkably similar to Go in many respects, the basis of much of the concurrency for sure, and some of the dynamic array stuff anyhow, it just seems logical to me, if you can have a non-rivalrous namespace to pin every piece of software into, and you have a versioning system that lets you build off a specific version, the really hard problem at this point is still the namespace, and i personally feel that Git overcomplicates the versioning history a little

I am not talking about runtime dependencies, which multi-binaries and busybox address. I am talking about the source code dependencies. When you have 100 times the number of entities (persons/projects) providing the source code golang pulls in for the easy-peasy build, vetting is 100 times more work. I really admire the lightning fast compiles of golang and the language features - but the security nightmare of their standard repo is something that younger programmers don't seem to understand, and is shared by other new languages.

yes! also, i want to rewrite the damn golang stdlib, after i rip out the damn string type also need to change how it treats methods of reference types (slices, maps) so they behave the same way as pointers these are the two biggest gripes i have with Go and don't get me started on the math/big library, what a shitshow