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

251–260 of 291 posts

Re: Eight years of Go

#251

Post by weberc2 »

foldr wrote: post #188
weberc2 wrote: post #48

Earlier quoted context omitted.

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.

I don't think there is a technical reason. It's probably not something they'll do for a while because it probably requires some significant reorganization of the compiler and making a passably fast implementation is probably quite hard (the Go community places a premium on fast compiler times, rightly or wrongly). Also they seem to value predictable optimizations. Not sure how keen they would be to add an optimization that works until a seemingly inoccuous code change prevents the compiler from guaranteeing that all elements in the slice have the same concrete type, making performance (probably) significantly worse.

Again, I don't necessarily agree with the Go team; I'm just guessing the are some of the concerns they're weighing.

Re: Eight years of Go

#252

Post by fithisux »

I use golang since 2010. My only complaint is that they dropped gxui. So I use golang mainly for cli utilities. The other options (I do not like javascript) are ill-maintained. For me it is more important than generics.

Re: Eight years of Go

#253

Post by mrep »

indescions_2017 wrote: post #45

> every single cloud company has critical components of their cloud infrastructure implemented in Go And this is how the "network effect" propagates. As the customers of cloud services also begin to experiment in Golang. And discover the holistic ecosystem of distributed systems packages. Even Blizzard with its massive C++ codebase is gaining converts https://youtu.be/Az5F4lwSljI?t=23m50s

That source just mentioned a few popular open source projects and provided no sources citing actual cloud providers using it in their backend infrastructure.

Re: Eight years of Go

#254

Post by AnIdiotOnTheNet »

TheDong wrote: post #228
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.

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

I am admittedly thinking of an interface from how they work in Java, so I may be making incorrect assumptions about how they work in Go, but wouldn't I have to do that anyway? In what sense can the compiler work out how I want to compare my types? If I hand it some vec3s, for instance, does it know I want them sorted by x value, or by length?

By defining an interface that assures the compiler each type has a compare(x) method, I can write a generic sort function that takes any two comparable objects and sorts them based on whatever the class of those objects decided was the ordering criteria.

Re: Eight years of Go

#255

Post by simon_o »

geoka9 wrote: post #231
simon_o wrote: post #130

Earlier quoted context omitted.

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}`.

> The last two options are not idiomatic Go.

Who are the authors of https://golang.org/pkg/io again?

Yeah, 90% of Go devs agree with you.

10% think it is a really great idea.

So you can never be sure without reading the documentation.

Re: Eight years of Go

#256

Post by peoplewindow »

ziotom78 wrote: post #242
rifung wrote: post #75

Earlier quoted context omitted.

I write Go at work but have never heard anyone say this. Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?

Not the OP, but here are my 2¢. Introducing generics in a language implies a deep revision of the type system, which risks to become much more complex to understand. Moreover, this might have a bad impact on compilation performance (compare C++ compilation times with Go compilation times and you'll understand what I mean).

C++ compile times are huge for many reasons, but templates are only one of them. And note that templates aren't the same thing as generics.

Java has near-instant compile times and has generics. Likewise for Kotlin. Generics don't have to mean slow compiles.

Re: Eight years of Go

#257

Post by peoplewindow »

qznc wrote: post #243
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.

I hear people praise the Java ecosystem so often, but when I use it I cannot replicate that. There is nothing like Django in Java land? Instead you are sent into a confusing mess of interface standards like JPA and implementations (hibernate, ebeans, ...) and little guidance how to choose.

Equivalent of Django would be something like Spring Boot, Play Framework etc.

It's quite common that some of these frameworks rely on community infrastructure that has several competing implementations, like JPA, but the point of a tool like Boot is that they picked all the implementations for you and documented it all centrally.

Re: Eight years of Go

#258

Post by peoplewindow »

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…

What's the big need for an AOT native EXE for you? You just don't want to copy a directory tree instead of a single file?

Re: Eight years of Go

#259

Post by peoplewindow »

dilap wrote: post #162
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.

Really? I've recently been recruited to pitch in on a Java project, they're using maven, and the compiles sure aren't incremental. What should we be using instead?

You don't normally use Maven to compile every change when doing Java projects. Your IDE will incrementally compile what's needed based on importing the Maven config. You use Maven for tasks like packaging, linting, building JavaDocs etc.

Re: Eight years of Go

#260

Post by dekhn »

yjftsjthsd-h wrote: post #183
dekhn wrote: post #83

Earlier quoted context omitted.

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.

https://blog.golang.org/survey2016-results

Note that generics is the highest requested change.

Post reply on HN