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

161–170 of 291 posts

Re: Eight years of Go

#161

Post by weberc2 »

AnIdiotOnTheNet wrote: post #73
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…

From this description, I'm getting the impression that Go's interfaces are not as much like Java interfaces as I had assumed. Never the less, I find that generics usually are just an over-engineered solution to any given problem.

The primary differences (I think) are that everything in Java is already a pointer, so there isn't an extra alloc to make an interface. The same is true in Go if your comparables are all pointers. Probably the more significant difference is that Java has a JIT compiler, which may be able to inline all of those calls to Compare(). This is largely why Go's `sort` package abstracts over the collection, not over the element.

Re: Eight years of Go

#162

Post by dilap »

MrBuddyCasino wrote: post #19
kown223 wrote: post #12

For me Go is amazing, is my first language where I don't need a virtual machine or interpreter to compile to machine code, C++ is OK but not for day to day web. Changing something then having to wait 40 seconds for java to recompile drive me crazy, also same for tests. Yes would love to have a package system, but is coming.

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?

Re: Eight years of Go

#163

Post by ryanplant-au »

erik_seaberg wrote: post #144
jopsen wrote: post #101

Earlier quoted context omitted.

Yeah, I wish go had more functional stuff, like .map(), .filter(), etc. On the other hand I enjoy that when I pickup a package someone wrote there is not a bunch of different meta-programming using templates. Generics sometimes lead people (including myself) to over-engineer solutions... usually because we want as much compile safety as possible. But at what cost in complexity.

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.

Re: Eight years of Go

#164

Post by slrz »

terminalcommand wrote: post #133
cube2222 wrote: post #122

Earlier quoted context omitted.

I actually experienced the opposite. Interfaces in go work so well, partly because you can create an interface which automatically gets satisfied by existing structures. For example I often use a requestDoer interface which only has the http clients "Do" method. I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling. The structurally typed in…

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.

Re: Eight years of Go

#165

Post by garfij »

pcwalton wrote: post #60
nine_k wrote: post #14

Earlier quoted context omitted.

For exceptional, unforeseen situations you do have exceptions, aka "panic". For signaling error conditions that the caller has to expect and handle, you have the `result, err = func(...)` idiom, and a compiler that would warn you if you forget to use the value of `err`. If Rob Pike's opinion on this is not enough, here's Martin Fowler saying essentially the same thing: https://martinfowler.com/articles/replaceThrowWi…

Go does not warn you if you forget to handle an error. It only does so if the function in question also returned a value that you're using. There exist important functions that don't return non-error values and report errors that you very much would like to avoid dropping on the floor: os.Chdir() for example.

While this is technically true, I've considered `errcheck` to be standard tooling for what feels like forever now, and it does exactly this; make sure you're checking your errors.

Re: Eight years of Go

#166

Post by valarauca1 »

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

Re: Eight years of Go

#167

Post by sanderjd »

misframer wrote: post #24
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.

I've been using Go at work and for my personal projects for over 4.5 years. I rarely have to sort. It's not a big deal for me.

It's not about sorting, it's about every single abstract operation on a collection or other type of container. You either have to use primitives, or reimplement everything yourself on each new type. Most people just use primitives. This proliferation of primitives is what I actually dislike about reading and writing code in Go, but it's caused by not having a way to define abstract data types that work well.

Re: Eight years of Go

#168

Post by nine_k »

coldtea wrote: post #151
nine_k wrote: post #58

Earlier quoted context omitted.

I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Also, let's not forget that Go is created at Google, and definitely Google's…

> I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first. Many large users writing in company and project blogs have mentioned lack…

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.

Re: Eight years of Go

#170

Post by skybrian »

coldtea wrote: post #153
freyir wrote: post #72

Earlier quoted context omitted.

It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that. But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.

> Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority. And many more want Generics without having responded to the issue. Issues are representative as a sampling, not absolute numbers.

Unless you do random sampling, you still can't conclude anything one way or the other about whether it's a majority of users. Perhaps something like Google Surveys could be used to settle this?
Post reply on HN