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

231–240 of 291 posts

Re: Eight years of Go

#231

Post by geoka9 »

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…

The last two options are not idiomatic Go. (zero, err) and (nonZero, nil) are. So the error check is almost always a simple `if err != nil {return err}`.

Re: Eight years of Go

#232

Post by zkomp »

noncoml wrote: post #2

Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…

Heh, that is fun: the thing I hate about go is immature very varied stdlib quality, leading to even more varied ecosystem.

Rust seems on the right path, go ... well do you even have package management after 8 years? No..

What other systems do you compare it with? Its not the best I guarantee it...

Re: Eight years of Go

#233

Post by weberc2 »

jackmott wrote: post #157
weberc2 wrote: post #53

Earlier quoted context omitted.

> by far most of the Go developers still prefer to use the language without generics I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.

yes, but those of us who would desperately like to use Go because there are vanishingly few GC languages that compile to native exe AOT, won't because of no generics. So it is a bit of a tautology. How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much be…

To be clear, I agree with you. I was just responding to the OP's claim that the Go community overwhelmingly rejects generics with my perception that at most 60% of the community feels that way. I am very much in favor of generics.

Re: Eight years of Go

#234

Post by closeparen »

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 Go community mostly deploys network server daemons to its own datacenter infrastructure. C and systems programming in general also target end-user devices, where it isn't the programmer's memory to spend.

The open-source community already has a mature ecosystem for dealing with shared libraries via package managers and distro maintainers. In a company's proprietary backend it's almost certainly cheaper to throw memory at the problem than to spend engineer time crafting and maintaining a coherent/compatible set of packages for its various backend services.

Re: Eight years of Go

#235

Post by fauigerzigerk »

terminalcommand wrote: post #223
dualogy wrote: post #194

Earlier quoted context omitted.

> 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 ev…

Java interfaces don't have properties either (nor do Java classes), and you can explicitly state interface conformance in Go as well as others have explained elsewhere in this debate: https://news.ycombinator.com/item?id=15672619

What Java does have (since 8) is default method implementations in interfaces.

Re: Eight years of Go

#236

Post by tonyedgecombe »

mohaine wrote: post #40
tonyedgecombe wrote: post #6

Earlier quoted context omitted.

Lack of exceptions is the main reason I won't use it.

I thought this as for a long time. Then I used go for awhile and I think I like the go way better. It solves the issues I had with execptionless languages without all the noise. With exceptions you most often just let them trickle up the call chain, which is the same thing you often do with err, just return it. And the returning the err works much better when doing async. Cross thread exceptions are a PITA and you ar…

I thought this as for a long time.

I have tried Go and worked with languages without exceptions in the past. The problem is the amount of error handling code I was writing time and time again. It might only be a case of returning an error but that is one more thing you need to think about instead of concentrating on the the domain.

Error handling in threads is a pain either way.

Re: Eight years of Go

#237

Post by pjmlp »

fulafel wrote: post #226
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.

Go still lacks a few goodies from Limbo, like proper dynamic loading (only kind of working on Linux currently).

Re: Eight years of Go

#238

Post by pjmlp »

kown223 wrote: post #33
MrBuddyCasino wrote: post #19

Earlier quoted context omitted.

Java has some flaws, but slow compilation is not one of them. Incremental compilers are available and pretty much eliminate pauses.

I did worked with spring boot and intelijava, and I timed for a decent size project it was over 40 seconds, but I believe a lot of it was Intelijava compiling, anyway, in go is instant.

InteliJ doesn't have a built-in incremental compiler like Eclipse does.

Re: Eight years of Go

#239

Post by dualogy »

terminalcommand wrote: post #223
dualogy wrote: post #194

Earlier quoted context omitted.

> 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 ev…

> I discovered Waitgroups during the project

Don't know about your exact map use-case you had at hand, but generally speaking the Mutexes suffice for Lock()ing/Unlock()ing a resource that is accessed concurrently, whereas the WaitGroups serve usually best to just fire off a couple of parallel jobs (that don't access any shared-between-them resources) and then simply Wait() for them all to finish. No real protection from concurrent accesses in there, other than for the WaitGroup's own hidden internal counter that's used to Wait()

Of course these are the low-level sync primitives, channels are the higher-level abstraction, but the former can take you far --- sometimes the latter are the sanest/only choice of course. Especially for parallel goroutines needing to work with each other's intermediate results.

Re: Eight years of Go

#240

Post by MoOmer »

z0r wrote: post #217
kjksf wrote: post #159

Earlier quoted context omitted.

For concurrency issues, -race flag is your friend. Don't blame the language for your buggy code. Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe. In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).

go, a language which comes with many built in concurrency primitives, has chosen to leave its core datatypes thread unsafe (the magic ones with generic powers) and gives no sensible tools to remedy this with. this is one of the many ways in which it is a language hostile to its users.

Often, you don’t need concurrent types and their overhead. The sync package makes it easy to bolt on if you truly do.

It’s not as if every block is sending out each line to run in a separate goroutine. Go encourages users to share data by communicating, not communicating by sharing data [0].

On phone, sorry for syntax

    struct CMap {
        sync.RWMutex
        i int 
    }

    func (m *CMap) Inc() {
        m.RWLock()
        defer m.Unlock()
        m.i++
    }
[0]: https://blog.golang.org/share-memory-by-communicating
Post reply on HN