Comment by brundolf | Hacker News Reader

Comment by brundolf | Hacker News Reader

The most insightful way I've ever heard Go described is as a "C fanfic". It's like a bunch of C programmers, writing software for web infrastructure, got together and made a wish-list of things they wanted to be different about C (specifically in the context of writing web infrastructure). And then they made a new language, taking the most direct path toward that wish-list, and inheriting most of C's other traits as a matter of course.

Taken in this light, Go makes a ton of sense. No undefined behavior! Well-defined zero values! Duck typing! Automatic memory management with minimal overhead! Easy-to-use threading primitives and trivial cross-platform builds! A networked-C programmer's dream.

But we've learned a whole lot about language design in the past 40 years, and combining those things we've learned with a loosening of C's constraints, there are much better fundamental design decisions that can be made for a greenfield language. It just seems like Go's designers weren't really interested in questioning a bunch of the ones they were used to.

Exactly

Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection

Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.)

Go puts essential C idioms directly into the language (pointer/length is formalized as slices, packages are part of the language instead of just being naming convention, etc.)

The longer I used C++, the more I despised it. I used C++ for 11 years and I literally hate the language. But C has always remained a pleasure, and Go is a continuation/modernization/enhancement of that

If you like C, you will love Go

It's a feature for sure. The article was a refreshing read too! Of course, hiding and abstracting away much of what is available in C, will have issues when you have special needs. But it beats "make configure" any day, and works well when you just need something with decent speed and memory footprint to get the job done.

I'm enjoying all of what you mentioned above, and dislike languages that are more C/C++ like now, as you often get "un-bit" by these snags using Go. However, Go has some snags on its own (hello slices!), so it's good to make sure one learns the fundamentals and what works well. A bit sad when repos import hundreds of other packages, I just turn away from such offers. It's been the state of IT for past 20 years that everything is essentially garbage. This is nothing new, and one just need to pick one's poison as you go along.

Nothing is ever simple either. All the "better solutions" in Rust, is sure to need refactoring and updates, while Go-code can mostly continue to run as-is. That's a good aim for its niche. Though, we all know the underlying platforms are very diverse, complex and come with snags of their own. I don't think the aim of Go is to tackle them all like "make configure" attempt to though.

I'll be happy to learn Rust for some herculean effort sometime.

Thanks for your comment

Picking up on one of your snags, Go's slices will "click" for you once you start thinking of it as a pointer and a length (and a capacity), but nothing more.

Realize it's just a C struct like this, passed by value:

  struct intSlice {
      int* addr;
      int len;
      int cap;
  };

The memory at addr is not owned by the slice. All the slice operations are simply notation for manipulating the struct. Go's garbage collection makes the whole thing work brilliantly

This can be confusing if you're used to std::vector (which owns the memory) or python's slices. Go's slices are a shallow pointer/length system exactly like is used in C all the time. For example:

  void sort(int* addr, int len);

becomes

  func sort(a []int)

A Go slice is just a pointer/length, with terse notation

For me I just use what's available and do not go into too much detail beyond what I need. However, slices can be confusing at first, and your above example could help think of them the right way. Although, until you get "bit", you might not deduct the consequences of slices right away. Especially when accustomed to other languages.

The latest thing that made me go "hmm" last time, was this one (I didn't get "bit", just went "hmm" reading it):

https://play.golang.org/p/2bTvXr6WLNN

  package main
  
  import (
   "fmt"
  )
  
  func main() {
   b := []byte{'g', 'o', 'l', 'a', 'n', 'g'}
   fmt.Println(string(b[1:4]))
   // Output:
   // ola
  }

I'm sure everyone expected this output when using b[1:4], right? All languages do these things a bit differently, so is why I always forget the detailed syntax required. I'm sure there's a valid pragmatic explanation and there's lots of ways to do this (ie. allow negative values etc.). Just a thing that while speedtyping, one could easily miss this little detail.

This one is a good intro, but doesn't explain this I believe:

https://blog.golang.org/slices-intro

I honestly think of Go as Java with an appeal to C programmers. And of course much better performance/memory usage than Java.

Go is a high-level language. It is not meant for low-level programming. and yet the authors keep claiming that it is.

Reply on news.ycombinator.com