Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eight years of Go

blog.golang.org

Post reply on HN
Print view View original

221–230 of 291 posts

Re: Eight years of Go

#221

Post by hliyan »

feelin_googley wrote: post #219
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

"... trivial deployment, etc.)..." Does this refer to static binaries? What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them. Were there many complaints about the absence of shared libraries originally? Whenever I have mentioned the benefits of compiling C progra…

The deployment time benefits of static binaries far outweigh the resource saving benefits of dynamic linking. I'm speaking from experience with C++. There is also a latency boost for high CPU intensive processes.

Re: Eight years of Go

#222

Post by mfrw »

mfrw wrote: post #88

Simplicity is the Ultimate form of sophistication -- Leonardo da Vinci The quote fits perfectly for the design of go.

I agree with all of you, but when I compare go with C++/Java, go turns out to be very simple.

Re: Eight years of Go

#223

Post by terminalcommand »

dualogy wrote: post #194
terminalcommand wrote: post #114

Earlier quoted context omitted.

I've run into concurrency problems using maps while writing an irc client. It was really frustrating for me, because it did not happen everytime I ran the program, but rather rarely. I had chosen Go for it's memory-safety and easy concurrency. But I felt like I could not vouch for my program's safety any more. I did not know about sync/map at the time, had I known, I would probably have used it. I think Golang has a…

> I did not know about sync/map at the time Apparently also not about sync.Mutex =) > if you want to use an interface you just have to implement all it's properties You surely mean "methods" --- don't interfaces work like that everywhere they exist?

I discovered Waitgroups during the project, but I have no formal training in concurrent programming, so it was a bit daunting for me. And as the error occured very rarely I could not be sure if using a mutex had solved my problem. But now I understand mutex was the way to go for accessing a shared resource.

As for the second point, sorry for the wrong wording, I meant "methods". But interfaces don't work like that everywhere they exist. For example in Java you explicitly use Class X implements Y, and if you do not implement all methods and properties, the compiler complains.

Re: Eight years of Go

#224

Post by dvlsg »

simon_o wrote: post #130
atmosx wrote: post #32

Earlier quoted context omitted.

I’ve read the first article. It was eye opening, cause I am writing a bot right now and using exceptions to control input flow. Made me think about my design. That said, it does not argue against exceptions. So, I am not sure what your argument is.

Exceptions are bad outside the "your computer just started burning" cases, but Go has replaced them with something even worse, "multiple return values". So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options: - ( value, no error) - (no value, error) - ( value, error) - (no value, no error) An…

Feels like Javascript callback error handling. Which was not much fun.

Re: Eight years of Go

#225

Post by geoka9 »

dansouzaio wrote: post #201
terminalcommand wrote: post #90

Earlier quoted context omitted.

IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies. And as there is no way to immediately see w…

> And as there is no way to immediately see where some interface is declared and if/which interface is implemented you can use go-oracle ( https://camo.githubusercontent.com/3fb1d62bbc7b1306da783f395... that!

It's now called Go Guru:

https://docs.google.com/document/d/1_Y9xCEMj5S-7rv2ooHpZNH15...

Re: Eight years of Go

#226

Post by fulafel »

nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

Another take, from the Bell Labs POV:

Go is an example of how to be extremely successful by inventing Unix and then going obscure for 30 years doing stuff like Inferno and Plan 9, and making a comeback when Google shows up.

Re: Eight years of Go

#227

Post by pjmlp »

nine_k wrote: post #202
pjmlp wrote: post #147

Earlier quoted context omitted.

> Looking at the adoption figures, they seem to be right. Not really, for me Go is a bit like JavaScript. I have to deal with Go thanks to Docker and K8s, doesn't mean I would use it when given the option.

Would you rather have them use C++? In this regard, Go is a lesser evil.

Yes, as long as it was modern C++, not C compiled with C++ compiler.

Or any modern natively compiled language.

Re: Eight years of Go

#228

Post by TheDong »

AnIdiotOnTheNet wrote: post #29
hood_syntax wrote: post #13

Earlier quoted context omitted.

Are the complaints about lack of generics really a minority thing? Writing separate functions to sort different types just strikes me as ridiculous. EDIT: My original tone was a bit nasty in retrospect. Did a little research and while I still am on the generics side, the current situation seems at least workable for a good number of use cases.

Yes, it is minor. Go has interfaces, so you just write a Comparer interface and sorter that takes two Comparers and then anything implementing Comparer is sortable. *Note: author has written basically nothing in Go and only has a passing familiarity.

So you define the Comparer interface with a Compare method. What does it look like?

If I have a struct X, then I might write it as:

    interface Comparer {
        Compare(other X)
    }
But wait, now I have to define a new interface for every type since "Compare" takes the type X in its signature so it doesn't work for type Y... If only I could define an interface that was for an unknown type T and then Compare was for that.

But that's exactly what generics are.

You know how Java has .equals? Go doesn't have an equivalent concept. Test code is neigh unreadable because there is no generic way to compare two structs of the same type. This is a similar problem.

Re: Eight years of Go

#229

Post by Santosh83 »

feelin_googley wrote: post #219
nine_k wrote: post #7

Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).

"... trivial deployment, etc.)..." Does this refer to static binaries? What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them. Were there many complaints about the absence of shared libraries originally? Whenever I have mentioned the benefits of compiling C progra…

Security: they need to be updated in one place instead a hundred different places.

Re: Eight years of Go

#230

Post by hikarudo »

cturner wrote: post #181
shkkmo wrote: post #62

Go's biggest issues still seems to be the lack of a standard mature dependency management system.

Could it be a strange mindset of our time that we look to language ecosystems to provide this? What if we could manage dependencies without being locked into language? Conda goes some way. Think of something like virtualenv, but not specific to python. I would be happier with something that had fewer features than conda, but where critical features were easier. Example: setting up a package server should be trivial.…

How about Nix, could it be the 'virtualenv, but not specific to python' you mentioned? I've never used it, but from what I understand that would be an appropriate description of Nix.
Post reply on HN