Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

491–500 of 670 posts

Re: Toward Go 2

#491

Post by cyphar »

43224gg252 wrote: post #378
jcadam wrote: post #81

Earlier quoted context omitted.

After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library). I've mostly moved on to Clojure for p…

I've programmed scores of libraries in Go and found it pleasant, in fact it's more pleasant writing a library in Go than in any other language I've used. I've never once even considered the fact that I might need generics because I've never run into an unsolvable problem or an extremely inelegant engineering solution. I see a lot of people claiming that the lack of generics is a big problem but no one is actually sho…

If you have a []T and you want to apply a function to make it into []K, you need to explicitly make a loop in every case. You might not think that's that bad, but note that T and K could also be interfaces such that T is a superset of K. In that case Go, T can be used as K but []T cannot be used as []K (meaning you have to do an explicit loop for something that should be an implicit type conversion).

That is a trivial example where generics help. And yes, the endless boxing and runtime type assertion does make your code slower eventually (see the comment from the libcuckoo authors).

This is one of the reasons why the container and sort stdlb libraries are such a joke. They're not generic so they have to special case every different type. With generics, the entire sort package would just be a function that takes []Ordinal and sorts it. Container would similarly only require one implementation of each data structure (because they would be generic).

I find it hard to believe that you've programmed "scores of Go" and you've never hit any of these issues. I also have programmed plenty of Go, and these problems are just frustrating.

Re: Toward Go 2

#492

Post by rsc »

dgacmu wrote: post #442

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloate…

Thanks for this. Will followup on email.

Re: Toward Go 2

#493

Post by xargon7 »

dtech wrote: post #391
elliotmr wrote: post #273

Earlier quoted context omitted.

> I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox Interesting read, and I admit there is some of that. But my point isn't to say that those features aren't useful or powerful, but rather that with the constraint of working with a large group of programmers of varying skills, simplicity has more value than power (as long as we can deliver software that…

One of the problems is who decides what is too simple. E.g. why are for loops, function calls and lamdbas considered simple enough to be in go, but generics aren't? When I TA'ed CS introductory courses, student usually had a lot less trouble with understanding generics than lambdas. Not including feature X in programming language Y will also ensure that no-one who primarily uses Y will ever come to understand or appr…

The complexity from generics isn't from the conceptual standpoint, it's from the resulting code standpoint... for the same reason that the ternary ?: operator is "too complex": it's really easy to say that `foo := cond ? 1 : 0` is better than the if/else alternative, but `foo := (a > (b.Active() ? Compare(b, a) : useDefault() ? DEFAULT : panic()) ? "worked" : "failed"` is a mess waiting to happen.

Same with generics. It's easy to point to simple examples. It hard to ensure that terrible metaprogramming monstrosities don't arise.

It's possible to write bad code with go as it is, but it's actually difficult to make such bad code inscrutable.

Re: Toward Go 2

#494

Post by bboozzoo »

grogenaut wrote: post #421
tsuraan wrote: post #364

Earlier quoted context omitted.

Have you used erlang? Pattern matching is a big part of it, and pattern match failures always result in errors. So, if you have some function foo() that always returns ok or {error, Reason}, then in the "follow the happy path" style, you'd just have a line reading "ok = foo(),", and then if foo actually returns something else, you get a "crash". There's no assuming anything there, it's just the way the language works…

Yes I have. but I see the erlang blindness still runs strong. Just because you have pattern matching doesn't mean you don't have bugs cause by humans. It can be syntactically correct and also logically not match the problem domain. For example what if you screw up and forget to encode that it SHOUDN'T return OK? you know that many other frameworks also have these safeguards right? Java server frameworks have been doi…

Logical errors are always an issue, regardless of the language.

As for Erlang's problems, it does have a fair number of warts and special cases, but the biggest of them all is that it's still a niche language. We actually had to dump Erlang for new projects in favor of Go. That may sound ridiculous, but filling positions involving Erlang was next to impossible (even with candidates without any prior knowledge of the language).

Re: Toward Go 2

#495

Post by ramenmeal »

aaronblohowiak wrote: post #456
dgacmu wrote: post #442

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost. (1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloate…

please do send that to rsc

Care to explain?

Re: Toward Go 2

#497

Post by grey-area »

liveoneggs wrote: post #125
stormbrew wrote: post #31

Earlier quoted context omitted.

If I were in the "go community" I would be pretty annoyed by this quote. I would find it dismissive of the literal years of people pointing at areas of their code that are bloated and less safe due to not having generics. It doesn't seem to me that there's a shortage of people pointing out real-world use cases at all, and I'm looking from the outside in.

the use of the monotonic click example is also interesting because of the similar tone of responses to that issue. I think it's just the rsc way. basically it goes like: > If google isn't screaming about it, it's not important. > If google has a workaround, then it's fixed.

As a maintainer, you're bombarded with reasonable requests (I think around 10 a day on the Go project). Part of your job is to turn down hundreds of these and pick the few that benefit the most people from a diverse set of users, and also don't break anything or extend the api surface too much. Then whatever you choose people complain vociferously. Sometimes good requests get ignored in that noise.

Choosing is hard, and while they could improve I think the Go maintners have done a pretty good job, and are willing to admit mistakes.

Re: Toward Go 2

#498

Post by herewego- »

treehau5 wrote: post #412
43224gg252 wrote: post #321

Earlier quoted context omitted.

Then why don't you come up with a legitimate use case?

I think this is a fair question. We have a lot of pseudo-intellectuals here that think 90% of their job isn't writing business functions. Not having generics in Go has not hindered me at all in performing the objectives of my business. Everyone wants generics, no one knows why. When I had generics in my previous two roles where I used Java and C# respectively, I can count on two fingers the number of times I needed t…

I am another developer who has never really suffered as a result of a lack of generics. Personally I really like how dead easy golang code is to read and understand. God forbid golang become a language where untold amounts of logic can be packed into a single line of code, resulting in near mathematical levels of complexity which always require more time to understand. Like most complex concepts in life, I suspect the number of developers who can effectively use these tools is rather small compared to the number of people who think they "need" them. But hey, I'm a vim programmer who doesn't like to have to rely on a bloated IDE to be able to deal with the code that I am interacting with so I might be a minority.

Re: Toward Go 2

#499

Post by herewego- »

treehau5 wrote: post #140
solomatov wrote: post #18

Earlier quoted context omitted.

I would start using Go in my projects if it introduces generics. It's a show stopper for me.

Conversely, I would stop using Go in my projects if it introduces generics. If Go wants to be more sophisticated, there are other sophisticated languages I can use out there like Haskell, Rust, F#, Scala, etc. The problem I have learned in my career is "sophistication" usually gets in the way of getting things done because now you have all these clever developers full of hubris creating these novel implementations th…

Parsimony is king.

Re: Toward Go 2

#500

Post by herewego- »

cyphar wrote: post #491
43224gg252 wrote: post #378

Earlier quoted context omitted.

I've programmed scores of libraries in Go and found it pleasant, in fact it's more pleasant writing a library in Go than in any other language I've used. I've never once even considered the fact that I might need generics because I've never run into an unsolvable problem or an extremely inelegant engineering solution. I see a lot of people claiming that the lack of generics is a big problem but no one is actually sho…

If you have a []T and you want to apply a function to make it into []K, you need to explicitly make a loop in every case. You might not think that's that bad, but note that T and K could also be interfaces such that T is a superset of K. In that case Go, T can be used as K but []T cannot be used as []K (meaning you have to do an explicit loop for something that should be an implicit type conversion). That is a trivia…

Been using it for years now in a setting with lots of data and never had any problems.
Post reply on HN