<p>Hello,</p>
<p>I've been looking for a new language and go is perfect. Until you want to structure your code. I'm a web developer and i always want my code to be MVC.</p>
<p>So what did i do? I created a controllers folder and imported it into my main.go using import "./controllers". It works until i want to use a "github.com/..." package in one of my controllers. I really don't understand this. It doesn't work and when i replace it with "myproject/controllers" it does work. But how absurd is that. That means if i change my folder name my entire code is broken.</p>
<p>I've read so many threads on this and all these people stating that relative imports are bad practice, i lolled. Relative imports are way more logical than absolute imports. Absolute = bad practice. It reminds me of wordpress storing absolute URLs in their database xD It's just so retarded.</p>
<p>Can anyone give me a good reason why they do this. Or if possible a work-around so i can still use relative paths.</p>
<p>Edit: I've seen other people do it: <a href="http://idealogylabs.com/blog/golang/2015/07/11/golang-and-mvc.html" rel="nofollow">http://idealogylabs.com/blog/golang/2015/07/11/golang-and-mvc.html</a>
Doesn't work for me (1.5.1)</p>
<p>(Still no reasons given yet, i must be right.. i guesse.. Although, someone mentioned that it's just how it is and the language might not be what im looking for = fair point)</p>
<hr/>
<p>Someone (PsyWolf) linked me this: <a href="https://groups.google.com/forum/m/#!topic/golang-nuts/1XqcS8DuaNc/discussion" rel="nofollow">https://groups.google.com/forum/m/#!topic/golang-nuts/1XqcS8DuaNc/discussion</a></p>
<p>And here you can read that relative paths work if your project is outside your GOPATH :o Perfect! it works! It's like almost no-one knows this or keeps it a secret. I'm amazed! 100x Thank you for sharing that link.</p>
<p>Or am i just stupid for placing my project in GOPATH/src?</p>
<hr/>**评论：**<br/><br/>bradfitz: <pre><p>You might try asking the question without first claiming that "It's just so retarded". You could say "stupid" instead if you really need to express an opinion, or perhaps you could ask a question and assume the authors made it that way based on experience or some design principle.</p></pre>cortexio: <pre><p>I'm sure they had a reason for it. But i'm also sure it's not a good one.</p></pre>jerf: <pre><p>Bending a language's design for how is modules work for one particular interpretation of one particular design pattern would be, what's the word, "retarded".</p>
<p>MVC merely mandates that you have classes that are clearly either M, V, or C. It does not require that you organize them in any particular way. That is a requirement you are bringing to the party, not MVC.</p>
<p>Personally I've never seen the point of that organization. I've always preferred to organize them by logical units of functionality, not by a rather arbitrary structural distinction.</p></pre>cortexio: <pre><p>Hey look at my project, 1 folder with 100 files. xD</p>
<p>Anyway. Relative paths do work. You just need to place your project outside the GOPATH/src , I didn't know this. Is that obvious? I might have followed the wrong tutorials.</p></pre>icholy: <pre><blockquote>
<p>Hey look at my project, 1 folder with 100 files. xD</p>
</blockquote>
<p>"I only know MVC, and everything else must suck."</p></pre>cortexio: <pre><p>Well, yeah... that's why everything is MVC in web unless you're making a tiny API. It's not about MVC though, it's more about your code being spread out in a structured way. Having everything in 1 folder reminds me of the 90s.</p></pre>PsyWolf: <pre><p>If you try to force your preconceived notions from other languages into go, you're gonna have a bad time. I'm not just talking about this one case, but in general. Go is a language where if you want to use it effectively, you really have to give up control about these tiny things (Relative vs absolute imports, vendoring vs package management, spaces vs tabs, generics vs code generation, etc). If you must have your way about these things then go probably isn't the language for you.</p></pre>cortexio: <pre><p>Understandable. Still i'd like to know why =/ I've been checking almost every language and Go is the only one that gets close to being a good language. Node js is single core callback hell. Rust and elixir aren't web ready yet. The only decent languages are php, ruby and python. But they are slow compared to compiled languages. If only someone could make the perfect compiled language... Go is the closest thing to that.</p></pre>PsyWolf: <pre><p>And as for why go prefers absolute import paths, check out</p>
<p><a href="https://groups.google.com/forum/m/#!topic/golang-nuts/1XqcS8DuaNc/discussion" rel="nofollow">https://groups.google.com/forum/m/#!topic/golang-nuts/1XqcS8DuaNc/discussion</a></p>
<p>It was discussed at length there</p>
<p>Edit: and also <a href="https://codereview.appspot.com/5787055" rel="nofollow">https://codereview.appspot.com/5787055</a></p></pre>cortexio: <pre><p>OMG! You solved my problem! It's only when you are working inside the GOPATH that you can't use relative paths. Outside your gopath they work perfectly! Thanks!</p></pre>PsyWolf: <pre><p>Sigh... I hope you realize that you're doing exactly the opposite of every piece of advice in this thread. I'm asking you one last time to forsake this madness.</p>
<p>By abandoning GOPATH, you're officially fighting the language. It's not that the community doesn't still want to help you, but we simply won't know how. You're going down a road that most of us have never traveled. If you do this, you're on your own. Good luck.</p></pre>PsyWolf: <pre><p>Then by all means, stick with go. Just try not to sweat small details like this. It's OK to think go's way of doing something is wrong. I have my own small gripes about the language too, but I'm most effective with go when I ignore them and try doing things "the go way". More often than not, the thing I thought was so awful, isn't all that bad. Sometimes it turns out to be even better than what I wanted go to let me do in the first place. <strong>cough</strong> error handling <strong>cough</strong></p></pre>devsquid: <pre><p>You could use the JVM if performance is a concern.</p></pre>Manbeardo: <pre><p>This topic is pretty well covered in several other locations. <a href="http://stackoverflow.com/questions/10687627/relative-import-from-parent-directory" rel="nofollow">Relevant StackOverflow</a>.</p></pre>zackkitzmiller: <pre><p>Relative imports actually are a bad practice. Perhaps you should try to listen to people before laughing at them. </p>
<p>Storing an absolute URL in a datastore is quite a bit different than code structure. </p></pre>cortexio: <pre><p>But why is it bad practice? I mean, people might say "Water is bad for you". You still need to know why else you might believe anything.</p></pre>zekzekus: <pre><p>it looks like this weirdness is a result of a design choice with go packages. </p>
<p>as i can see nobody did mention any reasonable argument about this design. i can find only one sentence about this, something like "a go package must be imported with an unique identifier everywhere".</p>
<p>at the end, it looks weird and bad design. and yes, may be the language is not for you. you should read this: <a href="https://news.ycombinator.com/item?id=9485741" rel="nofollow">https://news.ycombinator.com/item?id=9485741</a></p>
<p>i do not prefer to drive this golang car. may be you shouldn't either. </p></pre>cortexio: <pre><p>After finding out how it works, i can say: Go designed it perfectly. Only... It's like almost all go-devs don't know how it works. They all seem to jump to the retarded sentence "It's bad practice". And it's not. Ofcourse it's not. But hey. Almost everyone said "angular is awesome". = Majority of devs are shitty devs.</p>
<p>So how it works:</p>
<p>In GOPATH/src, use absolute paths</p>
<p>Projects outside GOPATH/src, use absolute or relative paths based on your needs.</p></pre>calebdoxsey: <pre><p>If you don't follow the convention your project will not be go-gettable. It's bad practice because it doesn't play well with others.</p>
<p>If you use goimports this is largely a non-issue. It will manage your imports so you rarely ever type it out. (And an editor like atom+go-plus or vim comes with all these bits included)</p>
<p>Renaming a project is rare. But it's also not difficult as you can easily use a find and replace.</p>
<p>In other words the design decision may seem strange, but in practice it has little impact on productivity. In fact its simplicity led to things like godoc.org.</p></pre>cortexio: <pre><p>That's the thing. It doesn't need to be go-gettable. I'm working on a web project in go and not a re-use-able go package.</p></pre>xsolarwindx: <pre><p>Thanks for letting us know that it's retarded. I'll be sure to pass the message along to Rob Pike and Ken Thompson et. al. </p></pre>cortexio: <pre><p>if you could, that would be great actually.</p></pre>
