Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LINQ in golang as part of standart library #32926

Closed
Hedgehogues opened this issue Jul 3, 2019 · 1 comment
Closed

LINQ in golang as part of standart library #32926

Hedgehogues opened this issue Jul 3, 2019 · 1 comment

Comments

@Hedgehogues
Copy link

Hedgehogues commented Jul 3, 2019

What version of Go are you using (go version)?

go1.12

Does this issue reproduce with the latest release?

No

What operating system and processor architecture are you using (go env)?

Ubuntu18.04

What did you do?

I have a question about linq. Why is golang still not in the standard of this wonderful thing. All that I have heard so far on this technology from gophers is that it is not goffer. Unfortunately, this argument fades when you need to make a couple of groupings, and then another couple of projections. As a result, 3-4 lines are transformed 3-4 screens. In my opinion the choice is obvious. Yes, there are problems. For example, to implement LINQ, you will most likely need to reflect, which will lead to a decrease in performance. But at the same time, we should not forget that with the same success, we can say that the reflector itself also leads to the fact that productivity sinks. So let's give it up. Of course, nobody will do that. The question is where to use this or that technology correctly.

By the way, there is an analogue of reflect. This is static code generation. For example, some non-standard packages are implemented in golang for working with json.

For acquaintance with LINQ technology in go, I provide link.

@bcmills
Copy link
Contributor

bcmills commented Jul 3, 2019

See https://golang.org/doc/faq#x_in_std.

This issue in its current form does not have enough detail to be a proposal.

If you want to describe a general area for improvement, please add an experience report instead.

Otherwise, please describe the specific changes you would like to see, including the motivation or background (including a compelling reason why the API must be in the standard library instead of a third-party module), specific API signatures, and concrete examples (ideally drawn from experience reports).

@bcmills bcmills closed this as completed Jul 3, 2019
@golang golang locked and limited conversation to collaborators Jul 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants