proposal: cmd/go: do not compile files larger than 1 MB #21562
Comments
|
Out of curiosity, on what order of magnitude are the resulting binaries for these huge sources? |
|
@as sorry, I don't have the numbers, nor do I think it would be relevant. My interest with this proposal is to have the files readable, not work on a package scope nor on the binary size. This is of little concern to me as the Go compiler should be pretty good at removing the unused symbols, hopefully, and my normal deployments are on things that have enough disk space for binary sizes not to be of concern. A different way to display documentation would be useful as well, see the examples, but that's probably better addressed in the godoc repository (and I don't have any good ideas on that for now). |
|
While ridiculously large source files are annoying for humans, I believe the toolchain is the wrong place to address this. Other than that, I don't have any better suggestions other than some other tooling. |
|
I share the intent, but not the solution. As @dsnet said, I don't think the toolchain is the right place for this. For example, for a project of mine I need to quickly iterate on small changes made to a package's source code. Something I've considered is merging all files into one (like with I also don't understand the point about the godoc. The godoc page is loaded from all the files in a package, so it should not matter whether there are 10k lines in a single file or across five files. This reminds me a bit about the linters that don't like code that is too long or too complex, such as https://github.com/fzipp/gocyclo. Have you thought about making a linter that would snap at any file larger than an amount of lines or megabytes? It obviously wouldn't get the same community blessing as |
|
Go was designed with good readability in mind, but if somebody wants to write unreadable code there's no way to prevent that. Setting a max. source file limit is certainly not going to achieve that. What's way too big for one person, may be just fine for another one. If anything, one might want to appeal to writers of APIs to organize them in a readable way. But some APIs are also generated from descriptions, so your mileage may vary. At best, I see this is an appeal for good documentation and perhaps "reasonably" sized files. Maybe at some point we'll have some AI-driven tool that can judge the quality of a piece of code. But I don't think the compiler should have an artificial limit. |
|
There is no single appropriate limit here. Tools need to be able to deal with large source files. This is not unique to Go. Past attempts to define size limits almost always turn out wrong. "640k should be enough for anyone" and so on. |
|
Agreed. Thanks for feedback and sorry for the delay. Do you think a discussion on golang-nuts for potentially a standalone linter would be helpful? |
Hi,
Before I start, I would like to state that I don't want to have this done in 1.10, 1.11 or 2.0 (whenever that would happen). However, I do wish to have a discussion around this. Maybe a different solution can be found so that both humans and editors (or other tools) can be better at this.
I'm writing this as I believe that it is a missing feature for Go, one which always left me with a bad feelign whenever I got near it.
Whenever I see code that longer than a couple of thousands of lines in a single file it just makes it terribly hard to follow / work with and understand what's happening.
Go's main feature for me, and I think/hope a lot of others, is readability. But that goes away when you have to keep reading such big sources.
To offer concrete examples:
Because of files like that, the documentation is often (caveat tables.go) bloated, see:
I understand that the examples are just code that's generated by tools but that doesn't mean that we must have a bad experience as programmers just because of the tools not being able to generate reasonable files. Equally, there is code out there (that I cannot link here) that is bigger than this.
Also, one can imagine code that wraps existing C libraries, which also tends to be rather big (see OpenGL for example).
The biggest downside of this proposal would be that generated code would need to suffer some improvements (as per example above). Equally, code that embeds resources would need to have a better definition and representation as to what this is (as seen above).
Thank you for your time and consideration.
The text was updated successfully, but these errors were encountered: