In Go that quote is literally true. If you do nothing on a new computer but download Go you can immediately build a statically linked application that can fetch from an https endpoint. There are no implied additional steps.

I don't believe this can be said of the other languages. I know that C, C++ and Rust do not include https in their standard libraries, so while they can be made to compile statically and use a library that provides https functionality, those are additional steps that must be taken by the developer, and it is the responsibility of the developer to choose the correct source and version of the https library to use. This will also include understanding and setting any additional compiler flags that the library may require, setting any optional defines or other library configuration settings and making the appropriate changes for every platform they wish to build for.

Go requires none of this.

> that can fetch from a HTTPS endpoint.

Seems like a lot of replies are glossing over that clause. How many of those other languages can do that in a fully static binary that runs on (almost) any system that can read and launch that executable?

It's glossed over because it's trivial, isn't it? Just statically link libcurl through a binding. And at least Haskell also has Haskell-implemented HTTP and TLS libraries. There's even options.

Then why not assume it is the static linking that is trivial? Isolated each item is trivial in some context, its the exclusive set that is non-trivial, or at least uncommon.

The fact https is included in the standard library means that you can give a new user a hello world tutorial that includes producing a web server. It's a huge boon to productivity in a programming language to have a default path for such libraries.

I also work in C++, and it is infuriating the amount of time that must be spent sorting out the correct libraries for all the various aspects of an application one is not inclined to write themselves. People who don't fully grok the Go ecosystem overlook this cost when they claim that you can do the same thing in some other language. What they are missing in the subtext is the fundamental quality of life improvement.

> Isolated each item is trivial in some context, its the exclusive set that is non-trivial, or at least uncommon.

I'm not just taking it in isolation for no reason. If you have static linking, you basically have HTTPS by consequence.

> The fact https is included in the standard library means that you can give a new user a hello world tutorial that includes producing a web server. It's a huge boon to productivity in a programming language to have a default path for such libraries.

I think you're taking our discussion as if it were about if the language is cool or not. I never argued against that.

> I'm not just taking it in isolation for no reason. If you have static linking, you basically have HTTPS by consequence.

Can you clarify what you mean by this because to me there is literally nothing about static linking that implies https as a consequence. The point about Go is centrally not that it uniquely has access to an https library.

The point is that it is included. This may not at first appear all that noteworthy, but this is a substantive quality of life improvement. The standard library not only provides a vary large set of common functionality it is packaged with the distribution, works on all the platforms supported by Go without user intervention, and is bound in lock step to the release version of the compiler.