Hacker News Reader

Comment by UI_at_80x24 | Hacker News Reader

Regarding Go:

>Yeah, but your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

Sorry couldn't resist. I'm a Systems Admin. An old-fart at that. Every single encounter I have had with Go has been a burning pile of unpleasantness. Most recently, the Go-Ethereum client.

So, referring back to the quote; could we just not shoehorn this into everything? It may be fast but it's fragile FWIW.

View on HN

As an old time sysadmin I'd expect you of all people should know better than to make assumptions about a programming language based solely on a small handful applications written in that language.

The ironic thing is what you described ("fast but fragile") better describes the traditional systems languages that are used to build X11 components: C and C++. If I had to describe Go as a systems language I'd say it was the exact opposite: slow but stable. Sadly it's also pretty inflexible for any real low level stuff (in my experience).

> Sadly it's also pretty inflexible for any real low level stuff (in my experience).

Which is what the poster above you meant by fragile. C and C++ rarely break in most spaces, these days. I can take a C library and expect it to build and just work 99% of the time, and I can build something in those languages and expect it to be flexible enough to work most of the time as well.

> I can take a C library and expect it to build and just work 99% of the time

You cannot imagine how many times I've heard that GCC upgrades broke builds. I've never heard of Go upgrades breaking builds.

If only that were actually true. I've done a lot of work porting C++ code to various different flavours of Linux and Unix as well as compiling stuff for Linux from working source and it's rare that things will "just work". Granted a lot of time the real pain point is manually having to deal with dependencies (even Go's old $GOPATH solution is better than the stanard C++ approach!). Then you have compiler flags, compile time options, distribution specific patch files, dependencies for the build scripts themselves, etc. And that's before you've even touched on compiler specific variations, language versions and undefined behaviours. There is a reason why the source-orientated repositories like FreeBSD ports, Gentoo's portage and Arch's AUR have wrappers around build scripts and it isn't because things "just work 99% of the time" ;)

Go does have its short comings, I'd be the first to admit that, but the actual reason I started writing Go was because it was far less brittle trying to write portable code than C++ and at the time I was having to do a fair amount of cross compilation on platforms of other CPU architectures as well as different host OSs (Rust wasn't mature at that point, .NET wasn't open source and I've never enjoyed working with Java so I thought I'd give Go a try)

really? I find that usually automake systems, despite how disgusting they are to deal with from a developer-standpoint, almost always tend to 'just work' from a user-standpoint.

I can't really speak very much for C++ systems, as I understand the dominant build system for that is CMake, which personally I have found completely abhorrent from a user-perspective. (I once tried to build a 32bit program on a 64bit system, and CMake completely and totally refused to do so! There were no override flag that actually affected the program, and it didn't look as if there was any standard place to inject flags to the compiler, I still have no idea how one goes about doing it, to be quite honest).

> Every single encounter I have had with Go has been a burning pile of unpleasantness.

Can you elaborate?

> It may be fast but it's fragile FWIW.

Go explicitly focuses on language stability over fancy new features.

> Go explicitly focuses on language stability over fancy new features.

I think that might be the problem... C is probably the most stable language around in terms of features, but it is probably the language that is most prone to bugs and security flaws that is in common use.

Yes, but it is very difficult to introduce the same kind of bugs in Go code considering you are no longer doing intricate memory management, etc.

C also has raw pointers, manual memory management and a bunch of other unsafe practices that Go doesn't. In comparison to C, Go is practically a scripting language.

Totally agree there. However, I think the metaphor might still hold that Go applications are brittle due to lack of features due to the ugly hacks you have to use to get around the lack of features. For instance, due to the heavy usage of manual error checking, it can be very easy to call a function and forget that it returns an error thereby ignoring that error. Bringing down your whole application due to a single error is bad, but silent failure is almost always much worse.

Go will complain loudly if you don't use a captured error value. It will also complain loudly if you don't capture the error value. This makes it harder in Go to ignore an error than most other languages. In fact a common complaint of Go is that it forces you to do something with the error when you would rather not.

I'm left to wonder what you are imagining would result in not handling errors on accident in Go.

Considering that Go by default compiles to a static, native executable with close-to-0 system dependencies, I can't imagine why you'd hate it.

I deploy Go code all day long to various clusters consisting of hundreds of machines, and I'll take whatever Go deployment issues you can throw at me all day long, any day, over "simple" python/ruby issues.

It's all been moot since I went with Docker anyway.

I wrote my first Go application that was to be run on a very Linux instance (1 GB), serving results to HTML from an in-memory map of some 150MB. The memory growth was really out of control, panicking with "out of memory" under even low load until I added debug.FreeOSMemory after serving each search result. Even with that, I had to change the instance to 2GB. It was a one-off excperiment, but I missed releasing memory by myself to ensure a manageable working set.

Your program certainly had a bug. Feel free to paste a link to it here, I may be able to debug it.

Yeah definitely a bug.

I've worked on systems that allocated and freed hundreds of GB every 10 minutes, written in Go with no such issues.

Is the code online somewhere?

It really sounds like there was something not-quite-right in there. Might not be too hard for someone with time + clue to spot it. :)

that's called a memory leak: https://en.wikipedia.org/wiki/Memory_leak

I've seen happening in Go multiple times when people forget to close the response body after making a http request.

One would think that syadmins love native executables with no system dependencies.

Errr why?

They come with no associated bits to hook them into the rest of the system. eg no launch/process monitoring things (start-at-boot and similar, metadata and "package info" for being able to pull down upgrades along with other system packages.

Go stuff is fine for a lot of deployment cases, but in production situations the rest of the er... crap that normal packages come with does serve some important purposes. At least on *nix systems. :)

Reply on news.ycombinator.com