Hacker News Reader

Comment by tobbyb | Hacker News Reader

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.

View on HN

All compiled languages support static linking, nothing special about Go.

At 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…

Language 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.

With 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

This 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.:)

Which 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.

:D You're comparing turbo pascal with Go today? You're gonna write microservices and web applications with Turbo Pascal?

Ever 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.

Yes, I heard about these FreePascal and Delphi but I have no prior experience with them.

Well, personally I wouldn't, but generally, why not?

>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.

The relevance is that a compiler running in 90's hardware is able to beat Go's compilation speeds of 2017. That same compiler has evolved through the years.

If you want the 2017 version of it, it is called Delphi. Beats Go in language features and compilation speed.

Go's compilation speed only surprises those developers that never used anything else beyond C and C++.

>The relevance is that a compiler running in 90's hardware is able to beat Go's compilation speeds of 2017

And beat 99% of other compilers today, meaning that overall compiler complexity has grown.

>If you want the 2017 version of it, it is called Delphi.

Ok, this is something actually relevant.

>Go's compilation speed only surprises those developers that never used anything else beyond C and C++.

For me (tm), Go compilation speed has compared equal or favorably against C, C++, Java, C#, Rust at least.

> And beat 99% of other compilers today, meaning that overall compiler complexity has grown.

Which ones?

> For me (tm), Go compilation speed has compared equal or favorably against C, C++, Java, C#, Rust at least.

Since when does Go compile faster than Java and C#?

When I hit Ctrl+S my binary is already on the disk, thanks to incremental compiler integration on the IDE.

I have a full blown WPF application with multiple plugins, including data visualization, talking to Oracle and Postgres, total compilation time after check out 12s.

Eiffel, D, Nim, Jai are other fast compilation examples.

As 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?

No, 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.

Aren’t JVM language equally simple? Just a fat JAR.

You're forgetting Java.

Java 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.

But 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).

The JVM adds 64 MiB if compressed, for comparison, node.JS with CEF adds 280 MiB

Only if we are speaking about versions older than Java 9.

Java 9 added linking support for custom runtimes.

Reply on news.ycombinator.com