> The fact that it produces a single static binary is one of the nicest things about golang.

AND unlike Rust, Go has an eminently usable and comprehensive stdlib.

It means that for most projects you can just Get Stuff Done (TM) instead of deciding which of 24 "reinventing the wheel" Rust Crates you want to use for X, Y and Z functions of your Rust binary.

Please don't start random language fights.

Directly addressing the topic of a upvoted article is starting random language fights?

The article is about Go, and while the article mentions other languages for comparison, Rust is not one of them. So traceroute66's comment comes across as starting a Rust vs. Go fight where not appropriate.

Not even, they just expressing an opinion.

Doesn’t come across as starting a fight to me. Not even close.

Yeah the only thing is how you parse "eminently usable and comprehensive". The way I read it, it's not saying that Rust's isn't "eminently usable", but that it isn't both of those things. At most it's suggesting that a standard library can't be "eminently usable" if it isn't comprehensive IMO - perhaps it can be extremely usable but not eminently usable. It would be like saying a manual transmission on a car can't be "eminently usable".

I think the comparison is totally apt and illustrates why Rust and Go get compared very often. They are both languages that compile to a binary, rather than running in a managed environment.

Where does the word Rust appear in the article?

In the comments about every article including Go, generally.

I can't speak for Go-centric articles in general, but for this one in particular, the only one (as of now, after 14 hours of comments) bringing up Rust is this single person with (apparently) a weird chip on their shoulder.

That's no language fight. Rust doesn't want batteries included. That's highlighting a difference between the languages.

From another point of view "usable" isn't a word I'd associate with Go, especially not when there is an "unlike Rust" in the phrase. I've not had any issues of the sort when building out Rust applications. At this point the only time I touch Go is if I need to modify something else someone has made-- which I avoid at all costs

Maybe AI will make it more palatable but I just can't get into Rust.

I can probably easily understand borrowing. It's mostly an issue of controlling pointer aliasing wrt mutability, especially in a multithreaded context I guess.

But that gottdarn syntax... And goroutines are too nice for the type of code I use.

I'm too spoiled with Go I guess.

Using a crate is the opposite if reinventing the wheel. Also are we talking about go? The language without a set implementation?

Parent is saying those crates themselves are reinventing the wheel, not talking about using a crate

So by that logic Golang reinvented the wheel by creating a new programming language when java already existed

Yes. Is reinventing the wheel always a bad thing, though? Not if you ask me, not if the new wheel has novel characteristics and performs better in some aspects.

If only they would decide what to do with plugin package, not use SCM paths for packages and decide to eventually support enumerations instead of iota dance (Pascal style would be enough.

Maybe 10 more years.

    type Kind enum {
        Simple,
        Complex,
        Emacs,
    }

    const kindStrings [Kind]string = {
        "simple",
        "complex",
        "emacs",
    }

    func (k Kind) String() string {
        return kindStrings[k]
    }

    func t() {
        var a = Kind.Emacs - Kind.Simple  // a has type int and value 2
        var b = Kind.Simple + Kind.Emacs  // type error
        var c = Kind.Simple + 1           // type error
        var d = len(Kind)                 // d has type int and value 3

        for k := range Kind {
            fmt.Printf("%v\n", k) // prints what you expect it to do
        }

        // not sure about legality or runtime behaviour of the followng
        var t = Kind.Emacs
        t++
        t = Kind(42)        
    }

Would be nice, not gonna lie.

How is this any different than Go's existing enumerations, aside from the enumeration also creating an implicit list structure which, while kind of neat, isn't really a property of enumerations.

The parent is likely lamenting that Go doesn't enforce compile-time value constraints on enumerated sets like some languages do, but many other languages don't ether. Not even Typescript does. If Typescript doesn't find it important to have such value constraints, Go most certainly never will.

> Go's existing enumerations

Go doesn't have enumerations. So the first difference would be that my enums would actually exist.

> implicit list structure which, while kind of neat, isn't really a property of enumerations

It absolutely is, or people wouldn't have been regularly writing enums like

    typedef Kind enum {
        KindSimple,
        KindComplex,
        KindEmacs,
        Kind_NUM_VALUES
    };

which they do about half the time.

> likely lamenting that Go doesn't enforce compile-time value constraints

Yes, that's my complaint as well. Which is why that "not sure about legality" part in my example: you want to be able to enumerate the enum (duh), but with last_value_of_enum++ being illegal, writing for-loop with "<" is illegal too, that's why there is support for it in for-range.

With incrementing (used in loops almost exclusively) taken care of, the rest of arithmetics on enums is meaningless in general except maybe in case of subtraction (when you use enums as keys/indices for a fixed-sized array) which is why I allow it — but it produces an int, of course.

As for what should happen in Kind(42) example — perhaps it could work like type-assertions?

    k, err := Kind(42)
    if err != nil {
        return err
    }

> Go doesn't have enumerations. So the first difference would be that my enums would actually exist.

That's obviously not true. That's what the iota dance is for.

    type Kind int

    const (
        KindSimple Kind = iota
        KindComplex
        KindEmacs
        Kind_NUM_VALUES   
    )

Go doesn't have a literal enum keyword, if that's what you mean, but enumerations aren't defined by having a specific keyword or specific syntax. Enumerations are a more general concept, defined as a set of named constants. The above is functionally identical to your example in C, among a host of other languages.

> Yes, that's my complaint as well.

Fine, but that's not a property of enumerations. If one wants support for value constraints, surely one should ask for that and not for something the language has had since the beginning?

Mmm. The original comment asked for "Pascal-style enums". Those are different from C enums: they are incompatible with integers and other enums, they don't support arithmetic operations (you have to use succ()/pred() built-ins) and they contain precisely the named values. Plus, enums being ordinal types, you could use them as array indices in type definitions, like "array[Kind] of real".

So that's what I went with, because I actually liked Pascal-style enums but thought they could be somewhat improved, so what you've read is my ideas (Go is surprisingly close to Oberon and both lack enums).

The original comment asked for enumerations. Despite him not realizing, Go has those. It has a relatively unique syntax for defining enums, sure, but enumerations are not defined by specific syntax. They are a higher level concept that transcends any specific syntax implementation.

The original comment also hinted at wanting other features that some other languages have, including Pascal, although not stating which features specifically. I expect he was referring to wanting some kind of constraint system, which is the most common feature I hear requested of Go. But that's beyond the scope of enumerations.

Regarding the “iota dance,” I wrote my 2 cents on what could be a slightly more robust approach a couple of days ago: https://preslav.me/2023/03/17/create-robust-enums-in-golang/

P.S generic type sets make it even better. I’ll write an update to my post these days.

Rust's philosophy (unlike Python's, for example) consists in not including tons of stuff in the standard library, this way you can choose the best implementation for your specific use case from one of the many crates (which are super easy to install, by the way). There is no "always the best" implementation for a specific functionality, nor a legacy-but-still-officially-supported-in-std implementation that nobody uses anymore but still needs to be maintained with its own namespace.

I don't see this as negative or "reinventing the wheel". Reinventing the wheel would be writing your own implementation, which doesn't happen if you can choose from many high-quality crates.

> legacy-but-still-officially-supported-in-std implementation

There is massive value in this.

Not officially supported doesn't mean not updated or not supported in general.

"a legacy-but-still-officially-supported-in-std implementation that nobody uses anymore but still needs to be maintained with its own namespace."

The cardinality of the set of "nobody uses anymore" is usually in tens of millions.

If something is used by tens of millions, be sure that it will be updated even if legacy. Just not officially by the people who maintain the language.

Ah yes, the #1 thing golang is known for: a comprehensive stdlib. Like including a max function for integers, right?

That attitude assumes that the go standard library is the global maximum for Getting Stuff Done, and because of backwards compatibility guarantees ensures that it’s difficult to innovate on.

I think having a small standard library is actually a good thing because it encourages exploration of the space of possibilities.

For example Go’s stdlib http.HandlerFunc sucks, people instead opt for leaving it behind entirely in favour of Gin or trying to work around it with bad patterns like interface smuggling.

From what I have seen in major OSS projects like systemd and PostgreSQL, nothing seems to support static linking, to the point where some contributors get annoyed when you ask for it.

Seems like the C/C++ ecosystem will stay dynamically linked, even with a lot of the industry shifting towards statically linked, fat binaries as disk space is pretty cheap.

I wonder how much simpler Linux packaging would be if everything was statically linked...

Packaging would be simpler, but you probably have to update the whole OS and all your installed apps when a security update for a common library is released.

Not wrong; at the same time, I'm becoming less convinced this is relevant. Seems many security updates have to do with code paths that are not used in a large number of applications. Similarly, many of them are fixes on features that even more apps didn't want/need, but they got when they updated to get the last round of security fixes. :(

The docker world is a neat example of this. The stories of ${absurdly high percent} of containers having vulnerabilities only gets to claim that because of "unpatched libraries." If you reduce it to the number of containers with exploitable vulnerabilities, it is still non-zero, but not nearly as high.

The problem is having to wait for all those applications to push updates when a vulnerability is found in a common library

That is the thing, though. For most applications, those vulnerabilities in a common library are not relevant. That is what I was talking about in saying that it is in code that isn't used by them.

You are, of course, right that it has the possibility of happening. But by and large, it doesn't happen there any more often than it does in the dynamically linked cases. And, by and large, the dynamically linked cases are often a lot more complicated to deploy. (Granted, deployment for either should be doable nowadays.)

The dream, of course, is you just patch the library and call it a day. The reality seems to usually be a circus check on every application that you have deployed to see if they are impacted anyway.

The solution to this is to make the build process as simple as possible. Then pushing updates has a much lower maintenance cost.

I can be confident I will be able to build >90% of go programs by cloning the repo and calling go build.

Simpler but small updates, like say openssl, become massive distro updates. There's a reason why everyone went with shared libs when they became stable.

A system with shared libraries also needs an update for the security fixes. There is no avoiding the update step. However, the only difference is the size of the update. If update process is robust, size of the update shouldn't matter, isn't it?

It does matter. If there is a problem with openssl, just the openssl maintainers have to push an update and everything on your system is secure.

If everything is statically linked, you need to wait for every maintainer of every single program on your system to rebuild and push an update. You're basically guaranteed that there is always _something_ missing important patches

The matter isn't the binary size of the update. It is the size of the crowd of people and parties involved in the update: For a bunch of statically linked applications, you need to involve all the application people/vendors. For a bunch of dynamically linked applications depending on a shared library, you (ideally) just need to involve the one library's people/vendor.

And "involve" might mean: wait for a bunch of unresponsive external parties to produce a new binary each for a security issue they might not care about. Of course on very different timelines, etc.

Docker images are static linking for the modern era.

Funnily enough I was looking at an issue in my one of personal projects last night about asking me to statically link libstdc++ - it's something I was interested in doing because I spent way too long spinning my wheels on an issue caused by loading an outdated libstdc++.so.6, but I read that statically linking can cause issues if your code loads another library that dynamically links libstdc++... which I'm pretty sure my project does (it's a pass-through between an executable and another library). So I want to, but it sounds like if I do it might work but be fragile at best.

> The fact that it produces a single static binary is one of the nicest things about golang.

Not only that it can also cross compile for different architecture and operating systems.

We used that to make a simple "VPN diagnostics" app for our helpdesk (app checked connectivity and config of the machine then displayed the summary page). Only thing that needed to be written per-os is how to call a browser to display the report

interesting. could you share what specifically the report had?

I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now.

Just do `release --name "mycoolprogram" --version "0.1.0"`

and it will output all of your labeled release binaries for every platform your code supports.

check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sports 40 different platform combos [1]

[0] - https://github.com/donuts-are-good/release.sh

[1] - https://github.com/donuts-are-good/bearclaw/releases/latest

looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.

Thanks for checking it out :) I'm not going to pretend I haven't been refreshing the page waiting for bugs and comments

So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?

I think the main thing that's different about Go compared to more old-school languages is that the Go binary distribution includes the cross-compilers right out of the box. So anybody who can run "go build" can also cross-compile their application -- and, importantly, all of its library dependencies -- for any architecture that Go supports.

On the other hand, if you want to cross-compile a C program using GCC, you need to separately build and install a complete gcc+binutils toolchain for every individual arch that you want to target. And you have to handle the dependency management yourself, which may be tricky if your dependencies' build scripts weren't designed with cross-compilation in mind.

No. Some bytecode compiled languages are compiled and require at least an archive to be unzipped or at least the virtual machine pre installed.

Java is an example -- you'll want your your system java deployment to match the stuff stashed in your jar.

Erlang is compiled but usually releases bundle the VM up with the project, so you typically deliver a full directory with the VM packed in there.

On top of this, with java, the jvm is itself dynamically linked to libc most of the time.

Golang is special because pure Go programs tend to have a closed ecosystem with its own linker (that typically don't link to libc or other C libs) so it makes static linking very easy. Other languages can certainly do static linking, but it tends to be a bit challenging to set it up on different OS's due to the need to have all needed C libs as static libs and then instruct the linker appropriately.

Not dynamically linking to libc is pretty unusual. The libc-equivalent parts are in the Go runtime, statically linked.

very true, for Go though if you need CGO it's hard to make a single executable, otherwise it is great.

I run a few Go apps, all are single executables, upgrading to new releases has never been easier.

if you have a network oriented application, nothing beats golang as far as release|maintenance is concerned.

> CGO_ENABLED=1 CC=musl-gcc go build --ldflags '-linkmode external -extldflags=-static'

Unless you cant use musl for some reason, but that’s a glibc problem, not Go

Some people are writing alternative via WebAssembly.

For instance wazero which I'm really excited about.

https://tetrate.io/blog/introducing-wazero-from-tetrate/?utm...

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace) because it is independent of dlopen.

And there's also "purego" as an implementation that directly generates shellcode.

Maybe those will help you, too?

I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.

[1] https://github.com/Binject/debug

[2] https://github.com/ebitengine/purego

very useful,thanks

You can still do that with musl, can’t you? Can make a static c binary with that

IME, using musl, compiling static binaries written in C is as easy as it was before glibc changes and as it has always has been on NetBSD. I compile static binaries written in C every day on Linux. I never encountered any problems compiling static binaries on BSD.

That’s great if your only dependency is libc. It gets progressively harder the more dependencies you need, and it becomes downright untenable the moment you run into some dependency with a dlopen-based plugin architecture.

Can you link something substantial, like Firefox, statically on NetBSD?

Compiling Firefox on NetBSD (dynamically) takes longer than compiling the kernel, maybe even longer than compiling an entire base system. It's been a long time since I tried it but it just took far too long so I lost interest. Granted, the computers I use have limited resources. Anyway, I gave up on graphical browsers many years ago. There are many programs I can compile statically because I prefer smaller software.^1 For example, the text-only browser, the TCP clients, the forward proxy, tmux, tinysshd, nvi, lua, stunnel, djbdns, daemontools, clockspeed, openssl, bssl, ffmpeg and various other programs I use are all static binaries. I also prefer crunched binaries on BSD to save space. These are static.

Whether a program can be compiled statically is a factor in whether I choose to use it. That effectively screens out many large programs that have numerous dependencies because compiling them statically often becomes too much hassle and the binaries are too large. For example, I compiled dnsdist statically using musl. Of course, "large" is subjective. I consider an 11M C program to be large but some HN commenters using memory-safe languages might think 11M is nothing.

1. Some have dependencies other than libc.

Graphical web browsers from "tech" companies are too large, too complex, too difficult for the user to control. IMHO.

If "you" means "a person", then yes.

If "you" means me, then no, because I do not have the patience nor do I think it would be worth the trouble.

The binary would be enormous.

One thing I used to do many years ago is create compressed images of directories containing programs or files needed by those programs, e.g., /usr/pkg/bin, etc., using makefs and vndcompress, then save these to bootable USB stick. For example, I might install Firefox, then create the images. The way I use NetBSD is that I boot into RAM from USB. I may or may not use a disk. Writeable directories are mounted as tmpfs. I use RAM as disk. This is one reason I like small programs. Installing Firefox would take up too much space, i.e., RAM, so I would mount the USB stick after boot, then mount the compressed images over certain directories, e.g., /usr/pkg/bin. As I recall, this worked, but eventually I gave up on graphical browsers, as well as X11.

Many of the static binaries I use rely on dependencies other than libc. Most are small programs. Out of personal preference, I generally try to avoid large programs with numerous dependencies. Exception might be something like ffmpeg. Static binary for the author is 21M but package from repository is 84M so the static binary uses less space. ffmpeg has many dependencies besides libc.

This is generally only true with CGO_ENABLED=0.

I've found many times that a go binary, even if it has no cgo or cgo dependencies, will randomly require glibc on the target system to execute if you don't explicitly disable cgo in your build.