11 ms·

Go's major selling point to me is that you can ship one binary, nothing beats that. Python, Node, Java all have to pre-install lots of dependencies before you

Go's major selling point to me is that you can ship one binary, nothing beats that. Python, Node, Java all have to pre-install lots of dependencies before you can use them, fine for developers, not so great if you want to distribute software for people who are not software savvy, who typically just wants to download one file, install and start using it. c and c++ can also do one executable, but, it is not as portable as Golang, and not as static-link friendly as Golang.

ashishb 3y ago
Fully compiled languages have another huge advantage. If you write a tool in Python and targeted say Python 3.10 then people using Phython 3.9 might not be able to use it. So, you really can't use latest and greatest features of Python 3.11 or 3.12. However, with Go, you can build your tool in Go 1.21 or whatever, and the user does not even need a Go toolchain on their machine. I was planning to write a small side-project to generate GitHub Actions boilerplate. And this time, I intentionally chose Go for that exact reason. https://github.com/ashishb/gabo https://github.com/ashishb/gabo
- pjmlp 3y ago
  Unless dynamic linking is used, or OS APIs change between version, or specific OS files change location.
  - pkolaczk 3y ago
    Go binaries are traditionally statically compiled.
    - pjmlp 3y ago
      Hence my 2nd and 3rd points. Also DNS uses dynamic linking unless configured otherwise, while being OS specific, then that are the libraries that rely on cgo.
      - ashishb 3y ago
        Yeah, you can list 100 such cases. Let me tell you the most common scenario. I have a fairly popular FOSS CLI tool written in Python. I cannot use the features from the latest version of Python or else I will alienate ~50% of the userbase. This problem does not exist with Rust or Go. This problem would have existed for Java on Android except Google took the burden of "desugaring" the Java 17 code -> Java 8 compatible bytecode for the old devices.
        kaba0 3y ago
        Google dug their own grave here, Java is as backwards and forward compatible as it gets.
        lern_too_spel 3y ago
        You cannot run Java 17 code on a Java 8 runtime without "desugaring."
chii 3y ago
> not so great if you want to distribute software for people who are not software savvy, who typically just wants to download one file, install and start using it. i think it's a flaw that wasn't considered properly in the standard java toolchain to not produce an embedded java runtime into a final packaged artifact that is self-executable. You end up with third party tooling like: https://www.ej-technologies.com/resources/install4j/help/doc/concepts/launchers.html https://www.ej-technologies.com/resources/install4j/help/doc... (and https://launch4j.sourceforge.net/ https://launch4j.sourceforge.net/ too). If oracle bundled this tool into the JDK, it would've not been an issue at all.
- pjmlp 3y ago
  It has existed for 20 years, and already started with Sun. Having AOT compilers as commercial offerings, was seen as one way to capture value in the Java market, in a culture where most compilers were still commercial, GCC being the exception.
  - coldtea 3y ago
    >It has existed for 20 years, and already started with Sun. In an anemic way, with mostly third party offerings few people know or care about, and various degrees of pain and shortcoming to their use. It should be a first class feature, and as simple to use as is in Go (including for cross compiling). In general, if something exists in "some form" for 30+ years in a language, and only a handful of people use it, whereas in another it's used all the time and people from other languages are jealous of how well it works, then the formers "some form" is not a good one.
    - pjmlp 3y ago
      Regardless, it exists.
- javcasas 3y ago
  That wasn't a flaw. It was a "feature". Can yo you think of a way to increase market awareness of Java other than putting an icon on every computer in the world saying "Your Java needs to be updated" every two weeks?
cbm-vic-20 3y ago
Since Java 9, developers can use jlink to provide a pre-packaged runtime environment bundled with the application. It's not static-link friendly or a single executable, but it does not require the user to pre-install anything or pull dependencies at runtime.
paradite 3y ago
You mentioned "distribute software" but did not consider Electron for Node. You can make an Electron app with JavaScript and ship the binary (or installer) on any platform. It's not a single executable file, but the user experience is the same. I don't think there's an equivalent in Go that allows you build a desktop app like that (with frontend and backend both written in Go)?
- synergy20 3y ago
  electronjs is probably the best cross platform desktops GUI,just a bit heavy.I actually use wxwidgets for GUI desktop apps.
  - troupo 3y ago
    The best cross platform desktop GUI is Qt.
    - synergy20 3y ago
      whose license model is a mess unless your GUI is totally open source.
      - wtetzner 3y ago
        Isn't it just LGPL? Why is that a "mess"?
        synergy20 3y ago
        I'm not a lawyer, I wish it's as simple as "it's just LGPL", it's not. Otherwise Qt has already conquered the desktop GUI world, it did not for a reason: the license mess.
        troupo 3y ago
        It did conquer (-ish) the desktop GUI world, for a while: quite a lot of software was written in it. And then Electron happened.
mathiasgredal 3y ago
You just add the -static argument, if you want a fully static executable that can run on any linux distro: ‘g++ -o main main.cpp -static’ You can even go above and beyond with cosmopolitan libc v2, which makes c/c++ build-once run-anywhere: https://github.com/jart/cosmopolitan/releases/tag/2.0 https://github.com/jart/cosmopolitan/releases/tag/2.0 There seems to be some work getting cosmopolitan libc support in Go, but it is not ready like it is for c/c++: https://github.com/golang/go/issues/51900 https://github.com/golang/go/issues/51900 Edit: There can be some problems with using static, if you are using your system package manager for library dependencies. I would recommend compiling dependencies from source using CMake and FetchContent, this has solved pretty much all problems I have had with c++ dependency management.
palata 3y ago
How do you distribute a Go library? How do you distribute a Go library that has dependencies?
- deleted 3y ago
  [deleted]
- mariusor 3y ago
  I'm not sure if your question is rhetorical, but Go doesn't have the concept of compiled library that you can link to another binary. So in Go you make available the library's source code, and the end-user will download it at build time, or vendor it in the source tree.
  - pjmlp 3y ago
    Which is a non starter for businesses that don't ship source code.
    - lakomen 3y ago
      https://pkg.go.dev/plugin https://pkg.go.dev/plugin
      - mdaniel 3y ago
        > Plugins are currently supported only on Linux, FreeBSD, and macOS, making them unsuitable for applications intended to be portable. uh-huh but, in all seriousness: I wonder why that is? I struggle to think of a technical reason that go would be unable to load and invoke a .dll even if one had to name it .so https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin_dlopen.go#L71 https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin...
      - pjmlp 3y ago
        Not only it doesn't work in all platforms, it uses a bare bones C API with unsafe code, and it hasn't been removed yet due to backwards compatibility, as Russ Cox already expressed his opinion that plugin was a mistake from his point of view.
ozim 3y ago
If you want to distribute app to non tech people you do it via browser ;)
- synergy20 3y ago
  there are many apps that are not suited for a browser :(, on some embedded devices with a touch screen, it does not even have a browser and no internet connection either.
  - ozim 3y ago
    From my POV that is bad example, for those embedded apps you have technical personnel installing and configuring those. Non-technical users don't have any means to install/modify whatever is there.
sangnoir 3y ago
> Go's major selling point to me is that you can ship one binary, nothing beats that. Are .war files no longer a thing? ;)
invalidname 3y ago
I suggest reading about GraalVM...
lenkite 3y ago
> Go's major selling point to me is that you can ship one binary, nothing beats that. You can ship one compiled binary in Java too if you want it. https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ > Go is simple. It's easy to understand, read, and maintain Go involves a lot of code repetition which makes it difficult to human-scan and maintain. Worked on both large scale Go and Java projects and I found Java projects easier and more comfortable to maintain. Had to pay a lot more attention to Go. Go is easier to write though thanks to its well-designed and extensive standard library which is possibly the best in the world, but the maintenance angle still tilts to Java. There are also more Gotchas in Go compared to Java.
- reacharavindh 3y ago
  I’m neither a Golang nor a Java developer per se, but I touch source from both as an SRE. I find it weird to see so many comments saying Go is verbose and Java is not. I found the opposite to be true. To do every little thing, the Java code has a ton of abstraction, and the actual implementation of anything is so far removed from the place where it is used that it gives me such a headache to touch anything without wondering “whatever else would break if I change this behavior?!” However, the Go code bases I’ve encountered have been less abstract and to the point(even if it means repetition of some little things). I also found it to be free of boilerplate except for the if err != nil part. I guess those that have spent decades in such abstractions must have learnt a skill to navigate such a spaghetti. But, I still hate it every time.
  - lenkite 3y ago
    Quite a bit depends on how the codebase has been written and what era are you looking. Before Java 8/9 or after it. Java code written in the recent era is pretty lean and mean. No matter the amount of abstraction though, one rarely runs into the sort of issues in Java that Go code tend to run into frequently - causing multi-million dollar mistakes frequently even for experienced Go programmers. For loop semantics https://bugzilla.mozilla.org/show_bug.cgi?id=1619047 https://bugzilla.mozilla.org/show_bug.cgi?id=1619047, Unintended variable shadowing, common mistakes in slice appends/copies, slices and memory leaks, defers inside loops, nil interface vs nil, panics in go-routines. There are loads of bugs in OSS projects wrt to these usually repeated again and again. Go is very simple to learn and very hard to master writing bug-free code. Looking forward to seeing how languages like Rust perform if/when adopted by enterprise.
saiya-jin 3y ago
You can easily pack every single class file and resource into one single .jar if you desire to do so, no external dependency apart from JRE itself. Oh and of course no installation necessary, just put it anywhere with read access, all works. At least in the past you could also make a single .exe out of it via 3rd party if you wanted, but I didnt use that for 20+ years so maybe its not valid anymore.
mdhb 3y ago
I never see Dart talked about in these contexts but just to highlight a few things. 1. Compiles to native code with a single and very reasonable sized binary on pretty much any platform. 2. Compile to WASM (coming this year) if that’s your thing. 3. Excellent concurrency support with lightweight and simple mental models 4. Variables are not nullable by default thus simplifying tedious checking in your codebase. 5. Syntactically it’s the best parts of Java and JavaScript combined without all the foot guns and verbosity. 6. Full support for both OOP and functional code styles 7. Existing interop support with C, C++, Rust, Java and JavaScript and in the future WASI. 8. Fully static / compile time metaprogramming capabilities coming this year. 9. Also have maybe one of the best teams working on it that I’ve ever seen in an open source project anywhere. They put in a stupid amount of detail and care to try and keep everything pointing in the right direction at a macro level and have really strong levels of transparency around how the language is developed https://github.com/dart-lang/language https://github.com/dart-lang/language Honestly I think it’s critically under-rated and under-used. Most of its common criticisms I see about it are many years out of date.
- lakomen 3y ago
  Performance matters. Dart isn't even in the same league. And its null handling and checking is the worst. I absolutely hate it. Java over Dart any day.
  - mdhb 3y ago
    What specifically about the null checking are you talking about? I’ve never heard this criticism before and have no idea what you’re even referring to here but I am genuinely curious..
  - sgt 3y ago
    Dart has excellent null handling[0] so I am not sure if you're perhaps talking of another language? It has had this since release 3.0, if I recall, and has been out for quite a while. https://dart.dev/null-safety https://dart.dev/null-safety
- synergy20 3y ago
vips7L 3y ago
Shipping one binary to install on a users machine has been solved by jlink and jpackage for ages.

ashishb 3y ago

Fully compiled languages have another huge advantage. If you write a tool in Python and targeted say Python 3.10 then people using Phython 3.9 might not be able to use it. So, you really can't use latest and greatest features of Python 3.11 or 3.12. However, with Go, you can build your tool in Go 1.21 or whatever, and the user does not even need a Go toolchain on their machine. I was planning to write a small side-project to generate GitHub Actions boilerplate. And this time, I intentionally chose Go for that exact reason. https://github.com/ashishb/gabo https://github.com/ashishb/gabo

pjmlp 3y ago
Unless dynamic linking is used, or OS APIs change between version, or specific OS files change location.
- pkolaczk 3y ago
  Go binaries are traditionally statically compiled.
  - pjmlp 3y ago
    Hence my 2nd and 3rd points. Also DNS uses dynamic linking unless configured otherwise, while being OS specific, then that are the libraries that rely on cgo.
    - ashishb 3y ago
      Yeah, you can list 100 such cases. Let me tell you the most common scenario. I have a fairly popular FOSS CLI tool written in Python. I cannot use the features from the latest version of Python or else I will alienate ~50% of the userbase. This problem does not exist with Rust or Go. This problem would have existed for Java on Android except Google took the burden of "desugaring" the Java 17 code -> Java 8 compatible bytecode for the old devices.
      - kaba0 3y ago
        Google dug their own grave here, Java is as backwards and forward compatible as it gets.
        lern_too_spel 3y ago
        You cannot run Java 17 code on a Java 8 runtime without "desugaring."

chii 3y ago

> not so great if you want to distribute software for people who are not software savvy, who typically just wants to download one file, install and start using it. i think it's a flaw that wasn't considered properly in the standard java toolchain to not produce an embedded java runtime into a final packaged artifact that is self-executable. You end up with third party tooling like: https://www.ej-technologies.com/resources/install4j/help/doc/concepts/launchers.html https://www.ej-technologies.com/resources/install4j/help/doc... (and https://launch4j.sourceforge.net/ https://launch4j.sourceforge.net/ too). If oracle bundled this tool into the JDK, it would've not been an issue at all.

pjmlp 3y ago
It has existed for 20 years, and already started with Sun. Having AOT compilers as commercial offerings, was seen as one way to capture value in the Java market, in a culture where most compilers were still commercial, GCC being the exception.
- coldtea 3y ago
  >It has existed for 20 years, and already started with Sun. In an anemic way, with mostly third party offerings few people know or care about, and various degrees of pain and shortcoming to their use. It should be a first class feature, and as simple to use as is in Go (including for cross compiling). In general, if something exists in "some form" for 30+ years in a language, and only a handful of people use it, whereas in another it's used all the time and people from other languages are jealous of how well it works, then the formers "some form" is not a good one.
  - pjmlp 3y ago
    Regardless, it exists.
javcasas 3y ago
That wasn't a flaw. It was a "feature". Can yo you think of a way to increase market awareness of Java other than putting an icon on every computer in the world saying "Your Java needs to be updated" every two weeks?

cbm-vic-20 3y ago

Since Java 9, developers can use jlink to provide a pre-packaged runtime environment bundled with the application. It's not static-link friendly or a single executable, but it does not require the user to pre-install anything or pull dependencies at runtime.

paradite 3y ago

You mentioned "distribute software" but did not consider Electron for Node. You can make an Electron app with JavaScript and ship the binary (or installer) on any platform. It's not a single executable file, but the user experience is the same. I don't think there's an equivalent in Go that allows you build a desktop app like that (with frontend and backend both written in Go)?

synergy20 3y ago
electronjs is probably the best cross platform desktops GUI,just a bit heavy.I actually use wxwidgets for GUI desktop apps.
- troupo 3y ago
  The best cross platform desktop GUI is Qt.
  - synergy20 3y ago
    whose license model is a mess unless your GUI is totally open source.
    - wtetzner 3y ago
      Isn't it just LGPL? Why is that a "mess"?
      - synergy20 3y ago
        I'm not a lawyer, I wish it's as simple as "it's just LGPL", it's not. Otherwise Qt has already conquered the desktop GUI world, it did not for a reason: the license mess.
        troupo 3y ago
        It did conquer (-ish) the desktop GUI world, for a while: quite a lot of software was written in it. And then Electron happened.

mathiasgredal 3y ago

You just add the -static argument, if you want a fully static executable that can run on any linux distro: ‘g++ -o main main.cpp -static’ You can even go above and beyond with cosmopolitan libc v2, which makes c/c++ build-once run-anywhere: https://github.com/jart/cosmopolitan/releases/tag/2.0 https://github.com/jart/cosmopolitan/releases/tag/2.0 There seems to be some work getting cosmopolitan libc support in Go, but it is not ready like it is for c/c++: https://github.com/golang/go/issues/51900 https://github.com/golang/go/issues/51900 Edit: There can be some problems with using static, if you are using your system package manager for library dependencies. I would recommend compiling dependencies from source using CMake and FetchContent, this has solved pretty much all problems I have had with c++ dependency management.

palata 3y ago

How do you distribute a Go library? How do you distribute a Go library that has dependencies?

deleted 3y ago
[deleted]
mariusor 3y ago
I'm not sure if your question is rhetorical, but Go doesn't have the concept of compiled library that you can link to another binary. So in Go you make available the library's source code, and the end-user will download it at build time, or vendor it in the source tree.
- pjmlp 3y ago
  Which is a non starter for businesses that don't ship source code.
  - lakomen 3y ago
    https://pkg.go.dev/plugin https://pkg.go.dev/plugin
    - mdaniel 3y ago
      > Plugins are currently supported only on Linux, FreeBSD, and macOS, making them unsuitable for applications intended to be portable. uh-huh but, in all seriousness: I wonder why that is? I struggle to think of a technical reason that go would be unable to load and invoke a .dll even if one had to name it .so https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin_dlopen.go#L71 https://github.com/golang/go/blob/go1.21.1/src/plugin/plugin...
    - pjmlp 3y ago
      Not only it doesn't work in all platforms, it uses a bare bones C API with unsafe code, and it hasn't been removed yet due to backwards compatibility, as Russ Cox already expressed his opinion that plugin was a mistake from his point of view.

ozim 3y ago

If you want to distribute app to non tech people you do it via browser ;)

synergy20 3y ago
there are many apps that are not suited for a browser :(, on some embedded devices with a touch screen, it does not even have a browser and no internet connection either.
- ozim 3y ago
  From my POV that is bad example, for those embedded apps you have technical personnel installing and configuring those. Non-technical users don't have any means to install/modify whatever is there.

sangnoir 3y ago

> Go's major selling point to me is that you can ship one binary, nothing beats that. Are .war files no longer a thing? ;)

invalidname 3y ago

I suggest reading about GraalVM...

lenkite 3y ago

> Go's major selling point to me is that you can ship one binary, nothing beats that. You can ship one compiled binary in Java too if you want it. https://www.graalvm.org/22.0/reference-manual/native-image/ https://www.graalvm.org/22.0/reference-manual/native-image/ > Go is simple. It's easy to understand, read, and maintain Go involves a lot of code repetition which makes it difficult to human-scan and maintain. Worked on both large scale Go and Java projects and I found Java projects easier and more comfortable to maintain. Had to pay a lot more attention to Go. Go is easier to write though thanks to its well-designed and extensive standard library which is possibly the best in the world, but the maintenance angle still tilts to Java. There are also more Gotchas in Go compared to Java.

reacharavindh 3y ago
I’m neither a Golang nor a Java developer per se, but I touch source from both as an SRE. I find it weird to see so many comments saying Go is verbose and Java is not. I found the opposite to be true. To do every little thing, the Java code has a ton of abstraction, and the actual implementation of anything is so far removed from the place where it is used that it gives me such a headache to touch anything without wondering “whatever else would break if I change this behavior?!” However, the Go code bases I’ve encountered have been less abstract and to the point(even if it means repetition of some little things). I also found it to be free of boilerplate except for the if err != nil part. I guess those that have spent decades in such abstractions must have learnt a skill to navigate such a spaghetti. But, I still hate it every time.
- lenkite 3y ago
  Quite a bit depends on how the codebase has been written and what era are you looking. Before Java 8/9 or after it. Java code written in the recent era is pretty lean and mean. No matter the amount of abstraction though, one rarely runs into the sort of issues in Java that Go code tend to run into frequently - causing multi-million dollar mistakes frequently even for experienced Go programmers. For loop semantics https://bugzilla.mozilla.org/show_bug.cgi?id=1619047 https://bugzilla.mozilla.org/show_bug.cgi?id=1619047, Unintended variable shadowing, common mistakes in slice appends/copies, slices and memory leaks, defers inside loops, nil interface vs nil, panics in go-routines. There are loads of bugs in OSS projects wrt to these usually repeated again and again. Go is very simple to learn and very hard to master writing bug-free code. Looking forward to seeing how languages like Rust perform if/when adopted by enterprise.

saiya-jin 3y ago

You can easily pack every single class file and resource into one single .jar if you desire to do so, no external dependency apart from JRE itself. Oh and of course no installation necessary, just put it anywhere with read access, all works. At least in the past you could also make a single .exe out of it via 3rd party if you wanted, but I didnt use that for 20+ years so maybe its not valid anymore.

mdhb 3y ago

I never see Dart talked about in these contexts but just to highlight a few things. 1. Compiles to native code with a single and very reasonable sized binary on pretty much any platform. 2. Compile to WASM (coming this year) if that’s your thing. 3. Excellent concurrency support with lightweight and simple mental models 4. Variables are not nullable by default thus simplifying tedious checking in your codebase. 5. Syntactically it’s the best parts of Java and JavaScript combined without all the foot guns and verbosity. 6. Full support for both OOP and functional code styles 7. Existing interop support with C, C++, Rust, Java and JavaScript and in the future WASI. 8. Fully static / compile time metaprogramming capabilities coming this year. 9. Also have maybe one of the best teams working on it that I’ve ever seen in an open source project anywhere. They put in a stupid amount of detail and care to try and keep everything pointing in the right direction at a macro level and have really strong levels of transparency around how the language is developed https://github.com/dart-lang/language https://github.com/dart-lang/language Honestly I think it’s critically under-rated and under-used. Most of its common criticisms I see about it are many years out of date.

lakomen 3y ago
Performance matters. Dart isn't even in the same league. And its null handling and checking is the worst. I absolutely hate it. Java over Dart any day.
- mdhb 3y ago
  What specifically about the null checking are you talking about? I’ve never heard this criticism before and have no idea what you’re even referring to here but I am genuinely curious..
- sgt 3y ago
  Dart has excellent null handling[0] so I am not sure if you're perhaps talking of another language? It has had this since release 3.0, if I recall, and has been out for quite a while. https://dart.dev/null-safety https://dart.dev/null-safety
synergy20 3y ago

vips7L 3y ago

Shipping one binary to install on a users machine has been solved by jlink and jpackage for ages.