Go Modules in 2019
blog.golang.org
Go Modules in 2019
1–10 of 178 posts
Re: Go Modules in 2019
#2Nice overview, however a small correction to the statement about Maven repositories.
Decentralized support has been a thing since the last decade.
Re: Go Modules in 2019
#3Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with "npx"; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn't compile.)
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.
Re: Go Modules in 2019
#4I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in.
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?
Re: Go Modules in 2019
#5Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with "npx"; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn't compile.) I am glad to see that the go team is working on cleaning u…
For tools in golang like goimports the best practice at the moment is to have a tools.go with a "tools" build tag. See https://github.com/golang/go/issues/25922
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
Re: Go Modules in 2019
#6I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. 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?
It's not well-suited to scientific computing at all.
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)
Re: Go Modules in 2019
#7Does anyone know what the story is for binaries generated by things your project depends on? npm versions them and lets you invoke them from the project with "npx"; I wish something like this existed for go. (protoc-gen-go is the main thing I want; if your global version gets out of sync with the version in go.modules, the generated protobuf doesn't compile.) I am glad to see that the go team is working on cleaning u…
On a vaguely related note, is there any decent documentation for writing a lang server. I've seen the official documentation by Microsoft and while it does seem a detailed reference, it's not great for someone who doesn't even know where to start in writing one.
Re: Go Modules in 2019
#8One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wrong.
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.
Re: Go Modules in 2019
#9One of the thing that's always been a bit off-putting about the Go community and leadership is that it seemed that when I came across things that I perceived as flaws in the tooling or language, I often felt told off and was made to feel that it's me who is wrong for a variety of reasons. Examples of this include GOPATH, the package infrastructure, error handling, lack of generics. Rob Pike disagrees so I must be wro…
Honestly I got the impression no one ever liked gopath.
Re: Go Modules in 2019
#10I really want to get into Go, I like that it's opinionated, I like that it's compiled, I like that it's garbage-collected, I like that coroutines are built-in. 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?
It's not well-suited to scientific computing at all. 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 t…
If one wants to be a pioneer and be one of the people who starts the movement, now is the time to jump in and make a name for yourself.