Rob Pike: What Golang Got Right & Wrong

21 thoughts on “Rob Pike: What Golang Got Right & Wrong”

• It's funny to see primes take on this because my experience is almost the opposite of his. Back during that time, I was mostly working on distributed networks and databases; I've never worked on front end code in my life and concurrency is just always been a part of being an engineer. Back in 2009, I was writing erlang and I had been writing it for a while. When go came out, I thought to myself, "oh that's nice, they're finally adopting straight forward concurrency as a core feature in a mainstream language.". Java and c++ both already had threads and coroutines but a lot of people in the mainstream enterprise domain ignored them because they were notoriously difficult to work with. Meanwhile, one of the first jobs I ever had was writing a locally distributed database in lisp and c.

  I like go and I've used it quite a few times but the one thing that really stops me from loving it is it's garbage collector and the lack of solid interrop with other c languages. Writing cgo is one of the worst experiences I've ever had as a developer and I believe it was intentionally designed that way because they want you to use go in the go ecosystem. I can understand that, but it just kind of sucks when it comes to certain use cases. Cgo is probably the biggest misstep of the go language even though somebody like Rob Pike would probably disagree.

• i think im falling in love with htmx

• 28:58 need to tweet that as well. "To successfully build Java you need a degree in maven"

• great story

• Unit testing can be such a pain because anything you want to mock must already be built with interfaces and dependency injection in mind. Golang markets itself as a simple language to write good code easily, but if you actually write "simple" code, it's not testable.👎

• I don't like that production code ends up with so much autogenerated code. The fast compiler provides no benefit if that time is merely transferred to code generation.

• It's so lame that they made types but didn't have the one type that fixes so many error, the Optional type.

• 23:35 "Promise proposal" is not even the right thing to look for. You want to look at release dates of jQuery promises, Bluebird, Angular.js $promise, and arguably caolan/async too. The ride from raw-dog callbacks to ECMAScript promises was wild.

  A few dates:

  – AngularJS initial release – October 2010 (not sure if this included $promise or not…)
  – jQuery 1.6 – May 2011 `.promise()` added.
  – Promises/A+ spec v1.0 – December 2012
  
  – Bluebird v1.0.0 – January 2014
  
  – Chrome v32 – January 2014 (partial support)
  – Firefox v27 – February 2014 (partial support)
  – "Don't release Zalgo by Isaac Z. Schlueter" – June 2014
  – Safari v7.1 – September 2014
  – Node.js v0.12.0 – February 2015
  – Node.js v4.0.0 – September 2015

• You sound like my manager when complaining about short variable names. Just do what you've been told your entire career you shouldn't do. Sometimes it's ok.

• seriously one letter vars = gfy i'm not approving that bs pr stop making people build hash tables in their heads to read your shit

• wait was not 2024 supposed to be rust, you are playing on both sides ?

• Can someone explain this to a senior C# dev? I don't see anything concrete mentioned in here

• go kinda has single letter non official "standards", like w as a writer, b as a buffer, r as a reader, etc. Also wrt, rdr, buf, etc. also 1 letter vars usually are Receiver access.

• allTheGoodVariableNamesAreTaken

• The one-letter thing is aka "Rob Code". He comes from a time when screens were monochrome and space was limited. You can find the same fun in Plan 9 and the Limbo language.
  And… well… that made it into Go, I suppose.

• 21:20 The issue of the CC-by license of the Go mascot is that sharing it without attribution is copyright infringement. The CC0 license is ideal for something like that. Ferris, the unofficial Rust mascot is under CC0.

• 13:41 On desktop computing, even back in the early 2000s, arbitrary precision integers should be the default type for what you intuit as “it’s an integer number”. Using fixed-size integer types should be reserved to the following cases:
  1. It’s part of an algorithm (e.g. hashing) or standard (e.g. IPv4 or IPv6 addresses are exactly 32 and 128 bit).
  2. It’s an optimization you implemented (of course, after profiled profiling revealed its value).

  For a customer’s age, use a BigInt, unless you profiled and it curbs the app’s performance.

• 10 minute build? The typescript project I'm currently working on takes 15-20 minutes to build the first time and my computer locks up while its building. Its so painful because its not even doing fancy optimizations or anything

• What rust did not take from these ideas: Fast compilation and avoidance of "cleverness". I think this is what stops its real spread. Too much cleverness its like what scala is for java rust is for C(++)…

• At university, I used a C/C++ language extension for concurrency and parallelism called Cilk+ made/maintained by Intel which was exactly like Go's routines but using the keywords spawn or cilk_spawn instead and with many other features. It came well before Go. Go's approach is not novel and didn't revolutionatise anything. I'm not sure if it spawnned an OS thread or if it had a lightweight thread run-time like go, but that is just an optimization.

• You could probably easily add auto integers as a new type, why not do that?

Comments are closed.