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

191–200 of 291 posts

Re: Eight years of Go

#191

Post by bsaul »

camus2 wrote: post #82
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).

> while paying much less attention to the vocal minority's complaints That's debatable. Those who can't stand the language don't bother using it,therefore don't bother complaining about it. My point is Go biggest critics have already abandoned the language long ago. Go reminds me Rails. It had a huge success 8 years ago but since all other languages have caught up when it comes to RAD webdev. The JVM and others will…

i don't think you can "catch up" with go, because it has aimed at being minimalist. catching up by removing major features to a language isn't something i've ever witnessed.

Re: Eight years of Go

#192

Post by dualogy »

terminalcommand wrote: post #90
tetraodonpuffer wrote: post #78

Earlier quoted context omitted.

> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough t…

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…

> I think that is so because Go hates circular imports.

Well it could be but I don't think so --- "duck typing" when it comes to interface{}s has been a goal from early on, quite simply. The very idea of interfaces as "a set of func signatures" preclude the necessity to verbosely spell out "struct Foo implements BinaryMarshaler" and/or "func (_ Foo) MarshalBinary implements BinaryMarshaler.MarshalBinary"!

In the same vain, you don't even need to declare interface TYPES, you can accept/pass/return "inlined" interface{MethodSig(argtype)rettype} anywhere if you want. Not the most ergonomic choice in practice, but the possibility hints at this underlying interfaces-are-duck-typed-method-sets paradigm at work here.

Re: Eight years of Go

#193

Post by dualogy »

donatj wrote: post #149
tetraodonpuffer wrote: post #78

Earlier quoted context omitted.

> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough t…

> intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough that doesn't work I've been writing Go for upwards of six years, professionally for three, and I have never tried that. I can't think of the last time I used interface{}... I generally consider anything using interface{} crap code someone who doesn't know the language wrote, probably coming from a loosely type…

> I generally consider anything using interface{} crap code someone who doesn't know the language wrote, probably coming from a loosely typed language.

Disagree. There's ample usage of interface{} that you need to type-switch on in parts of the stdlib that deal with the AST and reflection or various other areas. You might also UnmarshalJSON a structure where some field can contain any one of a number of possible sub-structures. Once we're talking about 1-2 dozens of possible sub-structures, you'll have that field be an interface{} and type-switch on it --- rather than having 1-2 dozen pointer fields that will all-but-1 be nil and having to if-else through them all.

Re: Eight years of Go

#194

Post by dualogy »

terminalcommand wrote: post #114
erik_seaberg wrote: post #98

Earlier quoted context omitted.

That's easy. Concurrent access to maps is unsafe. https://golang.org/pkg/sync/#Map should be a drop-in replacement but due to the lack of generics it can't present a compatible or typesafe API.

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?

Re: Eight years of Go

#195

Post by mioelnir »

krylon wrote: post #30
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).

You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…

> But something about is very compatible with the way my mind works.

Yes. For me it is channels. After nearly 20 years of UNIX'ish systems, pipes are a mental abstraction that I do not have to think about any more. And channels fit right in, they feel much closer to a how a pipe is used on the cli than a pipe or socketpair ever did in code.

For example a range loop over a closed channel is, for me, piping things to xargs. It's easy to understand, reason and conceptualize because it feels familiar.

Re: Eight years of Go

#196

Post by mattmanser »

tqkxzugoaupvwqr wrote: post #89
solox3 wrote: post #4

Earlier quoted context omitted.

Novice here. Why is having no exceptions a good thing, in your opinion?

In Go’s philosophy most problems are not exceptional. File can’t be opened? This is to be expected on systems with file permissions. The common pattern is for functions to return an error type as last return argument (Go supports returning multiple arguments). Programmers can then handle the problem right then and there if the error is not nil. This approach also helps to keep control flow straight forward. The happy…

It's actually pretty common for a file exception to be exceptional.

In all programs I've ever worked on you don't want to have to check useless junk like that and just want the general exception handler to handle it.

Re: Eight years of Go

#197

Post by Karupan »

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

And yet pip has just worked for me. Can’t say the same about any of the go dep tools.

Re: Eight years of Go

#198

Post by noncoml »

valarauca1 wrote: post #166
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)…

>Actually (5) is one of the few things I don’t like about Haskell. Haskell has exceptions FYI https://wiki.haskell.org/Exception

Yes, that's what I say I don't like. Sorry for not making myself clear.

Re: Eight years of Go

#199

Post by spc476 »

cube2222 wrote: post #136
brian-armstrong wrote: post #110

Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances: - Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works. - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered. - No easy way to construct arenas/pools…

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…

Wow! My network daemon at work, written in Lua (which uses Lua coroutines for processing, which are similar enough to Go routines/channels for this comparison) has a supervision tree. It can log the unexpected death of Lua coroutines and keep going, which is nice for the unexpected bit of input [1]. It's also helpful when testing new code as unexpected errors are logged (stack dump, so the location of the crash is reported) in development/QA.

[1] Yeah yeah, all input should be well specified. Could you please inform the vendors that their programs are spewing unspecified crap at me? Thanks.

Re: Eight years of Go

#200

Post by tedunangst »

steveklabnik wrote: post #172
nine_k wrote: post #168

Earlier quoted context omitted.

I suspect that Rob Pike's and Russ Cox's work is paid for by Google. But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.

We’ve actually worked a lot to ensure that Mozilla can’t dictate what happens with Rust; we run a consensus based process, and while Mozilla has the largest single group of people involved in leadership, it’s still a very stark minority. As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.

I wonder if this is good or bad. Sometimes it helps to have that singular vision. I think here of all the systems C coders I know, who have never used complex numbers, yet that finds its way into the standard.
Post reply on HN