Rob Pike interview • Hacker News Board

Re: Rob Pike interview

#151

Post by dnautics » Thu, Apr 30, 2020, 5:50 PM UTC

throwaway894345 wrote: post #53

alexeldeib wrote: post #37

Earlier quoted context omitted.

I write in Go daily and I've been ramping up on Rust. While CSP isn't built into the language, Crossbeam, Flume, and others are more than enough to fill the gap. If anything, I find Rust returns flexibility to me in programming choice that Go made me forget I had. There are places where library support in Go is still richer, but language support has been stellar across the board in Rust.

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.

Re: Rob Pike interview

#152

Post by bakul » Thu, Apr 30, 2020, 5:50 PM UTC

cletus wrote: 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…

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

You don't know what you are talking about. Someone who has written operating systems, windowing systems, editors, many many tools & library functions, and well regarded books on programming doesn't exactly lack systems programming experience.

Re: Rob Pike interview

#153

Post by thefounder » Thu, Apr 30, 2020, 5:52 PM UTC

christiansakai wrote: post #133

gorgoiler wrote: post #11

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…

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.

Re: Rob Pike interview

#154

Post by jrockway » Thu, Apr 30, 2020, 5:52 PM UTC

cletus wrote: post #135

jrockway wrote: post #113

Earlier quoted context omitted.

> The small one is the lack of IDE support. You don't need to write an IDE. You just need to have sufficient integration into Jetbrains IDEs (at a minimum). Jetbrains wrote their own Go IDE, goland. The rest of us use an LSP client that talks to gopls. I have used that for about a year and it does everything that I would want an IDE to do; accurate context-sensitive completion, an easy way to peek at signatures and d…

Hey, Rockway, how are you? Yeah, I should clarify: I was responding to Rob's point in the interview where he was talking about tooling and IDE integration from the outset rather than the current state of the world. As for Jetbrains writing their own IDE... well, yes and no. Sure there's a separate product from a user perspective but IntelliJ has had a Go plugin for several years. You'll probably find Goland (just lik…

Good! Still technically alive anyway.

You're right that go didn't have amazing tooling from day 1, but the tools it did have were enough for me to change my workflow. I never cared about autoformatting (too many knobs to turn) before gofmt, and now I can't live without autoformatters.

Coming from a dynamic language background, I also never really got tools that claimed to provide completion to work, so I ignored them for most of my career. I worked on a Java project at Google and Emacs worked fine. Now there is LSP, and I first tried it with gopls, and it worked perfectly. Now I can't live without it, and try to avoid having to work in languages that don't have a good LSP implementation. (I am also very annoyed by the multitude of C/C++ projects whose crazy bespoke build systems manage to make clangd not work. That's the reality of tools coming along late; sometimes it's too late to have an impact because people have gotten by without the tool and are happy to continue with that.)

I have also used a little Goland. At my last job, we replaced a lot of PHP and Expect scripts with Go programs, and it was quite the journey to keep people happy with their existing IDEs. (Everyone had the Jetbrains you-get-everything pack, so at least Goland was free.) Goland is really a from-scratch implementation of editor support for Go. They had no other choice... but it makes different decisions from the open source tools which is quite the pain point. (I remember it importing opentracing-go as a plain "github.com/whatever/opentracing-go" and let things in the file refer to that as opentracing.Whatever. goimports wrote it more explicitly as 'opentracing "github.com/whatever/opentracing-go"'. I still don't know how that works, but apparently it did, and so diffs would always oscillate between the two until we convinced Goland to just run goimports.

What I like about go's tool support is that it's done a good job of adding features for people that want them, and letting those people use the tools without upstream dependencies knowing about those tools. I started using go modules before it was particularly popular in the community, and it didn't cause much trouble. (People sure liked to force push to their version branches, though, causing go.sum checks to fail. And people would always blame the Go team for that, unfortunately.)

I have a hunch that not many people are using gopls, but it works perfectly on codebases where I know the authors never used it. That is a pretty big deal and is better than what a lot of other languages do. "We have this new thing... restructure your codebase to try it out." It's nice for new codebases, but even nicer when you don't have to do that.

So all in all, I am very satisfied with the tooling situation.

Re: Rob Pike interview

#155

Post by dnautics » Thu, Apr 30, 2020, 5:53 PM UTC

linuxftw wrote: post #148

batiste wrote: post #59

Earlier quoted context omitted.

Lord I hate YAML. 10 years after seeing for the first time I still haven't memorised the intricacies and feel unsafe modifying any file.

Just take the time to learn it, it's really trivial once you take the time to learn the basic types. You have lists, dictionaries (maps), and primitives. It could not be easier.

I think the real problem is that yaml encourages you to make things declarative (which is 99% of the time a good thing) but sometimes hiding complexity is the wrong thing, and so when you have clashing declarations, the imperative resolution path is not necessarily explicit, and hidden behind an operations layer that you can't really see or reason about.

For some reason YAML seems to be an attractive option to try to implement things that really should be imperative in a declarative sense. Other configuration languages are either semi-imperative (like the hashicorp stuff) or don't do that (I haven't seen TOML configs that do some of the thing that YAML does). My best guess is it's purely cultural, because that trend started with ansible, which, not to denigrate - in many ways did very good things.

The trouble is that 1% of the time always hits at a very inopportune time.

Re: Rob Pike interview

#156

Post by marcocampos » Thu, Apr 30, 2020, 5:53 PM UTC

cletus wrote: post #43

floren wrote: post #35

Earlier quoted context omitted.

> 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. Yeah, Rob Pike and Brian Kernighan definitely lacked experience in C and systems programming.

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.

Rob Pike is also the co-author of UTF-8.

Re: Rob Pike interview

#157

Post by qppo » Thu, Apr 30, 2020, 5:54 PM UTC

This interview was refreshing to read and the comment section far too toxic for the content.

Re: Rob Pike interview

#158

Post by mav3rick » Thu, Apr 30, 2020, 5:55 PM UTC

cletus wrote: post #105

mav3rick wrote: post #86

Earlier quoted context omitted.

If you didn't know you should have clarified before making such sweeping statements. Who knew writing an OS would count as systems programming experience.

"writing an OS" is a sweeping, unsupported and inaccurate statement. You can be involved in Linux and, say, write the ext4 filesystem or Wifi drivers. Those are pretty low-level. You could also write shell utilities like ls in probably anything where you're just using OS APIs. Is that low-level? I would say not.

Oh my god. Can you at least do your research now ? They wrote the core bits and not just userspace utils. Did you read what they wrote before blustering here ?

Re: Rob Pike interview

#159

Post by throwaway894345 » Thu, Apr 30, 2020, 5:55 PM UTC

dnautics wrote: post #146

throwaway894345 wrote: post #138

Earlier quoted context omitted.

> Go itself is probably the least software engineering friendly language out there My experience with software engineering went from "the language (type system, grammar, syntax, etc) is super important!" to "the language is one of the least important considerations in choosing a language". The more important features are tooling and ecosystem. I don't want to have to learn a new configuration language or imperative D…

> Go is a great language for software engineering Is it though? While tests in go are not terrible, to be a truly effective software engineer (vs just a programmer or dev) you want a very good test and documentation story, and there are languages out there with far, far, better tests and documentation primitives than Go.

I think the point is that Go gets like a 90% score in most categories. You can get languages that score 100% in performance or testing or documentation, but they tend to trade off 60+% in several other important categories.

Further, I contend that Go has excellent documentation primitives, notably that it doesn't have any sort of markup or documentation package management. I've never seen a better language in this regard.

Re: Rob Pike interview

#160

Post by apta » Thu, Apr 30, 2020, 5:56 PM UTC

eropple wrote: post #22

gorgoiler wrote: post #11

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…

I would entreat you to not be afraid of Golang. To be frank its adoption speaks to a desire to make software that does not require (or, often, benefit from "staff SWE" skills). Treat it as what it is, a jumped-up, terser, and in some ways gutted Java, and give it another go. It is designed, to a fault--and this is a little pejorative, I absolutely do not enjoy writing Golang because of it--to be not that hard .

golang is not terser than Java for any non-trivial code bases, it's quite the opposite.