Live data from Hacker News

Rob Pike interview

evrone.com

161–170 of 273 posts

Re: Rob Pike interview

#161
post #120
post #43

Earlier quoted context omitted.

AFAIK Brian Kernighan was never involved with the development of Go. He just likes to try new things and wrote a book about it. Rob Pike is probably most famous for his involvement in Plan9 (prior to this). I honestly don't know what this experience entailed.

If having worked in UNIX, Plan 9 and Inferno (and saying "having worked" is quite an understatement), having designed and implemented several programming languages (Alef, Squeak, Limbo, Sawzall, Go, ...), and having been an important part of Bell Labs and Google during their respective peaks is considered lack of experience in systems programming, what on earth would you consider as enough experience?

Flame bait on HN

Re: Rob Pike interview

#162
post #45

Really? Outside Google, I'm not aware of major orgs that use GO. I see the same .net C# stack, python, Ruby...... Java and PHP.

How hard are you looking? Facebook, Dropbox, Uber, Apple and literally thousands of other companies, big and small, use Go.

And those companies generally use C++, Java, etc. in a much larger capacity.

Re: Rob Pike interview

#163

Earlier quoted context omitted.

I do JS/TS profesionally, I play around with various languages on the side including Haskell/Rust. The more I work in JS the more I realized that I'm dumb. I'm not worthy to hold the power that JS has, much more other more complicated languages. I tried Go. I like it. It makes me feel safe and smart enough to write production grade app. Small docs, small language, no need fancy IDE, just any regular text editor like…

>> Now I finally can focus on other non-programming passion instead of chasing endless language features in other programming languages. I think this is really the best feature of Go. It's a pragmatic language. The only complain I have is the incomplete/half backed reflect package.

My only complaint is the use of capitalization as public private. Because I quickly run out of naming variables/instances/structs, and naming is hard!

Re: Rob Pike interview

#164

Go is the language that made me realize I’m not much of a production quality software engineer. Normally I would be quite happy riffing with ideas in Ruby or Python, and just running my code and iterating trying to figure out what to do. When I tried this in Go, every time I wanted to change the shape of my code to try doing things slightly differently I had to do a lot of work to get the code to compile again. I fee…

Sorry, but I have to be honest: in my opinion most of the replies you got to this comment are extremely misleading.

As a user of Go and Ruby I can tell you that: Ruby is an awesome language, and there's nothing else that beats it at getting things done quickly and painlessly (unless you have a mathematical mindset, in which case nothing gets shorter and more elegant (at least the day you write it) than functional programming). It has many other defects, like safety in larger codebases, speed, some weird quirks, etc., but it's an awesome language, don't expect many other languages to be less painful than Ruby (on small programs at least).

Don't listen to those that say professional programmers won't use Go. The only reason a professional programmer will say hard no to Go is for extremely optimized or mission critical code that can't tolerate garbage collection (even though the GC in Go is very low latency) or need a more sophisticated type system, or numerical applications for which Go isn't really well suited.

If you compare Ruby and Python to Go, the transition might be hard if you haven't studied computer science formally. That said, it's a matter of making the switch, understanding that all those objects (boxes to put data in) that you had in Ruby, now are statically typed; this means that a box is of exactly one type and can't change midway (and even subtle changes need explicit casting/conversion). You also need to learn the difference between composition and inheritance, which might be tricky depending on how you learned to program... but beyond that, Go is a very small and easy-to-write-code-in language. You might like the syntax more or less, but it's easy to write good code in Go. It has many other gotchas and hoops you will need to jump through (var initialization, error handling, new vs make, weird append/len, learn to printf, learn pointers, etc), but it's a good step after Ruby / Python, if you need things bigger than what Ruby / Python allow you to comfortably manage.

A hello world might require defining a package, importing another package, and a more verbose print statement than python / ruby, but those are all great (and minimal) appliances when developing at a larger scale.

Re: Rob Pike interview

#166
post #64
post #43

Earlier quoted context omitted.

AFAIK Brian Kernighan was never involved with the development of Go. He just likes to try new things and wrote a book about it. Rob Pike is probably most famous for his involvement in Plan9 (prior to this). I honestly don't know what this experience entailed.

Kernighan helped write Unix and Plan 9, literally wrote the book on C, and is the "K" in awk, among other achievements. Rob Pike worked on Unix, helped design and implement Plan 9 and Inferno, and co-designed UTF-8.

Apart from UTF-8, the piece of software he designed I used most was the sam text editor. An opinionated and rather quirky design, with some internals that made quite enthralling reading for me at the time: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

Re: Rob Pike interview

#167
post #26

I have huge respect for Rob Pike but there's a bit of revisionist history going on here. Go was originally envisioned as a systems programming language. It was often called "a better C". This exposed Rob Pike's lack of experience in the area (IMHO) because anyone who had done any systems programming at all knew that garbage collection made any systems language a nonstarter. Where Go succeeded was completely unintenti…

> garbage collection made any systems language a nonstarter

There are a significant number of systems that demonstrate otherwise: LISP machines, SmallTalk, Oberon.

Re: Rob Pike interview

#168

Earlier quoted context omitted.

I write Go daily, and I don't think CSP really panned out. For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP. That might be an artifact of how channels are implemented and their many hidden error cases--perhaps a better channel implementation could change the calculus. There are lots of reasons to prefer Go to Rust IMO, but I don't think CSP is among them.

> For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP It's easier to write code with standard threading tooling but I think CSP is much, much easier to debug and avoid deadlocks.

That has not been my experience with CSP via Go channels after 8 years of solid use (I still use channels here and there, but not in a CSP pattern). Different strokes, I suppose.

Re: Rob Pike interview

#169
post #130

> Although it's far from certain, after over a decade of work it looks like a design for parametric polymorphism, what is colloquially but misleadingly called generics... What exactly is misleading about generics? The psychology of thought leaders is fascinating. The term generics is colloquially understood to mean parametric polymorphism and here's Pike redefining the term to draw some distinction that doesn't reall…

(Also, once Rust gets specialization, our generics will no longer be parametric.)

Re: Rob Pike interview

#170
post #64

Earlier quoted context omitted.

Kernighan helped write Unix and Plan 9, literally wrote the book on C, and is the "K" in awk, among other achievements. Rob Pike worked on Unix, helped design and implement Plan 9 and Inferno, and co-designed UTF-8.

Apart from UTF-8, the piece of software he designed I used most was the sam text editor. An opinionated and rather quirky design, with some internals that made quite enthralling reading for me at the time: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/

It's an interesting editor, especially the split between the editor itself and the graphical frontend. That split has helped me work on some very limited systems, thanks to `sam -r`.

Personally, I prefer acme; it's my daily driver editor.

Post reply on HN