Go Modules in 2019(blog.golang.org) |
Go Modules in 2019(blog.golang.org) |
It's kind of satisfying to see that the "Go way" wasn't the best way after all and that some of these things are actively being addressed. I hope it makes the community a bit more welcoming as well.
Sometimes this is just due to defensiveness: someone uses a flaw to say the whole language is terrible and that gets a response from people who have learned to live with the flaw.
Generally, if you back to the original statements you'll find something more nuanced: generic types have a lot of complicated effects on language design and they didn't like their own early proposals, so they started out without them. Yes, error checking can be repetitive, but many of the attempts to fix that in other languages were worse.
In the meantime, the "Go way" is about following common conventions for working within the language's limitations. This isn't a bad thing!
But it's tricky to be welcoming while getting across that the best way to deal with limitations is just to accept them, for now. On the Internet, everyone wants to be Steve Jobs and demand changes.
(Also: Rob Pike, not Erik.)
I think they’re onto something, though as the GP notes, hopefully the situation is improving.
I’d flip your response around and suggest that in several cases, the correct fix is obvious and the core Go team’s insistence on extreme caution and “nuance” is misguided. GOPATH is a great example -- it’s just so obviously wrongheaded that I really don’t understand why it stuck around so long.
Another one that comes to mind, although this is quite old now, is the way early versions of Go would insist that the very last statement of a function was a “return”; you couldn’t do an “if foo { return x } else { return y }”, for example. It took a lot of pushing to persuade the core team to add some basic escape analysis, against insistence that it was some kind of nuanced feature with unpredictable side-effects, rather than a trivial thing that every other real compiler has to do.
Except the problem is that "the Go way" changes in a way that breaks your previously-"working within the language's limitations".
An example of this that comes to mind is how the Go 1.5 vendor/ change was done. The community had rallied around several tools that would do vendoring and then would modify GOPATH to include vendor/ and would then symlink the current project into vendor/. All this required was a vendor/src. The Go 1.5 vendor/ implementation was almost identical but they removed the src directory -- which meant that pre-1.5 vendoring was now broken by Go (you can't really have two copies of your vendor tree in a repo and symlinks wouldn't work either).
There are a few other examples of this, but this one sticks out as it was the first feeling I got that the Go development team doesn't really care how the community has decided to work around a language defect. It literally would have just taken them one additional directory to not break every vendor/ project.
(Also, there has been absolutely no discussion with distributions -- as far as I'm aware -- on how packaging Go binaries should be done so we're all forced to come up with our own ideas. The Go modules stuff has considerations -- like builds requiring an internet connection -- that distributions would've had input on, but we didn't get asked about it.)
My favorite example here is this arrogant dismissal of the idea that a one line expression, rather than a 5 line mutating statement, might be preferred for conditionally setting a value:
if expr {
n = trueVal
} else {
n = falseVal
}
...
n = expr ? trueVal : falseVal
&&, ||, switch, select, for, and while all do conditional execution in Go.
So the rule is not "A language needs only one conditional control flow construct." The rule is really, "We didn't think a conditional operator was worth it." That's a fine rule, but it's better to be honest about it than to pretend the language was designed around some pure principle that doesn't actually exist.
This isn't an insult to programmers, it is an option that clarity of code is more important then continence. Thus all if and for statements also require {} brackets.
I was thinking I could write my own if(condition, true_case, false_case) method similar to the way it's done in spreadsheets, but Go also doesn't have macros or inline if/else expressions, so there is simply no way to emulate ternary logic in a performant manner :-(
n = if(expr) trueVal else falseVal
If by "one" you mean `if` _and_ `switch` then yes!
Most everything I've seen from the Go camp, including the new re-discovery of various wheels with the Go 2.0 proposals, felt like the parent describes to me.
Never got the same from Rust, otoh.
> pretty much every Go-related conversation over at /r/programming seems to have someone arguing that it's literally impossible to build software in a language that lacks generics
Literally literally? Isn't your reply a "bad way to characterize the overall conversation" as well?
Generics is a major tell, too, since the Go team's position on generics was always "generics are interesting but we don't know how to make them work well with Go's existing type system". See for example, this blog post from 2009: https://research.swtch.com/generic which references the FAQ answer to the generics problem here: https://golang.org/doc/faq#generics: "Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it."
so I can see why people who have repeatedly answered the same question for years, only to have their answer misrepresented for years, to be annoyed when people who haven't read any prior discussion bring up a point that has been already talked about ad nauseam.
It was a comment on my personal experiences of interacting with the Go community, not the language and its limitations. My hope wasn't that Go implements my every pet peeve, my hope is that the community has gained some humility since I last dipped my toes in it.
Pike seems especially aggressive when interacting with people he disagrees with and this was for me indicative of the culture. It's been a few years though, so maybe by now I'm wrong!
Here's Pike on the topic of syntax highlighting:
https://groups.google.com/d/msg/golang-nuts/hJHCAaiL0so/E2mQ...
There were 22 comments, and the one from the Go developer was (and I quote):
"Tempted to stop reading after the first word in the article. (The language isn't called Golang)"
Frankly, it's just tiring; especially as a lot of the same points and misconceptions are repeated. Some points are valid, but it's repetitive at best. It would be like discussing Python's significant whitespace with inexperienced Python programmers every week. Sure, it's quirky and arguably not a good idea, but the discussion had been done a few times already.
Turns out that filtering stuff that uses "golang" instead of "Go" is actually a pretty good heuristic for determining if an article is worth reading. Is it perfect? Of course not; it's a heuristic.
Reading your article, this is exactly the sort of "been there, discussed that" kind of example. Your article isn't bad – I think it's mostly on-point – but it's also pretty much a repeat of what many others have said/discussed.
Given that, they do also 'talk down' in their official documentation. I had to look back in time to understand the memory model for the sync.atomic operations which is documented:
"These functions require great care to be used correctly. Except for special, low-level applications, synchronization is better done with channels or the facilities of the sync package. Share memory by communicating; don't communicate by sharing memory."
The final word on what 'great care' means is that Go doesn't actually have a memory model for this part of the standard library. The discussion thread around it has a different tone than the official documentation. They agree on how they want implementations to operate, but don't feel that it needs to be officially defined or documented. I would have been happy if they at least referenced the discussion thread rather than merely label it 'great care' meaning 'not for you'. The other thing you find is that the performant parts of the standard library often does not follow "Share memory by communicating; don't communicate by sharing memory".
One of the betrayals when working with I/O was finding that standard library routines can return a value AND an error, and that sometimes a non-nil error is not an error (EOF is not the only one of these).
CLASSPATH, PYTHON_PATH, PERL5LIB, ...
I never really understand the hate here. It seems more like they didn't hate GOPATH specifically and more that they didn't like not having a package manager.
Go solves Googles main problem -> something which new engineers can use to write practical solutions without having to think too much. It's not beautiful or expressive or technically interesting; most "craftsman" devs won't stick with it too long..But that's not the majority of devs google is hiring.
Sit down, bang out code and don't concern yourself too much with craftmanship - it will be re-written in a couple of years. Just worry about performance.
My primary use case is scientific computing, both data processing and interactive visualization.
I know Julia is an option as well.
For reasons I don't want to bother getting into I dislike Python.
Thoughts?
I am glad to see that the go team is working on cleaning up the tooling situation. I used gocode, then started using modules, found that the primary version was unmaintained, and had to switch to a different fork. I believe I also needed a different version of goimports for a while. Having all this tooling unified into the langserver maintained alongside go sounds wonderful. I hope other languages do the same thing.
So instead of creating M packages * N OSes, we do it just once.
For non-go tools like the protoc compiler I don't think the golang tooling provides any help. A heavyweight option would be a build system like bazel
- https://github.com/golang/tools/blob/master/cmd/golsp/main.g...
I regularly find myself in a position that this system would make impossible: I need a few custom changes in public available libraries. An extra method. A bugfix. What have you. This makes that impossible using the default method.
What we want is consistent builds. That means a build that happens, with the same source, with the same ... every time, always, on everybody's workstation.
Decentralized support has been a thing since the last decade.
I think decentralized is meant as "there's no central repository" here.
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.
> that anyone should be able to publish their code on any server, in contrast to central registries such as Perl’s CPAN, Java’s Maven, or Node’s NPM. Placing domain names at the start of the go get import space reused an existing decentralized system and avoided needing to solve anew the problems of deciding who can use which names. It also allowed companies to import code on private servers alongside code from public servers.
lol statements like this are infuriating. Go is no more decentralized than those languages, unless you consider git hosting something people in standard practice do on their own (survey some of the top Go dependencies and see if that holds true). They simply lack a package index, but the cited language package managers both have those and allow you to host your own.
I think that having a system in place with the language may be a better option than a company with its' own motivations and needs separated from the language/runtime/platform.
As to generics, I think you may well find generics in the future. I feel that most of the resistance was in order to better support core language features. I can't think of any languages (I'm no expert) that started with generics support, so I'd be surprised if this wasn't a go 2.x goal.
For exceptions, I think that the go solution works. Similar to the callback interfaces in node, it puts errors in your face, which isn't a bad thing. I mainly contrast this with node, as it's another language/platform that has grown a LOT but also relatively recent.
You can compare the progress of node, go and others to say python2/3, C#, Java and others. I think go progress has been great by comparison, and pragmatic choices have ruled out.
I use and like Go for writing network servers and ETL processes. In a scientific context though, the type system is awkward in the extreme, there is essentially no library of modules, and the interactive visualization story is nonexistent.
Python, R, Julia, even C++ would be better options IMO.
(I'll clarify again: I like Go! I just think it's not well suited for this context)
[1] https://oracle.github.io/graphpipe
[2] https://github.com/oracle/graphpipe-go/blob/master/helpers.g...
generics may help in that department.
in the meantime, there's Apache Arrow:
If you actually have a primary use case of "scientific computing, both data processing and interactive visualization", ignore Go.
And rethink Python.
Julia can be used, but is still fringe.
R perhaps.
Gonum is almost on par with _e.g._ NumPy/SciPy (most notably lacking: ODEs). So still ways to Go but it's getting there.
Go-HEP is my attempt to bring a few High Energy Physics oriented packages to particle physicists:
I've also written a few words on why I think Go is great for science:
- https://sbinet.github.io/posts/2018-07-31-go-hep-manifesto/
TL;DR: Go is great b/c it brings great s/w engineering practices and a s/w engineering-friendly environment to scientists.
Admittedly, generics will change how packages are written. So some code churn will take place when/if they land, but the Go community learned the lessons from Python2/3 and Perl5/6. Expect a better migration path.
Lastly, I guess the 2 remaining weak points of Go are:
- runtime performances sub-par wrt C++ or Rust
- GUIs (which may or may not fall into "interactive visualization")
That said, the Go community worked on a Go kernel for Jupyter:
- https://github.com/gopherdata/gophernotes
hth, -s
Beyond that, Go is easy and performant. It's great for paralellizing workflows via concurrency and compiling tools for distribution. So if you know what you want to do and need to scale up, it could be a great choice.
- neugram.io
- https://github.com/cosmos72/gomacro
here is a mybinder that used to use the former, and now uses the latter:
If I want to share things, I am aware of links in filesystems, thank you very much Go authors. "go.mod" overrides ... I wish golang did not try to solve yet another non-problem badly.
All the infrastructure with index, notary, mirror, etc. is nice, but at the end of the day you have to fetch some external code, verify it, lock it down in some vendor directory, and check it into your own backed up repo. Everything else is fluff.
If you're not doing this you're dancing with the devil and one day when you need to tweak some module or fix some bug, and the remote source is long gone, you will rue the day you depended on anything except your own source storage. And it will be 3 AM on Saturday, in some dismal server room, with no outside Internet connection, your customers screaming at you, and your phone battery dying, because Murphy's law.
For the purposes of software builds just pretend the rest of the Internet does not exist. Vendor everything, all the time, everywhere, and trust nothing.
This whole gopath-less thing is a bit confusing to me. I wish the 'how to use packages' stuff was clearer.
It didn't take "this long"; the Go team openly admitted the need for a better approach at the very first GopherCon back in 2014, nearly five years ago. (That was not the first time, either).
It takes time to do all that work.
(As a side note, I don't think there are any plans for exceptions -- for good)
Also, https://go.googlesource.com/proposal/+/master/design/go2draf...
However, I wonder how much of this is a difference in substance and how much is about writing style? There is an older, authoritive style that has an implicit "in our opinion, of course" and sounds pretty grating these days.
I remember being taught in school to remove "I think" and qualifiers expressing uncertainty, under the theory that in an opinion piece, that's understood.
Especially these days when hyperbole is common, I prefer writers that have a humble writing style, but also try not to get hung up on stylistic differences.
edit: addendum: but also, in every thread about Go, there are some Haskell people showing up to talk about how the Go team is too stupid to understand the Haskell type system. This happens regardless of what the opening topic is, which in this case, is dependency management. No matter what the topic is, if it's a thread about Go, you will find Haskell programmers there, condescendingly talking about how Haskell's type system is so much better than Go's type system. It is very tiring.
Yes; I've challenged this as hyperbole and people double down.
> Isn't your reply a "bad way to characterize the overall conversation" as well?
I don't think so. My reply characterizes the overall conversation as a difference of opinion about whether or not Go's design choices are matters of tradeoffs, and I believe this to be accurate. I chose my example because it was exceptionally stark, but the point is that if such stark comments are made so frequently, surely there is a long tail of less-stark comments. Anyway, I don't want to belabor the point because we have no data and all we can do is conjecture and stir up bad feelings and likely a flame war, so let's not do that.
To be clear, I give the Java people shit about it all the time and was on the original Java module system JSR that was supposed to deliver it. In the end, the Sun people yanked the dependency part and shipped a module system that is really only useful to the JDK.
And the missing ternary will be the least of your problems. Do you enjoy `map` and `filter`? Sorry, the "go way" is to use a for loop every time. Reimplementing map on every type where you need it is considered best practice in Go. Have a problem with that? Expect a snarky comment about your priorities.
This can all be pretty frustrating when you've experienced the joys of more expressive languages.
Go has good concurrency primitives and is fast. That's what it's good at. Those are the reasons to use it. Temper your expectations accordingly.
Whereas your comment is completely devoid of snark.
Not the official docs of a programming language. In one of those, a bit of snark is really quite normal and of no real impact.
Or try opening new thread on Swift forum on issues where decisions have been take. They will quickly put you in place and close the thread.
I have yet to see a successful language where whiners are embraced with great enthusiasm.
I don't speak about Rust enthusiasts or even the Rust community at large, there are people like that in all languages (though indeed some communities might be better than others, but with large enough numbers of users of a language you get all kinds of people in a similar enough distribution).
I speak of the core team. Go's one has a vibe I don't get from Rust's.
sure, when you need it, you need it. but float64 caters for a good 99% of my usual work day.
From a user POV, seamless installation of packages is a great boon. From a grid/cloud operator POV, static binaries are great too.
I disagree. Again, this may very well be science-domain dependent, but in High Energy Physics (where, finally, Python is recognized as a mainstream language, BTW) many -- if not all -- of the pain points that slow down undergrads, PhDs, post-docs and researchers at large, are these Go features.
yes, the time from "idea" to "little script that shows a bunch of plots" on a subset of the overall data is definitely shorter in Python (exploratory analysis is really really great in Python). but, at least for LHC analyses, python doesn't cut it when it comes to Tb of data to swift through, distribution over the grid/cloud, ... you die by a thousand cuts. and that's when you are alone on one little script. LHC analyses can see well over 10-20 people assembling a bunch of modules and scripts. You really long for a more robust to (automated) refactoring language than python, pretty quickly.
I only mentioned it because the op discussed Go’s language server.
Still, I think my and my parent's point is that: it would have been better if they'd just said nothing.
Yeah, it's an imperfect heuristic. I didn't intend it as a remark about you or your article in particular (I had added a sentence about that in my previous comment, but it must have gotten lost in the editing).
> it would have been better if they'd just said nothing.
Yes, I agree. "If you can't say it nice, then it's probably best to not say anything at all". I thought it would just be helpful to explain some of the frustrations that are (probably) behind the comment.
"While the ternary is often clearer, we chose to sacrifice expressiveness and brevity for the sake of preventing abuses, which we found were all too common."
But that is not the claim being made in the FAQ.
> Thus all if and for statements also require {} brackets.
Indeed this rule seems to spring from the same philosophy. It is most certainly not a preference for clarity, though. It is a preference for consistency.
The philosophy is: "We're giving up expressiveness and brevity because in our experience most people can't be trusted to not shoot themselves in the foot."
This choice would be much more palatable if they were honest about it. But instead, they take the road of insisting that the verbose consistency is actually clearer, which it isn't, at least in many people's opinions.
FTR, with "most certainly" you're committing the same fault your accusing the Go team here. You might not think it matters for clarity. I, at least, disagree.
> in our experience most people can't be trusted to not shoot themselves in the foot.
I don't understand the difference between this suggested phrasing and talking about clarity. I'd argue you tend to shoot yourself in the foot if and only if you aren't clear about what you're doing. Clarity and lack of footguns seem directly correlated.
Fair enough. It's too late to edit.
> I don't understand the difference between this suggested phrasing and talking about clarity. I'd argue you tend to shoot yourself in the foot if and only if you aren't clear about what you're doing.
This is partially true but it's not that simple imo.
In my OP, the ternary version is clearer. But if you allow it, then you also open the door to nested ternaries, and foot shooting.
Allowing single line if statements (as, eg, ruby does) also allows for clearer code, at the expense of consistency.
This is not true. If you pass -mod=vendor, or place it in $GOFLAGS, go will build something outside of GOPATH, in module mode, using the vendor directory exclusively. I wish it was the default, but only because it encourages people to not use vendor directories (which is a bad habit), not because it can't be worked around easily.
But that's not what I'm asking. I want "go build" (with some flags) to use my fork (vendored if needed) for one library, and pick up all other dependencies from the module cache as usual. How do I that?
Because this is already possible in a vendor-only world; I just edit the code in vendor.
Look in /usr/include. There you can see what's wrong with GOPATH, 5 years in the future. Now try installing 2 different versions of libraries.
I'll wait.
They aren't, not having them is.
The current way I handle it is that $HOME/.local is my GOPATH, and $HOME/src links to $HOME/.local/src. So you can just have $HOME/src/github.com/bar/foo -- which is less ideal than just $HOME/src/foo, but it's something at least.
But, yes, I rolled my eyes when learning about GOPATH for the first time.
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'd say the most official thing said on the topic is this FAQ entry, which is quite clear on the matter: https://tip.golang.org/doc/faq#go_or_golang
(not saying Brad's comment isn't abrasive or rude. But it's not "factually incorrect")
FWIW, go-nuts was already taken.
"Maven central" implies there is a central repository though.
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 'town square' or such.
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 means a lot in terms of how centralized things become culturally.
https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...
That was the day I dropped the mailing list.
I disagree with Rob though, syntax highlighting is not juvenile, it's cargo cult programming.
That clearly implies anyone who uses syntax highlighting is juvenile. I'd say calling someone juvenile is meant to be denigrating.
FWIW, as much as I agree with Rob Pike on most things, I totally agree that he's abrasive and his way of phrasing things is often unhelpful (even though I think people also tend to read contempt into his brevity that isn't there). If it helps, I think he has realized that in the meantime and is largely staying out of public discussions for that reason.
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.
My C++, Java and .NET packages work everywhere there is a toolchain available.
Can you explain why that would be a problem? It's certainly not a technical one, none of these are special when it comes to versioning or dependency management of software. I can see that there's a social/political problem - which is exactly what I'm talking about.
The more palatable argument that people who try to cover for ... seems to be that when people nest if expressions, it becomes a mess. I'm glad these people exist.
The real reason is found here: http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
(or if you prefer, in the compiler's source itself. It doesn't take a compiler expert to realize it's not very clean code. Even violates the go style, and the C one before that was just horrendous)
The TLDR is that Go's compiler is a "fisher-price my first compiler" and really shows that the authors simply barely knew how to get a compiler working in the first place. That they were not ready to go into a rational discussion on programming language and type theory ... is not something anyone should be surprised about.
That they avoid the arguments by dismissing the people making them in such a condescending way is ... well, there's not really anything good to say about that.
(setq n (cond
(expr trueVal)
(t falseVal)))
I'd say that even once Go has generics, that will simply take it from being an awful scientific programming language to a mediocre one. I don't really understand why there's a few people who seem to think it's a good idea to try to do their scientific computing in Go when there are so many better options for that that already exist.
Post-generics, though, if you really insist, it will probably be the case that Go can be upgraded from "mediocre" to "tolerable" with a lot of library work. (Part of the "mediocre" is lacking libraries. That aspect can be fixed.) But it'll be hard to start that work without running generic code. Even if you assume the current documentation is the final specs, you still won't be able to guess the performance implications of anything you'd be blindly writing, and performance is very important for this sort of code.
I didn't mean "now" as in right this second. Generics will indeed be key.
What would be the disadvantage of using a syntactic preprocessor to accomplish the same thing? We have an API for parsing golang. What if there was a way of marking certain files to be parsed and re-written with function calls? It could be done with a file suffix, and this could be made fairly convenient.
I don't think this solves the issues. For example, I have yet to think of a way to overload `+` in a consistent and performant manner. E.g. think of `a += b` vs. `a = a + b`. Either you make them separate operators (in which case there's no guarantee they do the same thing - see for example Python, where they commonly differ) or you are overallocating in the common case.
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) out of character. I want to acknowledge that it was rude and validate the person who was wrongly rebuked; I explicitly don't want to pick on anyone nor tempt the Internet to pile on.
"Sydney Golang Meetup - Rob Pike - Go 2 Draft Specifications"
Next have been oddities with vendoring workflows. Given previous decisions it seemed like the golang team was driving towards vendored solutions but with go mod they seem to have backed off of that position. The workflows with go mod are clunkier & less well documented. Unfortunately I’m (and my teams) are highly invested in vendored libraries.
We’ve also had trouble with it not playing nice with dependencies that have not taken up modules (and some that are unlikely to).
That’s not even to mention my problem with their design or the hamfisted way they have gone about it, which is something I just have to get past.
It seems this gets fixed in Go 1.12 though. AIUI you'll be able to set GOMODULES=on, unset GOPATH and just continue working as before.
This (or rather allowing conditionals without braces) was what I was referring to. They are a foot-gun, because of the lack of clarity. It's a common source of bugs in C/C++ code that a developer thought they'd add a line of code to a conditional block or loop but didn't, because of a lack of braces. Requiring braces unconditionally make it always unambiguous and obvious what block a given statement belongs to.
Obviously YMMV - this is, as most discussions in programming, a matter of opinion. Which was my point :)
if (condition)
doSomething
if (condition)
doSomething
doSomething2
if (condition) {
doSomething
}
if err != nil {
return err
}
And there are solutions that allow you to buy your insurance without such a high price. You can invert the position of the if, as ruby does. You could make a rule that when you don't have braces you have to write your statement on the same line. The point is this isn't the only way out. And clarity is not the same as preventing one specific kind of error, which occurs only in a context which could be changed as well.
Geez. That's obnoxious. Why do we programmers do this to ourselves?
or you are overallocating in the common case.
I see. I was thinking along the lines of being able to use complex numbers with arithmetic operators, not along the lines of doing high performance crunching of floats.
Basically before go 1.11, it was impossible to just do
git clone ... somedir
cd somedir
# build code and run something
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.
You can put your code anywhere you want and `go build` and `go run` will work just fine.
It's only third party libraries that have to be in GOPATH, which is exactly a library (well, package) search path.
ie if your code itself is split into modules, they won't work (as they are imported by their full path, not relatively), and anything in your vendor dir is also ignored when used outside of a GOPATH entry.
A package format that supports all OS system paths, installation processes, difference between build time/dev time/deployment time, language compilation toolchains, compiler flags, ways to address hardware resources,OS specific deployment processes, ... is bound to the lowest common denominator for any chance of success.
Thus forcing everyone that needs something beyond that lowest common denominator to implement their own workarounds, thus we are again back to language package managers.
ISTM the "lowest common denominator" is a superset of everything current language-specific package-managers support and a subset of anything a current language-agnostic package-manager supports (pretty much definitionally). So ISTM that this is a net win - easier to build than APT/DNF/Pacman… and yet more useful than npm/stack/pip/…
In particular, I don't know any currently existing language-specific package-manager that supports what I'd call the GCD of package-management (e.g. none that I can think of supports actual OS-specific installation of packages) so that clearly isn't even a requirement.
> Thus forcing everyone that needs something beyond that lowest common denominator to implement their own workarounds, thus we are again back to language package managers.
FWIW, a) part of the political and social problem is to talk more honestly about what "needing" really means and b) no, that's not at all "back to language package managers". You can have a layered design, e.g. splitting the "building" and the "installation" part, thus letting languages implement their workarounds in their dedicated building layer and letting OSes implement their workarounds in their installation layers. You just need to actually sit down and talk about the interface needed between the two (and the sets of layers actually needed, which will be >2). Which no one seems really willing to do.