5 ms·

This is so condescending, but I'm glad you're not pretending to have some other motivation. Go was designed for new devs (per pike, i dont think kernighan ever

This is so condescending, but I'm glad you're not pretending to have some other motivation. Go was designed for new devs (per pike, i dont think kernighan ever said this) and that is good for all devs, even those with overinflated egos. Making your software easy to understand and think about is good, and effective engineers will get more done working with simple code than complex code that memorializes their useless brainpower.

didntcheck 3y ago
Don't shoot the messenger, the condescension is Go and Pike's. He pretty much explicitly said he wrote Go to solve the problem of programmers who he considered too stupid to program anything else properly, and his behaviour (both in personal conduct and decision making) has continued this trend of treating his users like idiot sheep who can't be trusted with any language features much beyond 80s imperative programming. It all feels a bit "old man spiteful at kids these days"
- trane_project 3y ago
  Rob Pike once told me I was a moron (not those exact words) but that intent when I asked a question in some performance Golang slack about how big a Golang map is in memory (as in the total bytes used by it internally). He went to a previous commit from the one I had linked, saw my stupid attempt at estimating it, and proceeded to go on a rant in which he simultaneously called me an idiot and pointed to the answers in the runtime code. Pretty entertaining. Of course, the code was stupid because I wrote it knowingly so, just so I could fill the function with compilable code and go debug something else. I guess not writing a comment is on me for not knowing Rob Pike was going to go out of his way to find it the next day. Fun day at the office, that one. So yeah, I am not the greatest fan of Go or him either. But that was from way before when I had to write a JSON-LD parsing library and cast stuff to `interface{}` everywhere. I write personal stuff in Rust now, but would happily do it in any other language with a proper toolchain and type system. Go has only one of those, so I don't dislike it. Just don't really enjoy it.
- philosopher1234 3y ago
  The Rob Pike quote is accurate and not condescending. If it bristles your feathers, I think that may have more to do with your ego than Rob pike.
  - jjtheblunt 3y ago
    That’s a curious assertion in that oft maligned quote. I agree that it’s not meant to be condescending. Go is very much AT&T Limbo from plan 9, with loose ends wrapped up and refined on Google’s dime, since Google brought Bell Labs people and their projects to Google, and the quote is therefore a purposefully misleading retrofitting of a history and design predating any concern about noob hires at Google.
    - jjtheblunt 3y ago
      p.s. (since i can't edit) Go compiles to native instead of to a vm like Limbo did. evolution of the idea...
dcow 3y ago
There’s a time and place for everything. Not everyone works on a corporate team needing to KISS their software to death because they probably won’t even be working on it 18 months later. Software is a creative expression for some people, and useless brainpower for you. I’m not one to judge.
elromulous 3y ago
Speaking of overinflated egos. While there's no question pike, thompson, and k are a cut above, I think they made assumptions that engineers cannot be trusted. Garbage collection is another such example. Compare that to e.g. rust's model which hoists the understanding of lifetime to the engineer, while encumbering the compiler with the dirty work. Whereas golang asks the engineer to do neither (granted golang came later, so maybe they didn't think it was possible).
- Yasuraka 3y ago
  Even if they can be trusted (I wouldn't trust myself), GC is a big time saver and I'd say well worth the trade-off. There's far more performance to be had elsewhere (compiler) but wherever that's or manual memory management is needed, there is a language to fit that need.
- throwaway894345 3y ago
  This seems like a silly argument. By the same token, we can argue that Rust doesn’t think engineers can be trusted because it pushes a bunch of type and memory safety onto the compiler instead of letting the engineers manage it as their ancestors did. Of course, they were right to do so—we shouldn’t trust engineers with all of these tedious, error-prone processes. And while Rust solves for memory safety with borrow checking, that turns out to be a pretty limited solution from a productivity perspective (or at least that seems to be the majority opinion among people who have extensive experience with both languages) compared to borrow checkers—sometimes it’s appropriate to trade productivity for performance/correctness, but many times it isn’t.
- cube2222 3y ago
  The languages target different use-cases and rusts ownership model does indeed slow you down vs not having to think about it at all. Esp. closures, which Go uses a lot all over the place, are quite cumbersome in Rust. (I like both languages a lot)
  - chlorion 3y ago
    I'm not sure what you mean by closures being cumbersome in rust. Rust uses closures very heavily, for things like iterators, spawning threads, async tasks, and lots of other things. I've never felt them to be cumbersome at all. Actually, for me, closures in rust are easier to use than in any other language I have used besides for various lisps! https://doc.rust-lang.org/book/ch13-01-closures.html https://doc.rust-lang.org/book/ch13-01-closures.html

didntcheck 3y ago

Don't shoot the messenger, the condescension is Go and Pike's. He pretty much explicitly said he wrote Go to solve the problem of programmers who he considered too stupid to program anything else properly, and his behaviour (both in personal conduct and decision making) has continued this trend of treating his users like idiot sheep who can't be trusted with any language features much beyond 80s imperative programming. It all feels a bit "old man spiteful at kids these days"

trane_project 3y ago
Rob Pike once told me I was a moron (not those exact words) but that intent when I asked a question in some performance Golang slack about how big a Golang map is in memory (as in the total bytes used by it internally). He went to a previous commit from the one I had linked, saw my stupid attempt at estimating it, and proceeded to go on a rant in which he simultaneously called me an idiot and pointed to the answers in the runtime code. Pretty entertaining. Of course, the code was stupid because I wrote it knowingly so, just so I could fill the function with compilable code and go debug something else. I guess not writing a comment is on me for not knowing Rob Pike was going to go out of his way to find it the next day. Fun day at the office, that one. So yeah, I am not the greatest fan of Go or him either. But that was from way before when I had to write a JSON-LD parsing library and cast stuff to `interface{}` everywhere. I write personal stuff in Rust now, but would happily do it in any other language with a proper toolchain and type system. Go has only one of those, so I don't dislike it. Just don't really enjoy it.
philosopher1234 3y ago
The Rob Pike quote is accurate and not condescending. If it bristles your feathers, I think that may have more to do with your ego than Rob pike.
- jjtheblunt 3y ago
  That’s a curious assertion in that oft maligned quote. I agree that it’s not meant to be condescending. Go is very much AT&T Limbo from plan 9, with loose ends wrapped up and refined on Google’s dime, since Google brought Bell Labs people and their projects to Google, and the quote is therefore a purposefully misleading retrofitting of a history and design predating any concern about noob hires at Google.
  - jjtheblunt 3y ago
    p.s. (since i can't edit) Go compiles to native instead of to a vm like Limbo did. evolution of the idea...

dcow 3y ago

There’s a time and place for everything. Not everyone works on a corporate team needing to KISS their software to death because they probably won’t even be working on it 18 months later. Software is a creative expression for some people, and useless brainpower for you. I’m not one to judge.

elromulous 3y ago

Speaking of overinflated egos. While there's no question pike, thompson, and k are a cut above, I think they made assumptions that engineers cannot be trusted. Garbage collection is another such example. Compare that to e.g. rust's model which hoists the understanding of lifetime to the engineer, while encumbering the compiler with the dirty work. Whereas golang asks the engineer to do neither (granted golang came later, so maybe they didn't think it was possible).

Yasuraka 3y ago
Even if they can be trusted (I wouldn't trust myself), GC is a big time saver and I'd say well worth the trade-off. There's far more performance to be had elsewhere (compiler) but wherever that's or manual memory management is needed, there is a language to fit that need.
throwaway894345 3y ago
This seems like a silly argument. By the same token, we can argue that Rust doesn’t think engineers can be trusted because it pushes a bunch of type and memory safety onto the compiler instead of letting the engineers manage it as their ancestors did. Of course, they were right to do so—we shouldn’t trust engineers with all of these tedious, error-prone processes. And while Rust solves for memory safety with borrow checking, that turns out to be a pretty limited solution from a productivity perspective (or at least that seems to be the majority opinion among people who have extensive experience with both languages) compared to borrow checkers—sometimes it’s appropriate to trade productivity for performance/correctness, but many times it isn’t.
cube2222 3y ago
The languages target different use-cases and rusts ownership model does indeed slow you down vs not having to think about it at all. Esp. closures, which Go uses a lot all over the place, are quite cumbersome in Rust. (I like both languages a lot)
- chlorion 3y ago
  I'm not sure what you mean by closures being cumbersome in rust. Rust uses closures very heavily, for things like iterators, spawning threads, async tasks, and lots of other things. I've never felt them to be cumbersome at all. Actually, for me, closures in rust are easier to use than in any other language I have used besides for various lisps! https://doc.rust-lang.org/book/ch13-01-closures.html https://doc.rust-lang.org/book/ch13-01-closures.html