Hacker News Reader

Comment by nemo1618 | Hacker News Reader

Go has one very significant advantage over Rust: Simplicity. Reading someone else's Go code is such a breath of fresh air compared to reading someone else's C++ code (or god forbid, Haskell). Having a standard formatting further enhances this. I feel like this aspect of Go is not given enough weight. It's a huge benefit to large software projects and large software companies. I also suspect that this may be why the Go team has been so conservative re: generics: If they aren't implemented carefully, they could unacceptably complicate the language.

Rust is a powerful language, but with that power comes the ability to write "fancy" code -- esoteric, unreadable, and unmaintainable.

View on HN

In my experience working with new and experienced Go developers that simplicity is pretty superficial.

Take a look at SliceTricks[0]. These are all pretty simple operations in other languages that the Go authors think users should be forced to write manually so they understand the costs. Reading these in code reviews is definitely not a breath of fresh air.

I also see Go users develop bad habits that will burn them in other languages, like returning a reference to a "stack" allocated variable. In the same vein, if you care about performance you have to internalize the escape analysis rules, which most new users won't know about.

There are tons of footguns[1] in Golang as well. I constantly see people get burned by issues at runtime. I truly believe that the Golang benefits are short-sighted. You get some upfront development gains that you end up pain for with less reliable software. I personally would rather pain that cost upfront where possible with the compiler telling me when something is wrong.

[0] https://github.com/golang/go/wiki/SliceTricks [1] http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in...

Go is just the current incarnation of the so-called New Jersey approach.

> I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing.

> re: generics: If they aren't implemented carefully, they could unacceptably complicate the language.

Can you explain why?

For example, simple generics which could be implemented as regex doesn't seem to complicated? Am I missing something?

For example (in Java), an ArrayList <String> could be turned into a StringArrayList by a basic internal pre-processor.

How do you handle error messages? Can you make functions, methods or their parameters generic? Can you dynamically link generics?

Reply on news.ycombinator.com