4 ms·

> Very cross-platform out of the box. Not “sort-of cross-platform as long as it’s unix” like C/C++ Wut? Firstly, no it's not. I have to drop into MinGW just to

> Very cross-platform out of the box. Not “sort-of cross-platform as long as it’s unix” like C/C++ Wut? Firstly, no it's not. I have to drop into MinGW just to interface with native libs statically. Many languages don't do this. Secondly, C++ is very at home on Windows. Not a very good FFI story for something that is very cross-platform that it only binds w/ C libs with only one Unix compiler (gcc). It's like you got the phrasing exactly backwards and need to switch Go and C/C++. > Go feels under-engineered because it only solves real problems. Until I list the ones it doesn't. Or are they not "real"? You know what? I'm not reading these things anymore. We know the type...supposedly senior devs writing a bunch of words about one language over another, cherry picking specific things for both to fit the narrative. I feel like this is how Michael Moore would write blog posts comparing languages. Sorry to hop on this article like this, saw it a couple of days ago with the Java/Kotlin blog post too and I'm seeing it every so often. And I like Go and Java. I'm afraid I just don't see these language opinions as that valuable anymore since I write in them all myself and know better. Edit: In retrospect, probably a bit harsh. But I'd prefer the journalistic lang X does this but not this approach over the op-ed.

anothergoogler 8y ago
See, this is why I don't blog. Something hits the top of HN and you go from "guy writing about tech for fun" to "supposedly senior dev" faster than you can blink.
- kodablah 8y ago
  Meh, people like me shouldn't be able to make you feel bad about what you write. I would recommend ignoring me or disagreeing with me the way I have with the author. Otherwise, this would be the reason why I don't comment on HN. My comment hits the top and someone complains faster than you can blink.
tptacek 8y ago
I'm an old C++ programmer who's had the pleasure of doing an XP codebase and I would pick Go any day of the week over the early-aughts C++ I remember working in --- but I concede this may have gotten better since then. While I don't think he was trying to say Go solves every real problem (rather, just that the subset of problems Go solves are all practical and not theoretical), it would be constructive if you could take the time to list the problems you think Go is bad at solving, and why. I'll probably agree, but I may also learn something, and I'll definitely learn more about where you're coming from.
- kodablah 8y ago
  While I would choose Go too, my specific complaint was about saying that Go is very cross platform and C/C++ are only sort of in a Unix way. Not only do I think Go has cross-platform issues wrt Cgo and that they only support gcc (but hopefully changing [0]), but that it is incorrect to say C/C++ is "sort-of cross-platform as long as it's unix". Those types of statements turn me off the article. So I stopped reading after that and the "real problems" statement. I'm not sure it has much value to list places where Go may not solve the problem because we all know the limitations of our languages/platforms/runtimes. Among places Go is not the best: low-level embedded software, very performance critical software, software static correctness is more important than maintainability, etc. It's like saying Rust solves all real problems. While I guess mostly true, it doesn't mean too much to me. In general, I'm just finding these posts have little value to me anymore. 0 - https://github.com/golang/go/issues/20982 https://github.com/golang/go/issues/20982
  - skybrian 8y ago
    This is just disagreeing on definitions. You're assuming a particular definition of "cross-platform" and I think what they mean is that pure Go (using its standard library) is very portable. It's great if the standard library does what you need.
    - detuur 8y ago
      A portable stdlib does not a portable language make.
- atombender 8y ago
  As someone who uses Go daily and enjoys it a lot, there's definitely an inflection point in many areas where Go's lack of abstraction becomes a pain point. One application I work on is a real-time query engine. Queries are parsed into ASTs, then reorganized into a higher-level graph reminiscent of relational algebra, then run through optimization stages, etc. Go is terrible at this in pretty much exactly the same way C is. Clearly, good software has been written in C that face the same challenges; PostgreSQL comes to mind, but I've read the PostgreSQL code, and while it's clean, I don't find it that readable or nice. Those guys work with C's limitations, of course, and that's fine. One specific example here is matching structures. I look at Haskell and Scala with envy, because you can do things like this (pseudocode!): match expr { Or(p, And(q, r)) => And(Or(p, q), Or(p, r)) } Similarly, writing graph-traversal (walking and transformation) logic in Go is painful. Go doesn't have sum types, so you have to dick around with interfaces (which weren't meant for this) and write big table-driven tests to ensure that all your matching cases is exhaustive. There's a lot of boilerplate, and there are times where I've been tempted to write code generators that use small DSLs that let me express everything in a higher-level way. But I've not taken that step yet. If I'd started this particular project today, the choice would have been Rust or C++. This applies to future project that smell like something that'd need this kind of expressiveness. Another area where Go disappoints is how surprisingly hard it is to write good concurrent programs that need to distribute work and handle errors in a resilient manner. Your actual logic — the meat of your program — quickly becomes obscured by error handling, ErrGroups, channel orchestration, inelegant wrapper structs, managing the lifecycle of resources (sockets and files and what not) and, ugh, contexts. Context is like a virus that morphs code into refactoring monsters every time you start weaving it through your application. I get Erlang envy when I need to do even the simplest thing, like coordinate the concurrent importing of chunks of data that is distributed to a dynamically growing/shrinking pool of worker goroutines. With all the bragging about modern CSP, Go provides nothing that can compete with Erlang supervisors, which is mightily strange for a (relatively speaking) new language supposedly invented for writing resilient networked systems.
tene 8y ago
While I agree with most of your comment, I think you've misinterpreted the intent here: > Until I list the ones it doesn't. Or are they not "real"? My reading of the original post is asserting that there is a specific set of problems that Go is designed to solve well, and that it's avoided providing functionality not related to those specific problems. The entire comparison is to a "shop-made jig", which explicitly solves only a specific subset of all problems you might encounter in woodworking, but is not at all a general-purpose tool. This definitely fits with my experience with Go. If you want to build something that only needs concrete data types, channels, HTTP, and a database connection, and want to bang it out fast and move on, Go works well in this niche, because that's precisely the set of "real problems" that it was designed to solve. I do not consider Go a general-purpose programming language. I would not use Go for ambitious large-scale projects. If I were putting together an engineering team to write a small network service, with junior developers, Go would be at the top of my list.
- kodablah 8y ago
  I admit I may have taken the "solves real problems" too literally and did not read the rest to understand it.
  - tene 8y ago
    These kinds of nuances can be a bit subtle; I hope I managed to come across as polite correction instead of attack. :)
JepZ 8y ago
Go is cross-platform out of the box. The problem is that you can integrate other languages like C which often don't come with cross platform compilers. So any Go program which depends in some way on C is not cross platform anymore (as long as you don't have a cross platform C compiler). To be honest I don't know how to solve that issue. On the one hand I really like the easy cross platform capabilities of the Go compiler, on the other hand I don't want to sacrifice language interoperability for cross platform builds. I wonder how someone who has C/C++ experience thinks of Go as not being a cross platform language.
- kodablah 8y ago
  > To be honest I don't know how to solve that issue Support more compilers (e.g. clang, msvc). It can be more work than it's worth, sure and I understand the issues there, but jumping through hoops per platform (e.g. can't use a popular lib like https://github.com/mattn/go-sqlite3 https://github.com/mattn/go-sqlite3 on Windows without a MinGW gcc installation) is worth noting when touting the cross platform ease of use. Langs like Rust were lucky to compile to the same IR as a cross-platform C compiler. > I wonder how someone who has C/C++ experience thinks of Go as not being a cross platform language. I don't think that and definitely never would. I said it has issues, namely in the Cgo department. And I said that the other statement about C/C++ only being Unixy was wrong. I definitely like Go and its cross-platform ability and hope I didn't give the impression that I don't.
  - justin66 8y ago
    What's the big deal with using mingw?
    - pcwalton 8y ago
      MinGW doesn't integrate as well with the predominant workflows (toolchains, linking, debugging, etc.) Most Windows desktop apps are compiled using MSVC, so this is important for many people. Just to name one issue of many, MSVC uses Microsoft's PDB format for debugging instead of GCC's DWARF.
    - 8y ago
accnumnplus1 8y ago
It feels even less cross-platform when you have a team mate who uses x/sys/unix and you're on a mac, which may be expected, but your first quote seems to miss such situations. (The quote itself, not your comment on it - [edit for calrity]).
p_l 8y ago
The fun thing is that Go on unix is not the native Go environment, and it shows in several places, including treatment of import paths of all things (the whole GOPATH thing). It shows even more in the fact that it originated, and afaik is still partially compatible, with a C compiler that is completely alien to both GCC and MSVC worlds. In essence, Cgo is a hack even on GCC. Windows treatment of C and C++ as "just yet another language" is very alien, however, to the devs who come from unix world, and many basic things are not handled corrently by them or even planned for :(

anothergoogler 8y ago

See, this is why I don't blog. Something hits the top of HN and you go from "guy writing about tech for fun" to "supposedly senior dev" faster than you can blink.

kodablah 8y ago
Meh, people like me shouldn't be able to make you feel bad about what you write. I would recommend ignoring me or disagreeing with me the way I have with the author. Otherwise, this would be the reason why I don't comment on HN. My comment hits the top and someone complains faster than you can blink.

tptacek 8y ago

I'm an old C++ programmer who's had the pleasure of doing an XP codebase and I would pick Go any day of the week over the early-aughts C++ I remember working in --- but I concede this may have gotten better since then. While I don't think he was trying to say Go solves every real problem (rather, just that the subset of problems Go solves are all practical and not theoretical), it would be constructive if you could take the time to list the problems you think Go is bad at solving, and why. I'll probably agree, but I may also learn something, and I'll definitely learn more about where you're coming from.

kodablah 8y ago
While I would choose Go too, my specific complaint was about saying that Go is very cross platform and C/C++ are only sort of in a Unix way. Not only do I think Go has cross-platform issues wrt Cgo and that they only support gcc (but hopefully changing [0]), but that it is incorrect to say C/C++ is "sort-of cross-platform as long as it's unix". Those types of statements turn me off the article. So I stopped reading after that and the "real problems" statement. I'm not sure it has much value to list places where Go may not solve the problem because we all know the limitations of our languages/platforms/runtimes. Among places Go is not the best: low-level embedded software, very performance critical software, software static correctness is more important than maintainability, etc. It's like saying Rust solves all real problems. While I guess mostly true, it doesn't mean too much to me. In general, I'm just finding these posts have little value to me anymore. 0 - https://github.com/golang/go/issues/20982 https://github.com/golang/go/issues/20982
- skybrian 8y ago
  This is just disagreeing on definitions. You're assuming a particular definition of "cross-platform" and I think what they mean is that pure Go (using its standard library) is very portable. It's great if the standard library does what you need.
  - detuur 8y ago
    A portable stdlib does not a portable language make.
atombender 8y ago
As someone who uses Go daily and enjoys it a lot, there's definitely an inflection point in many areas where Go's lack of abstraction becomes a pain point. One application I work on is a real-time query engine. Queries are parsed into ASTs, then reorganized into a higher-level graph reminiscent of relational algebra, then run through optimization stages, etc. Go is terrible at this in pretty much exactly the same way C is. Clearly, good software has been written in C that face the same challenges; PostgreSQL comes to mind, but I've read the PostgreSQL code, and while it's clean, I don't find it that readable or nice. Those guys work with C's limitations, of course, and that's fine. One specific example here is matching structures. I look at Haskell and Scala with envy, because you can do things like this (pseudocode!): match expr { Or(p, And(q, r)) => And(Or(p, q), Or(p, r)) } Similarly, writing graph-traversal (walking and transformation) logic in Go is painful. Go doesn't have sum types, so you have to dick around with interfaces (which weren't meant for this) and write big table-driven tests to ensure that all your matching cases is exhaustive. There's a lot of boilerplate, and there are times where I've been tempted to write code generators that use small DSLs that let me express everything in a higher-level way. But I've not taken that step yet. If I'd started this particular project today, the choice would have been Rust or C++. This applies to future project that smell like something that'd need this kind of expressiveness. Another area where Go disappoints is how surprisingly hard it is to write good concurrent programs that need to distribute work and handle errors in a resilient manner. Your actual logic — the meat of your program — quickly becomes obscured by error handling, ErrGroups, channel orchestration, inelegant wrapper structs, managing the lifecycle of resources (sockets and files and what not) and, ugh, contexts. Context is like a virus that morphs code into refactoring monsters every time you start weaving it through your application. I get Erlang envy when I need to do even the simplest thing, like coordinate the concurrent importing of chunks of data that is distributed to a dynamically growing/shrinking pool of worker goroutines. With all the bragging about modern CSP, Go provides nothing that can compete with Erlang supervisors, which is mightily strange for a (relatively speaking) new language supposedly invented for writing resilient networked systems.

tene 8y ago

While I agree with most of your comment, I think you've misinterpreted the intent here: > Until I list the ones it doesn't. Or are they not "real"? My reading of the original post is asserting that there is a specific set of problems that Go is designed to solve well, and that it's avoided providing functionality not related to those specific problems. The entire comparison is to a "shop-made jig", which explicitly solves only a specific subset of all problems you might encounter in woodworking, but is not at all a general-purpose tool. This definitely fits with my experience with Go. If you want to build something that only needs concrete data types, channels, HTTP, and a database connection, and want to bang it out fast and move on, Go works well in this niche, because that's precisely the set of "real problems" that it was designed to solve. I do not consider Go a general-purpose programming language. I would not use Go for ambitious large-scale projects. If I were putting together an engineering team to write a small network service, with junior developers, Go would be at the top of my list.

kodablah 8y ago
I admit I may have taken the "solves real problems" too literally and did not read the rest to understand it.
- tene 8y ago
  These kinds of nuances can be a bit subtle; I hope I managed to come across as polite correction instead of attack. :)

JepZ 8y ago

Go is cross-platform out of the box. The problem is that you can integrate other languages like C which often don't come with cross platform compilers. So any Go program which depends in some way on C is not cross platform anymore (as long as you don't have a cross platform C compiler). To be honest I don't know how to solve that issue. On the one hand I really like the easy cross platform capabilities of the Go compiler, on the other hand I don't want to sacrifice language interoperability for cross platform builds. I wonder how someone who has C/C++ experience thinks of Go as not being a cross platform language.

kodablah 8y ago
> To be honest I don't know how to solve that issue Support more compilers (e.g. clang, msvc). It can be more work than it's worth, sure and I understand the issues there, but jumping through hoops per platform (e.g. can't use a popular lib like https://github.com/mattn/go-sqlite3 https://github.com/mattn/go-sqlite3 on Windows without a MinGW gcc installation) is worth noting when touting the cross platform ease of use. Langs like Rust were lucky to compile to the same IR as a cross-platform C compiler. > I wonder how someone who has C/C++ experience thinks of Go as not being a cross platform language. I don't think that and definitely never would. I said it has issues, namely in the Cgo department. And I said that the other statement about C/C++ only being Unixy was wrong. I definitely like Go and its cross-platform ability and hope I didn't give the impression that I don't.
- justin66 8y ago
  What's the big deal with using mingw?
  - pcwalton 8y ago
    MinGW doesn't integrate as well with the predominant workflows (toolchains, linking, debugging, etc.) Most Windows desktop apps are compiled using MSVC, so this is important for many people. Just to name one issue of many, MSVC uses Microsoft's PDB format for debugging instead of GCC's DWARF.
  - 8y ago

accnumnplus1 8y ago

It feels even less cross-platform when you have a team mate who uses x/sys/unix and you're on a mac, which may be expected, but your first quote seems to miss such situations. (The quote itself, not your comment on it - [edit for calrity]).

p_l 8y ago

The fun thing is that Go on unix is not the native Go environment, and it shows in several places, including treatment of import paths of all things (the whole GOPATH thing). It shows even more in the fact that it originated, and afaik is still partially compatible, with a C compiler that is completely alien to both GCC and MSVC worlds. In essence, Cgo is a hack even on GCC. Windows treatment of C and C++ as "just yet another language" is very alien, however, to the devs who come from unix world, and many basic things are not handled corrently by them or even planned for :(