Live data from Hacker News

Ask HN: Go programming language is over ten years old. What do you think of it?

news.ycombinator.com

181–190 of 310 posts

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#182

Great tool, two big negatives. First, checking result values is dumb. It adds 50% more code. Add exception handling. Second, the way imports work is obviously due to some internal google kitschy-ness. Remote import paths are so dumb. People set up entire domains and CDN's just to host some code. The import path has to have a specific format, you can't have three levels. github.com/me/sub1/module won't work, so everyo…

Your first negative is a matter of perspective, so depending upon your coding preferences you may be right.

For me personally, even with nearly 2 decades of C# (exceptions are used extensively) I prefer the Go way. Checking results values is not dumb, it's just not the way that suits you. And that's fine. Variety of preference is one of the reasons we have so many programming languages to choose from.

As for modules, despite extensive familiarity with packaging systems (nuget, npm, etc) I prefer the Go way. The import path is totally developer-defined (eg "github.com/russross/blackfriday/v2" which is three levels), and a single line in a Go module file redirects a repo import to your local development copy (by local folder location).

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#183
I find it tedious to work in, for a bunch of reasons. The docs suck. Packaging stuff keeps changing. The idea of “simplicity” that’s really just about ignoring complexity in one area so that other areas are forced to deal with it. The tools are crappy and unfriendly. The whole ecosystem just has this vibe of “ehh, deal with it ”.

I worked on a big project this year which was my first time using golang seriously. I’d rather not use it again if I have a choice in the matter.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#184

They set out to make a pretty generic ALGOL/C-ish/Java "OO"ish language with sharp corners filed off and some decent concurrency primitives put in. They executed successfully (they got the language out there, built an ecosystem, didn't undermine their own goal in the language design or make it unusable.) If I had to choose between Go and C++, I'd probably pick Go because of C++'s complexity, so they really nailed it.…

> In the grand scheme of things, it's a really forgettable language.

Strangely enough, for me that is one of the major plus points. A forgettable language (which is not the same as a language which you forget how to use) is one which gives you the tools for the job and then gets out of the way.

Some other languages feel like prima donnas with their shiny brilliance and complex possibilities. I'll take a small, dirty, simple, and performant back-seat one like Go every time.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#185
post #54

It was a large mistake to ignore the lessons of Java and now the language is full of quirks as well, including the upcoming generics design. Regardless of the whole systems programming language polemic from the anti-GC crowd, several projects deployed into production like gVisor and TamaGo prove otherwise. Finally thanks to killer applications like Docker, Kubernetes and everything around them, Go has become unavoida…

> several projects deployed into production like gVisor and TamaGo prove otherwise Do they? AFAIK gVisor absolutely had to fight with Go, and it has a huge performance impact, and lots of larger projects have done some semi-absurd work such as implementing their own generics impl via preprocessors.

Just like C then.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#186

Earlier quoted context omitted.

I think most Go people will put most anything that goes over the wire into some protocol description language like protobuf or even swagger. Inside your call stack I am not sure you need enums instead of constants. If you are either persisting or transmitting data then you want some formal description which will essentially get you enums as useful symbolic values.

Lack of real enums is one of my biggest annoyances with Go. So so many times I've put the wrong enum value in because it's just an int and it matches another set of enums. I've taken to putting each set of enums into a separate file and separate folder just to help the compiler catch this. The project I'm working on now has about 25 separate enum files+folders. Gagh!

I made this playground: https://play.golang.org/p/S1Yh0Oq24q-

There are a ways to do unique enums with implicit repetition. Like this: I 0 1 2 II 101 102 103 III 201 202 203 IV 10 20 40 80

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#188
post #49

More and more, when looking for (open source) software solutions to adopt for my startup, Go as a development language is a deciding factor. Go-based software is smaller, faster, easier to deploy, easier to update, easier to contribute to. I find that the installation footprint of a Go-based service is usually in the 10s of megabytes or less, where the installation footprint of pretty much anything else starts in the…

Fast compilation was one of the main reasons Golang was invented.

The gradual accumulation of #include clauses in C programs scales very badly. A large distributed compilation system was created in Google to handle the slow compilation. One reason is you never know if some #include is actually needed.

In Golang unused dependencies are a compile-time error. The generated object file includes type information for all related import dependencies in binary format. This speeds up the compilation significantly.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#190
After disliking it for 6-7 years, because it doesn't offer the amount of abstraction that others languages offer (Scala, Haskell, Java), Go has grown on me.

I got too caught up in designing elaborate abstractions in those languages. I couldn't avoid it either, since other libraries would also use elaborate abstractions.

With Go, I just write plain dull code, against a suite of good dull libraries. Ultimately I spend less time writing programs (typically internet services) in Go than other languages.

Post reply on HN