Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I doubt this is true in any objective sense. "issues" above is almost certainly subjective, and I don't think even in this particular case it's so much "how Google does it" as much as "Google isn't prioritizing limited Go-team resources to this issue right now".

In general, I've been very happy with Go's design for the last decade with relatively few, relatively minor exceptions. I specifically have enjoyed that the Go team has resisted demands from the wider community to add every feature that every other programming language has support for. Biasing toward minimalism has made the language very easy to learn and consequently any Go programmer can jump into any Go project and start being productive in a matter of minutes, and any non-Go programmer can be productive in a matter of hours. Similarly, the tooling is novel in that it has sane defaults (static, native compilation; testing out of the box; profiling out of the box; build tooling out of the box; reproducible package management and hosting out of the box; documentation generation and hosting out of the box; etc).



I guess following Turbo Pascal and Delphi tooling might feel novel to those that never used it.


The pedants among us might prefer: "novel among mainstream programming languages of the 21st century which predated Go".


Pity that even Limbo from 20th century was more feature rich than Go.


Pity that people still argue as though "feature rich" is some unmitigated good. :)


If it wasn't, Go wouldn't have gotten newer features.


Obviously this isn't true, it only indicates that Go didn't pick exactly the right set of features at inception (and of course, no one claimed it did).


Or the juice was worth the squeeze?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: