Live data from Hacker News

Rob Pike interview

evrone.com

181–190 of 273 posts

Re: Rob Pike interview

#181
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…

You just need to have sufficient integration into Jetbrains IDEs (at a minimum).

Are you aware that Jetbrains makes an IDE for Go, called GoLand?

Re: Rob Pike interview

#182
post #175

Earlier quoted context omitted.

This is not that obvious, since many people are resisting it, but if you ever tried to use type annotations in Python, it dramatically improves refactoring (from my experience PyCharm it actually is more reliable than GoLand), you get autocompletion and bug detection. Highly recommend this for large Python projects.

I didn't like type annotations in Python, but I didn't like Go's type system either when I started. I'd be willing to take a second look at types in Python now. But, my real reason for choosing Go was for performance, and it blows our previous solution out of the water. Go isn't perfect but I'm pretty happy with it for right now. I still use Python for a lot of other things though.

Well, if performance is the objective, then I can't suggest Python, because that isn't the goal. You can still have a performant application implemented in Python, I for example had it encode video stream on the fly, but this of course is done through extensibility via C extensions and the core work wasn't really done in Python itself.

Sometimes with the right approach (mapping PostgreSQL calls 1:1) and right tooling (uvloop, Cython) you can write code in Python and still squeeze better performance than in Go[1], but you need to know what you're doing.

If you want to explore types, these resources[2][3] were useful for me.

[1] https://github.com/MagicStack/asyncpg

[2] https://mypy.readthedocs.io/en/stable/

[3] https://docs.python.org/3/library/typing.htm

Re: Rob Pike interview

#183
post #25

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…

This isn't true at all. Go is not the tool of choice for experienced professional programmers for exactly this reason. The ability to quickly refactor code is very important and Go fails at it horribly for a number of reasons. 1) sheer verbosity. 2) multiple return makes altering function signatures tedious. 3) no generics mean code is written in hard to refactor styles out of the box 4) poor reflection support 5) po…

> The ability to quickly refactor code is very important and Go fails at it horribly for a number of reasons. 1) sheer verbosity. 2) multiple return makes altering function signatures tedious. 3) no generics mean code is written in hard to refactor styles out of the box 4) poor reflection support 5) poor tooling compared to professional grade languages (Java/C#/etc)

1) there are worse languages in that category. some are even more widely used.

2) that doesn't make sense. return arguments are part of the argument list signature. either changing any argument makes this tedious, or none does. you indicated that only return ones do for some reason.

3) can't argue there. in the rare occasion that type asserting interfaces is required because of lack of generics, things really do suck.

4) can you elaborate on that?

5) only thing i found lacking was absence of advanced refactoring tools. for everything else, the available tooling seems to be on part with what i've used with java (anecdotal)

Re: Rob Pike interview

#184
post #74
post #44

Earlier quoted context omitted.

Go has no expressiveness to it. You end up either with a large pile of copy pasted code, code generators, or massively error prone runtime introspection. Go blows up the entire idea of Don't Repeat Yourself. The language actively encourages it.

> Go blows up the entire idea of Don't Repeat Yourself. Yes, this is true. I programm in Go professionally, about 50% of my work time (other half is python). But in many cases, I have found that copying the same code to other places doesn't have that much negative consequences as one would believe.

So I'm almost certainly in a different industry (embedded) where EEs tend to prolifically copy+paste code. In the end this always makes it so that a change that should take very little time consumes an entire workweek or more. So I have a seething hatred of this practice from past experiences.

I suppose I should say that there's a lot of different types of duplicate code, some of which really don't matter per se. Sometimes two bits of code are basically the same but are completely unrelated and as things change they will diverge, i.e. it was just incidental. Code that is duplicated with a strong functional relationship make changes a nightmare though.

Re: Rob Pike interview

#185
post #178

Earlier quoted context omitted.

For Dropbox and Uber, it is.

I thought Uber was node.js company (to the point that they had to rewrite existing solid projects, because they weren't in node.js) As for Dropbox I was convinced primary language was Python.

Uber has primarily been a Go shop for over 2 years now.

Re: Rob Pike interview

#186

Earlier quoted context omitted.

I shouldn't need an industrial-strength editing engine to efficiently express my ideas. (And don't, if I'm using a nice expressive language.)

Generally speaking, Go is one of the easiest languages to write with a simple text editor. Rust is among the hardest due to its complexity and demanding static analysis. This isn't a bad thing, and tools like rust-analyzer make writing Rust a lot easier. But rust-analyzer is amazing technology from the future; hardly an ordinary text editor plugin.

> Go is one of the easiest languages to write with a simple text editor.

As long as you never refactor anything.

> Rust is among the hardest due to its complexity and demanding static analysis

I have never wanted or needed to offload Rust's "demanding static analysis" to my text editor. Rust's linearity/lifetime type system is really quite simple - it's not like you have to keep track of long-distance lifetime relationships in your head.

Even a reasonably powerful type system with e.g. HKTs, arithmetic, etc. like Haskell's rarely benefits from external tooling, and any interactivity can often be just as easily done via a polling build tool like ghcid rather than integrating it into a text editor.

The one place where it strikes me as sane to have a "smart" text editor is if you're using a proof assistant-style language like Coq/Idris/Isabelle/Liquid Haskell/etc. where there's actually a non-trivial amount of interactivity required while writing the code.

Re: Rob Pike interview

#187
post #185
post #178

Earlier quoted context omitted.

I thought Uber was node.js company (to the point that they had to rewrite existing solid projects, because they weren't in node.js) As for Dropbox I was convinced primary language was Python.

Uber has primarily been a Go shop for over 2 years now.

Sounds like they are driven by what's fashionable. They were very aggressive about node.js to the point that they refused anything that was't in node.js) before that.

Re: Rob Pike interview

#188
post #25

Earlier quoted context omitted.

This isn't true at all. Go is not the tool of choice for experienced professional programmers for exactly this reason. The ability to quickly refactor code is very important and Go fails at it horribly for a number of reasons. 1) sheer verbosity. 2) multiple return makes altering function signatures tedious. 3) no generics mean code is written in hard to refactor styles out of the box 4) poor reflection support 5) po…

> The ability to quickly refactor code is very important and Go fails at it horribly for a number of reasons. 1) sheer verbosity. 2) multiple return makes altering function signatures tedious. 3) no generics mean code is written in hard to refactor styles out of the box 4) poor reflection support 5) poor tooling compared to professional grade languages (Java/C#/etc) 1) there are worse languages in that category. some…

On tooling, Go doesn't seem to have anything like Java's

- configurable sandboxing

- hot reloading

- AspectJ (cross-cutting code injection at link time or during classloading)

- JMX (extensible RPC API for metrics and administration)

- YourKit (interactive remote profiler wired in during classloading)

Re: Rob Pike interview

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

I don't think Go's proposed system is parametric either. It's not clear to me how their contracts actually map to generics so I have no idea if Pike is telling the truth or just "thought leading".

Re: Rob Pike interview

#190

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…

Don't confuse the shortcomings of the tools you use with your intellectual limits. This is a very insidious philosophy and there is no good reason to internalize it. Always remember that tools must be subservient to user needs because they're tools.
Post reply on HN