I've started playing with Go today, just understood the basics and still a bit confused about the module and goroutine parts. I'll try to make something interesting soon.

(#pysczza) @justamoment I haven't touched the goroutines yet (I played with these like 10 years ago), but I haven't found a case where I need these. About the modules, those were very non-intuitive to me, coming from Python, C#, and JS. I think the official documentation from Go is not clear enough and has no simple examples... After a few searches, I reached Stack Overflow and blogs with tips for Modules and subdirectories. Now, I can replicate an MVC model with templates. This project helped a lot:

(#pysczza) @eaplmx Thank you so much. I got the fact that everything get bundled from a single folder but I too am used to properly specify what I want for every module since using Python/JS. On my tries I managed to do local imports and compile with `GO111MODULES` but I was confused on the uses of that flag. Online everything mentioned the url as a reference to the source and I was missing the point of using it locally from a single project. On a post the recommendation was to not use folder which is pretty bad in my opinion for a bigger project, also looking at yarn repo didn't cleared up my doubts (too big for me right now 😓). Thanks again!

(#pysczza) @justamoment @eaplmx Modules are a bit weird, indeed. In fact, you can name your module differently than the directory name. To the extreme, you can have a directory "foo", but call the module "bar" and call the "bar" directory your module "foo". Not sure why anyone wants that, but there you have it. However, when it comes to nested modules, I believe the "prefix" path components must match the directory names or else Go won't find anything. So I recommend to always make the module name and directory name the same. That also puts much less cognitive work on yourself. :-) Basically think of goroutines as lightweight threads.

(#pysczza) @lyse this is what confused me the most. But also Python is confusing in this case. Java does a good job here with the packages. Go, when you develop outside the gopath, can get as you described, weird too

(#pysczza) @carsten So I wanted to reply to this Yarn with some comments, but wasn't able to _really_ do so whilst out 'n about camping with the family 😅 -- Basically Go's modules (_the more recent version_) is actually pretty good. Let me try to help you understand the basics of it... When defining a new package/library, run `go mod init git.mills.io/prologic/foo` (_as an example_). This could also be `github.com/prologic/foo` or anywhere else with a publicly accessible Git source. I recommend this as the _easiest_ as things will "just work"™. Next, **never** do development in `$GOPATH` as this is basically deprecated and gone now. Always code outside of `$GOPATH` and use modules as per above. Finally if you are not ready to publish your work and you depend on `foo` and `bar` and maybe something else too (_like Yarn.social's codebase_) then use `$ go mod edit -replace git.mills.io/prologic/foo /User/prologic/Projects/foo` (_as an example_).

(#pysczza) @prologic ahh ok. Do you can now use local relativ air absolute path‘s? that was not possible before iirc

(#pysczza) @carsten Yes but only with the constructs i mentioned above👌

(#pysczza) @prologic I'm missing something here, does this allow to remap a local module with it, or is just a reference for the whole project/module locally?

(#pysczza) @justamoment I found that part is well documented 🙂 So, to understand the theory I started here And a few explanations in SO helped me to practice it in my project: