What? You've obviously never seen actual C++ code to make such a ridiculous statement.
- https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html
- https://golang.org/doc/articles/race_detector#IntroductionArguably, if the project requires lots of abstractions and copy-pasted code, then the project shouldn't be written in Go. Just because you can, technically speaking, write object-oriented code in Go does not mean that it is ergonomic to do so or a recommended use-case for the language. Projects that benefit from object-oriented design should stick to languages with first-class support for it.
> a language that doesn't support dynamic dispatch.
Go's interfaces do support this enough that I consider it worth at least mentioning.
https://en.wikipedia.org/wiki/Dynamic_dispatch#Go_and_Rust_i...
Go modules are pretty good packaging IMHO. What don't you like about them?
As for cross-compiling, are you joking? It's very easy and i literally cannot imagine it being easier. What's painful about it?
The biggest reason why Go modules are a very poor packaging solution is the horrendous stupidity of tying them to source control. This makes it difficult to develop multiple modules in the same repo, it requires your source control system to know Go, it makes internal refactors a problem for all consumers of your code (e.g. if you are moving from github to gitlab, all code consuming your package will have to change their imports).
The versioning ideas of their module system, particularly around the v2+, have made it such a pain that there still isn't a single popular package that uses the proposed solution so far, not even Google ones like the Go protobuf bindings.
I think it's actually a great idea. It uses native things you use anyway, avoids an unnecessary third party ( a package repository like pypi), and adds in extra security ( remember those hijacked pypi credentials and pypi-only malicious packages that weren't in source control, so hard to verify?).
> This makes it difficult to develop multiple modules in the same repo
How so? You can justs use different folders and packages.
> requires your source control system to know Go
Not really.
> it makes internal refactors a problem for all consumers of your code
That's always the case - regardless of your package repository, if you change it, you have to update the new references everywhere. You can use go.mod to replace a reference ( e.g. use gitlab.com/me/library instead of github.com/legacy/library) without updating all the code. And then there's the goproxy protocol, which makes all of this optional.
I agree on v2 modules, that is very weird.
Not really. You may be using Git internally, but if you want to consume a module that is developed in Perforce or Subversion, you must now also install P4 and/or Subversion and configure them so that they have access to the remote repo.
It doesn't avoid a third party, it actually makes you reliant on numerous third parties, the source hosting sites for every module you use (Github is a 3rd party between me and the developers of the Go language bindings for protobuf, for example).
Also, that is false extra security, as nothing prevents the code itself from being malicious or embedding malicious files, and this can be arranged to be served only when request through Go mod (based on headers, on the HTTPS requests that only Go mod makes etc.). Especially given that go supports shell execution in source files (//go:generate rm -rf ~/).
> How so? You can justs use different folders and packages.
If you have multiple modules in the same repo, you have to tag every "release" with multiple tags, one for each module (e.g. mod1/v1.0.123, mod2/v1.0.131) and you'll quickly run into problems (if you don't sync releases, you'll have absurd combinations of module versions whenever you sync your repo, so you won't be able to rely on `replace` clauses for example).
> > requires your source control system to know Go
> Not really.
It does, if you have a dependency like "github.com/user/proj", go mod will first make an HTTPS request to this URL and expect some specific responses telling it how to get the code.
> That's always the case - regardless of your package repository, if you change it, you have to update the new references everywhere.
If I publish my modules to Maven, I can switch from Perforce to Git without any change whatsoever for anyone consuming the Maven package. I can split or merge my repos internally in any way, but as long as I produce the same Maven package, my consumers don't need to care.
Replace directives and goproxy are bandaids for a silly problem to have.
`go build -target x.y` could be considered fractionally easier than `GOOS=x GOARCH=y go build`? But yeah, this is a nonsense claim by GP.
Go is basically how Java was pre-generics. People forget that early Java was much like Go in some respects. Everything casted to object. Not really sure what the object is unless you wrote the code. Lack of common patterns and a rich set of libraries (Guava, Apache Commons).
Early Java was supposed to be safe C++. Converting C++ to Java is still trivial unless there's pointer craziness. Generally copy paste the C++ and change naming conventions.
I hate working on unfamiliar Go projects. Copy pasted code everywhere. And everyone builds their own abstractions because there aren't enough.
I don't understand Go's appeal. To me it feels clunky and stuck in the 90's. Designed by C programmers for C programmers.
Like C it has no generics, bad packaging, and is a pain in the ass to cross compile. Its only killer feature, IMO, is it's fiber threading model and that's quickly being copied by other languages, even ancient Java.