Arthur T Knackerbracket has found the following story:
GO binaries are weird, or at least, that is where this all started out. While delving into some Linux malware named Rex, I came to the realization that I might need to understand more than I wanted to. Just the prior week I had been reversing Linux Lady which was also written in GO, however it was not a stripped binary so it was pretty easy. Clearly the binary was rather large, many extra methods I didn't care about - though I really just didn't understand why. To be honest - I still haven't fully dug into the Golang code and have yet to really write much code in Go, so take this information at face value as some of it might be incorrect; this is just my experience while reversing some ELF Go binaries! If you don't want to read the whole page, or scroll to the bottom to get a link to the full repo, just go here.
-- submitted from IRC
(Score: -1, Troll) by Anonymous Coward on Tuesday December 20 2016, @04:14AM
First off its Go, not GO. Then I saw this and stopped reading: "Since I’m working on an OSX machine..."
(Score: 2) by RamiK on Tuesday December 20 2016, @05:47AM
While Apple bashing is desirable and appreciated under most circumstances, many of Go's lead team are ex Bell Labs employees that prefer developing under OSX since that's the most successful direct Unix descendant available for desktops on the market.
compiling...
(Score: 0) by Anonymous Coward on Tuesday December 20 2016, @07:14AM
And yet macOS is descended from BSD. If it's Bell Labs nostalgia they want, shouldn't they be pining for System V.
(Score: 0) by Anonymous Coward on Tuesday December 20 2016, @09:23AM
> OSX
Why do macfags call it like that? They usually respect everything about Apple's marketing, like using "logic board" instead of motherboard.
However, Apple never used it. It was Mac OS X, then OS X for a very short while (they caved to macfags somewhat), then macOS.
(Score: 2) by FatPhil on Tuesday December 20 2016, @09:07AM
Secondly, why are you so insecure that feel that you need to granstand your sneering at others' choice of operating system? Does doing so make you feel superior, somehow?
I work for a company where the software we write runs 99.99% on linux machines. Half of our devs use macs (we have a "chose your own machine" policy with a "just remember that you'll be adminning it yourself, so chose wisely" rider), as that's what they consider themselves most productive on. The manufacturer of the keyboard an engineer types on says nothing about the worth of that which is typed.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by tangomargarine on Tuesday December 20 2016, @03:06PM
(we have a "chose your own machine" policy
Choose ;) Technically, the official rule is that end-of-sentence punctuation goes inside quotes, too.
Muphry's Law [wikipedia.org]
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: -1, Flamebait) by Anonymous Coward on Tuesday December 20 2016, @04:56PM
You, GP, and GGP are loosers
(Score: 2) by FatPhil on Friday December 23 2016, @06:09PM
Not in modern technical English. Correct punctuation (only mark up as a quote that which is a actually being quoted) is now favoured.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1, Funny) by Anonymous Coward on Tuesday December 20 2016, @05:10AM
Malware and everything! Go! You know a language is hardcore when blackhats use it to code malware!
(Score: 2) by turgid on Tuesday December 20 2016, @12:41PM
VisualBASIC for Applications (TM)?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2, Funny) by Anonymous Coward on Tuesday December 20 2016, @09:27AM
lol no generics
(Score: 5, Funny) by FatPhil on Tuesday December 20 2016, @10:21AM
However, the bigger problem appears to be the several thousand functions of bloat, which smacks of kitchen-sink-ism. It would be nice to perform a coverage run of the code, and see how much of that compile-time-deterministic code is actually needed.
Fortunately, they've made the source code much more compact by not requiring semicolons at the end of lines - phew, it's good to know they've got their priorities right!
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by RamiK on Tuesday December 20 2016, @07:02PM
Worse, it even jumps around a mov. cmov was introduced into x86 back in 1993-ish.
cmov is often slower [yarchive.net].
However, the bigger problem appears to be the several thousand functions of bloat...
Some work was done for 1.7 [golang.org] but during 1.8 efforts were refocused on expanding the SSA backend since it involved linker refractoring that should make stuff like dead-code elimination during the linking stage easier.
The thing to remember is that Go's GC and the stdlib's unicode, TLS and HTTP2 support can always be improved upon so shaving off a few bytes off the binaries is just not that appealing as a standalone priority.
compiling...
(Score: 3, Interesting) by NCommander on Tuesday December 20 2016, @09:28PM
I worked with Go professionally at a previous job. While I dislike the language itself immesensily, the toolchain and ecosystem are beyond fucked to say the least.
Go works on the philosphy that its binaries should be completely standalone, and that libraries shouldn't exist (they've partially caved on this view, but more in a moment). Unlike almost every programming language I've encountered before, Golang only generates static binaries, and directly embeds the runtime and dependent modules right into the output. This means you do get a binary that always works everywhere (assuming you have a recent enough kernel), but intentionally attempts to avoid things like kernel vDSO modules or the C library. As such security fixes to libraries require a full rebuild of all Go modules, and the resulting binary that comes out is relatively massive.
This is compounded by the fact that library imports on Go are just git repos. The "go" tool simply grabs them with git, builds them, and directly links them into the project. As far as I can tell, this design only makes sense with monorepos used by corporations like Google, and tends to run into the problems with dependency libraries, as I've had interfaces break on me due an upstream changing something, and go helpfully updating on the fly. As part of their magic of making goroutines and such work, Go setups up a segmented stack (an unusual, but not unique choice; Ada does the same, and I believe Rust does so), but refuses to have any interactions with operating system threads. Because Go exists as a monolithic binary, C interfaces have to be directly exposed for FFI and drastically complicate the build process since you now need to get cgo into the mix. If you're dealing with a C library that heavily depends on callbacks, you're about to hit a lot of pain. Furthermore, convincing cgo to use existing headers and libraries is an exercise in frustation; I mostly ended up having to write C wrappers to get everything to work and hand massage parts of the build system at times to keep this going. As goroutines only exist as part of the userspace Go library, Go is dependent on state being kept in the "main" thread that implicately exists in all processes. As best I can tell, a pointer to a go function immediately becomes invalid the moment C code returns into Go. That means if you're dealing with C code that threads, and depends on static callbacks being available, you're fucked. My "solution" to this was simply catch the callbacks in a C handle, and then Go would simply get the data structure from C on a regular interval.
This isn't even getting into the toolchain itself, which is directly descended from the Plan 9 compiler. I can understand that the Go developers wanted to work with something they understood, and could have forgiven it, except for the fact that they refuse to provide any serious support for gccgo (which tends to lag several major behind) or LLVM. As such, getting Go to do anything that isn't directly in the box requires bending the toolchain into a pretzel, and requires a lot of serious black magic. It's quite possibly one of the most fucked up programming environments I've ever worked with. (I could write a rant in-depth on the language itself; this is just the tooling and ecosystem I'm ranting about).
Still always moving