What's vexing Linux-loving Gophers? A few things: Go devs want generics, easier debugging

The Go team's latest developer survey shows that most "Gophers" like the language but highlight poor debugging tools and lack of generic support as top issues for improvement. The survey, which was conducted in November and December 2019, attracted nearly 11,000 respondents, almost double the 2018 number. Go was created by …

[Bronek Kozicki]

"The implication is that while Go may be great for developing APIs and web services, it is not so good at the lowest level, perhaps a price paid for developer-friendly features like garbage collection."

I concur. Garbage collection is not great if your program works with many low-level resources (other than memory) because you have to maintain their lifetime by hand. I use both C++ and Go and while I would prefer to write higher level code in Go only, anything low-level has a better chance of good performance and consistent low resource utilization if it is written in good, idiomatic C++

[DrXym]

Exactly. That's garbage collection for you - a larger memory footprint that expands and deflates. It doesn't really matter so much at the higher levels and can be beneficial. But it can be a critical issue at the low level.

That said Go definitely occupies a sweet spot - you can build self-contained executables that run pretty fast without the bloat or hassle of shipping a large runtime. Assuming you have the memory you can write an application that is more performant and less hassle to deploy than one written in Python or Java for example.

[MacroRodent]

Link the world

ou can build self-contained executables that run pretty fast without the bloat or hassle of shipping a large runtime.

On the other hand, last time I looked you cannot escape this self-containment, which means it is no good for smaller programs. Each exe carries with it much of the runtime system, so they start at about 2Mb in size. By contrast, the loated version of the "cat" command on Fedora Linux is 46K.

[RichardBarrell]

Re: Link the world

I notice that with big projects written in Go, where you might have a couple of command line utilities, they all get bundled into one executable with "subcommands". Say, instead of having "foo-create", "foo-list" and "foo-delete" as separate executables, they'll output a single binary called "foo" that you run as "foo create" or "foo list" or "foo delete", so the file size overhead of static linking doesn't get multiplied up.

This has no real cost in performance, complication or convenience, it's just mildly interesting. Seems to happen with every language that uses static linking by default.

Plus it's microscopically trendy: you also see programs opt to use this style which are written in languages whose hello world binary is <10kB.

[Anonymous Coward]

born out of frustration with existing languages and environments

See icon at right for a helpful visual describing Go's accomplishments in that respect.

[Irongut]

Re: born out of frustration with existing languages and environments

I'd agree with that. While I am using Go for one project and it is super fast I find the code very hard to read due to its lack of punctuation to denote syntax.

[Tom 38]

Re: born out of frustration with existing languages and environments

Can you clarify what you mean by lack of punctuation to denote syntax? Do you mean terminating statements with ";"?

[My other car WAS an IAV Stryker]

Gophers don't come from Google...

Gophers come from (University of) Minnesota! Long live the Gopher protocol!!

(Really, is everyone intentionally trying to cover up its existence? Can't even be labeled a Gopher without confusion now...)

[Flywheel]

Re: Gophers don't come from Google...

Hear Hear! Good point!

I'm fed up with trawling the 'Net for Gopher Server resources for my Gopher Server only to find that those pesky Go Folks have usurped the name. And before you start hrumphing about old tech, I'll have y'all know that there are 300 servers out there all serving some very eclectic content, much of it not found anywhere else.

/rant

(Paris, cos why on earth would they do such a thing?!

[Blackjack]

And that's okay

A programing language that tries to do everything will end doing it poorly.

[TheMeerkat]

If you developing web services there is no point to try to be “trendy” with Go. Just stick to Java like everyone else and you will get genetics, debugging etc and be more productive.

[Bronek Kozicki]

I disagree. Java GC is one or two orders of magnitude slower than that provided by modern Go runtime, not to mention both memory and CPU overhead of all the other 3rd party Java libraries which you will end up using in your program, for convenience or because Java defaults are not useful. It's just not very good for microservices, unless your memory and cores come for free. Although admittedly, Oracle is making an effort to bring Java to more modern age, with GraalVM.

[trevorde]

Caught in the middle with Go

Learnt Go for a project at work, after 20+ years C++/C# experience. I can't decide if it's an up market C++ or a down market C#.

[chuBb.]

Re: Caught in the middle with Go

Spot on sums up my feelings too, if i was feeling unkind and it was 20years ago i would probably dub it cscript.

I dislike its simplicity in error handling, php does a better job ffs and thats a very low bar, and im not to keen on the fairly obvious design cues taken from python either.

[Bronek Kozicki]

Re: Caught in the middle with Go

I like to think of it as "upmarket C".

[chuBb.]

Package Management and Versioning are a joke currently

Had a fun weekend and first half of week caused by an upstream package (a cron lib) changing from quarts style schedule strings (secs, mins, hours, days, months, years aka * * * * * *) to standard 5 variable cron strings.

As a mere user/admin of the vendors software I should have been able to pull the container image and build, but noooooo due in part to the updated cron libs dev using master as the release branch with a massive breaking change, instead of a tag meant new deploys were pulling in the wrong version and so failing to start, even though the vendors code was correct (for the old version) the way the packages were pulled in meant it was pot luck if it would work or not depending on if you had the correct package locally cached (yay random errors and works on my machine debugging on a vendors release!!). Sure i could say the dev of the cron lib is an asshat for releasing in such a way as to break existing code, but ensuring new projects have the new shiny, but really i dislike the assumption in the build process that i want the latest, and if the references mention the version to use, it should bloody well use that version, which is why you need a registry not a source control system for this to normalise releases, could care less if the git repo tags a release as "unicorn-rainbow-facemask-latest" as long as in the registry it knows its 1.0.0

This was despite the fact the vendor having what looked like an pegged version in its package references turned out to be more of a comment than an instruction. Ultimately i put this down to being a failing of the language/ecosystem than any given dev, git is not a package manager nor should it be used as such, but thats what it seems GO does, i mean seriously it makes me almost (almost) have a good thing to say about npm and bower.

[Tomato42]

Re: Package Management and Versioning are a joke currently

lack of backwards compatibility and API stability is a bane of all the "hip" new languages: Go, Javascript, ruby

it's much better with older established languages (as in, some developers behave as if they actually heard of the concept) like Java and Python

but it's wide-spread basically only in C land, shame really