7 ms·

I frequently describe Go as "C, with memory safety and GC". I don't run into many that disagree. Go is basically how Java was pre-generics. People forget that

I frequently describe Go as "C, with memory safety and GC". I don't run into many that disagree. 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.

otabdeveloper4 6y ago
> Converting C++ to Java is still trivial unless there's pointer craziness. Generally copy paste the C++ and change naming conventions. What? You've obviously never seen actual C++ code to make such a ridiculous statement.
- nvarsj 6y ago
  Google C++ looks a lot like Java, maybe that's where they are coming from. But it's still quite a stretch!
  - otabdeveloper4 6y ago
    As they say, "you can write FORTRAN in any language".
- pjmlp 6y ago
  1996 C++ (when Java appeared) being used in MFC, OWL, Powerplant and CSet++, alongside Smalltalk in the gang of four book, definitely.
sofixa 6y ago
> Like C it has no generics, bad packaging, and is a pain in the ass to cross compile. 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?
- zimpenfish 6y ago
  > It's very easy and i literally cannot imagine it being easier. `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.
- simiones 6y ago
  I would say Go has very poor packaging, but this is when comparing it with Java (maven), Rust etc. It's definitely much better than C. 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.
  - sofixa 6y ago
    > The biggest reason why Go modules are a very poor packaging solution is the horrendous stupidity of tying them to source control 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.
solatic 6y ago
> I hate working on unfamiliar Go projects. Copy pasted code everywhere. And everyone builds their own abstractions because there aren't enough. Arguably, 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.
- cy_hauser 6y ago
  I don't disagree with your conclusion but I don't see it following from the quoted premise. What was your thought chain to get from the quoted text to OO stuff?
  - solatic 6y ago
    There's a difference between using a struct to represent concepts like program configuration or grouped function parameters, and shoehorning OO-native design concepts like the decorator pattern that need inheritance into a language that doesn't support dynamic dispatch. Much of the bad Go code I see comes, yes, from overusing abstractions and lots of copy-pasting, but most of that comes from trying to fit square pegs like OO design into Go's round hole.
    - cy_hauser 6y ago
      Still don't get the connection in the way you do. Maybe I'm so used to OO stuff that I just gloss over 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_implementation https://en.wikipedia.org/wiki/Dynamic_dispatch#Go_and_Rust_i...
Tobu 6y ago
In fact, Go is not even memory safe despite the GC. It has data races, which are exploitable. - https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html - https://golang.org/doc/articles/race_detector#Introduction

otabdeveloper4 6y ago

> Converting C++ to Java is still trivial unless there's pointer craziness. Generally copy paste the C++ and change naming conventions. What? You've obviously never seen actual C++ code to make such a ridiculous statement.

nvarsj 6y ago
Google C++ looks a lot like Java, maybe that's where they are coming from. But it's still quite a stretch!
- otabdeveloper4 6y ago
  As they say, "you can write FORTRAN in any language".
pjmlp 6y ago
1996 C++ (when Java appeared) being used in MFC, OWL, Powerplant and CSet++, alongside Smalltalk in the gang of four book, definitely.

sofixa 6y ago

> Like C it has no generics, bad packaging, and is a pain in the ass to cross compile. 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?

zimpenfish 6y ago
> It's very easy and i literally cannot imagine it being easier. `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.
simiones 6y ago
I would say Go has very poor packaging, but this is when comparing it with Java (maven), Rust etc. It's definitely much better than C. 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.
- sofixa 6y ago
  > The biggest reason why Go modules are a very poor packaging solution is the horrendous stupidity of tying them to source control 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.

solatic 6y ago

> I hate working on unfamiliar Go projects. Copy pasted code everywhere. And everyone builds their own abstractions because there aren't enough. Arguably, 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.

cy_hauser 6y ago
I don't disagree with your conclusion but I don't see it following from the quoted premise. What was your thought chain to get from the quoted text to OO stuff?
- solatic 6y ago
  There's a difference between using a struct to represent concepts like program configuration or grouped function parameters, and shoehorning OO-native design concepts like the decorator pattern that need inheritance into a language that doesn't support dynamic dispatch. Much of the bad Go code I see comes, yes, from overusing abstractions and lots of copy-pasting, but most of that comes from trying to fit square pegs like OO design into Go's round hole.
  - cy_hauser 6y ago
    Still don't get the connection in the way you do. Maybe I'm so used to OO stuff that I just gloss over 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_implementation https://en.wikipedia.org/wiki/Dynamic_dispatch#Go_and_Rust_i...

Tobu 6y ago

In fact, Go is not even memory safe despite the GC. It has data races, which are exploitable. - https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html - https://golang.org/doc/articles/race_detector#Introduction