Hacker News Reader

Comment by philosopher1234 | Hacker News Reader

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.

View on HN

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"

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.

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.

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.

p.s. (since i can't edit) Go compiles to native instead of to a vm like Limbo did. evolution of the idea...

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.

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

> I think they made assumptions that engineers cannot be trusted.

I disagree, if you don't think engineers can be trusted, you wouldn't want to trust engineers to remember to close files or connections, you'd have some language feature to do that automatically.

C++ and Rust solved this with RAII and destructors.

In my opinion, this is on the same level as "just remember to check bounds" or "just remember to free memory".

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)

Go doesn’t have immutability or enforced synchronization, and something as simple as a read/write conflict in a map can panic. If your language (like most) has shared mutable state, you must think about ownership, and it’s better for the compiler to check your work reliably.

You must think about synchronization, really, not necessarily ownership.

What you're saying is true, but it's still not an obvious choice - there's still a tradeoff.

The (hypothetical, e.g. Rust) compiler can check only a subset of correct programs, which means that many correct programs can't be successfully checked. This is all good if it only affects edge cases, it's not that good if it affects common cases.

It additionally becomes less of an issue (in Go) if you avoid shared mutable state and use channels for complex cases.

So all in all I agree the compiler checking your synchronization is nice, but it's a tradeoff (at least for now), and with the current state of it I think most projects will be just fine without it. On the other hand, there are projects that should definitely use languages that allow for static analysis like that.

Yeah, I’m thinking of ownership as exclusive access handed off in sync, and disposal as one more duty of the final owner.

I would feel a lot more comfortable with channels if a linter would verify that every message is either mutex protected or a newly created graph (maybe a deep copy) never accessed again by the sender. Go already does some escape analysis to minimize heap allocations, but doesn’t flag a goroutine receiving nested maps or array slices that may be shared.

You’re making an argument in favor of Go: Go only makes you think about ownership in proportion to the amount of shared mutable state in your program. Many Go programs don’t have any shared mutable state and the ones that do often limit this state to a small kernel that manages the ownership details. In Rust, every single program has to deal with ownership, and the burden is proportional to that of the total amount of state in the program (not just the shared mutable bit).

Further still, “it’s better for the compiler to check your work reliably” is limited to the shared mutable state that is completely in the purview of a single process—if you have a networked resource or a file that is accessed by multiple processes, rustc won’t save you. In Go’s niche (web services, daemons, etc), this is the overwhelming majority of all state.

> networked resource or a file that is accessed by multiple processes

Leases or transactions save us in that case. Transactional memory has been offered, but hasn’t gone mainstream.

Yes, there are solutions to those problems, but the point is that rustc doesn’t force you to use them. For example, rustc will happily let you write to a file without first ensuring that the process has exclusive write access to the file. It is no safer than Go in this regard.

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

When I say closure I mean anonymous functions that capture their environment, esp. in a mutable way.

Those work fine in Rust for simple use-cases, but it gets annoying quickly.

With a garbage collected language like Go, closures can freely capture stuff, use it, and then once no closure (or any other code, fwiw) references it anymore, it gets freed.

Escape analysis and garbage collection make even more complex (like closures that outlive the scope) use cases (where lifetimes would be hell) trivial.

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.

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.

> I think they made assumptions that engineers cannot be trusted.

Having spent ~2 decades working with engineers, I'm inclined to agree... Past, present, and future self included!

Reply on news.ycombinator.com