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

181–190 of 291 posts

Re: Eight years of Go

#181

Post by cturner »

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.

I think we do not yet have the git of dependency systems, with the gravity to draw in the community and for people to regard it a solved problem. Maybe the most efficient route would be: find a way to get Linus pissed off about it.

Re: Eight years of Go

#182

Post by wbl »

kjksf wrote: post #159
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…

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#).

But I can't implement a drop in compatible concurrency safe map.

Re: Eight years of Go

#183

Post by yjftsjthsd-h »

dekhn wrote: post #83
tqkxzugoaupvwqr wrote: post #68

Earlier quoted context omitted.

How do you know? Anyone who is not interested in generics simply abstains from these discussions/polls. This skews perception.

because people at my company collect data on this.

Could you expand in this? Like, if there's somebody surveying what programmers want as a population, that's pretty cool.

Re: Eight years of Go

#184

Post by Groxx »

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).

Survivorship bias would explain this pretty succinctly.

Re: Eight years of Go

#185

Post by Groxx »

pmoriarty wrote: post #55
wheaties wrote: post #44

Earlier quoted context omitted.

The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.

Python's packaging is a nightmare of half-baked, incompatible approaches that puts the lie to the famous "Zen of Python" that "There should be one-- and preferably only one --obvious way to do it."

Agreed on the packaging side, but the python community / existing libs (the entire rest of the ecosystem) is miles ahead of Go's at this point.

Re: Eight years of Go

#186

Post by cube2222 »

slrz wrote: post #164
terminalcommand wrote: post #133

Earlier quoted context omitted.

How do you jump to the interface from any structure implementing it? Beside from comments there is no immediate way to which interface/interfaces a structure is implementing. Maybe Gogland solves this by keeping records on all interfaces, and checking all structures whether they satisfy them. If that's the case, this is definitely solved by tooling.

The standard godoc documentation browser does this too when started with the -analysis option. They all use the same source code oracle functionality available from the x/tools repo.

No, Goland actually doesn't use that, they're rolling their own for everything.

Re: Eight years of Go

#187

Post by cube2222 »

dozzie wrote: post #179
cube2222 wrote: post #136

Earlier quoted context omitted.

Why would you want a supervision tree? This would suggest using an actor-like model, which is pretty senseless for single-machine usage. It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash". I'm not sure, but I think this also ends up being good for modelling interactions with good performance…

> It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash". Supervision tree gives a structure to put whole subsystems somewhere, including their boot initialization and shutdown (not just restarting it at crash), allows to spawn workers while keeping usual logging/crash monitoring for free , give…

No, it's saying: if my goroutines crash it's the same as if my main thread crashed, which means: game over, application down.

Which gets handled by the container scheduler

Re: Eight years of Go

#188

Post by foldr »

weberc2 wrote: post #48
AnIdiotOnTheNet wrote: post #29

Earlier quoted context omitted.

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.

If your `Comparer` is an element type (as opposed to Go's `sort.Interface` abstraction over collections), this is going to be horribly unperformant. Suppose your `Foo` type implements `Comparer`, and you have a large `[]Foo`. Then you'll first have to iterate over each element in `[]Foo` and add it to your `[]Comparer`, probably with an allocation per element. Then each invocation of `foo.Compare()` is going to be in…

I don't see any reason why the interface lookup couldn't be done at compile time in this instance.

Re: Eight years of Go

#189

Post by cube2222 »

ryanplant-au wrote: post #163
erik_seaberg wrote: post #144

Earlier quoted context omitted.

I'd rather read x.filter().map() than read the loops someone had to expand them into by hand.

I groan every time I have to implement the 15th type-specific loop implementation of what I'd do with a single map or fold in Ruby/Elm/Haskell/JS/TS/Crystal/every other language I use. It's not a lot of effort but it's a lot of mess and cruft.

Check out goderive

Re: Eight years of Go

#190

Post by dozzie »

cube2222 wrote: post #187
dozzie wrote: post #179

Earlier quoted context omitted.

> It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash". Supervision tree gives a structure to put whole subsystems somewhere, including their boot initialization and shutdown (not just restarting it at crash), allows to spawn workers while keeping usual logging/crash monitoring for free , give…

No, it's saying: if my goroutines crash it's the same as if my main thread crashed, which means: game over, application down. Which gets handled by the container scheduler

So every unrelated request that happened to be currently processed is thrown away because of a rare corner case, and with no way to intercept shutdown and save state, flush buffers, or anything. Yes, totally right granulation.

Not to mention that you have just introduced a very complicated piece of software to run a single daemon.

Post reply on HN