logoalt Hacker News

stevecoalbeartoday at 1:06 PM4 repliesview on HN

Go's full of hacks, and holds no shame over it. Zero-initialized everything, and proceeding to 'defer' instead of RAII, generic builtin types despite lack of generics (until recently), no builtin list type, slices having capacity...

This was Go's design philosophy until Rob Pike left - to do the simple thing simply and not try to be clever about it.


Replies

tialaramextoday at 1:41 PM

> no builtin list type

Wait, which thing do you mean by a "list type" ? A growable array type like Rust's Vec<T> or C++ std::vector<T> or the ArrayList type seen in several languages ?

Or do you mean a linked list type akin to C++ std::list or std::forward_list or Rust's std::collections::LinkedList ?

"List" is vague, which is appropriate if you're talking about very high level abstractions where it doesn't matter how it works and 5 gigabytes, 5 bits, 5 weeks or 5 seconds are all finite so who cares - but in the real world we usually do care.

show 2 replies
josephgtoday at 1:45 PM

It’s not simple though. The language is simpler, sure. But you pay for language simplicity with program complexity. In go, you have to write and debug a lot more code.

I don’t mind spending a few extra weeks learning a more complex language if doing so saves me months of time down the track programming and debugging. That is an excellent investment.

show 1 reply
kbolinotoday at 2:05 PM

RAII has the advantage that you can't forget to do it, but defer has the advantage that you can handle failure in ways other than panicking. Of course, in many cases (e.g. closing a file), there's generally not much you can do anyway even if you want to handle the error directly, but at least it's possible.

show 1 reply
bewareofscamstoday at 2:28 PM

More like Pike's design philosophy was "let's do some half-thought things and sabotage any current or future improvement proposal for decades to come, while gaslighting everyone that Go is good because Google and because people can't see difference between 'systems' and 'system' programming".