5 ms·
A slightly different perspective. For the end user Go apps are by far the easiest to setup and use. Usually it's just a single binary to download. That is a hug
by tobbyb 9y ago
A slightly different perspective. For the end user Go apps are by far the easiest to setup and use. Usually it's just a single binary to download. That is a huge advantage that can't be beat.
Other languages usually need a large number of dependencies, with Ruby and Node, often an entire build environment, with plenty of potential for dependency hell and hours wasted.
Some may advocate containers at this point, but it just hides the issue temporarily and may be too much for a certain category of end users. You now need to know how containers, ports, volumes and Linux systems work in far more detail when you actually just want to use an app.
- pjmlp 9y agoAll compiled languages support static linking, nothing special about Go.
- klodolph 9y agoAt least historically speaking, this wasn’t true. And the fact that it’s true today for Java and C# is an anomaly, since for most of the history of those languages native compilation was either third party, second-class with missing features, or both. Look at GCJ or Excelsior (commercial). Or look at Python, which is also compiled. Or Ruby, or JavaScript, TypeScript, Dart…
- pjmlp 9y agoLanguage and implementation is not the same thing. Does not matter where the implementation comes from, if it is free or commercial, what matters is that it exists.
- mustardo 9y agoWith say a java app thou you'd typically get a .zip with all your class path dependencies and a launcher in one bundle. This is not the case for ruby, js (node), python etc where the norm is to splatter dependencies across your file system. Its not quite static linking but closer
- royge 9y agoThis is not always true. Static linking with other language doesn't always have similar experience with Go. One of these is the compilation speed. With other languages you'll still have time to get a coffee break before its done.:)
- pjmlp 9y agoWhich other languages? Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. There are lots of languages with modules support, with static linking and native compilation to choose from.
- royge 9y ago:D You're comparing turbo pascal with Go today? You're gonna write microservices and web applications with Turbo Pascal?
- pjmlp 9y agoEver heard of FreePascal and Delphi? In any case it doesn't change the fact that Go's compilation speed is nothing to brag about, it has been done before in many other languages, Turbo Pascal was just one example. If you wish I can provide other examples of languages that compile as fast, on such old hardware while matching Go's compilation speed, with richer language features.
- royge 9y agoYes, I heard about these FreePascal and Delphi but I have no prior experience with them.
- seba_dos1 9y agoWell, personally I wouldn't, but generally, why not?
- gribbly 9y ago>Turbo Pascal compilation speed, in MS-DOS, using 90’s hardware was already faster than Go. What relevance does this have on the compiler landscape today ? If you have to use a compiler from ~30 years ago to find a comparison supporting your claim, it sounds very much like Go is indeed much faster than what it competes against today.
- noncoml 9y agoAren’t JVM language equally simple? Just a fat JAR.
- mjevans 9y agoYou're forgetting Java.
- lwansbrough 9y agoJava isn’t required for the JVM of course. Scala is pretty great. I’ll throw my hat in the ring for C# on .NET Core. Just need the dotnet binary to init, build, install, restore, run. It’s like if node included npm in the same binary.
- Erlich_Bachman 9y agoBut nowadays it's pretty much installed everywhere? If not installed yet - it's a really easy and quite unobtrusive to install, one-liners in many OSes. So in the strict practical sense, is that such a big difference? What, extra 300MB for storing JVM? Who cares with 2TB commodity harddrives? (unless you're embedded, but then you wouldn't use Java or Go usually).
- dom96 9y agoAs far as I know this is only true for code written in Go. As soon as you try using C libraries you're going to have a non-trivial time statically linking everything. Isn't that the case?
- pjmlp 9y agoNo, only if by C you mean code compiled with gcc and linked against GNU libc. There are other C compilers to choose from, with libc implementations that properly support static linking.