Hacker News new | past | comments | ask | show | jobs | submit login

> And yet it still feels like a language out of the 60s or 70s.

Lisp is from that era and is far more poweful.

> To me, Go feels like the programming language equivalent of insisting that everyone communicate just by grunting

This is fair. I mean, Go is outright _primitive_. The most notorious things about the language itself: are Goroutines, channels and the interfaces. This is why there is so much discussion around, for instance, Generics. Noone really "wants" Generics. Instead, they just need to not repeat themselves. There are very few ways to work around issues in the language itself.

Another issue is that, if a library implements something in a way that doesn't suit you, or you need to add extra behavior, you are out of luck. Say you want to add distributed tracing to code that's not owned by you (even if writting in your company). You'll have to track down people, you cannot "annotate" your way as other languages can.

That said, the fact that it is mind-numbly dumb can be a feature. Everything is damn obvious. Error handlers? Staring at you in the face like the sore thumb they are supposed to be. You can't even get too fancy with 'design patterns', just go write the function you need to solve your problem and stop reading that gang of four book.

They are fixing the Go modules mess, which is one of the last pieces of the ecosystem. No "coding standards" document – it is whatever go fmt and the go compiler says it is. Lots of trivial things are errors (like unused variables), which helps keep the codebase sane. The ecosystem and toolset are great (I feel like Rust learned from Go and improved on it).

Go has to be compared with alternatives. Rust? Awesome language, but slightly different niche with a far higher learning curve. Java? Please. C or C++? They are the opposite of simple (C is a larger language, but with far more baggage, don't get me started on C++). I can't include Python and ilk as their purpose is completely different, although for things like backends both could be used.

What else could we use to write Docker or Kubernetes, that would be more expressive, and still learnable in a weekend?

> There must be a golden balance here

I would argue that Go has not nailed it completely, but it is in the ballpark.






> Java? Please.

Please elaborate.

> I can't include Python and ilk as their purpose is completely different, although for things like backends both could be used.

Yet, many real world sysadmin programs formerly written in Python are now written in Go. Go's compilation to a single statically linked binary, and tool support for easy cross-compilation makes it popular for these usecases. And when many people say "Go is blazingly fast!" they compare it to Python.

> What else could we use to write Docker or Kubernetes

Borg, I think, was written in Java at Google.


Borg is mostly C++

Lots of trivial things are errors (like unused variables)

My learning experience with Go ended when I happened upon this. Unused variables aren't even worth a warning, and yet it is absolutely impossible to get around them in Go.

Maybe it's just my style, but I like to start out code with methods and variables in rough outline, and then build it from there. If a language makes that impossible well...there are other languages. Also, I didn't want to learn what other doozies Go had in store if they made that kind of stupid nanny issue a categorical imperative.


And that's a fine style to have - as long as they're not left behind when you commit them. Go is a bit painful in this regard, but it's targeted at maintainability by large teams over a long period of time, sacrificing local developer ergonomics in the process.

I mean I wouldn't object to it being a bit more forgiving in some instances, as long as it's as anal as can be when you commit some work and / or share it with others.

Of course, it's an open source project so in theory the unused variable check can be disabled.


Fast forward to someone maintaining your code full of empty method stubs and unused variables because "that's my style".

Housekeeping and maintainability are important.

can't you just comment them out?

_ = myUnusedVar

Done.




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

Search: