5 ms·

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.

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.

sumitgt 8y ago
> 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.
- slaymaker1907 8y ago
  > 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.
  - sumitgt 8y ago
    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.
  - laumars 8y ago
    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.
    - slaymaker1907 8y ago
      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.
      - zaphar 8y ago
        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.
laumars 8y ago
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).
- fao_ 8y ago
  > 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.
  - majewsky 8y ago
    > 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.
  - laumars 8y ago
    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)
PopsiclePete 8y ago
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.
- antaviana 8y ago
  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.
  - dcu 8y ago
    that's called a memory leak: https://en.wikipedia.org/wiki/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.
  - sagichmal 8y ago
    Your program certainly had a bug. Feel free to paste a link to it here, I may be able to debug it.
  - courtf 8y ago
    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.
  - justinclift 8y ago
    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. :)
jy3 8y ago
One would think that syadmins love native executables with no system dependencies.
- justinclift 8y ago
  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. :)

sumitgt 8y ago

> 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.

slaymaker1907 8y ago
> 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.
- sumitgt 8y ago
  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.
- laumars 8y ago
  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.
  - slaymaker1907 8y ago
    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.
    - zaphar 8y ago
      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.

laumars 8y ago

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).

fao_ 8y ago
> 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.
- majewsky 8y ago
  > 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.
- laumars 8y ago
  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)

PopsiclePete 8y ago

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.

antaviana 8y ago
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.
- dcu 8y ago
  that's called a memory leak: https://en.wikipedia.org/wiki/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.
- sagichmal 8y ago
  Your program certainly had a bug. Feel free to paste a link to it here, I may be able to debug it.
- courtf 8y ago
  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.
- justinclift 8y ago
  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. :)

jy3 8y ago

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

justinclift 8y ago
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. :)